DeepSeek-V4 on KnightLiブログ

DeepSeek-V4のKV Cache解説：1MコンテキストでVRAMを節約できる理由

Mon, 18 May 2026 18:38:26 +0800

長文コンテキストモデルで本当に高くつくのは、100万Tokenを入力できるかどうかだけではない。推論時にKV CacheがどれだけVRAMを使うかだ。

Transformerのデコードでは、新しいTokenを1つ生成するたびに、過去Tokenに対応するKeyとValueを保持する必要がある。コンテキストが長くなるほどKV Cacheは大きくなり、VRAM、メモリ帯域、初回Token遅延、スループットを圧迫する。

DeepSeek-V4の特徴は、注意ヘッド数だけでキャッシュを節約するのではなく、圧縮をシーケンス長の次元へ進めたことにある。Hugging FaceによるDeepSeek-V4の解説では、1M Tokenの場面で、DeepSeek-V4-ProのKV CacheはDeepSeek-V3.2のおよそ10%、一般的なbf16 GQA構成のおよそ2%程度とされている。

ここがDeepSeek-V4のキャッシュ機構で最も注目すべき点だ。KVを単に小さく保存するだけではなく、長期保存・検索が必要なKVエントリ数そのものを減らしている。

KV Cache最適化の流れ

KV Cache最適化には、いくつかの代表的な流れがある。

第一は従来のMHA、つまりMulti-Head Attentionだ。各Queryヘッドが対応するKey/Valueヘッドを持つ。構造は直接的だが、長文コンテキストではキャッシュがシーケンス長に比例して増え、VRAM負荷が最大になる。

第二はGQA、Grouped Query Attentionだ。複数のQueryヘッドがより少ないKey/Valueヘッドを共有する。LLaMA、Mistral、Qwenなど多くの現代的なモデルが似た考え方を採用している。KVヘッド数を大きく減らせるため、長文コンテキストモデルの標準的な節約手法になっている。

第三はMLA、Multi-head Latent Attentionだ。DeepSeek-V2やDeepSeek-V3はこの方式を使い、Key/Valueを低ランクの潜在表現へ圧縮し、注意ヘッド次元でさらにキャッシュを削減する。

第四がDeepSeek-V4のハイブリッド圧縮注意機構だ。焦点はシーケンス長にある。各Tokenが保存するKVを小さくするだけでなく、複数の過去Tokenを少数のKVエントリへ圧縮し、疎または密な注意で検索する。

大まかに言えば：

MHA：各ヘッドが個別に記憶する。
GQA：複数のQueryヘッドが一部の記憶を共有する。
MLA：各TokenのKV表現を潜在ベクトルへ圧縮する。
DeepSeek-V4：多くの過去Tokenをより少ない圧縮記憶ブロックへ集約する。

重要な変化：ヘッド次元からシーケンス次元へ

GQAとMLAは主に「各TokenがどれだけKVを保存するか」を最適化する。この方向は有効だが、コンテキストが1M Tokenまで伸びると、Token数そのものが問題になる。

DeepSeek-V4は古いコンテキストをブロックへ圧縮する。つまり、遠い過去のすべてのTokenに完全なKVを保持するのではなく、複数Tokenを圧縮エントリにまとめる。

長い本を読むときに似ている。直近の数ページは細部まで覚えているが、前の章は要約、テーマ、重要な手がかりとして覚える。DeepSeek-V4の注意機構も同じように、近い場所では細部を残し、遠い場所では圧縮表現を使う。

CSA：4倍圧縮と疎検索

CSAはCompressed Sparse Attentionの略で、より細かい粒度の長距離圧縮機構だ。

CSAでは、隣接するTokenを少数のKVエントリへ圧縮する。Hugging Face Transformersドキュメントでは、デフォルト圧縮率は m=4 とされており、おおよそ4Tokenごとに1つの圧縮エントリが作られる。

ただし単純平均ではない。CSAは学習可能な圧縮プールと重なり窓を使い、圧縮時に有用な情報を残す。圧縮後、Queryはすべての圧縮ブロックへ直接注意を向けるのではなく、Lightning Indexerでスコアを付け、関連度の高いtop-k圧縮ブロックを選んでから主要な注意計算に入る。

この構造には2つの利点がある。

過去のKVエントリ数が少なくなる。
各Queryは関連する一部の圧縮ブロックだけを見る。

CSAは、コードベース、長文書、ツール呼び出し履歴のように、遠い情報でも細部検索が必要な場面に向いている。

