vLLM ha integrado una ruta de decodificación opcional y específica para Kimi K3 en las GPU NVIDIA Blackwell. En su descripción del 16 de octubre, el proyecto informa de 842 tokens generados por segundo frente a 488 con vLLM estándar, una mejora de 1.73×. La comparación tiene límites precisos: una solicitud cada vez, paralelismo de tensores en 16 GPU GB300, decodificación especulativa DSpark con siete tokens de borrador, una longitud de aceptación sintética de seis, una entrada de un token y una salida de 1000 tokens. La cifra mide el rendimiento agregado de decodificación después del prefill. No mide la rapidez con que termina una solicitud completa del usuario.

Para los ingenieros que deciden si evaluar esta ruta, el avance útil es la combinación de un resultado considerable de decodificación con una explicación bastante explícita de dónde se aplica. La implementación integrada se activa de forma opcional mediante decode_backend: latency_specialized; el ajuste predeterminado auto sigue usando la decodificación estándar. vLLM dice que la ruta especializada se dirige a despliegues GB300 con ocho o 16 GPU en un mismo dominio NVLink, mientras que el prefill, los lotes mixtos y los pasos no compatibles recurren a la ruta estándar de propagación hacia delante del modelo.

Dónde se fue el tiempo

Kimi K3 es un modelo grande de mezcla de expertos, según su ficha del modelo. Durante la decodificación, un sistema de inferencia ejecuta repetidamente la atención, elige expertos e intercambia datos entre GPU para producir los siguientes tokens. El equipo de vLLM creó una ruta en CuTe DSL que especializa esas operaciones para las formas de tensores previstas. Su descripción incluye distintos kernels de proyección de atención para lotes pequeños y mayores; la fusión de la proyección de salida de atención, la reducción entre GPU y el trabajo residual posterior; cálculos fragmentados del enrutador; superposición entre expertos compartidos y enrutados; y precarga de pesos durante la comunicación. En una traza por capa mostrada en la publicación, la ruta especializada usa 13 kernels y 69 microsegundos, frente a 23 kernels y 130 microsegundos con vLLM estándar. Es una traza declarada para la configuración ilustrada, no una cifra de latencia de aplicación.

El alcance importa tanto como el diseño de los kernels. La solicitud de incorporación de cambios describe validación en GB300 con TP8 y TP16, decodificación no especulativa hasta lote 64, verificación DSpark con entre tres y siete tokens de borrador y paralelismo de contexto de decodificación opcional. Indica que el trabajo de rendimiento utilizó caché KV en FP8, caché SSM en FP32 y pesos del proveedor del modelo. La ruta no modifica los pesos, la planificación, el muestreo ni el generador de borradores DSpark. Eso permite comparar una implementación de decodificación distinta manteniendo un entorno conocido, pero también significa que la optimización no acelera todas las partes del servicio.

Lea las dos tablas de pruebas por separado

El resultado de 842 frente a 488 utiliza TP16 en 16 GPU GB300, lote 1, DSpark con siete tokens de borrador, longitud de aceptación sintética seis, DL=7, ISL=1 y OSL=1k. vLLM llama a la métrica tokens de decodificación agregados por segundo y excluye el prefill. La aceptación sintética fija cuántos tokens propuestos acepta la prueba; no es una tasa de aceptación medida con las instrucciones de los usuarios. Un despliegue con instrucciones, comportamiento de aceptación, tamaños de lote o longitudes de entrada diferentes necesita su propia medición.

La publicación también ofrece una tabla no especulativa. En TP16, por ejemplo, informa de 256.4 tokens por segundo en lote 1 y 3606.1 en lote 64, con mejoras de 1.88× y 1.62× respecto a las configuraciones estándar correspondientes. Son resultados agregados del grupo TP sin decodificación especulativa. No pueden combinarse con la cifra DSpark para afirmar una experiencia más rápida por usuario en lote 64.

Otra cifra de la publicación se refiere a AgentX, una carga que reproduce patrones de tráfico de agentes de programación con contenido sintético. vLLM informa de una interactividad P90 de 403.2 frente a 223.7 tokens por segundo y usuario con concurrencia uno. El resultado optimizado se ejecutó en 16 GPU GB300, mientras que la comparación anterior se ejecutó en ocho. Como el número de GPU cambia junto con la implementación, esa comparación de 1.8× no aísla la mejora de la ruta de decodificación. AgentX también incluye contextos más largos, turnos, pausas y reutilización de caché, por lo que su métrica responde a una pregunta distinta de la prueba de decodificación pura.

Hay una pequeña discrepancia entre la publicación pública y la anterior tabla de rendimiento de la solicitud de cambios: esta última muestra 838 frente a 489 tokens por segundo para TP16, lote 1, DSpark DL7 y aceptación sintética seis. La comparación de 842 frente a 488 de la publicación es la fuente de la cifra de 1.73× usada aquí. La tabla anterior aporta información útil sobre una ejecución similar, pero no deben mezclarse los dos pares. vLLM ha publicado el código y su propia validación; BIG CHANGE no ha reproducido ninguna de las dos ejecuciones.

Qué necesitaría una evaluación

Una comparación local significativa partiría de la PR integrada y su configuración declarada: los mismos pesos de Kimi K3 del proveedor del modelo, un sistema GB300 con 16 GPU en un dominio NVLink, TP16, los formatos de caché y la configuración DSpark exacta de la prueba destacada. Ejecute el modo estándar auto y el opcional latency_specialized con la misma carga y registre el rendimiento de decodificación por separado del prefill, el tiempo hasta el primer token, el rendimiento de salida y la latencia por solicitud. Una estación de trabajo o un conjunto menor de GPU no puede reproducir directamente la cifra destacada de 16 GB300. La publicación no establece un precio de alquiler para esa configuración.

La descripción de validación de la PR informa de comprobaciones numéricas y evaluaciones de modelos que incluyen AIME25, GPQA-Diamond y una prueba MRCR de contexto largo. También describe un error de sincronización hallado durante el desarrollo y variaciones en las pruebas de salida larga. Estas comprobaciones ofrecen más elementos que inspeccionar que un gráfico de velocidad, aunque siguen siendo pruebas de los implementadores. El equipo que ofrece el servicio debe decidir si su hardware real, la agrupación en lotes, las longitudes de contexto y la aceptación especulativa se parecen lo suficiente a las configuraciones compatibles como para justificar medir esta ruta opcional con su propio tráfico.

El gran cambio

La ruta Kimi K3 integrada en vLLM ofrece una implementación GPU de decodificación especializada y opcional, con una prueba y un historial de validación documentados. La cifra pública más destacada es 842 frente a 488 tokens de decodificación agregados por segundo, o 1.73×, con TP16 en 16 GPU GB300, lote 1, siete tokens de borrador de DSpark y longitud de aceptación sintética seis. Se excluye el prefill. Que mejore un servicio concreto depende del hardware de ese servicio y de la carga completa de sus solicitudes.

Fuentes y lecturas adicionales