한 기술 노트가 텔레메트리로 Gemini 모델을 구분한다고 주장했다

저는 프롬프트와 응답을 보지 않고 두 Gemini 모델을 가른다는 주장에 멈췄습니다. 대상은 Gemini 3.6 Flash와 Gemini 3.1 Pro Preview입니다. 노트가 내세운 방식은 프롬프트와 응답 대신 네트워크에 남는 통신 기록을 보는 것입니다. 저는 대화 내용 바깥에도 모델의 흔적이 남을 수 있다는 점에 멈췄습니다.

Gemini 4 코딩 성능을 두고 구글 내부에서 이견이 나왔던 소식과 연결됩니다. 성능과 모델 식별은 다른 문제지만, Gemini를 둘러싼 수치가 어떤 조건에서 나왔는지 살펴야 한다는 점은 닮았습니다.

대화 내용을 검사하지 않고 모델을 가릴 수 있다는 발상은 반갑습니다. 여러 환경에서 재현된다면, 민감한 응답을 보지 않고도 서비스가 어느 모델로 답하는지 확인할 수 있습니다.

노트는 약 2만5000토큰을 누적한 같은 조건에서 두 모델을 24회 비교했습니다. 노트는 Flash의 24회 정상 상태와 Pro Preview의 17회차 전환을 보고합니다. 전환 때 지연은 24.1초였고, 상태는 임계 깜박임(Critical Flickering)으로 불렸습니다. 이 차이는 인상적이지만, 두 모델과 한 조건의 실험이라는 경계도 선명합니다. 다른 모델이나 문맥·네트워크에서도 유지되는지는 이 설명만으로 확인할 수 없습니다.

같은 요청을 두 모델에 보내 네트워크 기록을 비교하십시오. 한 모델을 고정하고 요청 길이나 네트워크 상태를 하나씩 바꿔 같은 기록을 살펴보십시오. 모델은 그대로인데 판별 결과가 흔들리면, 특징이 운용 조건에도 좌우된다는 뜻입니다.

요청 길이를 바꾸는 시험과 네트워크 상태를 바꾸는 시험 가운데 무엇부터 해 보시겠습니까?