DeepSeek-V4：エージェントが実際に活用できる100万トークンコンテキスト

記事一覧に戻る

• エージェントにおけるKVキャッシュ（KV cache）の問題
• ハイブリッドアテンション：CSAとHCA
• エージェントにとっての変更：ツール呼び出しをまたぐインターリーブ思考
• 専用トークンを持つツール呼び出しスキーマ
• DSec：RLロールアウト（RL rollouts）用に構築されたサンドボックス
• エージェントベンチマーク結果
• モデルの使用法

DeepSeekは本日V4をリリースしました。Hubには2つのMoE（Mixture of Experts）チェックポイントが公開されています：総パラメータ数1.6T、アクティブ49BのDeepSeek-V4-Proと、総パラメータ数284B、アクティブ13BのDeepSeek-V4-Flashです。両者とも1Mトークンのコンテキストウィンドウを備えています。ベンチマークの数値は競争力がありますが、SOTA（State of the Art）ではありません。それは問題ありません。真の革新は、DeepSeek V4が効率的な大規模コンテキスト長サポートのためにどのように設計されているか、そしてそれゆえにエージェントタスクの最有力候補の一つとなっている点にあります。

長時間実行されるエージェントワークロードへの焦点。現在、最先端のオープンモデルをエージェントとして実行すると、予測可能な方法で失敗します。モデルが停止する。再プロンプトする。トレースがコンテキスト予算を超えたり、KVキャッシュ（KV cache）がGPUを埋め尽くしたり、あるいは長時間のタスクの途中でツール呼び出しの往復が劣化したりする。V4はこれらの既知の失敗を修正するために構築されており、コミュニティが従うべき道を示すものです。

本記事では3つのトピックをカバーします：長文コンテキスト推論を低コストにするためにアーキテクチャがどのように異なることをしているか、それに加えて重なるエージェント固有のポストトレーニングでの判断、そしてこれらの変更について推論するのに役立つ論文からのいくつかの知見です。

エージェントにおけるKVキャッシュ（KV cache）の問題

1Mのコンテキストウィンドウは単なる容量であり、パフォーマンスではありません。それを使用できるかどうかは、その深さでのすべてのフォワードパス（forward pass）のコストにかかっています。長時間のツール使用軌道（tool-use trajectory）を実行するエージェントにとって、すべてのツール結果はコンテキストに追加され、その後のすべてのトークンは以前のものすべてに対して完全なアテンションコストを支払います。

重要なのは2つの数値です：単一トークン推論FLOPs（single-token inference FLOPs）とKVキャッシュ（KV cache）サイズ。両者はシーケンス長とともに増加します。1Mトークンにおいて、DeepSeek-V4-ProはDeepSeek-V3.2と比較して単一トークン推論FLOPsの27％しか必要としないため、同じハードウェアでより高速に動作します。また、KVキャッシュメモリも10％しか使用しません。V4-Flashはこれらの数値をさらに低下させます：FLOPsの10％、KVキャッシュの7％です。

8つのヘッドを持つグループドクエリアテンション（Grouped Query Attention）のような確立されたアーキテクチャと比較し、通常のbfloat16形式で保存した場合、DeepSeek V4は約2％のキャッシュサイズしか必要としません。これにより、非常に大規模なコンテキスト処理のためのデプロイがはるかに容易になります。

*図1：ベンチマーク比較（左）、シーケンス長に対するトークンあたりのFLOPsと累積KVキャッシュ（KV cache）（右）。*

ハイブリッドアテンション：CSAとHCA

効率の向上は、アテンションを2つのメカニズムに分割し、レイヤー間でインターリーブ（交互配置）することから得られます。

圧縮スパースアテンション（Compressed Sparse Attention, CSA）は、学習された位置バイアス付きのsoftmaxゲート型プーリングを用いて、シーケンス次元に沿ってKVエントリを4倍に圧縮します。ライトニングインデクサ（FP4、ReLUスコア付きマルチヘッドドット積）は、各クエリに対して上位k個の圧縮ブロックを選択します。これはV3.2のDeepSeekスパースアテンションからスパース選択のアイデアを継承していますが、元のシーケンスよりもすでに4倍短いブロックに対して実行されます。インデクサの探索空間もそれに伴って縮小します。

