DSparkはNovitaが公開した投機的復号手法です。私たちはKimi-K2.6およびKimi-K2.7-Code向けの本番指向のDSpark投機器をトレーニングしてリリースし、vLLMに統合し、投機ウィンドウの拡大に伴って並列ブロックドラフト手法がどのようにスケーリングするかを評価しました。
チェックポイントは、ターゲットモデルを変更せずにKimiのサービングを高速化するように設計されています。軽量なドラフトモデルが候補トークンのブロックを提案し、完全なKimiモデルがそれらの候補を受け入れる前に検証します。
バッチサイズ1のvLLM nightly評価では、num_speculative_tokens=7のDSparkがKimi-K2.6で平均スループット2.55倍、Kimi-K2.7-Codeで2.36倍の高速化を達成しました。投機ウィンドウがn=3からn=7に増加するにつれ、DSparkは利用可能なEagle3-MLAベースラインよりも一貫して追加のドラフトトークンをスループットに変換しました。
リリースされたチェックポイントは以下の通りです：
- novita/kimi-k2.6-dspark for Kimi-K2.6
- novita/kimi-k2.7-code-dspark for Kimi-K2.7-Code
Kimi-K2.6およびKimi-K2.7-CodeのDSparkベンチマーク結果
バッチサイズ1では、num_speculative_tokensを3から7に増やすと、DSparkの平均高速化率がKimi-K2.6で2.17倍から2.55倍に、Kimi-K2.7-Codeで2.12倍から2.36倍に上昇しました。記載されたEagle3-MLAベースラインは平均してほぼ横ばいでした。
| ターゲットモデル | ドラフトモデル | n=3平均高速化率 | n=7平均高速化率 | 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% |
これらの値は、GSM8K、MATH500、AIME、HumanEval、LiveCodeBench、およびSPEED-Bench Codingにわたるベンチマークレベルの高速化率の単純な未加重平均であり、プロンプト数で重み付けされていません。ドラフトウィンドウが大きいほど自動的にスループットが向上するわけではありません。追加の提案は、ドラフトおよび検証のオーバーヘッドを相殺するのに十分な頻度で受け入れられる必要があります。
LiveCodeBenchはその違いを具体的に示しています。Kimi-K2.6では、DSparkがn=3の1.86倍からn=7の1.87倍に移行したのに対し、Eagle3-MLAは1.67倍から1.48倍に低下しました。Kimi-K2.7-Codeでは、DSparkが1.75倍から1.78倍に増加し、Eagle3-MLAは1.69倍から1.52倍に低下しました。SPEED-Bench Codingでは、DSparkはKimi-K2.6で2.19倍から2.41倍に、Kimi-K2.7-Codeで2.15倍から2.31倍に増加しました。
評価設定： バッチサイズ1、オンラインvLLM nightly投機的復号、グリーディ復号、TP=8、max_model_len=20000、CUDAグラフ有効、fuse_allreduce_rms=false。高いトークン/秒と高速化率が優れています。バッチサイズ1は単一リクエストのデコード動作を分離します。結果はコンティニュアスバッチングや高同時実行の本番ワークロードでは異なる可能性があります。完全な結果は、Kimi-K2.6 DSparkおよびKimi-K2.7-Code DSparkのHugging Faceページで入手できます。
DSparkがKimiの投機的復号を改善する理由
私たちのチェックポイントは、DSparkをKimi-K2.6およびKimi-K2.7-CodeにvLLMサービング用のドラフトモデルとして適用します。
DFlash並列ドラフティングバックボーンに対して、DSparkは2つの軽量ヘッドを追加します。ブロック内の低ランクトークン依存関係のためのマルコフロジットバイアスヘッドと、受入予測のための位置ごとの信頼度ヘッドです。DSparkは完全なドラフトブロックを並列に提案し、これらのヘッドを使用してブロックレベルのドラフト品質を向上させ、検証者が受け入れそうな位置を推定します。
ドラフトモデルは、vLLMのSpeculatorsフレームワークのベンダーフォークを使用してトレーニングしました。トレーニング中、ドラフトはvLLMで実行中のライブKimi検証器からストリーミングされる隠れ状態を消費し、投機器をサービング時に遭遇する検証器の動作に合わせます。
公開された表では、利用可能なオープンソースのEagle3-MLAチェックポイントを、同じ検証器およびサービング構成の下でのドラフトモデルベースラインとして使用しています。中心的な結果は、手法がより大きな投機ウィンドウでどのようにスケーリングするかです。n=3からn=7で、DSparkの平均高速化率はKimi-K2.6で17.8%、Kimi-K2.7-Codeで11.7%増加したのに対し、リストされたEagle3-MLAベースラインは平均してほぼ横ばいで、両方のLiveCodeBench評価で減速しました。これは、DSparkがウィンドウが大きくなるにつれて有用なドラフト品質をより効果的に維持することを示唆しています。この比較は、ここでテストされたチェックポイント、バッチサイズ1のワークロード、およびサービング構成に固有のものです。
vLLMでDSparkを使用してKimi-K2.7-Codeをサービングする方法
DSparkのサポートは現在、vLLM nightlyビルドを必要とします。Kimi-K2.7-Codeには、次の投機的復号設定を使用します：
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"
}'
Kimi-K2.6の場合は、同じ設定を使用し、speculative_config.modelをnovita/kimi-k2.6-dsparkに指定します。
既知のnightlyビルドの注意点： ドラフト側のFA3 AOTスケジューリングでは、ドラフトアテンションメタデータを構築する際にfast_build=Trueを渡す必要がある場合があり、CUDAグラフキャプチャがFlashInfer all-reduceワークスペースサイズエラーに遭遇する可能性があります。テスト済みの設定ではfuse_allreduce_rmsを無効にしています。現在の回避策については、リンクされたHugging Faceページを参照してください。
DSparkはターゲットのKimiモデルを変更せずに復号パスを変更します。num_speculative_tokens=7から始め、代表的な本番トラフィックに対してスループット、受理長、トークン間レイテンシ、エンドツーエンドレイテンシを検証することをお勧めします。最適な設定は、ワークロードの形状、バッチ処理、およびサービングハードウェアに依存します。