HCA：128倍圧縮と密な注意

HCAはHeavily Compressed Attentionの略で、より強い圧縮を行う。

Transformersドキュメントでは、デフォルト圧縮率は m'=128 とされている。HCAは長いコンテキスト区間を1つの圧縮エントリへまとめる。圧縮後のシーケンスは非常に短いため、CSAのような疎なtop-k検索は不要で、すべてのHCA圧縮エントリに対して密な注意を計算できる。

HCAはグローバル要約に近い。すべての細部を保存するのではなく、非常に低コストで長い履歴範囲を覆い、モデルが全体背景、長期テーマ、遠方情報を把握し続けるために使われる。

CSAが「検索できる圧縮ノート」なら、HCAは「全体目次と要約」に近い。

スライディングウィンドウ：近い文脈は細部を残す

DeepSeek-V4はすべての文脈を圧縮するわけではない。

CSAとHCAに加えて、最近の未圧縮コンテキストを扱うスライディングウィンドウ分岐を残している。Transformersドキュメントでは、DeepSeek-V4のattention blockが長距離圧縮分岐とスライディングウィンドウのK/Vを結合すると説明している。

これは重要だ。次のTokenを生成するとき、直近の文脈が最も重要なことが多い。変数名、関数シグネチャ、書いている途中の文、直近のツール結果、最新のユーザー指示などだ。これらを過度に圧縮すると出力品質が落ちる。

DeepSeek-V4の考え方はこうだ。

近い文脈：未圧縮の細部を保持する。
中距離から長距離：CSAで検索可能な圧縮を行う。
さらに遠い文脈：HCAで強く圧縮した全体要約を使う。

ハイブリッド層スタック：層ごとに異なる注意

DeepSeek-V4は全層で同じ注意機構を使わない。

Hugging FaceのDeepSeek-V4記事では、V4-Proの61層構造で、最初の2層がHCA、その後の層がCSAとHCAを交互に使い、最後のMTP blockがスライディングウィンドウを使うと説明されている。Transformersドキュメントも、V4-Proは2層のHCA bootstrapと交互のCSA/HCA層を使うと説明している。

これはDeepSeek-V4が注意機構を階層システムとして設計していることを示す。層によって情報流の役割が異なり、ある層は全体圧縮を重視し、ある層は疎検索を重視し、ある部分は局所ウィンドウを保持する。

単一の注意機構を全層で使うより複雑だが、1M Tokenのような極端な長文コンテキストには適している。

FP8とFP4がさらにキャッシュコストを下げる

DeepSeek-V4の節約は圧縮率だけではない。

Hugging Faceの記事では、V4の多くのKVエントリはFP8で保存され、RoPE関連次元はBF16のまま、CSAのLightning IndexerはFP4を使うとされている。圧縮率、低精度保存、疎検索が組み合わさって、非常に低いKV Cache使用量になる。

これは重要な注意点でもある。宣伝文句としての「1Mコンテキスト長」だけを見るべきではない。実際にデプロイできるかどうかは、長文コンテキスト時のVRAM使用量、帯域圧力、推論遅延、実装品質で決まる。

他のモデルとの違い

従来のMHAと比べると、DeepSeek-V4は長い履歴のすべてのTokenに完全な注意記憶を保持しないため、キャッシュ圧力が大きく下がる。

GQAと比べると、DeepSeek-V4はKV head数を減らすだけではない。長い履歴に対するKVエントリ数も減らす。GQAは依然としてシーケンス長に比例してキャッシュが増えるが、V4は遠い文脈をブロックへ圧縮する。

DeepSeek-V3のMLAと比べると、V4は「各Tokenの表現をよりコンパクトにする」だけでなく、「履歴Tokenの数も圧縮する」方向へ進んでいる。MLAは単TokenあたりのKVコストを大きく下げるが、百万Token級ではシーケンス長そのものが依然として圧力になる。

普通の疎注意と比べると、DeepSeek-V4のCSAは先に圧縮し、短くなった圧縮シーケンスに対して疎検索を行う。HCAはさらに進み、128倍圧縮によって全量の密な注意も安くする。

Agentと長時間タスクへの意味

Agentワークフローは長文コンテキストを大量に使う。ファイルを読み、ツールを呼び、ツール結果を受け取り、計画を作り、計画を修正し、さらにツールを呼ぶ。コンテキストが長くなるほど、KV Cacheはボトルネックになりやすい。