*Figure 3: CSA. The compressor collapses every 4 tokens into one compressed KV entry. The lightning indexer picks the top-k compressed blocks per query. A sliding-window branch handles the most recent uncompressed tokens.*

重圧縮アテンション（Heavily Compressed Attention, HCA）はKVエントリを128倍に圧縮し、スパース選択を廃止します。すべてのクエリは各圧縮ブロックに対して密なアテンション（Dense Attention）を適用します。圧縮されたシーケンスは十分に短いため、密なアテンションのコストは低くなります。

*Figure 4: HCA. A heavier compressor (128x vs. 4x) followed by dense attention over the compressed stream, with the same sliding-window branch for recency.*

各レイヤーはCSAとHCAを交互に切り替えます。異なるレイヤーは異なるアテンションパターンを担っており、すべてのレイヤーに一つの機構を強制的に適用すると容量が無駄になります。V4-Proの61層構成では、レイヤー0〜1はHCA、レイヤー2〜60はCSAとHCAを交互に切り替え、末尾のMTP（Multi-Token Prediction）ブロックはスライディングウィンドウのみを実行します。

両方のパスは、ほとんどのKVエントリにFP8ストレージを使用し、RoPE（Rotary Positional Embedding）次元にはBF16のみを使用します。CSA内部のライトニングインデクサはFP4で動作します。これらのストレージ選択と圧縮率が相乗的に作用し、KVキャッシュが2%という数値を実現しています。

*Figure 2: overall architecture. Attention layers alternate between CSA and HCA. Feed-forward layers use DeepSeekMoE. Residual connections are replaced with manifold-constrained hyper-connections (mHC).*

エージェントにとっての変更点

効率的なロングコンテキストアテンション（Long-Context Attention）はエージェントワークフローに必要ですが、それだけでは不十分です。本論文では、エージェントの使用ケースを直接対象とした3つのポストトレーニングおよびインフラストラクチャの選択について説明しています。

ツール呼び出しをまたぐ思考のインターリーブ（Interleaved thinking across tool calls）

V3.2はツール結果ラウンドをまたいで推論トレース（Reasoning Traces）を保持しましたが、新しいユーザーメッセージが届くたびに破棄していました。単一のユーザーターンを処理するエージェントにとってはこれで問題ありませんでした。しかし、エージェントがすでに複数のツール呼び出しをチェーンした後にユーザーがフォローアップを送信するマルチターンエージェントワークフローでは、モデルは蓄積された推論を失い、状態を再構築する必要がありました。

V4は、会話にツール呼び出しが含まれる場合、ユーザーメッセージの境界をまたいで推論内容を保持します。モデルはすべてのラウンド、およびユーザーターンをまたいで、完全な推論履歴を保持します。これにより、長期にわたるエージェントタスクで一貫性のある累積的な思考の連鎖（Chain of Thought）が可能になります。ツールを使用しない対話用途では、従来の動作が維持されます：コンテキストを簡潔に保つため、各ターンで推論はフラッシュ（破棄）されます。

*Figure 7: thinking with tools (top) preserves reasoning across all turns. Thinking without tools (bottom) discards reasoning at each new user message.*

専用トークンによるツール呼び出しスキーマ（tool-call schema）

V4では、|DSML|という特殊トークン（special token）とXMLベースのツール呼び出し形式が導入されました。このXML形式は、モデルがネストされた引用コンテンツ（nested quoted content）を出力する際に発生しやすい失敗モードである「JSON文字列内でのツール呼び出し（JSON-in-string tool calls）」に比べて、エスケープ処理の失敗（escaping failures）を減らします。

