DSpark es un método de decodificación especulativa publicado por Novita. Entrenamos y lanzamos especuladores DSpark orientados a producción para Kimi-K2.6 y Kimi-K2.7-Code, los integramos con vLLM y evaluamos cómo su enfoque de borrado paralelo por bloques escala a medida que crece la ventana especulativa.
Los checkpoints están diseñados para hacer que el servicio de Kimi sea más rápido sin cambiar el modelo objetivo. Un modelo borrador ligero propone un bloque de tokens candidatos, y el modelo Kimi completo verifica esos candidatos antes de que sean aceptados.
En nuestras evaluaciones nocturnas de vLLM con tamaño de lote 1, DSpark con num_speculative_tokens=7 logró una aceleración promedio de rendimiento de 2.55x para Kimi-K2.6 y 2.36x para Kimi-K2.7-Code. A medida que la ventana especulativa aumentaba de n=3 a n=7, DSpark convirtió los tokens borrador adicionales en rendimiento de manera más consistente que las líneas base Eagle3-MLA disponibles.
Los checkpoints publicados son:
- novita/kimi-k2.6-dspark para Kimi-K2.6
- novita/kimi-k2.7-code-dspark para Kimi-K2.7-Code
Resultados de benchmark de DSpark para Kimi-K2.6 y Kimi-K2.7-Code
Con tamaño de lote 1, aumentar num_speculative_tokens de 3 a 7 elevó la aceleración promedio de DSpark de 2.17x a 2.55x para Kimi-K2.6 y de 2.12x a 2.36x para Kimi-K2.7-Code. Las líneas base Eagle3-MLA listadas se mantuvieron casi planas en promedio.
| Modelo objetivo | Modelo borrador | Aceleración promedio n=3 | Aceleración promedio n=7 | Cambio desde 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% |
Estos valores son promedios simples y no ponderados de las aceleraciones a nivel de benchmark en GSM8K, MATH500, AIME, HumanEval, LiveCodeBench y SPEED-Bench Coding; no están ponderados por cantidad de prompts. Una ventana de borrador más grande no mejora automáticamente el rendimiento: las propuestas adicionales deben ser aceptadas con suficiente frecuencia para compensar la sobrecarga de borrado y verificación.
LiveCodeBench hace concreta la diferencia. Para Kimi-K2.6, DSpark pasó de 1.86x en n=3 a 1.87x en n=7, mientras que Eagle3-MLA cayó de 1.67x a 1.48x. Para Kimi-K2.7-Code, DSpark aumentó de 1.75x a 1.78x, mientras que Eagle3-MLA cayó de 1.69x a 1.52x. En SPEED-Bench Coding, DSpark aumentó de 2.19x a 2.41x para Kimi-K2.6 y de 2.15x a 2.31x para Kimi-K2.7-Code.
Configuración de evaluación: tamaño de lote 1, decodificación especulativa nocturna de vLLM en línea, decodificación voraz, TP=8, max_model_len=20000, gráficos CUDA habilitados y fuse_allreduce_rms=false. Mayores tokens/segundo y aceleración son mejores. El tamaño de lote 1 aísla el comportamiento de decodificación de una sola solicitud; los resultados pueden diferir bajo lotes continuos o cargas de trabajo de producción con mayor concurrencia. Los resultados completos están disponibles en las páginas de Hugging Face para Kimi-K2.6 DSpark y Kimi-K2.7-Code DSpark.
Por qué DSpark mejora la decodificación especulativa de Kimi
Nuestros checkpoints aplican DSpark a Kimi-K2.6 y Kimi-K2.7-Code como modelos borradores para el servicio de vLLM.
En relación con el backbone de borrado paralelo DFlash, DSpark añade dos cabezas ligeras: una cabeza de sesgo de logits de Markov para la dependencia de tokens intra-bloque de bajo rango, y una cabeza de confianza por posición para la predicción de aceptación. DSpark propone el bloque borrador completo en paralelo, luego utiliza estas cabezas para mejorar la calidad del borrador a nivel de bloque y estimar qué posiciones es probable que el verificador acepte.
Entrenamos los modelos borradores con un fork modificado del framework Speculators de vLLM. Durante el entrenamiento, el borrador consume estados ocultos transmitidos desde un verificador Kimi en vivo ejecutándose en vLLM, alineando el especulador con el comportamiento del verificador que encontrará en tiempo de servicio.
Nuestras tablas publicadas utilizan los checkpoints de código abierto Eagle3-MLA disponibles como líneas base de modelos borradores bajo la misma configuración de verificador y servicio. El resultado central es cómo los métodos escalan con una ventana especulativa más grande: de n=3 a n=7, la aceleración promedio de DSpark aumentó un 17.8% para Kimi-K2.6 y un 11.7% para Kimi-K2.7-Code, mientras que las líneas base Eagle3-MLA listadas se mantuvieron casi planas en promedio y se ralentizaron en ambas evaluaciones de LiveCodeBench. Esto sugiere que DSpark preserva la calidad del borrador de manera más efectiva a medida que la ventana crece. La comparación es específica para los checkpoints, la carga de trabajo de tamaño de lote 1 y la configuración de servicio probados aquí.
Cómo servir Kimi-K2.7-Code con DSpark en vLLM
El soporte de DSpark actualmente requiere una compilación nocturna de vLLM. Para Kimi-K2.7-Code, use la siguiente configuración de decodificación 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 Kimi-K2.6, use la misma configuración y apunte speculative_config.model a novita/kimi-k2.6-dspark.
Advertencias conocidas de la compilación nocturna: La programación AOT de FA3 en el lado del borrador puede requerir pasar fast_build=True al construir metadatos de atención del borrador, y la captura de gráficos CUDA puede encontrar un error de tamaño de espacio de trabajo de reducción total de FlashInfer. La configuración probada deshabilita fuse_allreduce_rms; consulte las páginas de Hugging Face vinculadas para las soluciones actuales.
DSpark cambia la ruta de decodificación sin cambiar el modelo Kimi objetivo. Recomendamos comenzar con num_speculative_tokens=7, luego validar el rendimiento, la longitud aceptada, la latencia entre tokens y la latencia de extremo a extremo frente al tráfico de producción representativo. La mejor configuración dependerá de la forma de la carga de trabajo, el lotes y el hardware de servicio.
