DeepSeek V4.1 Flash：VRAMキラーはローカルで動くのか？

V4.1 FlashとV4 Flashは何が違う？

V4.1 FlashはV4 Flashの小さな手直しではなく、まったく新しいアーキテクチャです。レイヤー数は43から40へ減り、総パラメータは284Bから769Bへ増え、デコードの活性化は13Bから16Bへ増え、視覚入力をネイティブに備えます。 3つのバージョンの主な違いは次のとおりです。

能力の差は本物です。公式評価ではV4.1 FlashがTerminal Bench 2.1で90.6点（V4 Flashは82.7、V4 Proは87.9）、DeepSWE v1.1の解決率は74.2%（V4 Flashは54.4%）、Codeforcesレーティングは3471です。DeepSeek自身の結論は「V4.1 Flashは性能、コスト、速度のすべてでV4 Proを上回る」というもので、APIではdeepseek-flashがすでにこれを指し、deepseek-v4-proも9月14日正午からV4.1 Flashへルーティングされます（V4.1 Proが公開されるまで）。

出典：モデルカード、技術報告書、DeepSeek APIドキュメント。

511 GBの重みは何で構成されている？

Engramのルックアップテーブルが189 GiB、エキスパートが260 GiBを占め、合わせて94%になります。どちらも削れません。 vLLMチームが示したネイティブcheckpointの構成は次のとおりです（出典）。

ローカル導入にとって重要な点が2つあります。

• エキスパートはネイティブで4-bitです。 コミュニティでよく使われる「Q4量子化」は、V4.1 Flashのエキスパート部分をほとんど圧縮できず、Engramとアテンション層の精度をさらに下げるしかありません。そのためV4.1 FlashのGGUFが出た後も、Q4のサイズは他のモデルのようにネイティブの1/4まで小さくはならず、400 GB前後にとどまると見られます。
• Engramは原則としてディスクに置けますが、実行環境の対応待ちです。 これは2/3/4-gramのハッシュによるルックアップで、アクセスはスパースです。2つのモジュールがそれぞれ8個のハッシュヘッドを持ち、tokenごとに合計48行、約12 KBを読むだけで、挙動は行列積ではなくトークン埋め込みに近いものです。どの行を引くかは入力tokenだけで決まるため、プロンプト全体のアドレスはフォワードが始まる前にすべて算出でき、まとめてプリフェッチできます。技術報告書2.4.2節は、公式の推論もテーブルをホストのメモリに置き、RDMAでバックグラウンドからプリフェッチしていて、VRAMを使わないと明記しています。NVMeに置き換えても遅延がマイクロ秒から数百マイクロ秒になるだけで、10 tokens/sのデコードに必要な読み出し帯域幅は120 KB/sにすぎません。そのためローカルのメモリを計画するときは、この189 GiBを予算から外し、NVMeの容量だけを確保すれば済みます。前提は、実行環境が「必要に応じてディスクからルックアップする」演算子を実装することで、9月10日時点ではllama.cpp、vLLM、MLXのいずれにもなく、公式の参照コードもテーブル全体をメモリへ読み込みます。

下表は当サイトのモデルライブラリが汎用の式で算出したVRAM要件です。モデルライブラリは公式の基準に従い、パラメータ数はEngramを含まない552Bのバックボーンとして記載し、活性化パラメータは「8 / 16」と記載しています。Q4の列は、まだ存在しないQ4_K_M GGUFを仮定したもので、実際のサイズはこれより大きくなります。

8Kと128Kの2列の数値がほぼ同じである点に注目してください。V4.1 FlashのグローバルKVキャッシュはtokenあたり890バイトしかなく、128Kコンテキストでも0.11 GiB、1Mコンテキストでも0.87 GiBです。当サイトのモデルライブラリでKVキャッシュを無視できる初めてのモデルであり、その理由は次節で説明します。

なぜVRAMキラーと呼ぶのか：KVキャッシュはどこへ消えたのか

「VRAMキラー」が殺すのはKVキャッシュという項目です。V4.1 FlashはtokenあたりのグローバルKVを890バイトまで圧縮し、1Mコンテキストでも1 GiB未満に収め、コンテキスト長がVRAMを決めることはもうありません。 まず他のモデルとの差を見てみましょう。KVのtokenあたりのバイト数は各モデルのアテンション構造から算出し、V4 Flashは公式の「V4.1はその1/4」という基準を取っています。

DeepSeek自身の図によれば、この数値はV1の時代より437倍小さくなっています。技術報告書2.3節から2.4節が示す4段階の圧縮は、どれもアーキテクチャの層で行われるもので、量子化による劣化と引き換えに得たものではありません。