DeepSeek-V4のキャッシュ設計には次のような価値がある。

長いコードベース、長文書、多段のツール履歴を扱いやすい。
初回Token遅延とスループットがKV Cacheに引きずられにくい。
同じハードウェアでより長いコンテキストやより多い同時リクエストを扱える。
100万Tokenコンテキストが、単なるベンチマークではなく実運用に近づく。

ただし圧縮注意は無料ではない。履歴Tokenをブロックへ圧縮する以上、情報の取捨選択が起きる。モデルはVRAM節約と、検索可能な細部保持のバランスを取らなければならない。コード探索、法律文書、長文QA、Agentツールチェーンでは、細部をどれだけ思い出せるかの要求が異なる。

2%を全コスト2%と読んではいけない

「KV CacheがGQAの約2%」という表現は誤解されやすい。

これは主にKV Cacheのメモリサイズの話であり、総推論コストが2%になるという意味ではない。すべての場面で50倍速くなるわけでもない。推論にはモデル重みの読み出し、MoEルーティング、FFN、注意計算、スケジューリング、通信なども含まれる。

Hugging Faceの記事でも、1M Token文脈でDeepSeek-V4-Proの単Token推論FLOPsはDeepSeek-V3.2の27%、KV Cacheは10%と分けて説明されている。キャッシュと計算は別の次元だ。

より安全な言い方は、DeepSeek-V4は超長文コンテキストのKV Cache圧力を大きく下げ、百万Token級のデプロイ可能性を改善する、というものだ。実際のレイテンシとスループットは、実装、ハードウェア、バッチ処理、量子化、推論フレームワークに依存する。

まとめ

DeepSeek-V4のキャッシュ機構が他の大規模モデルと最も違う点は、KV Cache最適化を注意ヘッド次元からシーケンス長次元へ進めたことだ。

GQAはKVヘッドを少なく保存する。MLAは各TokenのKV表現をよりコンパクトにする。DeepSeek-V4はさらに、遠いTokenを圧縮ブロックへ集約し、CSA、HCA、スライディングウィンドウ、低精度保存を組み合わせ、百万TokenコンテキストがKV Cacheで簡単に詰まらないようにしている。

これは単一のテクニックではない。近くは細部を残し、遠くは圧縮し、必要な細部は疎検索し、全体は強い要約で見るという、長文コンテキスト推論のためのアーキテクチャだ。

開発者やAgentアプリケーションにとって意味は明確だ。長文コンテキストは、単に多く入力できるだけでは足りない。動き、安定し、コストが許容できなければならない。DeepSeek-V4が変えたのは、まさにその点である。

参考資料

DeepSeek V4 FlashでGodotゲームDemo：数セントでどこまで動くのか

Wed, 06 May 2026 09:22:18 +0800

DeepSeek V4 Flash をGodotゲームDemoの開発に使うと、どこまでできるのか。

焦点ははっきりしている。実行でき、観察でき、物理効果を備えた小さなGodot Demoを作れるのかという点だ。

結論から言えば、動く。商用レベルの品質ではないが、ゲームプレイのプロトタイプや物理インタラクションDemoとしては十分に使える。さらに重要なのは、コストが非常に低く、アイデアの素早い検証に向いていることだ。

Demoの表現

このDemoの中心は物理インタラクションだ。

直感的に確認できる効果は次の通り。

ロープを切断できる。
箱が地面に落ちる。
質量を大きくすると、箱の衝突がより激しくなる。
ロープには比較的はっきりした弾性がある。
摩擦と弾性を調整すると、箱に明確な滑りや反発が出る。

見た目の挙動からすると、これは単に「Godotスクリプトを数本生成した」だけではない。実行でき、物理挙動を観察できる小型プロトタイプになっている。

使える度合い

このDemoの価値は「動く、見られる、直せる」ことにある。完全なゲームでも、そのまま商用化できるプロジェクトでもないが、いくつかの点は示している。

DeepSeek V4 Flash はGodot Demoの基本目標を理解できる。
AI Agentは要求を実行可能なプロジェクトに変換できる。
Godotの物理インタラクションのような非Web系タスクも、低コストなプロトタイプ段階に入っている。
個人開発者にとって、アイデアを素早く「見えるもの」に変えられる。

正式なゲームを作るにはもちろん不十分だ。しかし「この遊びは面白いのか」「物理効果はだいたい作れるのか」を検証する目的なら、このDemoはすでに使える。

