Google Cloud publicó un benchmark que compara cargas de trabajo de clasificación y generación en TPU v6e a las 15:36 UTC del 4 de septiembre. Su conclusión principal: "Para tareas de generación intensivas en decodificación, el modelo Gemma 3 27B alcanza un estricto límite de rendimiento más allá de 64 usuarios concurrentes, estabilizándose en un multiplicador de rendimiento normalizado de 4,12x con 128 usuarios. En cambio, el modelo de 12B escala hasta un multiplicador de 8,19x."
La salvedad más abajo
"En niveles extremos de concurrencia (por ejemplo, 128 usuarios), puede observar picos matemáticamente anómalos en el rendimiento medio. … Bajo restricciones severas de recursos, una configuración incorrecta de --max-num-seqs o --max-model-len puede provocar caídas silenciosas de solicitudes, timeouts de conexión del cliente o OOM en nodos de trabajo de GKE. Cuando estas solicitudes fallidas terminan de inmediato, acortan falsamente la duración de la sesión y inflan artificialmente las métricas de rendimiento. Los puntos de datos de 128 usuarios de estos benchmarks representan el límite absoluto de estabilidad del clúster y deben tratarse como un techo y no como una métrica de producción sostenible."
Lo que dicen las filas avaladas
La tabla de generación para 16, 32, 64 y 128 usuarios muestra 1,00x / 1,98x / 2,96x / 8,19x para Gemma 3 12B, y 1,05x / 1,97x / 4,00x / 4,12x para 27B. Con 64 usuarios concurrentes —la última fila que la publicación no desautoriza—, el modelo más grande es el más rápido, lo contrario de lo que sugiere el titular. Toda la narrativa del "límite de rendimiento" es una comparación de dos cifras de la fila desautorizada.
Nada de esto es una medición absoluta
Cada celda es un múltiplo de Gemma 3 12B con 16 usuarios, en una tabla cuyo encabezado de columna dice "Throughput (req/s)". No hay ninguna cifra absoluta de solicitudes por segundo, y ninguna cifra de coste —en una publicación cuyo primer párrafo habla de economía unitaria. La configuración es un único grupo de nodos TPU v6e en una topología de chips 2x2 en GKE Autopilot, atendido por vLLM mediante tpu-inference, con max-model-len=128000, max-num-batched-tokens=8192, max-num-seqs=512.
En qué se equivoca el encuadre recibido
Esto se citará como "TPU v6e entrega 8x". Es un múltiplo normalizado, en un nodo, sobre una sola pila de serving, en un nivel de concurrencia que el propio autor califica de inestable y posiblemente alterado por solicitudes descartadas. La publicación es inusualmente honesta —la advertencia está ahí, sin matices— y la honestidad está en el párrafo al que nadie llega. La tabla de clasificación, cuyos picos de 6,04x-6,37x proceden de la misma fila de 128 usuarios, arrastra el mismo problema.