Google Cloud는 9월 4일 15:36 UTC에 TPU v6e에서 분류 및 생성 워크로드를 비교한 벤치마크를 공개했다. 핵심 결론은 다음과 같다. "디코딩 비중이 큰 생성 작업에서 Gemma 3 27B 모델은 64명의 동시 사용자 이후 엄격한 성능 한계에 부딪혀, 128명에서 4.12배의 정규화 처리량 배수로 정체된다. 반면 12B 모델은 8.19배까지 확장된다."
더 아래에 있는 단서
"극단적인 동시성 수준(예: 128명)에서는 평균 처리량에 수학적으로 이상한 급등이 보일 수 있다. … 심각한 자원 제약 아래에서, 잘못 설정된 --max-num-seqs 또는 --max-model-len은 조용한 요청 누락, 클라이언트 연결 시간 초과, 또는 GKE 워커 노드 OOM으로 이어질 수 있다. 이러한 실패한 요청이 즉시 종료되면 세션 지속 시간이 잘못 짧아지고, 처리량 지표가 인위적으로 부풀려질 수 있다. 이 벤치마크의 128명 사용자 데이터 포인트는 클러스터 안정성의 절대 한계를 나타내며, 지속 가능한 생산 지표가 아니라 상한으로 봐야 한다."
검증된 행이 말하는 것
16, 32, 64, 128명 사용자에 대한 생성 표는 Gemma 3 12B가 각각 1.00배 / 1.98배 / 2.96배 / 8.19배, 27B가 1.05배 / 1.97배 / 4.00배 / 4.12배를 기록했다고 보여준다. 게시물이 부인하지 않는 마지막 행인 64명 동시 사용자 시점에서는 더 큰 모델이 더 빠르며, 이는 헤드라인과 정반대다. 전체 "성능 한계" 서사는 사실상 부인된 행에서 나온 두 수치의 비교다.
여기에는 절대 측정치가 없다
모든 셀은 16명 사용자에서의 Gemma 3 12B를 기준으로 한 배수이며, 표의 열 제목은 "Throughput (req/s)"라고 적혀 있다. 어느 곳에도 절대 초당 요청 수 수치는 없다, 그리고 비용 수치도 없다 — 단위경제성에 관한 첫 문장으로 시작하는 게시물인데도 그렇다. 구성은 GKE Autopilot의 2x2 칩 토폴로지를 갖춘 단일 호스트 TPU v6e 노드 풀이며, tpu-inference를 통한 vLLM으로 제공되고, max-model-len=128000, max-num-batched-tokens=8192, max-num-seqs=512 설정을 사용한다.
받아들여진 프레이밍이 잘못 짚은 것
이 수치는 "TPU v6e가 8배를 제공한다"는 식으로 인용될 것이다. 그러나 이는 단일 노드, 단일 서빙 스택, 그리고 발행자가 불안정하며 요청 누락으로 오염됐을 수 있다고 표시한 동시성 수준에서 나온 정규화 배수다. 이 게시물은 이례적으로 솔직하다 — 면책 문구가 바로 그곳에, 완곡한 표현 없이 적혀 있다 — 다만 그 솔직함은 아무도 읽지 않는 문단에 있다. 6.04배에서 6.37배까지의 정점을 같은 128명 사용자 행에서 가져온 분류 표도 같은 문제를 안고 있다.