GPUの無駄な計算を削る：DeepSeekが主力サービスを支える中核推論エンジンをオープンソース公開

DeepSeekは、V4.1 Flashのオンラインサービスを支える中核推論エンジンDeepInferをオープンソース公開しました。GPUの役割分担、計算済み結果の再利用、継続的な回答生成をスケジューリングし、ハードウェアの重複計算やアイドル待機を削減します。

この技術はすでに、単一クラスタで1日あたり約155兆トークンを処理する本番サービスで運用されています。計算削減の効果も具体的に示されています。モデルが回答を開始する準備段階では、局所的な状態再構築の最適化により総プリフィル計算量がほぼ半減しました。また回答の生成段階では、ドラフトの確信度に応じて検証の計算量を配分することで、本番負荷に近い公式ベンチマークにおいて、毎ステップ固定で5つのドラフトを検証するベースラインと比べ、試算スループットが約4%〜7%向上しています。一方は回答前の準備計算を削減し、もう一方は生成フェーズにおける単位時間あたりの出力を高める設計です。

同時にdeepseek-recipeも公開されました。これは外部ソフトウェアからのAPIリクエストをモデル入力に変換し、モデルの出力を本文、思考プロセス、あるいはツール呼び出しのレスポンスへと復元するコンポーネントです。今回開発者に提供されたのは、検証や再利用が可能なコアコードであり、完全なオンラインサービスの構築に必要なキャッシュ管理やサービス層の負荷分散は、別途組み合わせる必要があります。

これら2つのコンポーネントが解決する中核的な課題を理解するために、典型的なインタラクションを考えてみましょう。大規模言語モデルに長文を送信して要約を依頼し、続いてその要約の特定のポイントについて追加の質問を投げかけるケースです。

このインタラクションには、2つの主要な計算フェーズと、追加の質問時に再計算が必要かどうかを左右するキャッシュ機構が含まれています：

1. 入力の読み込み（Prefill）：モデルはまず、送信された長文を読み込みます。テキストはモデルが処理する基本単位であるトークン（トークンと文字数は1対1ではなく、1つの単語が複数のトークンに分割されることもあります）に分割されます。これらの入力トークンはあらかじめ与えられているため、GPUは大きな行列としてまとめてバッチ計算を行い、テンソル計算コアの能力を最大限に活用できます。
2. 逐次生成（Decode）：要約の本文を生成する際、モデルは後続のテキストを事前に把握できないため、それまでの入力を踏まえて1ステップずつ次のトークンを計算・予測します。Mixture of Experts（MoE）モデルには「エキスパート」と呼ばれる計算モジュールが多数含まれており、各トークンはその一部のみを選択して計算を行います。毎ステップすべてのエキスパートを動かす必要はありませんが、トークンを1つ生成するごとにメモリアクセスが発生し自己回帰計算を進めるため、VRAM帯域やGPU間通信の制約を強く受けやすくなります。
3. 状態の再利用（KVキャッシュ）：要約をもとに追加の質問を行う際、それまでの文脈はすでに計算されています。以前計算したキー・バリューのキャッシュ（KVキャッシュ）を保持できていれば、2巡目のやり取りでは計算済みの部分を再利用でき、長文全体に対する重複計算を回避できます。

これらの処理にかかる計算負荷に対し、DeepInferはオフラインエンジンにおいてカスタムカーネル最適化、大規模エキスパート並列、有界リプレイ、動的投機検証を実装しています。一方のdeepseek-recipeは、フロントエンドとバックエンド間で厳密に整合したプロトコル変換およびストリーミングパースのパイプラインを提供します。

入力の読み込みと逐次生成：サービス大規模化における分離設計

長い入力の読み込みと、返答の逐次生成とでは、ハードウェアに求められる特性が異なります。これらを物理的に分離してデプロイすることで、それぞれに最適化したリソースを割り当て、回答開始までの待機時間と生成速度を個別に最適化できます。

大規模なオンラインサービスにおいて、DeepSeekはビジョンエンコーディング（VE）、入力プリフィル（Prefill）、逐次生成デコード（Decode）を物理的なサービス単位で分離するアーキテクチャ（E/P/D分離）を採用しました：

