DeepSeek-V4-Pro-DSparkは新モデルではなく投機的デコード用のV4-Pro派生
目次
Hugging Faceに deepseek-ai/DeepSeek-V4-Pro-DSpark が出ていた。
名前だけ見るとDeepSeek V4の新しいPro版に見えるが、モデルカードにははっきり「新モデルではない」と書かれている。
中身は同じDeepSeek-V4-Proチェックポイントに、投機的デコード用の追加モジュールを付けた派生リポジトリだった。
4月に書いたDeepSeek V4 Previewの記事では、1.6T総パラメータ、49Bアクティブ、1Mコンテキスト、CSA+HCAの長文脈アテンションを見た。
DSpark版はその基盤性能を伸ばした発表ではなく、焦点はデコード時のトークン生成をまとめて先読みするための部品にある。
投機的デコードで何を足したのか
投機的デコードは、軽いドラフトモデルが先に複数トークンを提案し、本体モデルがそれを検証して採用する推論手法だ。
1トークンずつ本体を呼ぶより、採用された分だけデコードの待ち時間を縮められる。
品質は本体モデルで検証するため、ドラフト側は「当たりやすく、安く、速い」ことが役割になる。
検証は本体の1回の前向き計算でまとめて行う。
ドラフトが出した候補列を本体に通し、先頭から本体の分布と一致する分だけ採用する。
途中で外れた位置は本体側の出力で1つ埋め直すので、最終的に出てくるトークン列は本体を単体で回したときと同じになる。
速くなるだけで品質は落ちない、というのがこの手法の前提だ。
flowchart TD
A[確定済みトークン列] --> B[DSparkドラフトヘッド<br/>5トークンを一括提案]
B --> C[V4-Pro本体で<br/>5トークンを1回の計算で検証]
C --> D{先頭から<br/>どこまで一致したか}
D -->|全部一致| E[5トークン採用<br/>本体が次の1つを追加]
D -->|途中で外れ| F[一致分だけ採用<br/>外れた位置は本体の出力で訂正]
E --> A
F --> ADeepSeekが参照している DeepSpec は、このドラフトモデルを訓練・評価するためのコードベースだ。
扱うドラフトは3種類で、外部で提案されたEAGLE系のEagle3に、DeepSeek名義のDSparkとDFlashが加わる。
パイプラインはデータ準備・訓練・評価の3段。まず本体モデルでターゲット出力を作り直してキャッシュし、それを教師にしてドラフトを訓練する。
READMEには、小さい Qwen/Qwen3-4B を本体に使うデフォルト例でもターゲットキャッシュが約38TBに達する、と注意書きがある。1.6T級のV4-Proを本体に据えれば当然これより重い。手元で軽く再学習するための道具ではない。
DSpark版V4-Proの config.json には、通常のV4-Proにはない設定が増えている。
| 項目 | DSpark版の値 | 意味 |
|---|---|---|
dspark_block_size | 5 | 一度にドラフトする候補トークン数 |
dspark_target_layer_ids | 58, 59, 60 | 本体側の終盤層から隠れ状態を取る位置 |
dspark_markov_rank | 512 | Markov head側の低ランク表現 |
dspark_noise_token_id | 128799 | ドラフト入力を埋める専用トークン |
inference/model.py では DSparkBlock が mtp.* 名前空間の下に置かれ、forward_spec がドラフト候補、ロジット、confidenceを返す。
本体の終盤層から取った隠れ状態を main_proj でまとめ、ノイズトークンで埋めたドラフト列を作り、5トークン分の候補を生成する流れになっている。
Markov headが直前トークン由来のバイアスを足し、confidence headが候補ごとの採用しやすさを出す。
ファイルサイズはむしろ増えている
Hugging Face APIで見ると、通常の DeepSeek-V4-Pro は usedStorage が約864.8GB、DSpark版は約892.8GBだった。
投機的デコードは推論時の待ち時間を下げるための仕組みで、重みファイルの配布サイズを小さくするものではない。
DSpark版では追加モジュールの分だけストレージは増えている。
モデル本体の条件もV4-Proのままだ。
総パラメータ1.6T、アクティブ49B、最大位置埋め込み1,048,576、MoEエキスパート384個、トークンごとに6エキスパート。
重みはFP8中心で、MoEエキスパートはFP4を使う。
Hugging Faceのパラメータ表示は、V4-Proが約8,616億、DSpark版が約8,895億と出る。公称の1.6Tと桁が合わないが、これは数え方の問題だ。
FP4のエキスパート重みは2つを1バイト（int8）にまとめて格納され、メタデータ上は詰めたあとの要素数で数えられている。
V4-Proの内訳ではint8が約7,864億要素を占め、これを2倍に開くとエキスパートだけで約1.57Tになる。残りのFP8・BF16を足すと、おおよそ公称の1.6Tに届く。
DSpark版で要素数が増えているのも、別モデルになったからではなく、ドラフトヘッドのぶんが上乗せされただけだ。
inference/README.md も、ローカル実行の入り口は軽くない。
まずHugging Face形式の重みをプロジェクト独自形式に変換し、EXPERTS=256、MP=4 の例で torchrun を叩く。
FP8で使う場合は config.json から expert_dtype: "fp4" を外し、変換時に --expert-dtype fp8 を指定する、とある。
個人PCで「DSparkが付いたからV4-Proを触りやすくなった」という話ではない。
V4-Proを置けるGPU構成が先にあり、そのうえでデコード待ち時間を削るための派生だ。
既存のMTPとは別の先読み経路
V4-Proの設定にはもともと num_nextn_predict_layers: 1 がある。これは本体側のMTP（複数トークン予測）で、本体が次トークンを出すついでに先のトークンも当てにいくための1層だ。
DSparkはこれとは別系統の先読みになる。model.py では本体の layers とは独立に self.mtp という ModuleList が用意され、そこに DSparkBlock が並ぶ。
段数は n_mtp_layers という推論側の引数で決まり、config.json には書かれていない（コード上の既定値は1）。
config.jsonに固定されているのは参照先の層のほうだ。dspark_target_layer_ids: [58, 59, 60] の通り、61層あるうちの終盤3層から隠れ状態を引く。
DSparkBlock の main_proj はこの3層ぶんの隠れ状態を連結し（入力次元は dim × 3）、1本にまとめてからドラフト生成へ渡す。
DSparkは単なるサンプリング設定ではない。
終盤3層の隠れ状態を受け取り、専用ブロックで候補を作り、直前トークン由来のバイアスを足すMarkov headと、候補ごとの採用しやすさを出すconfidence headまで持つ。
構造としては「V4-Proを速く回すための外付けドラフトヘッド」に近い。
V4-Pro本体は、もともとメモリ側の負荷を削る方向に振った設計でもある。
KVヘッドは num_key_value_heads: 1 の実質マルチクエリーで、論文でもV3.2比でKVキャッシュは1割まで落ちるとされる。
メモリを削り切ると、残る待ち時間は1トークンずつ順に出す逐次デコードそのものになる。DSparkはそこを縮めにいく派生だ。
Claude Fable停止後の中華系エージェントモデル比較では、DeepSeek V4を「1M文脈のオープンウェイトを置いたモデル」として扱った。
DSpark版を足すと、その後段に「配った重みをどう速く生成させるか」という推論ランタイム側の話が出てくる。
APIで叩く分には表に出ないが、自前ホストでは出力速度とGPU占有時間にそのまま差が出る。
まだ速度の数字は読めない
モデルカードには、DSpark版そのものの速度ベンチは載っていない。
DeepSpec側も評価スクリプトとデータセット名（gsm8k、math500、aime25、humaneval、mbpp、livecodebench、mt-bench など）は公開しているが、READMEにDeepSeek-V4-Pro-DSparkの速度倍率や採用長（1ステップで平均何トークン通るか）の数字はない。
作成は2026年6月27日。翌日に見直した時点でダウンロード数は数百件まで増えていたが、893GBの配布物という性質上これが丸ごと走らせた回数とは限らず、速度を測った第三者のベンチもまだ見当たらない。
なので、今の段階で読めるのは構造までだ。
V4-Pro本体の能力比較ではなく、1.6T級MoEを本番推論に載せるとき、ドラフトヘッドまで含めた配布物をDeepSeekが出し始めた。
同じMITライセンスで、推論コード、変換スクリプト、エンコーディング実装、66分割のsafetensorsまで揃っている。