コスト面の意味

注目すべきなのは、画面がどれだけ精緻かではなく、コストだ。

Godotの物理Demoが数セント程度のモデルコストで実行可能な形になるなら、その意味はプロのゲーム開発を置き換えることではない。プロトタイプの試行錯誤コストを大きく下げることにある。

以前なら、小さなゲームアイデアを検証するだけでも、Godotを理解し、スクリプトを書き、シーンを組み、物理パラメータを調整する必要があった。いまはAI Agentに実行可能な版をまず作らせ、人間が方向性を判断できる。

インディー開発者にとって、この種の低コストな試行は役に立つ。

ゲームプレイのコンセプトを素早く検証する。
他人に見せる一時的なDemoを生成する。
Godot APIや物理システムを探索する。
アイデアを実行可能な初版プロジェクトに変える。
方向性が固まる前の手書きコードコストを減らす。

DeepSeek V4 Flashの表現

注目したいのは、使っているのが DeepSeek V4 Flash であり、より高価で重いフラッグシップモデルではない点だ。

低コストなプロトタイプという位置づけでは、十分よく機能している。最強でも、最も安定しているわけでも、プロダクション工程の納品に最適なモデルでもないが、予算に敏感で、方向性を素早く試したい場面では魅力がある。

向いている場面

DeepSeek V4 Flash + Agent + Godot がより向いているのは、次のようなタスクだ。

小規模なゲームプレイプロトタイプ。
物理効果Demo。
UIまたはインタラクションのコンセプト検証。
教材用サンプル。
Godotプロジェクト構造の理解補助。
実行可能な初版プロジェクトの生成。

一方で、次のようなタスクを直接任せるのには向いていない。

大規模なゲームアーキテクチャ。
複雑なキャラクターコントローラー。
ネットワーク同期。
商用プロジェクトの中核コード。
高精度な物理シミュレーション。
人間のテストを経ない自動コミット。

言い換えれば、第一稿や実験場には向いているが、プロダクション工程の責任者には向いていない。

何を示しているのか

これは、AIコーディングがWeb、スクリプト、バックエンドAPIから、ゲーム開発やインタラクティブプロトタイピングへ広がり続けていることを示している。

かつてゲーム開発の参入障壁は高かった。特にエンジン、スクリプト、アセット管理、物理システムが絡み合うと、初心者は詰まりやすい。いまはモデルとAgentツールで先にプロジェクトを組み立て、開発者はゲーム性の判断や効果の調整に集中しやすくなっている。

この変化は、主に三つの影響をもたらす可能性がある。

第一に、ゲームプロトタイプが安くなる。多くのアイデアは完全開発まで待たずに、まず実行可能なDemoとして検証できる。

第二に、インディー開発者がより試しやすくなる。Godotを知らない人でも、AIの助けでプロジェクト構造と基本フローに触れられる。

第三に、モデルの安定性がより重要になる。ゲーム開発はコードが動くだけでは足りない。効果が自然で、操作感がまともで、パラメータを制御できる必要がある。今後、実際の画面や実行状態とよりうまく結びつけられるモデルほど、この種のタスクに向く。

まとめ

DeepSeek V4 FlashでGodot Demoを作ることは、一言で言えばこうだ。完璧ではないが、十分安く、十分速く、プロトタイプには十分向いている。

商用ゲームにはまだ遠いが、非常に低いコストで小さなゲームアイデアを検証する目的なら、すでに価値がある。

個人開発者にとって現実的な使い方は、ゲーム全体をAIに任せることではない。まずAIに動く工程を出させ、その後の判断、取捨選択、磨き込みを人間が担当することだ。この使い方なら、DeepSeek V4 Flashのような低コストモデルはかなり魅力的になる。

DeepSeek V4 をローカルで動かす：Pro、Flash、Base 版のVRAM使用量見積もり

Fri, 01 May 2026 11:55:25 +0800

DeepSeek V4 と Gemma 4 は、ローカル実行の難度がまったく違います。 Gemma 4 の 26B や 31B なら、24GB や 32GB のGPUでどの量子化版を選ぶかをまだ議論できます。DeepSeek V4 は巨大な MoE モデルであり、完全なローカル実行では多GPUワークステーションやサーバー級のVRAMが必要になります。

公式の DeepSeek V4 Preview には、主に2つの推論モデルがあります。

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

Hugging Face の公式 collection には、さらに2つの Base モデルも含まれています。

