vLLM supera a SGLang en prompts de 64K tokens, pero SGLang toma la delantera una vez que el contexto alcanza los 200K en un servidor B300 con 8 GPUs. El cambio demuestra cómo los cuellos de botella en la etapa de decodificación (decode), y no el prellenado (prefill), dictan el rendimiento a medida que las ventanas de tokens se expanden.
Por qué es importante este benchmark
La inferencia de contexto largo impulsa los costes para los asistentes de chat, asistentes de código y cualquier aplicación que deba mantener cientos de miles de tokens en memoria. Kimi-K3, un modelo de gran cantidad de parámetros, es uno de los primeros LLM de pesos abiertos (open-weight) que puede manejar cómodamente tales ventanas, pero el motor que lo ejecuta decide si una solicitud termina en segundos o en minutos.
Tanto vLLM como SGLang prometen una inferencia de alto rendimiento (high-throughput), pero adoptan enfoques opuestos para la etapa de decodificación. vLLM mantiene simple la ruta de decodificación, evitando la sincronización adicional que introduce el Paralelismo de Contexto de Decodificación (DCP, por sus siglas en inglés). SGLang distribuye las lecturas de la caché de clave-valor (KV) entre múltiples GPUs utilizando DCP, una técnica que puede amortizar el ancho de banda de la memoria a costa de una mayor comunicación.
El entorno de pruebas
- Hardware: un único servidor con ocho GPUs NVIDIA B300, cada una con la misma memoria.
- Cargas de trabajo: dos configuraciones de longitud de contexto: 64K tokens (el límite inferior de "contexto largo") y 200K tokens (el límite superior que muchos demos de investigación buscan).
- Métricas: tiempo total para procesar un lote (batch) fijo de prompts; el rendimiento (throughput) se deriva de la diferencia de tiempo.
Mantuvimos constantes el tamaño del lote, los pesos del modelo y los objetivos de utilización de memoria. El único parámetro que cambiamos entre ejecuciones fue el motor de inferencia.
Los números en juego
| Contexto | Motor | Tiempo (s) | Velocidad relativa |
|---|---|---|---|
| 64 K | vLLM | 100.5 | – |
| SGLang | 150.8 | vLLM ≈ 1.5× más rápido | |
| 200 K | vLLM | 295.2 | – |
| SGLang | 225.3 | SGLang ≈ 1.31× más rápido |
El rendimiento (tokens por segundo) cayó drásticamente para vLLM cuando el contexto creció: una caída de 3.29× de 64K a 200K. El rendimiento de SGLang disminuyó solo 1.25× en el mismo rango.
De dónde viene la brecha
Ambos motores pasan una cantidad similar de tiempo en la etapa de prellenado (prefill): cargar el prompt en la caché KV. La divergencia aparece en la etapa de decodificación, donde el modelo genera tokens uno por uno.
- 64K tokens: la comunicación entre GPUs predomina. La ruta de decodificación de una sola GPU de vLLM evita la sincronización adicional requerida por DCP, lo que le permite terminar aproximadamente 1.5× más rápido.
- 200K tokens: la caché KV crece tanto que leerla se convierte en el cuello de botella. El DCP de SGLang, configurado con un tamaño de 8, distribuye esas lecturas entre las ocho GPUs. La ganancia de ancho de banda compensa la penalización de comunicación, otorgando a SGLang una ventaja clara.
Una observación secundaria y práctica concierne a la presión de la memoria. Ejecutar cualquiera de los motores con un objetivo de utilización de memoria de 0.95 provocó reintentos por falta de memoria (OOM) en las B300. Reducir el objetivo a 0.92 eliminó los reintentos y estabilizó los tiempos de ejecución, a costa de un modesto aumento en la latencia.
Quién gana y quién pierde
- Desarrolladores con contextos cortos a medios (≤ 64K tokens) obtienen más provecho de la ruta de decodificación ligera de vLLM. Un tiempo de respuesta más rápido se traduce en facturas de computación en la nube más bajas y ciclos de experiencia de usuario más ágiles.
- Equipos que construyen herramientas de investigación o de análisis profundo que necesitan mantener cientos de miles de tokens en contexto deberían inclinarse por SGLang con DCP habilitado. Su rendimiento más estable reduce el riesgo de tiempos de espera (time-outs) y mantiene una mayor utilización de la GPU a medida que aumentan las demandas de memoria.
- Planificadores de hardware: observan que el número bruto de GPUs por sí solo no garantiza un escalado lineal. Cuando el ancho de banda de la caché KV se convierte en el punto de estrangulamiento, las arquitecturas que puedan paralelizar las lecturas de la caché —ya sea mediante DCP o futuras actualizaciones del subsistema de memoria— extraerán más valor del mismo silicio.
Contrapunto: ¿puede vLLM cerrar la brecha?
Hasta que aparezcan nuevos datos, las cifras actuales se mantienen como la mejor comparación pública.
Qué observar a continuación
- Ventanas de contexto más grandes estresarán aún más el ancho de banda de la caché KV, lo que podría ampliar la ventaja de SGLang.
Conclusión
Cuando necesite atender solicitudes de contexto largo en un clúster basado en B300, elija el motor que se adapte a su ventana de tokens. Para cargas de trabajo de 64K tokens, vLLM ofrece una inferencia aproximadamente 1.5× más rápida. Si supera los 200K tokens, la decodificación impulsada por DCP de SGLang se convierte en la opción más eficiente, con una caída de rendimiento de 1.25× en comparación con la caída de 3.29× de vLLM. Ajuste la utilización de la memoria a 0.92 para evitar reintentos por OOM, y recuerde que el "mejor" motor depende del contexto y no es una solución única para todos.