La guerra de la inferencia ya no se decide solo por “cuántos tokens por segundo” puede escupir una GPU en un prompt corto. En 2026, el nuevo campo de batalla es el contexto largo: modelos que leen bases de código enteras, mantienen memoria en flujos agénticos y responden con latencia baja mientras el prompt crece hasta tamaños que hace poco parecían inviables en producción.
En ese escenario, LMSYS (el equipo detrás de desarrollos y evaluaciones muy seguidas en el ecosistema de serving) ha publicado resultados de rendimiento de DeepSeek ejecutándose sobre NVIDIA GB300 NVL72 (Blackwell Ultra) comparándolo con GB200 NVL72. Y el mensaje es contundente: en un caso de uso de contexto largo (128.000 tokens de entrada y 8.000 de salida), el sistema alcanza 226,2 TPS/GPU, lo que supone un 1,53× sobre GB200 en el pico de rendimiento. La mejora se vuelve aún más llamativa cuando se mira la experiencia por usuario y la degradación bajo restricciones de latencia, dos puntos críticos para agentes y asistentes de programación.
Un rack completo como unidad de medida (y no una GPU suelta)
GB300 NVL72 no es una tarjeta aislada, sino un sistema a escala de rack: 72 GPUs Blackwell Ultra junto a 36 CPUs Grace, con interconexión pensada para funcionar como una “fábrica” de inferencia. NVIDIA, de hecho, lo presenta como una plataforma diseñada para acelerar atención y razonamiento en escenarios de alta exigencia, donde la memoria y el ancho de banda pasan a ser tan determinantes como el cómputo.
Y es precisamente ahí donde el contexto largo cambia las reglas: el cuello de botella suele desplazarse hacia el KV cache (la memoria que el modelo usa para “recordar” el contexto durante la generación) y hacia la capacidad de HBM (memoria de alto ancho de banda) disponible para sostener más peticiones simultáneas sin expulsar estado.
Qué midió LMSYS y por qué importa
LMSYS evaluó DeepSeek-R1 en un patrón de servicio típico de contexto largo: entrada enorme (ISL 128.000) y salida relevante (OSL 8.000). Para sostener esto, aplicaron técnicas ya consideradas “de manual” en serving moderno, pero afinadas para sacar partido del hardware:
- Prefill-Decode (PD) Disaggregation: separar la fase de prefill (procesar el prompt) de la fase de decode (generar tokens) para evitar que un único nodo se convierta en cuello de botella.
- Dynamic chunking: trocear el prefill en bloques y solapar trabajo para reducir el TTFT (Time To First Token), un indicador que marca si un asistente “se siente” ágil o desesperante.
- MTP (Multi-Token Prediction): una técnica para mejorar rendimiento por usuario sin hundir el throughput agregado, especialmente valiosa cuando se busca respuesta rápida en flujos agénticos.
Los números: pico, por-usuario y escenarios con latencia
En su apartado de “Highlights”, el post de LMSYS resume lo más llamativo: 226,2 TPS/GPU en GB300 sin MTP, frente a 147,9 TPS/GPU en GB200. Con MTP activado, el throughput agregado se mantiene alto, pero el verdadero salto llega en la métrica que más entiende cualquier usuario: la velocidad que percibe cada sesión.
Tabla 1 — Resultados clave (contexto largo 128.000/8.000)
| Métrica | GB300 NVL72 | GB200 NVL72 | Diferencia |
|---|---|---|---|
| Pico sin MTP (TPS/GPU) | 226,2 | 147,9 | 1,53× |
| Con MTP (TPS/GPU) | 224,2 | 169,1 | 1,33× |
| TPS por usuario con MTP (TPS/User) | 43 | 23 | +87% |
LMSYS añade otro dato relevante para producción: cuando iguala condiciones de latencia y ajusta configuraciones comparables, GB300 entrega entre 1,38× y 1,58× más TPS/GPU según el escenario, con mayor ventaja en casos sensibles a latencia (donde el sistema suele degradarse más). En su escenario “latency–throughput balanced”, por ejemplo, la mejora sin MTP llega a 1,58×.
Tabla 2 — Ganancias bajo restricciones de latencia (escenarios representativos)
| Escenario | Sin MTP (GB300 vs GB200) | Con MTP (GB300 vs GB200) |
|---|---|---|
| Alto throughput (latencia relajada) | +38,4% | +44,9% |
| Balance latencia–throughput | 1,58× | 1,40× |
Por qué GB300 gana: más memoria para sostener más sesiones “vivas”
En contexto largo, el sistema no suele estar limitado por “fuerza bruta” de cómputo, sino por cuántas solicitudes simultáneas puede mantener activas en memoria sin replegar estado (retraction). Aquí aparece el factor diferencial que LMSYS menciona de forma explícita: GB300 tiene 1,5× más HBM (288 GB frente a 192 GB), lo que permite subir el batch de decode y soportar más concurrencia con menos penalización.
En otras palabras: no es solo “más rápido”, es más resistente cuando el tráfico real obliga a servir muchas sesiones a la vez y el contexto no cabe en un esquema estrecho.
TTFT: el tiempo hasta el primer token también mejora
El prefill de 128.000 tokens es el momento en el que muchos asistentes se vuelven lentos o “se quedan pensando”. Para atacarlo, LMSYS usa chunking y destaca un mejor caso con 32.000 tokens de chunk dinámico, logrando 8,6 segundos de TTFT. Sin chunking, el TTFT supera los 15 segundos en ambos sistemas, lo que explica por qué estas técnicas han pasado de ser “opcional” a “necesario” en despliegues serios.
Tabla 3 — TTFT en prefill largo (128.000 tokens)
| Configuración | GB300 | GB200 | Nota |
|---|---|---|---|
| Sin chunking | 15,2 s | 18,6 s | Diferencia mayor sin optimización |
| Mejor caso (chunk dinámico 32.000) | 8,6 s | — | Reducción fuerte del TTFT |
El elefante en la sala: energía, costes y el “precio del rack”
La comparación GB300 vs GB200 se centra en rendimiento, pero el mercado siempre termina preguntando por el coste total: energía, amortización y despliegue. Ahí hay dos narrativas paralelas:
- NVIDIA asegura, apoyándose en datos de SemiAnalysis InferenceX y análisis de terceros, que GB300 puede ofrecer hasta 50× más throughput por megavatio y hasta 35× menor coste por token frente a Hopper en ciertos rangos de latencia, y también menciona mejor economía en largo contexto.
- Al mismo tiempo, incluso en medios del sector que celebran el salto de rendimiento se repite la cautela: no hay todavía una foto completa y pública del TCO comparado GB300 vs GB200 en todos los escenarios, y el coste de despliegue de un rack de esta clase no es trivial.
En resumen: los datos de LMSYS indican que Blackwell Ultra entra fuerte en el terreno más “agéntico” (contexto largo y latencia), pero la conversación sobre costes reales se va a decidir con números de factura y disponibilidad, no solo con gráficos.
Preguntas frecuentes
¿Qué significa “contexto largo 128.000/8.000” en inferencia de modelos como DeepSeek?
Que el sistema procesa entradas de hasta 128.000 tokens y genera salidas de hasta 8.000 tokens, un patrón típico en asistentes de programación que leen mucho código antes de responder.
¿Qué es PD Disaggregation (Prefill-Decode) y por qué mejora el rendimiento?
Es una arquitectura que separa el procesamiento del prompt (prefill) de la generación de tokens (decode) en nodos distintos, reduciendo cuellos de botella y mejorando escalabilidad y latencia.
¿Qué aporta MTP (Multi-Token Prediction) en producción?
Según LMSYS, MTP puede mejorar mucho el rendimiento por usuario (TPS/User) manteniendo el throughput global, haciendo que cada sesión reciba respuestas más rápidas sin “robar” capacidad al sistema.
¿Por qué la memoria HBM es tan crítica en el contexto largo?
Porque el KV cache crece con el contexto y, si no cabe, el sistema debe replegar o expulsar estado, degradando latencia y throughput. Más HBM permite más concurrencia real sin penalización.
vía wccftech