1. KVは512次元の潜在ベクトルで、FP4で保存します。 MLAの発想を引き継ぎ、tokenごと・層ごとに512次元の圧縮されたベクトルを1本だけ保存し、64個のヘッドそれぞれのKとVは保存しません。V4.1ではさらにこれをE2M1形式で格納し、16チャネルごとにE4M3のスケール係数を1つ付けるため、V4のFP8からさらに半減します。そのために事後学習で量子化認識学習（QAT）を行っています。
2. 40層のうち実際にKVを産出するのは4層だけです。 CSA2は各層をFull、Reindex、Reuseの3つのモードのいずれかに設定し、設定ファイルのkv_source_layer_idsでは第2、8、14、20層だけがFullモードで、残りの層はそれらのKVとスパースインデックスを再利用します。これが「層間再利用」です。
3. エンコーダーは2 tokenごとに1本へまとめます。 エンコーダー18層のCSA2の圧縮率は2で、グローバルKVの本数はtoken数の半分になります。デコーダー20層のKVはエンコーダー最終層の出力から射影して得られ（CED）、個別には保存しません。
4. ローカルなアテンションの窓は128に固定です。 スライディングウィンドウ注意（SWA）の分のKVはFP8で保存しますが、直近128 tokenしか保持しないため、40層を合わせても数MBにとどまり、コンテキスト長には依存しません。

計算側も同じくコンテキスト長に対して線形には増えません。グローバルなアテンションはインデクサが選んだ512箇所に対してだけ行い、デコーダーはさらに候補の範囲を一つ前のFull層が出した候補プールに限定します。そのため1Mコンテキストは「収まる」だけでなく「計算も回る」のです。

ローカル導入に落とし込むと、これは3つのことを意味します。

• コンテキスト長がVRAMの予算から消えます。 24GBのカード1枚でQwen3.8 27Bを動かす場合、コンテキストを32Kまで開くとKVに8 GiBを充てる必要があります。V4.1 Flashのオフロードモードでの7 GBというVRAMは定数で、8Kでも1Mでも変わりません。モデルページの「どのGPUで動くか」の表で、推奨コンテキストがそのまま128Kになっているのはこれが理由です。
• 複数セッションと状態のディスク保存がほとんど無料になります。 20万tokenのエージェントセッションでもグローバルKVは178 MBしかなく、llama.cppのようにslotをディスクに保存して復元するやり方をセッションごとに気軽に行えます。サーバー側でも並行する多数の長いセッションがKVで詰まることはなくなり、これこそDeepSeekがAPIの価格を引き下げられた裏付けです。
• ただし重みは殺せません。 511 GBの重みは1バイトも減っておらず、VRAMの要件が「重み + どんどん膨らむKV」から「重み + ほぼゼロのKV」に変わっただけです。そのためローカルで動くかどうかという問題は、VRAMからメモリとディスクへ移りました。以下の3つのルートで議論するのは、すべて重みをどこへ置くかという話です。

CEDアーキテクチャはローカル推論に何を意味するのか？

Causal Encoder-Decoder（CED）はプリフィルの作業量を半減させますが、デコードはまったく節約しません。ローカルの利用者にとって改善されるのは長いプロンプトの待ち時間であり、毎秒の生成token数ではありません。 技術報告書2.2節が示す仕組みは次のとおりです。

1. 40層は20層の「因果エンコーダー」と20層の「デコーダー」に分けられます。デコーダー各層のグローバルKVは、その層自身の隠れ状態から計算されるのではなく、第20層の出力から直接射影して得られます。
2. そのためプリフィル（プロンプトの処理）は前半20層を通すだけで済み、tokenあたり8Bのパラメータしか活性化しません。デコード（応答の生成）は依然として40層すべてを通し、16Bを活性化します。
3. デコーダーのスライディングウィンドウ注意（SWA、ウィンドウは128 token）は従来どおり層ごとに計算されるため、プリフィルの終了時にプロンプトの末尾128 tokenをもう一度デコーダーに通し、デコーダーのSWA状態を再構築します。この手順はSWA Bounded Replayと呼ばれ、コストは128 token分に固定され、プロンプトの長さには依存しません。

ローカル導入に落とし込むと、次のようになります。

