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, 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 é 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. 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 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. 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, 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: 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: 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 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 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 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 identifica o modelo e os pesos referenciados pela implementação.
  • A metodologia AgentX descreve a carga de reprodução de tráfego por trás da comparação separada de interatividade.