DeepSeek-V4-Pro-Base
DeepSeek-V4-Flash-Base

この記事では、モデル重みを完全に読み込む場合のおおまかなVRAM要件だけを扱います。 MoE の active params は主に各 token の計算量に効くものであり、その分のパラメータだけを読み込めばよいという意味ではありません。専門家のオンデマンド読み込み、CPU/NVMe offload、分散推論、専用ランタイム最適化がない場合、VRAMは基本的に完全な重みサイズを基準に見積もる必要があります。

まず結論

VRAM規模	比較的現実的に試せるもの	期待しないほうがよいもの
24GB	DeepSeek V4 の完全実行は不可。小型蒸留モデルまたはAPI向け	V4-Flash / V4-Pro の完全ローカル読み込み
48GB	まだ完全読み込みには不向き。小型モデルやリモートAPIクライアント向け	V4-Flash Q4 の安定実行
80GB	理論上 V4-Flash Q2/Q3 や強い offload を試せる	V4-Pro
128GB	V4-Flash Q4 が比較的現実的。Q5/Q6 はまだ厳しい	V4-Pro Q4
192GB	V4-Flash FP8/Q6 は余裕が出る。Pro Q2 は実験範囲	V4-Pro Q4
256GB	V4-Flash FP8 はかなり安定。Pro Q2/Q3 は実験可能	V4-Pro Q5 以上
512GB	V4-Pro Q4 が議論できる範囲に入る	V4-Pro FP8
1TB+	V4-Pro FP8、Pro-Base の低ビット幅がより現実的	低コスト単体マシン運用
2TB+	Pro-Base FP8 クラス	普通のワークステーション運用

個人PCでローカル実行することが目的なら、DeepSeek V4 は適切な対象ではありません。より現実的な選択肢は次の通りです。

DeepSeek 公式 API または互換サービスを使う。
安定したコミュニティ製 GGUF/EXL2/MLX 量子化と推論サポートを待つ。
より小さな DeepSeek 蒸留モデルを使う。
Qwen、Gemma、Llama などの 7B〜70B 級ローカルモデルを使う。

公式重みサイズ

以下は Hugging Face 公式リポジトリの model.safetensors.index.json から確認できる重み総量です。これは現在公開されている重みファイルのサイズであり、長いコンテキスト実行時の完全なVRAM使用量ではありません。

モデル	パラメータ規模	公式重みサイズ	説明
`DeepSeek-V4-Flash`	284B total / 13B active	159.61GB	推論版。この中では最小
`DeepSeek-V4-Pro`	1.6T total / 49B active	864.70GB	推論版。より強力だが非常に大きい
`DeepSeek-V4-Flash-Base`	284B total	294.67GB	Base 版。全量 FP8 重みに近いサイズ
`DeepSeek-V4-Pro-Base`	1.6T total	1606.03GB	Base 版。約 1.6TB クラス

最小の V4-Flash でも、公式重みはすでに約 160GB あります。そのため、13B active params だからといって 13B 小型モデルのようには扱えません。

DeepSeek V4 Flash のVRAM見積もり

V4-Flash は DeepSeek V4 の中では最もローカル実験に近いモデルです。ただし、それは Pro と比べた場合の話であり、消費者向け単体GPUモデルではありません。

以下では、公式の 159.61GB 重みサイズを基準にしています。 Q4/Q3/Q2 はビット幅からの推定であり、安定した公式 GGUF 版が存在することを意味しません。

版 / 量子化	推定重みサイズ	最低VRAM	安全なVRAM目安	向く用途
`FP8 / 公式重み`	159.61GB	192GB	256GB	多GPUサーバー、推論サービス
`Q6`	120GB	160GB	192GB	品質優先の量子化実験
`Q5`	100GB	128GB	160GB	品質とサイズのバランス
`Q4`	80GB	96GB	128GB	Flash ローカル化の比較的現実的な出発点
`Q3`	60GB	80GB	96GB	大容量VRAM単体GPUまたは多GPU実験
`Q2`	40GB	48GB	64GB	極限低ビット実験。品質リスクは大きい

将来、成熟した V4-Flash Q4 が出たとしても、24GB GPU向けのモデルにはなりにくいです。より現実的な出発点は、96GB〜128GB 級の総VRAM、または速度を犠牲にした CPU/offload 構成です。

DeepSeek V4 Pro のVRAM見積もり