• 長いプロンプトのプリフィルのコストはおよそ半減します。 エキスパートのオフロードでは、プリフィルの際に各層で活性化したエキスパートの重みをメモリからGPUへ運ぶ必要があります。V4.1 Flashは20層、8Bのパラメータだけを運ぶのに対し、V4 Flashは43層、13Bを運びます。エージェントに数十KBのコードや文書を渡す場合、この待ち時間はV4 Flashより明らかに短くなります。
• デコード速度は恩恵を受けず、むしろ遅くなります。 デコードの活性化16BはV4 Flashの13Bより23%多く、メモリ帯域幅で頭打ちになるオフロードでは約9 tokens/sと見込まれます。V4 Flashは約12 tokens/sです。
• 会話の状態はほとんど容量を使いません。 グローバルKVはtokenあたり890バイトなので、20万tokenのエージェントセッションでも178 MBにしかならず、llama.cppのようにslotをディスクに保存して復元する使い方が非常に安価になります。SWAの状態は永続化する必要がなく、復元時は公式の方法どおり末尾128 tokenを再生すれば十分です。
• 単一ユーザーなら公式より正確にできます。 公式のサーバー側でのSWA再生は近似的な再構築であり、技術報告書第6節はキャッシュ復元の境界で未知の劣化が生じ得ると認めています。単一ユーザーのローカルの実行環境にこの近似は不要です。SWAのKVをメモリに保持し続ければそれが正確な状態であり、40層 × 128 tokenのSWAキャッシュは数MBにすぎません。
• 実行環境の実装難度はV4より高いです。 プリフィルとデコードで通る層数が違ううえ、階層スパースインデクサ、Engramのハッシュルックアップ、FP4 KVの逆量子化、mHC残差ストリームが加わり、llama.cppが新たに書くべきグラフ構造はV4 Flash対応時よりはるかに多くなります。V4 Flash 0731は公開当日にunslothがGGUFのリポジトリを作りましたが、V4.1 Flashで同じペースを期待することはできません。

3つの導入ルートにはそれぞれ何が必要か？

データセンターのルートだけが今日すでに使え、Mac Studioとコンシューマー向けGPUの2つはソフトウェア待ちです。 当サイトの式による各デバイスの推定速度は次のとおりです。

アスタリスク付きはエキスパートのオフロード時の速度で、llama.cppが対応済みであることが前提です。当サイトのモデルライブラリは公式の552Bバックボーンのパラメータ数で計算しており、Engramは含みません。オフロードに必要な304 GBのメモリと、後述のレイアウトBのネイティブ280 GBは同じ基準です。DGX Sparkはユニファイドメモリが128GBしかないため、表のオフロードの数値は当てはまりません。

ルート1：vLLMのマルチGPUデータセンター、今日から動く

vLLMは0.30.0から専用のDockerイメージを提供しており、公式は4種類のハードウェアで検証しています。8枚のH200ノード（VRAM 1128 GB）、GB200 NVL4の1トレイ（768 GB）、GB300、そしてAMD MI350Xです。vLLMが示す最低VRAMは614 GB（511 GB × 1.2の余裕）なので、4枚のH200（564 GB）では足りません。A100世代はFP8とFP4に対応しておらず、検証リストに入っていません。DeepSeek自身の推論コードの例も8-wayのテンソル並列です。初回ロードでは511 GBの重みを読み切る必要があり、公式はエンジンの準備完了のタイムアウトを1時間に設定しています。

ルート2：Mac Studio M3 Ultra 512GB、MLXがEngramのディスク配置に対応するのを待つ

512GBのユニファイドメモリは家庭向け機器で唯一近い容量です。476 GiBのネイティブ重みを丸ごと載せることはできません。macOSは既定でGPUがユニファイドメモリの約75%までしか使えず、iogpu.wired_limit_mbで限界まで引き上げても残るのは数GBです。しかしEngramをSSDに残せば、メモリに残るのはエキスパート、アテンション、トークン埋め込みだけになり、ネイティブFP4精度で約290 GiB、512GBなら余裕をもって収まるので、エキスパートの精度をさらに落とす必要はありません。つまりMacのこのルートが待っているのは低ビット版ではなく、MLXがV4.1アーキテクチャとディスク上のルックアップを実装することです。mlx-communityには9月10日時点でV4.1の変換が一つもありません。版が出た後は、帯域幅819 GB/sと16Bの活性化から推算してデコードは約40 tokens/sとなり、家庭向け機器では最速の選択肢になります。

ルート3：コンシューマー向けGPUまたはワークステーション向けGPU + 大容量メモリ、llama.cpp待ち

Engramをディスクに置いたあと、残るエキスパート、アテンション、トークン埋め込みの置き方は2通りあります。どちらもllama.cppにすでにある仕組みで、V4.1アーキテクチャへの対応を待つだけです。