• Prefillフェーズ：長文や大量の同時リクエストに対しては、大きなバッチサイズでの行列演算が適しています。DeepSeekはこれを一般的な8GPUノードに配置し、比較的小規模なエキスパート並列（EP2〜EP8など）を適用して、GPUのテンソル計算能力を活かして未キャッシュの入力を高速に処理します。
• Decodeフェーズ：逐次生成では、バッチの同時実行数、VRAM帯域幅、GPU間通信のバランスが求められます。DeepSeekはこれを高帯域インターコネクトを備えた64〜128基のGPUスーパーノードに配置し、超大規模エキスパート並列（Wide-EP）を採用してエキスパートを多数のGPUに分散させることで、1ステップあたりのメモリアクセス負荷を軽減しています。
• ビジョンエンコーディング（VE）：画像の入力処理を単一GPUで独立して実行し、画像のパッチ数に応じて負荷分散を行った上で、視覚特徴量をPrefillノードへと渡します。

こうした役割分担により、Prefillは最初のトークンを出力するまでのスループットと計算効率の最大化に集中し、Decodeはユーザーが返答を受け取る際のスムーズな生成速度の維持に専念できます。完全なオンラインでの協調動作にはキャッシュと負荷分散サービスが必要ですが、今回公開されたのはオフライン推論エンジンのコアであり、オンラインサービス全体はまだ含まれていません。

メモリアクセスと再利用：Wide-EP、種別ごとのKVキャッシュ保存、およびSWA有界リプレイ

Decodeフェーズでは、各トークンがMoEモデルの一部のエキスパートのみをアクティブ化します。少数のGPUだけで実行しようとすると、各GPUが多数のエキスパートパラメータを保持しなければならず、高い並行環境下ではVRAM帯域がボトルネックになりやすくなります。

エキスパートをより多くのGPUへ分散し、高頻度エキスパートにはレプリカを配置

DeepSeekの解決策はWide-EPの採用です。エキスパートを64基、さらには128基のGPUに分散配置します。各GPUが担当するエキスパート数が減るため、1ステップあたりに各GPUが読み出すエキスパートの重みも減少します。特定のエキスパートにリクエストが集中して負荷が偏るのを防ぐため、システムはエキスパート並列負荷分散（EPLB）を導入しています。各GPUに冗長なエキスパートスロットを確保してホットスポットのレプリカとして活用し、直近の実行統計に基づいてエキスパートの配置を動的に調整します。

下図は8GPUと64GPUの2つの構成を比較したものです。図中のDP rankはデータ並列に参加する1つの計算プロセスを指し、ここではGPU 1基が1つのプロセスに対応します。「1つのDP rankあたり64リクエスト」とは、各プロセスがそれぞれ64リクエストを同時に処理している状態を意味し、クラスタ全体で合計64個という意味ではありません。そのため、単一ユーザーあたりの生成速度、GPUごとのスループット、およびクラスタ全体のスループットは、それぞれ異なる集計指標となります。

長文への追加質問時、前回の計算結果を再利用

ユーザーが長文に対して繰り返し質問を行う場合、過去のプロンプトを再計算するコストは極めて大きくなります。本番システムでは2種類のキャッシュを分けて保持しています：

• ブロックKVキャッシュ（Block KV）：モデル本体のブロックKVキャッシュは、専用の3FS分散SSDクラスタ（約100 PiB規模）に保存され、Agent用途では約3日間、Chatbot用途では約7日間保持されます。このキャッシュを独立させることで、任意のPrefillマシンが既存のプレフィックスキャッシュを読み込めるようになり、キャッシュヒットのために特定のマシンへリクエストをルーティングしたり、前回の長文を処理したマシンへ追加の質問を固定して送ったりする必要がなくなります。
• SWA状態とホストメモリ：スライディングウィンドウに関連するSWA状態は3FSには書き込まず、それを生成した計算ノードのローカルホストメモリに保持され、LANを介してマシン間でオンデマンドに取得されます。
• マッチングと転送：プレフィックスのマッチングは、リクエストのルーティング前にエントリーポイントノードでハッシュに基づき高速に完了させ、有効なヒット長を確定する必要があります。その後バックグラウンドでキャッシュデータを非同期に取得し、データ転送とフォワード計算を可能な限りオーバーラップさせて転送待ち時間を削減します。

局所状態が欠落した際、必要な区間のみを再構築

このモデルは、局所ウィンドウ内の状態と再利用可能なブロックキャッシュを併用しています。スライディングウィンドウアテンション（SWA）は、限定されたウィンドウ内でのみ近隣トークンの関係を計算します。長文のキャッシュに部分的な欠落が生じたり、デコーダを初期化したりする際、数千ものトークンをすべて再計算する必要があるのでしょうか。

DeepInferはSWA有界リプレイを採用し、局所状態の近似再構築を行います：