V4-Pro は旗艦推論版で、公式重みサイズは約 864.70GB です。 4-bit 量子化をしても、完全な重みは数百GB級のままです。

版 / 量子化	推定重みサイズ	最低VRAM	安全なVRAM目安	向く用途
`FP8 / 公式重み`	864.70GB	1TB	1.2TB+	多ノードまたは多GPU推論サービス
`Q6`	648GB	768GB	1TB	高品質な量子化サービス
`Q5`	540GB	640GB	768GB	品質とコストのバランス
`Q4`	432GB	512GB	640GB	Pro ローカル化で現実的な最低品質ライン
`Q3`	324GB	384GB	512GB	低ビット実験
`Q2`	216GB	256GB	320GB	極限実験。品質と安定性のリスクが高い

個人ユーザーにとって、V4-Pro は API 経由で使うほうが現実的です。完全なローカル実行を目指すなら、4090、5090、RTX PRO 単体GPUではなく、多GPUサーバーモデルとして考えるべきです。

DeepSeek V4 Flash-Base のVRAM見積もり

Base 版は通常、研究、微調整、継続学習向けであり、普通のチャット用途の第一候補ではありません。 V4-Flash-Base の公式重みサイズは約 294.67GB です。

版 / 量子化	推定重みサイズ	最低VRAM	安全なVRAM目安	向く用途
`FP8 / 公式重み`	294.67GB	384GB	512GB	研究、前処理、評価
`Q6`	221GB	256GB	320GB	高品質量子化研究
`Q5`	184GB	224GB	256GB	品質とサイズのバランス
`Q4`	147GB	192GB	224GB	低コストな Base 版実験
`Q3`	111GB	128GB	160GB	低ビット実験
`Q2`	74GB	96GB	128GB	極限実験

DeepSeek V4 の能力を使いたいだけなら、Base 版から始めることはおすすめしません。 Base 版はデプロイと調整のコストが高く、通常のアプリケーションには推論版または API のほうが向いています。

DeepSeek V4 Pro-Base のVRAM見積もり

V4-Pro-Base は最も重いバージョンで、公式重みサイズは約 1606.03GB です。これはすでに 1.6TB クラスのモデルファイルです。

版 / 量子化	推定重みサイズ	最低VRAM	安全なVRAM目安	向く用途
`FP8 / 公式重み`	1606.03GB	2TB	2.4TB+	大規模研究クラスタ
`Q6`	1205GB	1.5TB	2TB	高品質量子化研究
`Q5`	1004GB	1.2TB	1.5TB	研究と評価
`Q4`	803GB	1TB	1.2TB	低ビット研究
`Q3`	602GB	768GB	1TB	極限低ビット研究
`Q2`	402GB	512GB	640GB	極限実験

この種のモデルは、「家庭用GPUで動くか」という枠組みで考える対象ではありません。 Q4 であっても、ほとんどの単体ワークステーションの快適な範囲を超えています。

active params だけを見てはいけない理由

DeepSeek V4 は MoE モデルです。 MoE では各 token が一部の専門家だけを有効化するため、計算量は総パラメータ数よりかなり小さくなります。しかし、それはVRAMに active params だけを載せればよいという意味ではありません。

完全なローカル推論では、次の要素も考える必要があります。

すべての専門家重みをGPUに常駐させる必要があるか。
専門家のオンデマンド読み込みに対応しているか。
CPUメモリとGPU VRAM間のデータ転送コスト。
NVMe offload の遅延。
長コンテキストで増える KV cache。
1M context 実行時の追加ランタイムコスト。
多ノード・多GPU通信コスト。

したがって、49B active の V4-Pro を 49B モデルとして扱ってはいけません。 13B active の V4-Flash も、13B 小型モデルとして扱うべきではありません。

どう選ぶか

普通の個人ユーザーなら：

DeepSeek V4 を完全にローカル実行することはおすすめしません。
DeepSeek V4 の能力が必要なら、まず公式 API を使う。
ローカル私有化が必要なら、成熟した推論サービス基盤や社内多GPUサーバーがあるかを先に確認する。
24GB〜48GB VRAM しかない場合は、7B、14B、32B、70B 級の量子化モデルのほうが現実的です。

128GB〜256GB の総VRAMがある場合：

V4-Flash Q4/Q5 の安定したコミュニティ実装を注視する。
V4-Pro を主力ローカルモデルとして扱うのはおすすめしません。

512GB 以上の総VRAMがある場合：