このスキーマは、文字列パラメータ（string parameters、string="true"でそのまま渡される）と構造化パラメータ（structured parameters、string="false"でJSONとして渡される）を分離しています。これにより、JSONベースのツール呼び出し形式（JSON tool-call formats）で頻繁に発生する数値やブール値に関する一連のパースエラー（parsing errors）が解消されます。

DSec：強化学習ロールアウト（RL rollouts）用に構築されたサンドボックス

エージェントの動作は、実際のツール環境に対して強化学習（Reinforcement Learning, RL）で訓練されました。論文では、その目的のために構築されたサンドボックスインフラストラクチャ（sandbox infrastructure）について説明しています。DeepSeek Elastic Compute（DSec）は、1つのPython SDKの背後に4つの実行基盤（execution substrates）を公開するRustプラットフォームです。これには関数呼び出し、コンテナ、マイクロVM（Firecracker）、フルVM（QEMU）が含まれます。単一のクラスターで、数十万の並行サンドボックスが実行されます。

エージェント訓練において重要なDSecの3つの特徴は、階層型3FSストレージによる高速イメージ読み込み（RLロールアウトがコンテナの起動を待たなくて済むように）、プリエンプション安全な軌道リプレイ（preemption-safe trajectory replay、中断された訓練ステップがツール呼び出しを再実行せずに再開できるように）、そして基盤全体にわたる統一API（訓練ハーネス（training harnesses）が書き換えなしで関数呼び出しまたはフルVMを対象にできるように）です。これらのインフラストラクチャの決定が、エージェントベンチマークスコア（agent benchmark scores）の基盤となっています。

エージェントベンチマーク結果（agent benchmark results）

知識と推論の数値は競争力がありますが、トップではありません。エージェントの数値こそが、V4-Pro-Maxが他のモデルを大きく引き離す部分です。

表6のエージェントセクションからの具体的な数値は以下の通りです：

• Terminal Bench 2.0：V4-Pro-Maxは67.9点を記録し、GLM-5.1（63.5）やK2.6（66.7）を上回り、GPT-5.4-xHigh（75.1）やGemini-3.1-Pro（68.5）には及びません。

• SWE Verified：80.6件の解決。Opus-4.6-Max（80.8）およびGemini-3.1-Pro（80.6）とほぼ同点です。

• MCPAtlas Public：73.6。Opus-4.6-Max（73.8）に次ぐ第2位です。

• Toolathlon：51.8。K2.6（50.0）、GLM-5.1（40.7）、Gemini-3.1-Pro（48.8）を上回ります。

論文内の社内R&Dコーディングベンチマークでは、PyTorch、CUDA、Rust、C++にわたる30の厳選タスクにおいて、V4-Pro-Maxは67%の合格率を記録しました。Sonnet 4.5（47%）やOpus 4.5（70%）と比較した結果です。V4-Proを日常の主要モデルとして使用しているDeepSeekの開発者85名への調査では、52%が現在の主要コーディングモデルを置き換える準備ができていると回答し、39%が「はい」に傾いていると答えました。

長期コンテキストの検索数値は図9に示されています。MRCR 8-needleの精度（accuracy）は256Kトークンまで0.82以上を維持し、1Mでは0.59で安定しています。

*図9：MRCR 8-needle検索。V4-Pro-Maxは256Kまで0.82以上を維持し、1Mで0.59に落ち着きます。*

モデルの使用（Using the models）

4つのチェックポイント（checkpoints）がHubに公開されています。インストラクトモデルは、MoEのエキスパート重み（MoE expert weights）にFP4を、その他にFP8を使用しています。ベースモデルは全体がFP8です。

• deepseek-ai/DeepSeek-V4-Pro（1.6T / 49B活性化、インストラクト）

• deepseek-ai/DeepSeek-V4-Flash（284B / 13B活性化、インストラクト）

• deepseek-ai/DeepSeek-V4-Pro-Base（1.6T / 49B活性化、ベース）

• deepseek-ai/DeepSeek-V4-Flash-Base（284B / 13B活性化、ベース）