• ブロックキャッシュがヒットし、局所SWA状態が欠落している場合：Block KVがヒットしているものの局所のSWA状態が欠落している場合、システムは長文全体を再計算する必要はなく、ヒットしたプレフィックス末尾の128トークンのみを再計算して局所SWA状態を再構築し、既存のBlock KVをそのまま再利用します。
• デコーダ（Decoder）のプリフィル時：このモデル内部にはさらなる役割分担があります。エンコーダ層がまずコンテキストを処理し、その計算結果をデコーダ層に渡します。デコーダ層に必要なブロックキャッシュは、エンコーダ層の結果から直接変換できるため、層ごとに再構築する必要はありません。復元が必要なのは各層の局所SWA状態です。なお、ここで述べているのはモデル内部の計算レイヤーであり、前述の物理的に分離デプロイされた2つのサービスとは異なる次元の役割分担です。デコーダのSWA状態を厳密に再構築するには、末尾2,560トークンを20層のデコーダ層に通す必要がありますが、有界リプレイではプロンプト末尾の128トークンのみをデコーダ層で近似的に局所再計算します。この近似結果は現在のデコードを開始するためだけに利用され、プレフィックスの永続キャッシュには書き込まれません。公式の試算では、この手法により総プリフィル計算量がほぼ半減したとされています。

エンジンの設定では、通常140トークンを保持するようパラメータが指定されます（例：DEEPINFER_YOCO_PREFILL_KEEP_TOKENS=140）。これは、保持領域として128トークンの局所ウィンドウに加えて、投機実行のロールバックなどに備える境界マージンをカバーする必要があるためであり、両者はメカニズムとして明確に役割が分かれています。

パイプラインのオーバーラップ：デバイスのアイドル待機を減らす非同期スケジューリング

大規模言語モデルの逐次デコードにおいて、標準的な実行フローは通常次の通りです：GPUが現在のステップを計算（フォワード計算とサンプリング）→ 結果をCPUへ同期 → CPUが結果を整理し次のバッチを計画 → GPUへ新しいタスクを発行。この各ステップの間、GPUはCPU側のスケジューリングや後処理ロジックの完了を待機しなければならないことが多々あります。

業界ではSGLangやNanoFlowなどのフレームワークを通じて、パイプラインのオーバーラップが広く探求されてきました。DeepInferも同様に非同期スケジューリング機構を採用しています。GPUがステップNのフォワード計算とサンプリングを実行している間に、CPUはバックグラウンドで並行してステップN+1のバッチスケジューリングとタスク発行を行い、さらに合間にステップN-1の後処理を進めます。これによりCPUの準備作業とGPUの計算を可能な限り重ね合わせ、GPUのアイドル待機を削減しています。

DSpark：確信度の高いドラフトに検証の計算リソースを集中

デコード時の生成速度を高める一般的な手法に投機的デコードがあります。軽量なドラフトモデルがあらかじめ複数の候補トークン（デフォルトでは最大5つ）を連続して推測し、メインモデルが1回のフォワードパスでまとめてそれらを検証します。

ここで比較対象としている固定長方式では、毎回5つのドラフトトークンを検証します。しかし、リクエストや位置によってドラフトが承認される確率は異なり、すべてを無差別に検証すると確信度の低い候補にも計算リソースを消費してしまいます。

DeepInferのDSparkは、確信度に基づく動的検証スケジューリングを導入しました。ドラフトモデルが候補トークンを提示した後、システムは確信度予測ヘッド（Confidence Head）を用いて各位置の承認確率を評価し、ハードウェアのスループット特性と組み合わせてそのステップにおける最適な検証長を動的に決定します。これにより、期待値の高いトークンへ優先的に検証リソースを配分します：

• 本番基準の並行度（1 rankあたり60シーケンス）：1ステップあたりの平均検証ドラフト長は固定5個から3.58個へと減少した一方、承認されたドラフトトークン数の平均は3.30から3.21へのわずかな減少にとどまりました。公式の試算によると、1 rankあたりのスループットは13,730から14,466 token/sへと引き上げられ、約+5.4%のスループット向上が得られました。
• 並行度による影響：1 rankあたり96シーケンスという高並行環境では、動的検証によるスループット向上は+11.0%に達しました。一方、1 rankあたり16シーケンスという低並行環境では、スループットは-1.5%（4,891から4,816 token/s/rankへ低下）を記録しました。

より多くのリクエストをさばくことと、各ユーザーの応答を速くすることは異なる目標

公式のテストスクリプトでは、様々なバッチパラメータをスキャンすることで、PrefillとDecodeの各フェーズにおけるスループットと応答速度のパレート曲線をプロットしています。これら2つのグラフを読み解く際は、具体的な測定基準を念頭に置く必要があります。

1. Prefillフェーズ：バッチサイズと1ステップあたりの所要時間

