Edição Markdown

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

# A via de descodificação do Kimi K3 no vLLM atinge 842 tokens por segundo num teste específico com GB300

> O vLLM comunica 842 contra 488 tokens de descodificação agregados por segundo para o Kimi K3 em 16 GPU GB300, com uma configuração DSpark específica. O pré-preenchimento fica excluído.

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 integrou uma via de descodificação opcional e específica do Kimi K3 em GPU NVIDIA Blackwell. No seu [relato de 16 de outubro](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel), o projeto comunica 842 tokens gerados por segundo contra 488 no vLLM de base, uma melhoria de 1.73×. A comparação tem um âmbito restrito: um pedido de cada vez, paralelismo de tensores em 16 GPU GB300, descodificaçã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 valor mede o débito agregado de descodificação após o pré-preenchimento. Não mede a rapidez com que termina um pedido completo do utilizador.

Para os engenheiros que decidem se devem avaliar esta via, o avanço útil está na combinação de um resultado expressivo de descodificação com uma descrição bastante explícita de onde se aplica. A [implementação integrada](https://github.com/vllm-project/vllm/pull/61867) é ativada por opção através de `decode_backend: latency_specialized`; a definição predefinida `auto` continua a utilizar a descodificação de base. Segundo o vLLM, a via especializada destina-se a implementações GB300 com oito ou 16 GPU num único domínio NVLink, enquanto o pré-preenchimento, os lotes mistos e os passos não suportados regressam à via normal de propagação para a frente do modelo.

## Onde se gastava o tempo

O Kimi K3 é um grande modelo de mistura de especialistas, segundo a sua [ficha do modelo](https://huggingface.co/moonshotai/Kimi-K3). Durante a descodificação, um sistema de inferência executa repetidamente a atenção, escolhe especialistas e troca dados entre GPU para produzir os tokens seguintes. A equipa do vLLM criou uma via em CuTe DSL que especializa estas operações para as formas de tensores previstas. O 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 GPU e do trabalho residual seguinte; cálculos do router repartidos; sobreposição entre especialistas partilhados e encaminhados; e pré-carregamento de pesos durante a comunicação. Num traço por camada apresentado na publicação, a via especializada utiliza 13 kernels e 69 microssegundos, enquanto o vLLM de base utiliza 23 kernels e 130 microssegundos. Trata-se de um traço comunicado para a configuração ilustrada, não de uma medida da latência da aplicação.

O âmbito importa tanto como o desenho dos kernels. O [pull request](https://github.com/vllm-project/vllm/pull/61867) descreve a validação em GB300 com TP8 e TP16, descodificação não especulativa até ao lote 64, verificação DSpark com três a sete tokens de rascunho e paralelismo de contexto de descodificação opcional. Refere que o trabalho de desempenho utilizou cache KV FP8, cache SSM FP32 e pesos do fornecedor do modelo. A via mantém inalterados os pesos do modelo, o escalonamento, a amostragem e o gerador de rascunhos do DSpark. Isso permite a uma equipa de inferência comparar uma implementação de descodificação alterada com o restante conjunto tecnológico familiar, 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 utiliza **TP16 em 16 GPU 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 à métrica tokens de descodificaçã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 a partir dos pedidos dos utilizadores. Uma implementação com prompts, comportamento de aceitação, dimensões de lote ou comprimentos de entrada diferentes precisa de medições próprias.

A publicação também apresenta uma [tabela sem descodificação especulativa](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#decode-performance-without-speculation). Em TP16, por exemplo, comunica 256.4 tokens por segundo no lote 1 e 3606.1 no lote 64, com melhorias de 1.88× e 1.62× face às respetivas configurações de base. São resultados agregados do grupo TP sem descodificação especulativa. Não podem ser combinados com o número do DSpark para afirmar uma experiência mais rápida por utilizador 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 comunica uma interatividade P90 de 403.2 contra 223.7 tokens por segundo e por utilizador com concorrência um. O resultado otimizado foi executado em **16 GPU GB300**, enquanto a comparação anterior foi executada em **oito**. Como o número de GPU muda juntamente com a implementação, essa comparação de 1.8× não isola a melhoria da via de descodificação. O AgentX também inclui contextos mais longos, turnos, pausas e reutilização da cache, pelo que a sua métrica responde a uma pergunta diferente da do benchmark de descodificação pura.

Existe uma pequena discrepância entre a publicação pública e a anterior [tabela de desempenho do pull request](https://github.com/vllm-project/vllm/pull/61867): esta última indica 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 valor de 1.73× aqui referido. A tabela anterior constitui evidência útil de uma execução semelhante, mas os dois pares não devem ser misturados. O vLLM publicou o código e a 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 com significado começaria pelo [PR integrado e pela configuração nele indicada](https://github.com/vllm-project/vllm/pull/61867): os mesmos pesos do Kimi K3 disponibilizados pelo fornecedor do modelo, um sistema GB300 com 16 GPU num domínio NVLink, TP16, os formatos de cache e a configuração DSpark exata do teste em destaque. Execute o modo de base `auto` e o modo opcional `latency_specialized` com a mesma carga de trabalho e registe o débito de descodificação separadamente do pré-preenchimento, do tempo até ao primeiro token, do débito de saída e da latência por pedido. Uma estação de trabalho ou um conjunto menor de GPU não consegue reproduzir diretamente o resultado em destaque com 16 GB300. A publicação não estabelece um custo de aluguer para essa configuração.

O [relato de validação do PR](https://github.com/vllm-project/vllm/pull/61867) comunica 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. Estas verificações dão aos leitores mais elementos para analisar do que um gráfico de velocidade, embora continuem a ser evidência dos responsáveis pela implementação. A equipa de inferência tem de decidir se o seu hardware real, agrupamento em lotes, comprimentos de contexto e aceitação especulativa se aproximam suficientemente das configurações suportadas para justificar a medição desta via opcional com o seu próprio tráfego.

## A grande mudança

A via Kimi K3 integrada no vLLM disponibiliza uma implementação de descodificação em GPU especializada e opcional, com benchmark e histórico de validação documentados. O resultado público mais destacado é **842 contra 488 tokens de descodificação agregados por segundo, ou 1.73×, com TP16 em 16 GPU GB300 no lote 1, sete tokens de rascunho do DSpark e comprimento de aceitação sintética seis**. O pré-preenchimento fica excluído. A melhoria de um serviço específico depende do hardware desse serviço e da carga de trabalho dos seus pedidos completos.

## 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 alterações na descodificação e fornece a configuração 842/488, a tabela não especulativa e a comparação AgentX. Os resultados são comunicados pelo projeto e pelo colaborador da NVIDIA Benjamin Chislett.
- [O pull request do vLLM #61867, já integrado,](https://github.com/vllm-project/vllm/pull/61867) documenta a definição opcional, as configurações suportadas, os limites da implementação, a validação e uma tabela DSpark anterior de 838/489. É um registo do código e dos resultados, não uma reprodução independente.
- [A ficha do modelo Kimi K3 da Moonshot AI](https://huggingface.co/moonshotai/Kimi-K3) identifica o modelo e os pesos referidos pela implementação.
- [A metodologia AgentX](https://inferencex.semianalysis.com/agentx) descreve a carga de reprodução de tráfego subjacente à comparação separada de interatividade.

## Sources

- [vLLM, Otimizar intensivamente o Kimi K3 no vLLM: avançar depressa e com 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 GPU GB300, lote 1, DSpark DL7, AL6 sintético, ISL1, OSL1k e TPS de descodificação agregados sem pré-preenchimento. Fornece também resultados separados sem descodificação especulativa e com AgentX.
- [Pull request do vLLM #61867, descodificação especializada do Kimi K3](https://github.com/vllm-project/vllm/pull/61867) — Implementação integrada e registo de validação realizada pelos autores. Documenta a definição opcional final, as configurações suportadas e o regresso à via normal. A tabela DSpark anterior indica 838/489 em TP16 B1 com AL6 sintético, pelo que esses valores não são combinados com o par do blogue.
- [Moonshot AI, ficha do modelo Kimi K3](https://huggingface.co/moonshotai/Kimi-K3) — Identifica o modelo e os pesos do fornecedor do modelo; não comprova de forma independente o desempenho do vLLM.
- [InferenceX, Metodologia e Conjuntos de Dados AgentX](https://inferencex.semianalysis.com/agentx) — Descreve a carga de reprodução de tráfego usada na comparação de interatividade comunicada em separado. A comparação do vLLM também altera o número de GPU.