レイアウトAのデコードはGPUの帯域幅で決まり、当サイトの式ではRTX PRO 6000で約80 tokens/sの水準ですが、複数GPUに分割すると割り引かれます。レイアウトBはメモリ帯域幅で頭打ちになり、デュアルチャネルDDR5で約9 tokens/s、8チャネルDDR5は帯域幅がデュアルチャネルの約4倍あるので20〜30 tokens/sに届きます。両者の中間もあります。どの6個のエキスパートが活性化するかはtokenごとにルーターが決めるため、「活性化したエキスパート」だけをVRAMに置くことはできませんが、前からN層分のエキスパートをすべてGPUに残し、残りの層をオフロードすることはできます。llama.cppの--n-cpu-moeがまさにこの意味です。ネイティブFP4では1層あたりのエキスパートが約6.8 GBなので、24GBのカードなら2層多く残せ、96GBのPRO 6000なら12層残せます。

悪い知らせは、9月10日時点でllama.cppのリポジトリにV4.1アーキテクチャのPRがなく、ディスク上のルックアップの演算子も存在しないため、この2つのレイアウトはどちらも今は通れないことです。すでに大容量メモリのワークステーションをお持ちの方は、まずV4 Flash 0731のGGUFでオフロードの手順を通しておいてください。VRAM不足にメモリ増設は有効？を参照してください。

いま使える起動コマンドは？

使えるのはvLLMの1つだけで、ほかの実行環境には対応するモデルファイルがまだありません。 8枚のH200ノードで、vLLM公式のrecipeに従って起動します（出典）。

docker run --gpus all --privileged --ipc=host -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e VLLM_ENGINE_READY_TIMEOUT_S=3600 \
  -e VLLM_USE_RUST_FRONTEND=1 \
  vllm/vllm-openai:deepseekv41-flash-0909 deepseek-ai/DeepSeek-V4.1-Flash \
  --tokenizer-mode deepseek_v41 \
  --tensor-parallel-size 8 \
  --tool-call-parser deepseek_v41 \
  --enable-auto-tool-choice \
  --reasoning-parser deepseek_v41 \
  --mm-encoder-tp-mode data

GB200 NVL4の1トレイでは--tensor-parallel-sizeを4に変えます。AMDのカードではvllm/vllm-openai-rocm:deepseekv41-flash-0909イメージを使います。テキストのタスクだけを動かす場合は--language-model-onlyを付けると、視覚エンコーダーを飛ばしてその分のVRAMをKVキャッシュに回せます（--mm-encoder-tp-mode dataとはどちらか一方だけを使います）。

踏みやすい落とし穴が2つあります。

• 既定で思考モードが有効になっており、推論強度は50です。リクエストのmax_tokensが小さいと、予算がすべて思考のトレースに使われ、内容が空でfinish_reason=lengthが返り、モデルが壊れたように見えます。chat_template_kwargsでthinking: falseを指定するか、max_tokensを大きくしてください。
• 推論強度はlow / high / xhigh / max、または1から100の整数だけを受け付け、mediumとminimalは拒否されます。

Ollama、LM Studio、llama.cpp、MLXは、9月10日時点でどれも使えるファイルがありません。登場したら当サイトのモデルページで起動コマンドを更新します。

待つべきか、買うべきか？

V4.1 Flashのためにハードウェアを買わないでください。 理由は3つです。

• 能力上の優位は長いコンテキストのエージェントタスクに集中しています。この種のタスクは1回のセッションで数十万tokenに達し、ローカルのオフロードでの9 tokens/sというデコード速度では支えきれません。APIでdeepseek-flashを使うほうが安く、速くもあります。計算方法はローカル導入にかかる費用を参照してください。
• 家庭でフルモデルを動かせるDeepSeekは依然としてV4 Flash 0731です。Q4 GGUFは155 GBで、24GBのカード1枚と192GBのメモリがあればオフロードで動きます。構成はDeepSeekのGPU選びを参照してください。
• 「Flash」はもう小さいという意味ではありません。V4 Flashは284B、V4.1 Flashは769Bで、この名前が指すのはAPIの区分であってサイズではありません。V4.1 Proが公開されたときに、V4.1シリーズ全体のためにハードウェアを更新する価値があるかを判断してください。

すでに256GB以上のメモリのワークステーションやMac Studio M3 Ultra 512GBをお持ちの方は、llama.cppのV4.1対応とmlx-communityの変換の進み具合を注視する価値があります。GGUFまたはMLX版が現れ、Engramのディスク配置に対応すれば、この2種類のマシンが家庭向け機器では最初に動かせるものになります。