V4-Pro Q4 がようやく工学的な検証対象になります。
それでも推論フレームワーク、専門家スケジューリング、KV cache、スループット、並列性を確認する必要があります。

DeepSeek V4 のローカル部署で重要なのは、「どの量子化ファイルをダウンロードするか」ではありません。「このモデルを支えるだけのシステムレベルの推論能力があるか」です。これはデスクトップモデルというより、サーバーモデルに近い存在です。

参考元

GPT 5.5、Claude Opus 4.7、DeepSeek V4、Qwen 3.6 Max はどう選ぶべきか

Tue, 28 Apr 2026 22:18:00 +0800

もし今すぐ一言だけ答えが欲しいなら、まずはこの形で覚えておけば十分です。

いちばん安定していて、時間も無駄にしにくいのは GPT 5.5
ページの見た目、創意、プレゼン感を重視するなら Claude Opus 4.7
中国系モデルの中で最前線にかなり近いのは Qwen 3.6 Max
DeepSeek V4 も弱くはないが、出力の波はやや大きい

「今いちばん強いコーディングAIはどれか」と聞く人は多いですが、実際にはランキングを知りたいというより、もっと現実的なことを知りたいはずです。
ページを書きたい、デモを作りたい、小さなツールを作りたい、インタラクションを足したい。そのとき最初の一回で使えるものを出してくれるのはどれか。

その視点で見ると、この数モデルの違いはかなりはっきりしています。

まず全体の判断

GPT 5.5、Claude Opus 4.7、DeepSeek V4、Qwen 3.6 Max を並べて見たとき、総合的にいちばん安定しているのはやはり GPT 5.5 です。

毎回いちばん派手というわけではありません。ただ、露骨にがっかりさせられることが少ないです。速度が速く、最初の生成物の完成度も高く、ロジック、インタラクション、動き、小さなゲームのような総合課題に強いです。

Claude Opus 4.7 は性格がかなり違います。最大の強みは安定感そのものではなく、ページの雰囲気、UIの整理、見せ方です。出てきたものを開いた瞬間に「見た目がちゃんとしている」と感じやすいタイプです。ページの見え方を重視するなら、今でもかなり魅力があります。

Qwen 3.6 Max は、この中でいちばん見直す価値が大きいモデルです。もはや「中国系モデルとしては使える」という段階ではありません。場面によっては GPT 5.5 と出力品質で正面から比べられるところまで来ています。特にフロントエンドのページ、見た目の完成度、擬似的なリアルさの部分では、かなり存在感が出てきました。

DeepSeek V4 は、できないわけではありません。問題は安定性です。うまくいくときは普通に良く、場面によってはかなり悪くありません。ただ、良いときと崩れるときの差が、他のモデルより見えやすいです。

`GPT 5.5` は何が強いのか

普段やりたいことが次のような内容なら、

完成したWebページをそのまま出したい
動きのある小さなデモを作りたい
少しロジックのあるインタラクティブなページを書きたい
ミニゲームや複数状態のUIを作りたい
なるべく手戻りを減らしたい

GPT 5.5 はやはり最も無難な答えです。

主な強みは次の通りです。

コード生成が速い
最初の出力の usable さが高い
ロジックやインタラクションで大きな傷を作りにくい
複合課題に対して安定している

もっと直截に言うと、GPT 5.5 は「要件を投げたら、まず土台を正しく組みやすい」タイプのモデルです。
多くの人が本当に欲しいのは、どこか一項目だけで最も驚く結果ではなく、最初の版が破綻しないことです。その点では今でもかなり安心できます。

もちろん弱みがないわけではありません。

ビジュアル寄りのページでは、いちばん驚きがあるとは限らない
安定しているぶん、デザイン面での強い記憶点が薄いこともある

なので、デフォルトで一つ選ぶなら GPT 5.5 です。
ただし、それだけ見ていれば十分という話でもありません。

`Claude Opus 4.7` はどんな人に向くか

Claude Opus 4.7 の魅力は、見た目の質感にあります。

長所として出やすいのは、

UI構成がきれい
ビジュアル表現がまとまりやすい
ページにプレゼン感が出やすい
可視化やデザイン面で個性が出やすい

もしモデルにやらせたいものが次のような内容なら、

デモページ
データ表示ページ
見た目の印象が重要な小規模ページ
開いた瞬間に完成品っぽく見えてほしいもの

Claude は今でもかなり有力です。

一方で弱みもはっきりしています。

