DeepSeek は、オープンソースの投機的デコード フレームワークである DSpark をリリースしました。同社によれば、これにより、出力品質を損なうことなく、ライブ トラフィック下で大規模言語モデル (LLM) 推論が最大 85% 高速化されます。 DeepSeek-AI と北京大学の新しい論文で説明されているように、このシステムは実際のユーザーのリクエストを処理する DeepSeek-V4 サービス インフラストラクチャ内ですでに実行されています。

この研究は、実稼働 AI における最も頑固な問題の 1 つに取り組みます。モデルは一度に 1 トークンずつテキストを生成し、それぞれがネットワークを完全に通過する必要があるため、推論が遅くなります。投機的デコードは、小規模で高速な「ドラフト」モデルがトークンのブロックを提案し、フルサイズのモデルがシングルパスで検証し、最長の正しいプレフィックスを受け入れる一般的な解決策です。検証は並行して行われ、数学的に正確であるため、元のモデルの分布を維持しながら処理が高速化されます。 GitHub 上の DeepSpec トレーニング リポジトリと一緒にリリースされた DSpark は、すぐに Hacker News で最も議論される AI エンジニアリング ストーリーの 1 つになりました。 この件の詳細は、AIニュースをご覧ください。

既存の投機的解読が壁にぶつかる理由

最近の投機的なデコード研究は、1 回の順方向パスで候補トークンのブロック全体を生成する「パラレル ドラフター」に移行しており、ドラフトのレイテンシーはブロック サイズにほぼ依存しません。 DSpark の論文では、これらの手法が大規模にその約束を達成することを妨げている 2 つのボトルネックを特定しています。

1つ目は品質の問題です。パラレルドラフターは各位置を独立して予測するため、ブロック内のトークンが互いにどのように依存するかをモデル化できません。研究者らは、これが「マルチモーダル衝突」を引き起こし、ドラフトブロックの後の位置で受け入れが急速に減衰することを示しており、これをサフィックス減衰と呼んでいます。平行ブロックが長ければ長いほど、その末尾が間違っている可能性が高くなります。

2 つ目はシステムレベルの問題です。長いドラフト ブロックの生成は安価ですが、提案されたすべてのトークンを盲目的に検証すると、拒否される可能性が高いトークンの不足したバッチ容量が無駄になります。実際のサービス システムの同時実行性が高い場合、理想的な検証の長さは 2 つの軸に沿って変化します。コードのような構造化されたリクエストは、オープンエンド チャットよりも高い受け入れ率を維持します。また、追加のトークンの検証は負荷が軽い場合はほぼ無料ですが、システムが飽和状態になると費用がかかります。

半自己回帰ドラフト モデル

サフィックスの減衰を修正するために、DSpark は作者が半自己回帰アーキテクチャと呼ぶものを採用しています。一度に多くのトークンを提案できる計算量の多い並列バックボーンと、ブロック内依存関係モデリングを導入する軽量のシーケンシャル モジュールを結合します。この設計は、初期の位置での並列モデルの高い能力と、トークンを次々に生成し、依存関係を自然に尊重する従来の自己回帰ドラフターの接尾辞の一貫性を組み合わせることを目的としています。

数学的推論、コード生成、毎日のチャットにわたる制御されたオフライン ベンチマークにおいて、チームは、DSpark が強力なベースラインよりも検証サイクルごとに許容される長さを大幅に改善すると報告しています。具体的には、DSpark は、3 つの設定全体で、自己回帰型 Eagle3 ドラフターよりも許容長さが 30.9%、26.7%、30.0% 向上し、並列 DFlash ドラフターよりも 16.3%、18.4%、18.3% 向上すると述べています。

信頼性を考慮してスケジュールされた、負荷を認識した検証

DSpark のより斬新な部分は、検証へのアプローチです。 DSpark は、リクエストごとに固定数のドラフト トークンを検証するのではなく、グローバルなスループット最大化の問題として検証長の選択を定式化します。これは、ドラフトのプレフィックスがどのくらいの期間存続する可能性があるかについての調整された推定値 (論文では生存確率と呼ばれるもの) と、リアルタイムのエンジン負荷を読み取るハードウェア対応スケジューラーを組み合わせています。

