O DSpark é um método de decodificação especulativa publicado pela Novita. Treinamos e disponibilizamos especuladores DSpark orientados à produção para o Kimi-K2.6 e Kimi-K2.7-Code, os integramos ao vLLM e avaliamos como sua abordagem de rascunho em bloco paralelo escala à medida que a janela especulativa cresce.
Os checkpoints são projetados para tornar a inferência do Kimi mais rápida sem alterar o modelo alvo. Um modelo de rascunho leve propõe um bloco de tokens candidatos, e o modelo Kimi completo verifica esses candidatos antes que sejam aceitos.
Em nossas avaliações noturnas do vLLM com tamanho de lote 1, o DSpark com num_speculative_tokens=7 alcançou um ganho médio de taxa de transferência de 2,55x para o Kimi-K2.6 e 2,36x para o Kimi-K2.7-Code. À medida que a janela especulativa aumentava de n=3 para n=7, o DSpark converteu os tokens de rascunho adicionais em taxa de transferência de forma mais consistente do que as baselines Eagle3-MLA disponíveis.
Os checkpoints disponibilizados são:
- novita/kimi-k2.6-dspark para o Kimi-K2.6
- novita/kimi-k2.7-code-dspark para o Kimi-K2.7-Code
Resultados do benchmark DSpark para Kimi-K2.6 e Kimi-K2.7-Code
Com tamanho de lote 1, aumentar num_speculative_tokens de 3 para 7 elevou o ganho médio do DSpark de 2,17x para 2,55x no Kimi-K2.6 e de 2,12x para 2,36x no Kimi-K2.7-Code. As baselines Eagle3-MLA listadas permaneceram quase planas em média.
| Modelo alvo | Modelo de rascunho | Ganho médio n=3 | Ganho médio n=7 | Mudança em relação a n=3 |
|---|---|---|---|---|
| Kimi-K2.6 | DSpark | 2,17x | 2,55x | +17,8% |
| Kimi-K2.6 | Eagle3-MLA | 2,01x | 2,01x | +0,2% |
| Kimi-K2.7-Code | DSpark | 2,12x | 2,36x | +11,7% |
| Kimi-K2.7-Code | Eagle3-MLA | 2,04x | 2,05x | +0,3% |
Esses valores são médias simples e não ponderadas dos ganhos em nível de benchmark em GSM8K, MATH500, AIME, HumanEval, LiveCodeBench e SPEED-Bench Coding; eles não são ponderados pela contagem de prompts. Uma janela de rascunho maior não melhora automaticamente a taxa de transferência: as propostas adicionais devem ser aceitas com frequência suficiente para compensar a sobrecarga de rascunho e verificação.
O LiveCodeBench torna a diferença concreta. Para o Kimi-K2.6, o DSpark passou de 1,86x em n=3 para 1,87x em n=7, enquanto o Eagle3-MLA caiu de 1,67x para 1,48x. Para o Kimi-K2.7-Code, o DSpark aumentou de 1,75x para 1,78x, enquanto o Eagle3-MLA caiu de 1,69x para 1,52x. No SPEED-Bench Coding, o DSpark aumentou de 2,19x para 2,41x no Kimi-K2.6 e de 2,15x para 2,31x no Kimi-K2.7-Code.
Configuração de avaliação: tamanho de lote 1, decodificação especulativa online no vLLM nightly, decodificação gulosa, TP=8, max_model_len=20000, gráficos CUDA ativados e fuse_allreduce_rms=false. Maior tokens/s e ganho são melhores. O tamanho de lote 1 isola o comportamento de decodificação de requisição única; os resultados podem diferir sob agrupamento contínuo ou cargas de trabalho de produção com maior concorrência. Resultados completos estão disponíveis nas páginas do Hugging Face para Kimi-K2.6 DSpark e Kimi-K2.7-Code DSpark.
Por que o DSpark melhora a decodificação especulativa do Kimi
Nossos checkpoints aplicam o DSpark ao Kimi-K2.6 e Kimi-K2.7-Code como modelos de rascunho para inferência via vLLM.
Em relação ao backbone de rascunho paralelo DFlash, o DSpark adiciona duas cabeças leves: uma cabeça de viés de logits Markov para dependência intra-bloco de baixo rank, e uma cabeça de confiança por posição para previsão de aceitação. O DSpark propõe o bloco de rascunho completo em paralelo e, em seguida, usa essas cabeças para melhorar a qualidade do rascunho em nível de bloco e estimar quais posições o verificador provavelmente aceitará.
Treinamos os modelos de rascunho com um fork personalizado do framework Speculators do vLLM. Durante o treinamento, o rascunho consome estados ocultos transmitidos de um verificador Kimi em execução no vLLM, alinhando o especulador com o comportamento do verificador que encontrará no momento da inferência.
Nossas tabelas publicadas usam os checkpoints Eagle3-MLA de código aberto disponíveis como baselines de modelo de rascunho sob a mesma configuração de verificador e inferência. O resultado central é como os métodos escalam com uma janela especulativa maior: de n=3 para n=7, o ganho médio do DSpark aumentou 17,8% para o Kimi-K2.6 e 11,7% para o Kimi-K2.7-Code, enquanto as baselines Eagle3-MLA listadas permaneceram quase planas em média e desaceleraram em ambas as avaliações do LiveCodeBench. Isso sugere que o DSpark preserva a qualidade útil do rascunho de forma mais eficaz à medida que a janela cresce. A comparação é específica para os checkpoints, carga de trabalho de tamanho de lote 1 e configuração de inferência testados aqui.
Como servir o Kimi-K2.7-Code com DSpark no vLLM
O suporte ao DSpark atualmente requer uma versão nightly do vLLM. Para o Kimi-K2.7-Code, use a seguinte configuração de decodificação especulativa:
uv pip install vllm --extra-index-url https://wheels.vllm.ai/nightly
vllm serve moonshotai/Kimi-K2.7-Code \
--tensor-parallel-size 8 \
--max-model-len 20000 \
--trust-remote-code \
--compilation-config='{"pass_config": {"fuse_allreduce_rms": false}}' \
--speculative-config '{
"model": "novita/kimi-k2.7-code-dspark",
"num_speculative_tokens": 7,
"method": "dspark"
}'
Para o Kimi-K2.6, use a mesma configuração e aponte speculative_config.model para novita/kimi-k2.6-dspark.
Ressalvas conhecidas da versão nightly: O agendamento AOT do FA3 no lado do rascunho pode exigir a passagem de fast_build=True ao construir os metadados de atenção do rascunho, e a captura do gráfico CUDA pode encontrar um erro de tamanho de workspace de all-reduce do FlashInfer. A configuração testada desabilita o fuse_allreduce_rms; consulte as páginas vinculadas do Hugging Face para as soluções alternativas atuais.
O DSpark altera o caminho de decodificação sem modificar o modelo Kimi alvo. Recomendamos começar com num_speculative_tokens=7 e, em seguida, validar a taxa de transferência, o comprimento aceito, a latência entre tokens e a latência ponta a ponta em relação ao tráfego de produção representativo. A melhor configuração dependerá da forma da carga de trabalho, do agrupamento e do hardware de inferência.