GPT 5.5 ほど安定しない
見た目はよくても、細かいロジックがずれることがある
動くけれど、肝心の体験が少し外れる場面がある

つまり Claude は、美意識の強いフロントエンド寄りの選手という感じです。
ページがどう見えるかを最優先するならかなり魅力がありますが、最初の一回でロジック事故を避けたいなら少し慎重に見たほうがいいです。

なぜ `Qwen 3.6 Max` を真面目に見るべきか

この中で、勢いの変化をいちばん感じさせるのが Qwen 3.6 Max です。

少し前まで、中国系のコーディングAIを見るときは「そもそも追いつけるか」が主な論点でした。今の Qwen 3.6 Max では、問いそのものが変わっています。
フロントエンド寄りの直出しタスクで、海外トップモデルと正面から比べられるか。

今の強みはおおむね次の通りです。

ページの見た目が良い
動きや擬似的なリアルさをうまく出せる場面がある
出力に完成感がある
場面によっては GPT 5.5 にかなり近いところまで行く

これは大きいです。
Webページ、フロントエンド、見せるための出力が中心なら、Qwen 3.6 Max はもはや単なる予備候補ではありません。十分に主力候補として扱えます。

もちろんまだ弱みはあります。

インタラクション寄りのロジック課題では完成度が少し落ちることがある
かなり見栄えのいいページもあれば、急に平凡に感じる課題もある
ばらつきはまだ GPT 5.5 より大きい

それでも、今いちばん注目すべき中国系モデルはどれかと聞かれたら、Qwen 3.6 Max を外すのは難しいです。

`DeepSeek V4` は今どの位置にいるか

DeepSeek V4 の立ち位置は少し複雑です。

問題は、できないことではなく、どの水準で出てくるか読みづらいことです。
ちゃんと作れるときは、見た目も機能もそこそこ悪くありません。ですが、アニメーション、ロジック、データ表現を同時に求めるような課題になると、崩れやすさが出ます。

今の印象をまとめると、

能力はある
弱いわけではない
課題によっては普通に提出できる
ただし安定性はまだ心許ない

だから向いている人もはっきりします。

何度か試すことを気にしない人、たまにやり直しが入ってもいい人、自分でコードを見て直す前提の人なら、DeepSeek V4 はまだ十分使えます。
ですが、とにかく手間を減らしたい人、最初の一回の成功率を重視する人には、まだ最適解とは言いにくいです。

普通のユーザーは結局どう選ぶべきか

モデル比較そのものが目的ではなく、実際に作業を進めたいなら、用途で選ぶのがいちばん簡単です。

1. 手間を減らして、一回目の成功率を上げたい

GPT 5.5 を選ぶ。

「要件を渡すから、まず使える一版を返してほしい」という流れに最も向いています。
何度もやり取りしたり、細かく修正したりする時間がないときほど、その総合的な安定感が効いてきます。

2. ページの見た目や仕上がりを重視したい

Claude Opus 4.7 を選ぶ。

より完成品っぽく見えるページが欲しいなら、あるいはデモや見せるための制作が中心なら、Claude の長所はかなり分かりやすく出ます。

3. 中国系で最も強いフロントエンド直出し能力を見たい

Qwen 3.6 Max を優先する。

もう「妥協して使う」段階ではありません。正面から比べる価値があります。
タスクがWeb、動き、見た目重視に寄るなら、かなり現実的な選択肢です。

4. ばらつきを許容しつつ、中国系の総合力を追いたい

DeepSeek V4 を見続ける。

能力不足ではなく、出力の揃い方がまだ弱いという段階です。
この先、安定性が改善されれば、存在感はもっと強くなるはずです。

最後に一言

今の主流コーディングAIの差は、もう「書けるか、書けないか」ではありません。
「どれがより安定しているか」「どれがより見た目に強いか」「どれが自分の仕事に合っているか」の差です。

いちばん手堅い答えが欲しいなら、まだ GPT 5.5 が第一候補です。
見た目の仕上がりやプレゼン感を重視するなら、Claude Opus 4.7 はまだかなり魅力があります。
中国系の中で今いちばん真面目に見るべきものを挙げるなら、Qwen 3.6 Max はかなり前の位置にいます。
DeepSeek V4 は、まだ安定性を伸ばしている途中の有力選手という印象です。

最短でまとめるなら、

安定性なら GPT 5.5、見た目なら Claude、中国系で最も注目すべきは Qwen 3.6 Max。