Prefillのテストにおいて、横軸はGPUが単一のバッチ処理チャンク（Chunk）を実行する物理的な所要時間を記録し、縦軸はGPU 1基あたりが1秒間に処理する未キャッシュの入力トークン数を示しています：

• バッチサイズを4,096に設定した場合、1ステップあたりの所要時間は約68ミリ秒、GPUあたりのスループットは約60,000 token/sとなります。バッチサイズを65,536まで拡大すると、GPUあたりのスループットは約89,500 token/sに向上しますが、1ステップの所要時間は約732ミリ秒へと増加します。
• グラフを見る際の注意点として、1ステップのチャンク処理時間はユーザーにとってのファーストトークン返答時間（TTFT）と同一ではありません。実際の本番リクエストにおけるTTFTには、ネットワーク転送、キューイングとスケジューリング、キャッシュのマッチング、チャンクのデータ転送など複数の段階が影響し、非常に長い入力は複数のチャンクに分割されて連続計算されます。

2. Decodeフェーズ：並行度と対話型生成速度

Decode曲線は、異なる並行規模におけるリソースのトレードオフを示しています：

• 単一DP rankあたりの並行リクエスト数がわずか8件の場合、GPUあたりの出力スループットは約2,600 token/s/GPUにとどまりますが、換算される単一ユーザーの生成速度は約325 token/sに達します。並行数が256まで上昇すると、GPUあたりの出力スループットは約26,300 token/s/GPUまで跳ね上がる一方で、単一ユーザー換算の速度は約103 token/sへと低下します。
• この曲線では、テストスクリプト内の固定換算パラメータが用いられています。固定で3つのドラフトトークン（nextn=3）を設定し、想定承認率を75%として、1ステップあたり 1 + 3 × 0.75 = 3.25トークンとして換算しています。この数値はオンラインユーザーのタイピング体験を直接測定したものではなく、また前述のDSpark動的検証における5ドラフト構成とも異なり、ベンチマークにおいて投機的利益を含めた出力スループットを一律に評価するためのものです。

deepseek-recipe：自前の推論サービスで現実のAPIリクエストを受け止める

DeepInferと同時にオープンソース公開されたdeepseek-recipeは、Rustで記述されPythonバインディングを備えたリクエスト変換およびトークナイズコンポーネントです。上位の標準APIと下位の推論エンジンを橋渡しする役割を担います：

上層リクエスト (Messages / Chat Completions / Responses)
  │
  ▼
deepseek-recipe: 統一Conversationフォーマットへの変換
  │
  ▼
テンプレートの組み立てとToken IDシーケンスへのエンコード（構造化出力の制約設定などを付与）
  │
  ▼
呼び出し側推論エンジンによるフォワード計算の実行（DeepInferなど）
  │
  ▼
出力Tokenストリームをイベント（思考プロセス、本文、ツール呼び出し）へパース
  │
  ▼
ストリーミング組み立てと対応プロトコルレスポンスの返却

このコンポーネントの中核的な責務は、DeepSeek公式APIと一致した処理ロジックを実現することです。呼び出し側は推論サービス、HTTP転送、ツール実行環境を独自に用意する必要があります。公式ロジックとの整合は、主に以下の3つの具体的な工程に現れています：

1. 制御トークンと通常テキストの完全分離

プロンプト構築段階において、deepseek-recipeはテンプレート特有の制御トークン（ロール切り替えタグなど）の位置を明示的に記録し、対応する特殊Token IDへと直接マッピングします。一方、ユーザー入力や外部ツールから返却されたすべての通常テキストは、一律にベース語彙を用いてエンコードされます。 たとえば、ユーザーが入力内容に手動で <｜User｜> と書き込んだとしても、その文字列は通常のテキスト文字シーケンスとしてエンコードされ、システムが本物のロール制御タグと誤認することはありません。同様に出力パース時においても、モデルの真の思考終了タグ </think> やツールタグは専用のToken IDによって識別されます。モデルが通常のテキスト内で同一の文字列を出力した場合でもそのまま保持され、フロー制御が妨げられるのを防ぎます。

2. セグメント並列トークナイズと構造化制約

