DeepSeek-V4技術報告：100万トークン文脈は「長さ」ではなく「運用コスト」の話になってきた

まず、何が出たのか

今日は、2026年6月19日のarXiv新着に掲載された DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence を取り上げます。注意しておきたいのは、DeepSeek-V4というモデルのプレビューや重み公開そのものは以前から確認されていた点です。今回のニュースとして見るべきなのは、DeepSeek-AIによる技術報告がarXivの新規投稿として出てきて、モデル設計・効率化・評価結果がまとまった形で読めるようになったことです。arXiv新着一覧では、DeepSeek-V4-ProとDeepSeek-V4-Flashの2系統、どちらも100万トークン文脈を扱うMoEモデルとして説明されています。(arxiv.org)

100万トークンの本当のボトルネック

「100万トークン」と聞くと、まず思い浮かぶのは、長い本、巨大なコードベース、社内ドキュメント一式をそのまま入れられる、という使い方かもしれません。

ただ、ここで重要なのは、文脈窓を長くするだけなら話は単純ではない、ということです。Transformer系モデルでは、長い入力を扱うほど注意機構とKVキャッシュの負担が大きくなります。つまり、100万トークン対応をうたっても、実際に遅すぎる、メモリを食いすぎる、料金が高すぎる、という状態なら、実用上はあまり意味がありません。

DeepSeek-V4の技術報告が面白いのは、性能スコアだけでなく、この「長文脈をどう安く動かすか」に正面から触れているところです。モデルカードでは、DeepSeek-V4-Proが総パラメータ1.6兆、活性化パラメータ49B、DeepSeek-V4-Flashが総パラメータ284B、活性化パラメータ13Bで、どちらも100万トークンのコンテキスト長を持つとされています。(huggingface.co)

新しい設計の中心：圧縮された注意機構

技術的な中核は、DeepSeekが Compressed Sparse Attention、CSA と Heavily Compressed Attention、HCA を組み合わせたハイブリッド注意機構を採用している点です。モデルカードによると、100万トークン設定でDeepSeek-V4-ProはDeepSeek-V3.2と比べて、単一トークン推論FLOPsが27%、KVキャッシュが10%で済むと説明されています。(huggingface.co)

これは、かなり大きな主張です。長文脈モデルの競争は、これまで「何トークン入るか」というスペック表の競争になりがちでした。しかし実務で本当に効いてくるのは、1回の長文入力をどれくらいのメモリ、レイテンシ、費用で処理できるかです。100万トークンの窓があっても、毎回それをフルコストで読むなら、日常的なエージェント運用には重すぎます。

DeepSeek-V4は、そこを「圧縮された注意」とMoEで押し下げようとしている。ここが、今回の技術報告を単なる大型モデル発表ではなく、長文脈インフラの提案として読むべき理由です。

ProとFlashの役割分担

DeepSeek-V4には、ProとFlashという2つの主要な系統があります。Proは1.6兆パラメータ級の大きなモデルで、Flashは284B級の軽量側です。ただしMoEなので、毎回すべてのパラメータを使うわけではなく、Proでは49B、Flashでは13Bが活性化される設計です。Hugging Face上では、Flash-Base、Flash、Pro-Base、Proの各モデルが並び、Pro/Flashの推論向けモデルではMoE expert部分にFP4、その他の多くにFP8を使う混合精度構成も示されています。(huggingface.co)

この分け方は、最近のLLM運用の流れとよく合っています。すべてのタスクに最大モデルを使うのではなく、日常的な問い合わせや大量処理にはFlash、難しい推論やエージェント作業にはPro、さらに推論予算を増やす場面ではThink Max、というように、モデルサイズと推論努力を組み合わせて使う設計です。モデルカードでは、Non-think、Think、Think Maxという3つの推論モードも説明されています。(huggingface.co)

ベンチマークはどう読むべきか

自己報告のベンチマークでは、DeepSeek-V4-Pro-BaseはLongBench-V2で51.5を示し、DeepSeek-V3.2-Baseの40.2を上回っています。また、MMLU-Pro、SimpleQA、FACTS ParametricなどでもV4-Pro-Baseの改善が示されています。(huggingface.co)

ただし、ここは少し慎重に見る必要があります。ベンチマーク表には、Claude、GPT、Gemini、Kimi、GLMなどとの比較も載っていますが、モデルごとに推論設定、ツール利用条件、評価ハーネス、プロンプト、サンプリング条件が完全に揃っているとは限りません。たとえば、長文脈ではMRCR 1MやCorpusQA 1Mの数字が示され、DeepSeek-V4-Pro-MaxはMRCR 1Mで83.5、CorpusQA 1Mで62.0とされています。一方で同じ表では、Opus-4.6 MaxがMRCR 1Mで92.9、CorpusQA 1Mで71.7と記載されています。(huggingface.co)

つまり、「DeepSeek-V4がすべてを上回った」という話ではありません。むしろ重要なのは、オープンウェイトのモデルが100万トークン級の文脈処理を、効率化設計込みで前面に出してきたことです。Hugging Faceでは、DeepSeek-V4-ProとFlashのリポジトリおよびモデル重みがMITライセンスと表示されています。(huggingface.co)

生成AIエージェントへの影響

この報告の一番大きな意味は、エージェント設計にあります。

これまで、AIエージェントに大量の情報を扱わせるには、検索、要約、チャンク分割、メモリ管理を外側でかなり工夫する必要がありました。もちろん、これからも検索や要約は不要になりません。ただ、モデル側が100万トークンを比較的現実的なコストで扱えるようになると、設計の重心が少し変わります。

たとえば、巨大なコードベースを読むエージェント、長い契約書群を横断する法務支援、研究論文と実験ログをまとめて扱う科学エージェントでは、「何を捨てるか」だけでなく、「どこまで一度に保持して推論するか」という選択肢が増えます。これは便利である一方、危険でもあります。長い文脈には、古い情報、矛盾した情報、プロンプトインジェクション、低品質な断片も一緒に入ってくるからです。

文脈窓が広がるほど、モデルは賢くなる、という単純な話ではありません。むしろ、広い文脈の中から何を信じ、何を無視し、どの情報を根拠にしたかを追跡する仕組みがより重要になります。

今後見るべきポイント

今後の焦点は3つあります。

第一に、独立した再評価です。DeepSeekの自己報告ベンチマークは有用ですが、実際の長文脈タスク、特にノイズが多い企業文書や大規模コードベースでどれだけ安定するかは、外部の検証が必要です。

第二に、コストとレイテンシです。FLOPsやKVキャッシュ削減の主張は重要ですが、ユーザーが体験するのは最終的な速度、料金、失敗率です。100万トークンを「入れられる」ことと、「毎日使える」ことの間にはまだ距離があります。

第三に、エージェント安全性です。長文脈は、エージェントに多くの材料を与えますが、同時に攻撃面も広げます。文書の奥に埋め込まれた悪意ある指示、古い仕様、矛盾する手順をどう扱うのか。ここは、モデル性能だけでなく、周辺のランタイム、権限管理、監査ログの問題になります。

まとめ

DeepSeek-V4の技術報告は、「100万トークン入りました」というスペック発表として読むよりも、「長文脈を日常的な推論基盤にするために、注意機構とKVキャッシュをどう再設計するか」という論文として読むと面白いです。

LLMの進化は、モデルが大きくなる方向だけではなく、長く読む、安く読む、必要な部分を壊さず圧縮する方向にも進んでいます。これからの生成AIエージェントでは、賢さそのものと同じくらい、「大量の文脈をどう運ぶか」が競争力になる。DeepSeek-V4は、その流れをかなりはっきり示した一件だと思います。