Google Cloud publicó el 5 de septiembre de 2026 un benchmark que muestra por qué las decisiones de infraestructura para modelos de lenguaje no pueden basarse únicamente en el tamaño del modelo. El estudio compara Gemma 3 12B y Gemma 3 27B en Google Cloud TPU v6e, con diferencias claras entre una tarea de clasificación y otra de generación de texto.
La misma TPU afronta dos cargas muy diferentes
Las pruebas se ejecutaron en Google Kubernetes Engine Autopilot, con un grupo de nodos TPU v6e de un solo host configurado en una topología de 2x2 chips. El servicio utilizó vLLM mediante el plugin vllm-project/tpu-inference. Google Cloud midió ambas cargas con 16, 32, 64 y 128 usuarios simultáneos.
La clasificación empleó unos 4.000 tokens de entrada y aproximadamente 10 tokens de salida para un caso de cumplimiento normativo en comercio electrónico. La generación partió de un prompt mucho más corto, de 500 tokens de entrada, pero produjo unos 1.000 tokens de salida para un informe analítico sobre políticas públicas y el futuro de la IA en el mercado laboral.
La diferencia no es un detalle de la prueba. La clasificación representa una entrada extensa seguida de una respuesta breve, mientras que la generación exige producir una salida mucho más larga por solicitud. Al aumentar la concurrencia, esa relación entre entrada, salida y número de usuarios modifica las exigencias sobre la capacidad del sistema.
Google Cloud mantuvo constantes varios ajustes importantes del servicio: max-model-len=128000, max-num-batched-tokens=8192 y max-num-seqs=512. Por eso, las cifras describen el comportamiento de los modelos dentro de ese marco operativo concreto y no una clasificación universal de Gemma 3 12B frente a Gemma 3 27B.
La generación separa más a los dos modelos
Con 128 usuarios simultáneos en la prueba de generación, Gemma 3 12B alcanzó un multiplicador de rendimiento normalizado de 8,19x. La referencia era el mismo modelo, Gemma 3 12B, con 16 usuarios. Gemma 3 27B llegó a 4,12x en esa comparación. En esta carga, el modelo de mayor tamaño obtuvo aproximadamente la mitad del resultado relativo de escalado del modelo más pequeño.
La clasificación ofreció un contraste mucho más estrecho con la misma concurrencia. Gemma 3 12B alcanzó 6,37x y Gemma 3 27B llegó a 6,04x. El resultado no demuestra que Gemma 3 12B sea siempre más rápido. Sí muestra que la carga de trabajo puede cambiar lo suficiente el panorama de capacidad como para alterar la diferencia aparente entre ambos tamaños.
La latencia decide si esa capacidad resulta utilizable
El rendimiento no fue la única variable relevante. En la clasificación con Gemma 3 12B, la latencia normalizada de extremo a extremo pasó de 0,99x con 32 usuarios a 1,79x con 64 usuarios y alcanzó 2,90x con 128 usuarios. Google Cloud advierte de que la saturación del hardware puede provocar fuertes aumentos de latencia y el abandono silencioso de solicitudes.
Para un equipo que dimensiona un servicio de IA, el compromiso práctico está entre atender más trabajo y conservar un tiempo de respuesta predecible. Un rendimiento normalizado más alto con mucha concurrencia no implica necesariamente una mejor experiencia si la latencia crece con rapidez o algunas solicitudes terminan abandonándose.
El alcance del benchmark es concreto: Gemma 3 12B y Gemma 3 27B, TPU v6e, el servicio con vLLM y las cargas de trabajo descritas. Otros prompts, modelos, topologías de hardware o patrones de tráfico requerirían mediciones independientes. Las cifras sirven para orientar esa evaluación, pero no sustituyen una prueba ajustada al servicio que cada equipo pretende desplegar.
La conclusión operativa es directa: clasificación y generación deben evaluarse por separado al dimensionar un servicio de LLM. El rendimiento ayuda a entender cómo escala el sistema bajo carga; la curva de latencia determina si esa capacidad sigue siendo útil para las personas que realizan las solicitudes.