テンプレート内の特殊タグの位置は組み立て時にあらかじめ確定しているため、タグに挟まれた通常のテキストセグメントはそれぞれ独立してBPEエンコードを行えます。deepseek-recipeはこれらのテキストセグメントを並列にトークナイズした後に結合することで、長文入力のエンコード所要時間を短縮します。 特定のフォーマットでの返答を強制する必要があるリクエストに対して、deepseek-recipeは構造化出力の制約を整理して渡す役割を担い、その強制実行自体は推論バックエンドに委ねられます。DeepInferは、JSON Schemaや正規表現、文法ルールを構文ステートマシンへとコンパイルすることをサポートしています。モデルがデコードを行う各ステップにおいて、エンジンは現在のステートマシンに基づいて正当な候補トークン集合をフィルタリングしてマスクを適用し、出力があらかじめ設定された構造に従うよう強制します。ただし、これは形式的な準拠を保証するものであり、内容の事実としての正確性を保証するものではありません。

3. チャンクをまたぐストリーミングパースとツール引数のフラグメント処理

推論エンジンはトークン単位でストリーミング結果を出力するため、マルチバイトのUTF-8文字や、ツール呼び出しを構成するDSMLタグ、あるいはツールの引数が複数のパケットに分断されることがあります：

• 受信が完了していないマルチバイトUTF-8文字に遭遇した際、コンポーネント内部のステートマシンが該当バイトを一時退避し、後続のトークンで揃ってから出力することで、クライアントへの文字化け送信を防止します。
• ツール呼び出しを検出した場合、コンポーネントは完全なJSON全体の生成完了を待つ必要はなく、DSML構文の境界に基づいて引数を解析し、生成しながらエスケープ処理を施してクライアントへと順次送出します。これによりクライアントは最初の引数フラグメントをより迅速に受け取ることができます。

活用できるチームと、完全なオンラインサービスまでの距離

1. オープンソースの対象範囲と含まれないコンポーネント

• 公開された内容：DeepInferはオフライン推論エンジンのコアをオープンソース化しました。これにはアテンションデータ並列（DP）、MoEエキスパート並列（EP）、SWA有界リプレイ、DSpark投機検証、構造化出力のサポートが含まれ、DeepSeek-V4.1-Flashモデルに対応しています。付属のカーネルライブラリにはDeepGEMM、DeepEP、TileKernels、FlashMLAが含まれます（FlashMLAについて公式は、社内版と比べて手動チューニングされたSASS最適化が1箇所省かれており、デコードカーネルが5%〜10%遅いものの、エンドツーエンドの差は5%以内と注記しています）。deepseek-recipeはリクエスト変換、トークナイズ、ストリーミングパースの完全な実装を公開しました。コードはそれぞれApache 2.0およびMITライセンスで提供され、今後のDeepSeekモデルの推論コードや継続的な最適化もリポジトリで順次更新していくと公式に表明されています。
• アーキテクチャの背景と未公開部分：DeepInferは当初vLLMをベースに構築され、SGLangおよびTensorRT-LLMの設計思想を取り入れています。今回公開されていない部分には、本番クラスタと密結合したKVキャッシュ管理システムの統合、DPレプリカ間のロードバランシングゲートウェイ、そして完全なオンラインE/P/D分離サービスのオーケストレーションが含まれます。
• ハードウェアサポート：DeepInferは初回リリースとしてNVIDIA SM100 GPUおよびHuawei Ascend 950 NPUをサポートしています。

2. デプロイ規模と適用シナリオ

• クラスタおよびテスト規模：公式の本番デプロイが推奨する高効率ユニットは、64GPUのPrefillと64GPUのDecodeを組み合わせた構成（64P+64D、Wide-EPによるマルチGPUメモリアクセスの利点を最大限に活かす構成）です。ただし、フレームワークの動作に必ず128GPUが必要というわけではなく、ドキュメントでは1つのPrefillサービスインスタンスと1つのDecodeサービスインスタンス（1P+1D）でデプロイ可能と説明されています。ここでのインスタンスはGPU 1基と同一ではなく、リポジトリのオフライン推論サンプルでは8GPUの単一マシンで実行するオプションも提供されています。
• 想定されるユーザーと活用の価値：
  • 対応ハードウェアを保有するチーム：DeepInferのオフラインエンジンとカーネルライブラリを直接活用し、長いコンテキストにおけるスループット性能を検証でき、産業グレードの分散推論におけるリファレンス実装として利用できます。
  • APIサービス開発者・インテグレーター：DeepInferエンジンを直接実行しない場合でも、deepseek-recipeを単体で導入することで、複数プロトコルのリクエスト変換、プロンプトテンプレートの組み立て、ストリーミングイベントのパースを標準化して処理できます。
  • リグレッション比較検証が必要なチーム：NVIDIAプラットフォームではバッチ不変性と決定論的サンプリング設定が提供されており、同一入力に対する出力の一貫性を検証しやすくなっています。なお、決定論的サンプリングを利用するには乱数シードを固定し、動的ドラフトを無効にする必要があります。