その結果、信頼度に基づいてスケジュールされた検証が行われます。システムは、リクエストの内容とサービス提供エンジンの現在の状態の両方に基づいて、リクエストごとに検証するトークンの数を動的に調整します。負荷が軽い場合は十分に検証する余裕があり、同時実行性が高い場合は、ターゲット モデルの検証予算を最も期待されるリターンが高いトークンにのみ振り分け、確率の低いトークンにバッチ容量を費やすことで生じるスループットの崩壊を回避します。

ライブ ユーザー トラフィックの結果

最も重要な数字は生産から得られます。チームは、ライブ ユーザー トラフィックを処理する DeepSeek-V4 サービング システム内に DSpark を導入し、同社の以前の運用ベースラインである MTP-1 として知られるマルチトークン予測方法と比較しました。

論文によると、DSpark は、一致する総スループットでユーザーごとの生成速度を DeepSeek-V4-Flash で 60% ～ 85%、DeepSeek-V4-Pro で 57% ～ 78% 高速化します。ベースラインの容量が大幅に低下する厳格なサービスレベル契約の下では、Flash では 1 秒あたり 120 トークン、Pro では 1 秒あたり 50 トークンに相当し、DSpark は検証オーバーヘッドを軽減して堅牢なスループットを維持します。著者らは、このパフォーマンスの崖を克服することで、以前は達成できなかった厳格な対話性層のロックを解除し、LLM サービスのパレートフロンティアを効果的に外側にシフトすると主張しています。

この区別はオペレーターにとって重要です。同じ総スループットでのユーザーごとの速度が速いということは、追加のハードウェアを購入することなく、アシスタントやエージェントのワークフローの応答性が向上することを意味します。また、負荷がかかった状態で厳格なレイテンシ SLA を維持できるかどうかが、トラフィックの急増時に耐えられるシステムと研究デモを分けるものです。

コミュニティ向けにオープンソース化

DeepSeek は、DeepSeek-V4-Flash と DeepSeek-V4-Pro プレビュー モデルの両方に対して、トレーニングされた DSpark チェックポイントをリリースしています。付属の DeepSpec リポジトリは、寛容な MIT ライセンスの下で公開されており、投機的デコード用のフルスタック、アルゴリズム駆動のトレーニングおよび評価コードベースとして説明されています。これには、データ準備ユーティリティ、ドラフト モデルの実装、トレーニング スクリプト、評価ハーネスが含まれており、DSpark、DFlash、Eagle3 の 3 つのドラフト モデル アルゴリズムが付属しています。

このリリースにより、他のラボやインフラストラクチャ チームが標準化されたパイプラインに対して独自のドラフト モデルをトレーニングおよびベンチマークするための障壁が低くなります。 DeepSpec の評価スイートは、GSM8K、MATH500、AIME 2025、HumanEval、MBPP、LiveCodeBench、MT-Bench、AlpacaEval、Arena-Hard-v2 などの確立されたベンチマークをカバーしています。

なぜそれが重要なのか

推論コストと遅延は現在、AI 業界の決定的な制約の 1 つとなっており、企業が AI エージェントをどのように積極的に導入するかから、小規模プロバイダーがユニットエコノミクスでハイパースケーラーと競争できるかどうかまで、あらゆるものを形作ります。 DSpark の貢献は、単一の新しいアルゴリズムというよりも、ドラフト モデルと検証スケジューラを慎重に共同設計し、検証の長さをライブ システム状態の関数として扱うことで、実際の展開において有意義な変化をもたらすことができるというデモンストレーションです。

効率的でオープンにリリースされたシステムで評判を築いてきた DeepSeek にとって、DSpark は、研究室が 1 年以上にわたって主張してきた主張のもう 1 つのデータ ポイントです。つまり、フロンティア グレードのサービス パフォーマンスは、生のコンピューティングだけではなく、よりスマートなエンジニアリングを通じて達成できるというものです。ゲインが合成ベンチマークではなく、実際のトラフィックの下で測定されたという事実により、オープンソース コミュニティが論文を消化して数値を再現し始めると、他の通信事業者が結果を真剣に受け止めやすくなります。

---

AIの最新情報をお届け

AIの最新ニュース、分析、ブレイクスルーを一箇所で。

AIニュースをもっと読む →