AI-translated from English; not yet reviewed by a fluent editor. # O caminho de decodificação do Kimi K3 no vLLM chega a 842 tokens por segundo em um teste específico com GB300 > O vLLM informa 842 contra 488 tokens de decodificação agregados por segundo para o Kimi K3 em 16 GPUs GB300 com uma configuração DSpark específica. O pré-preenchimento fica de fora. 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. O vLLM incorporou um caminho de decodificação opcional e específico para o Kimi K3 em GPUs NVIDIA Blackwell. Em seu [relato de 16 de outubro](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel), o projeto informa 842 tokens gerados por segundo contra 488 no vLLM padrão, um ganho de 1.73×. Essa comparação tem um escopo restrito: uma solicitação por vez, paralelismo de tensores em 16 GPUs GB300, decodificação especulativa DSpark com sete tokens de rascunho, comprimento de aceitação sintética de seis, entrada de um token e saída de 1000 tokens. O número mede a vazão agregada de decodificação depois do pré-preenchimento. Não mede a rapidez com que uma solicitação completa do usuário termina. Para os engenheiros que decidem se devem avaliar esse caminho, o avanço útil é a combinação de um resultado significativo de decodificação com uma explicação bastante clara de onde ele se aplica. A [implementação incorporada](https://github.com/vllm-project/vllm/pull/61867) é ativada por opção por meio de `decode_backend: latency_specialized`; a configuração padrão `auto` continua usando a decodificação original. Segundo o vLLM, o caminho especializado tem como alvo implantações GB300 com oito ou 16 GPUs em um único domínio NVLink, enquanto pré-preenchimentos, lotes mistos e etapas sem suporte retornam ao caminho padrão de propagação direta do modelo. ## Onde o tempo era gasto O Kimi K3 é um grande modelo de mistura de especialistas, segundo seu [cartão do modelo](https://huggingface.co/moonshotai/Kimi-K3). Durante a decodificação, um sistema de inferência executa repetidamente a atenção, escolhe especialistas e troca dados entre GPUs para produzir os próximos tokens. A equipe do vLLM criou um caminho em CuTe DSL que especializa essas operações para os formatos de tensores esperados. Seu relato descreve diferentes kernels de projeção da atenção para lotes pequenos e maiores; fusão da projeção de saída da atenção, da redução entre GPUs e do trabalho residual seguinte; cálculos do roteador particionados; sobreposição entre especialistas compartilhados e roteados; e pré-busca de pesos durante a comunicação. Em um rastreamento por camada mostrado na publicação, o caminho especializado usa 13 kernels e 69 microssegundos, enquanto o vLLM padrão usa 23 kernels e 130 microssegundos. É um rastreamento relatado para a configuração ilustrada, não uma medida de latência da aplicação. O escopo importa tanto quanto o projeto dos kernels. O [pull request](https://github.com/vllm-project/vllm/pull/61867) descreve a validação em GB300 com TP8 e TP16, decodificação não especulativa até o lote 64, verificação DSpark com três a sete tokens de rascunho e paralelismo de contexto de decodificação opcional. Afirma que o trabalho de desempenho usou cache KV FP8, cache SSM FP32 e pesos do fornecedor do modelo. O caminho não altera pesos do modelo, escalonamento, amostragem nem o gerador de rascunhos do DSpark. Isso permite que uma equipe de inferência compare uma implementação de decodificação modificada com o restante da pilha tecnológica já conhecido, mas também significa que a otimização não acelera todas as partes do serviço. ## Leia as duas tabelas de benchmark separadamente O resultado de 842 contra 488 usa **TP16 em 16 GPUs GB300, lote 1, DSpark com sete tokens de rascunho, comprimento de aceitação sintética seis, DL=7, ISL=1 e OSL=1k**. O vLLM chama a métrica de tokens de decodificação agregados por segundo e exclui o pré-preenchimento. A aceitação sintética fixa quantos tokens propostos o benchmark aceita; não é uma taxa de aceitação medida nos prompts dos usuários. Uma implantação com outros prompts, comportamento de aceitação, tamanhos de lote ou comprimentos de entrada precisa das próprias medições. A publicação também apresenta uma [tabela sem decodificação especulativa](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#decode-performance-without-speculation). Em TP16, por exemplo, informa 256.4 tokens por segundo no lote 1 e 3606.1 no lote 64, com ganhos de 1.88× e 1.62× em relação às respectivas configurações padrão. Esses são resultados agregados do grupo TP sem decodificação especulativa. Eles não podem ser combinados com o número do DSpark para afirmar uma experiência mais rápida por usuário no lote 64. Outro número da publicação diz respeito ao [AgentX](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#improvement-on-agentx), uma carga de trabalho que reproduz padrões de tráfego de agentes de programação com conteúdo sintético. O vLLM informa uma interatividade P90 de 403.2 contra 223.7 tokens por segundo e por usuário com concorrência um. O resultado otimizado foi executado em **16 GPUs GB300**, enquanto a comparação anterior foi executada em **oito**. Como a quantidade de GPUs muda junto com a implementação, essa comparação de 1.8× não isola a melhoria do caminho de decodificação. O AgentX também inclui contextos mais longos, turnos, pausas e reutilização do cache, então sua métrica responde a uma pergunta diferente da do benchmark de decodificação pura. Há uma pequena divergência entre a publicação pública e a [tabela de desempenho anterior do pull request](https://github.com/vllm-project/vllm/pull/61867): esta última lista 838 contra 489 tokens por segundo para TP16, lote 1, DSpark DL7 e aceitação sintética seis. A comparação de 842 contra 488 da publicação é a fonte do número de 1.73× usado aqui. A tabela anterior é uma evidência útil de uma execução parecida, mas os dois pares não devem ser misturados. O vLLM publicou o código e sua própria validação; a BIG CHANGE não reproduziu nenhuma das duas execuções. ## O que seria necessário para uma avaliação Uma comparação local relevante começaria pelo [PR incorporado e pela configuração declarada](https://github.com/vllm-project/vllm/pull/61867): os mesmos pesos do Kimi K3 fornecidos pelo provedor do modelo, um sistema GB300 com 16 GPUs em um domínio NVLink, TP16, os formatos de cache e a configuração DSpark exata do teste em destaque. Execute o modo padrão `auto` e o modo opcional `latency_specialized` com a mesma carga de trabalho e depois registre a vazão de decodificação separadamente do pré-preenchimento, do tempo até o primeiro token, da vazão de saída e da latência por solicitação. Uma estação de trabalho ou um conjunto menor de GPUs não consegue reproduzir diretamente o resultado principal com 16 GB300. A publicação não estabelece um custo de aluguel para essa configuração. O [relato de validação do PR](https://github.com/vllm-project/vllm/pull/61867) informa verificações numéricas e avaliações do modelo, incluindo AIME25, GPQA-Diamond e um teste MRCR de contexto longo. Também descreve um erro de sincronização encontrado durante o desenvolvimento e variações nos testes de saída longa. Essas verificações dão aos leitores mais elementos para examinar do que um gráfico de velocidade, embora continuem sendo evidências dos responsáveis pela implementação. A equipe de inferência precisa decidir se seu hardware real, processamento em lotes, comprimentos de contexto e aceitação especulativa se aproximam o bastante das configurações suportadas para justificar medir esse caminho opcional no próprio tráfego. ## A grande mudança O caminho Kimi K3 incorporado ao vLLM disponibiliza uma implementação de decodificação em GPU especializada e opcional, com benchmark e histórico de validação documentados. O resultado público de maior destaque é **842 contra 488 tokens de decodificação agregados por segundo, ou 1.73×, com TP16 em 16 GPUs GB300 no lote 1, sete tokens de rascunho do DSpark e comprimento de aceitação sintética seis**. O pré-preenchimento está excluído. A melhoria de um serviço específico depende do hardware desse serviço e da carga de trabalho de suas solicitações completas. ## Fontes e leituras adicionais - [A publicação técnica do vLLM de 16 de outubro](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) explica as mudanças na decodificação e fornece a configuração 842/488, a tabela não especulativa e a comparação AgentX. Os resultados são relatados pelo projeto e pelo colaborador da NVIDIA Benjamin Chislett. - [O pull request vLLM #61867 incorporado](https://github.com/vllm-project/vllm/pull/61867) documenta a configuração opcional, as configurações suportadas, os limites da implementação, a validação e uma tabela DSpark anterior de 838/489. É o registro do código e dos resultados, não uma reprodução independente. - [O cartão do modelo Kimi K3 da Moonshot AI](https://huggingface.co/moonshotai/Kimi-K3) identifica o modelo e os pesos referenciados pela implementação. - [A metodologia AgentX](https://inferencex.semianalysis.com/agentx) descreve a carga de reprodução de tráfego por trás da comparação separada de interatividade. ## Sources - [vLLM, Otimizando profundamente o Kimi K3 no vLLM: avançando com rapidez e responsabilidade (2026-10-16)](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) — Relato técnico de primeira mão e fonte do resultado 842/488, 1.73×. Especifica TP16 em 16 GPUs GB300, lote 1, DSpark DL7, AL6 sintético, ISL1, OSL1k e TPS de decodificação agregados sem pré-preenchimento. Também fornece resultados separados não especulativos e do AgentX. - [Pull request vLLM #61867, decodificação especializada do Kimi K3](https://github.com/vllm-project/vllm/pull/61867) — Implementação incorporada e registro de validação realizada pelos autores. Documenta a configuração opcional final, as configurações suportadas e o retorno ao caminho padrão. A tabela DSpark anterior informa 838/489 em TP16 B1 com AL6 sintético, então esses valores não são combinados com o par do blog. - [Moonshot AI, cartão do modelo Kimi K3](https://huggingface.co/moonshotai/Kimi-K3) — Identifica o modelo e os pesos do provedor do modelo; não comprova de forma independente o desempenho do vLLM. - [InferenceX, Metodologia e Conjuntos de Dados do AgentX](https://inferencex.semianalysis.com/agentx) — Descreve a carga de reprodução de tráfego usada na comparação de interatividade relatada separadamente. A comparação do vLLM também muda a quantidade de GPUs.