Edición en Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# La ruta de decodificación de Kimi K3 en vLLM alcanza 842 tokens por segundo en una prueba concreta con GB300

> vLLM informa de 842 frente a 488 tokens de decodificación agregados por segundo para Kimi K3 en 16 GPU GB300 con una configuración DSpark concreta. Se excluye el prefill.

By BIG CHANGE Editorial

Published: 2026-10-18T20:03:34.885Z
Updated: 2026-10-18T20:03:34.885Z
Canonical: https://bigchange.ai/blog/kimi-k3-vllm-gpu-inference-benchmark

![Conceptual charcoal illustration of the rear of a generic compute cabinet with rack units and secured cables in a data-center aisle.](https://bigchange.ai/api/media/file/kimi-k3-decode-cabinet-concept-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual GB300 chassis, vLLM installation or measured result is depicted.

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](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel), 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](https://github.com/vllm-project/vllm/pull/61867) 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](https://huggingface.co/moonshotai/Kimi-K3). 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](https://github.com/vllm-project/vllm/pull/61867) 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](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#decode-performance-without-speculation). 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](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#improvement-on-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](https://github.com/vllm-project/vllm/pull/61867): 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](https://github.com/vllm-project/vllm/pull/61867): 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](https://github.com/vllm-project/vllm/pull/61867) 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

- [La publicación técnica de vLLM del 16 de octubre](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) explica los cambios en la decodificación y aporta la configuración 842/488, la tabla no especulativa y la comparación AgentX. Los resultados los comunican el proyecto y Benjamin Chislett, colaborador de NVIDIA.
- [La solicitud de cambios de vLLM #61867 ya integrada](https://github.com/vllm-project/vllm/pull/61867) documenta la activación opcional, las configuraciones compatibles, los límites de la implementación, la validación y una tabla DSpark anterior de 838/489. Es el rastro del código y los resultados, no una réplica independiente.
- [La ficha del modelo Kimi K3 de Moonshot AI](https://huggingface.co/moonshotai/Kimi-K3) identifica el modelo y los pesos a los que se refiere la implementación.
- [La metodología AgentX](https://inferencex.semianalysis.com/agentx) describe la carga de reproducción de tráfico de la comparación separada de interactividad.

## Sources

- [vLLM, Hiperoptimizar Kimi K3 en vLLM: avanzar rápido y con responsabilidad (2026-10-16)](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) — Descripción técnica de primera mano y fuente del resultado 842/488 y 1.73×. Especifica TP16 en 16 GPU GB300, lote 1, DSpark DL7, AL6 sintética, ISL1, OSL1k y TPS de decodificación agregados sin prefill. También aporta resultados distintos no especulativos y de AgentX.
- [Solicitud de cambios de vLLM #61867, decodificación especializada de Kimi K3](https://github.com/vllm-project/vllm/pull/61867) — Implementación integrada y registro de validación realizada por los autores. Documenta la activación opcional final, las configuraciones compatibles y la ruta alternativa. Su tabla DSpark anterior indica 838/489 con TP16 B1 y AL6 sintética, de modo que no se combinan esas cifras con el par de la publicación.
- [Moonshot AI, ficha del modelo Kimi K3](https://huggingface.co/moonshotai/Kimi-K3) — Identifica el modelo y los pesos del proveedor; no establece de forma independiente el rendimiento de vLLM.
- [InferenceX, metodología y conjuntos de datos de AgentX](https://inferencex.semianalysis.com/agentx) — Describe la carga de reproducción de tráfico usada en la comparación de interactividad publicada por separado. La comparación de vLLM también cambia el número de GPU.