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