DeepSeek-V4-Flash-Vision-Expをローカルで動かすには？GGUF・必要メモリ・llama.cpp対応を整理

DeepSeek-V4-Flash-Vision-Expは、「最新DeepSeekをローカルで試してみたい」だけで気軽にダウンロードするにはかなり大きいモデルだ。

DeepSeek公式のHugging Faceでは、モデルサイズは305B パラメータ。V4 系列初の実験版マルチモーダルモデルとして、テキストだけでなく画像を含む入力を扱う画像入力機能も備える。

さらに2026年9月2日、llama.cpp 上流へDeepSeek-V4-Flash-Vision-Expのマルチモーダル対応が取り込みされた。これでローカル実行の現実性は一段上がった。

ただし、ここには重要な注意点がある。

「古いGGUFがllama.cppで読み込める」ことと、「画像入力まで正しく処理できる」ことは同じではない。

llama.cppの後続修正では、DeepSeek V4の画像入力に必要なexp_probs バイアスとSWA処理の修正が入り、PR本文でテキストモデルを再変換する必要があると明記されている。

そのため、今から画像入力目的で導入するなら、実行環境のバージョンだけでなくGGUFがいつ・どの変換ツールで作られたかまで確認したい。

llama.cppの画像入力対応は進んだが、必要メモリは依然として巨大

DeepSeek-V4-Flash-Vision-Expには第三者GGUFがあり、llama.cpp 上流でも画像入力対応が取り込みされた。

ローカルPCで試す経路は以前より明確になった。

一方、305B級の巨大MoEであることは変わらない。判断軸は「VRAMが何GBあるか」だけでは足りない。

GGUFのモデルファイル、システムRAM、GPUへオフロードする量、KVキャッシュ、画像入力処理、そしてGGUF 変換の世代を分けて考える必要がある。

構成	判断
16GB VRAM + 32GB RAM	このモデル目的では厳しい。別の小型モデルを優先
24GB VRAM + 64GB RAM	一部オフロードを試すにも余裕が小さい
32GB VRAM + 128GB RAM	実験候補。量子化とRAM使用量を先に確認
32GB VRAM + 192〜256GB級RAM	巨大GGUFをCPU/RAM主体＋GPU オフロードで試す方向と相性がよい
大容量統合メモリ / 複数GPU ワークステーション	本格検証候補。実行環境と変換の対応確認が必要

これは公式の最低要件表ではない。モデル規模とローカルGGUFの性質から、PC購入・ダウンロード前の判断目安を示したものだ。

DeepSeek-V4-Flash-Vision-Expとは

DeepSeekはこのモデルを、DeepSeek-V4 系列で最初の実験版マルチモーダルモデルと説明している。

ベースとなるDeepSeek-V4-Flashへ画像モジュールを追加し、画像を含むエージェントタスクへ対応したものだ。

項目	内容
モデル	DeepSeek-V4-Flash-Vision-Exp
規模	305B パラメータ
用途	Image-Text-to-Text / マルチモーダルエージェント
ライセンス	MIT
系列	DeepSeek-V4
位置づけ	実験版マルチモーダルモデル
公式実行環境例	vLLM / SGLang
llama.cpp	2026年9月2日に画像入力対応が上流へ取り込み

今回重要なのはベンチマーク順位より、この規模の画像入力 MoEを自宅PCでどう扱えるかだ。

llama.cppの対応で何が変わった？

2026年9月2日、llama.cppのPR #28133が取り込みされ、mtmdへDeepSeek-V4-Flash-Vision-Exp 対応が追加された。

DeepSeek V4ではテキスト側が4 トークン単位で圧縮するため、画像トークンを境界へ合わせる処理が必要になる。PRでは、このために画像入力前へパディングを入れるロジックが追加されている。

ただし、このPRだけで話は終わらない。

後続のPR #28154では、画像入力時に必要な2つの正しさ修正が入った。

• 画像入力用の特別なexp_probs バイアス
• 非因果入力ではSWAを適用しない処理

そしてPR本文にはText モデル必要 to be 再変換済みと明記されている。

つまり、2026年9月2日以前に作られたGGUFや、対応前変換ツールを使ったGGUFについては、単に起動できるからといって画像入力が正しく動いているとは判断できない。

今から確認するポイント

画像入力目的なら次を確認したい。

1. llama.cppがPR #28133 / #28154以降のビルドか
2. GGUFが正しさ修正を反映した変換ツールで再変換されているか
3. 画像入力用プロジェクター / マルチモーダル構成要素の配布方法が現在の実行環境手順と一致しているか
4. 配布元がテキスト-のみ起動だけでなく画像入力まで検証しているか

特に第三者GGUFでは、リポジトリ名やREADMEにVisionと書いてあるだけで判断しない方が安全だ。

305Bでも毎トークンで305B全部を同じように計算するわけではない

DeepSeek公式設定では、n_routed_expertsが256、num_experts_per_tokが6となっている。

つまりMoEでは、トークンごとにルーティング対象のエキスパートの一部を選んで処理する。

しかし、計算時に有効になるエキスパートが少ないことと、重みを保存・読み出すためのメモリが少なくて済むことは同じではない。

巨大MoEをローカル実行するときは、

• ストレージに置くモデルファイル
• システムRAMに保持する重み
• GPU VRAMへオフロードする重み
• コンテキストに応じて増えるKVキャッシュ
• 画像入力側の処理

が別々に効く。

MoEの有効パラメータ数だけを見て「24GB VRAMで十分」と判断しない方がよい。

1M コンテキスト設定も「常に1M使える」とは考えない

公式設定にはmax_position_embeddings: 1048576が設定されている。

しかし、設定上の最大値と、ローカルPCで実用的に確保できるコンテキストは別だ。

コンテキストを伸ばせばKVキャッシュなどのメモリ負荷も増える。巨大モデルでは重みだけでもメモリ負荷が大きいため、最初から最大コンテキストを狙うより、短いコンテキストで起動確認してから伸ばす方がよい。

公式の4×GB300例は何を意味する？

DeepSeek公式モデルカードは、vLLMでの例として単一 4×GB300 ノードを掲載している。

これは重要な一次情報だが、次を意味するものではない。

• 4×GB300が絶対最低要件
• RTX 5090では起動不可能
• GGUFも4枚GPUが必要

公式が示しているのは、ネイティブチェックポイントをvLLMで本格サーバーとして実行する構成例だ。

一般向け PC側ではGGUF 量子化とCPU/RAM オフロードを使うことで、異なるメモリ階層で実行できる可能性がある。

その代わり、速度やメモリ使用量はネイティブ複数GPU構成と同じではない。

GGUFなら何が変わる？

GGUFは、llama.cpp系実行環境で量子化モデルを扱いやすくする形式だ。

Hugging Face上には第三者によるDeepSeek-V4-Flash-Vision-ExpのGGUFも公開されている。

Unslothの配布ページではUD-Q4_K_XLを例に、llama.cppで次のように起動する方法が案内されている。

llama serve -hf unsloth/DeepSeek-V4-Flash-Vision-Exp-GGUF:UD-Q4_K_XL

Ollama向けにもHugging Face リポジトリを指定する例が掲載されている。

ollama run hf.co/unsloth/DeepSeek-V4-Flash-Vision-Exp-GGUF:UD-Q4_K_XL

ただし、このGGUFはDeepSeek公式チェックポイントそのものではなく第三者量子化だ。

さらに今回、llama.cpp側の画像入力正しさ修正で再変換が必要と明記されたため、配布物については量子化方式だけでなく変換日時と対応コミットも確認したい。

一般的な確認ポイントはGGUFモデルをダウンロードする前に確認したい5項目でも整理している。

llama.cpp・Ollama・LM Studio対応はどう見る？

「対応」という言葉には段階がある。

llama.cpp

2026年9月2日時点で、DeepSeek-V4-Flash-Vision-Expのマルチモーダル対応と画像入力正しさ修正は上流へ取り込み済みだ。

これは以前より強い根拠だが、古いバイナリや古いGGUFまで自動的に正しくなるわけではない。

画像入力を使うなら、対応後ビルドと再変換済みモデルの組み合わせを確認する。

Ollama

第三者GGUFページにはollama run hf.co/...の起動例がある。

ただし、Ollamaが内部で使う実行環境とモデル変換の更新時期はllama.cpp 上流の取り込み時点と必ずしも一致しない。

テキスト生成が動いたことだけで画像入力まで対応済みと判断せず、利用バージョンで画像入力を確認したい。

LM Studio

Hugging Faceのローカルアプリ導線にはLM Studioも含まれる。

ただし、モデル一覧に表示される・ダウンロードできることと、自分のPCで快適に推論できること、画像入力まで正しく動くことは別だ。

必要VRAMではなく「必要メモリ」を考える

このモデルで検索すると「何GB VRAMが必要？」が最初の疑問になりやすい。

しかし、GGUF＋CPU オフロードを使うなら、より正確な質問は**「モデル全体をどこに保持するか」**だ。

1. ストレージ

まずGGUF ファイル自体をSSDへ保存する容量が必要になる。

巨大モデルでは量子化を変えるだけでもダウンロード容量が大きく変わる。複数量子化を試すなら、その分だけストレージも必要だ。

2. システムRAM

重みのうちVRAMへ載らない部分をCPU側で扱う構成ではシステムRAMが重要になる。

128GB RAMは一般用途では非常に大容量だが、300B級GGUFでは「何でも余裕」という容量ではない。

モデルファイルがRAM 容量へ近づくと、OSや実行環境、KVキャッシュなどの余白がなくなる。

3. VRAM

VRAMへ多くオフロードできればGPU側で処理できる範囲を増やせる。

ただしRTX 5090の32GBでも、モデル全体から見れば一部だ。

VRAM量は「起動できる/できない」だけでなく、どこまでGPUへ寄せられるかを見る指標として考えたい。

4. KVキャッシュ

コンテキストを伸ばすほど重み以外のメモリも増える。

特に最大コンテキストの数字だけを見て設定すると、重みが読み込めても生成開始後にメモリ不足になる可能性がある。

5. 画像入力

DeepSeek-V4-Flash-Vision-Expには画像入力エンコーダーが含まれる。

さらにllama.cpp側では画像トークン位置合わせや画像入力専用バイアス処理が必要になることが分かったため、テキスト-のみモデルと完全に同じ実行環境挙動だと考えない方がよい。

どんな人なら今試す価値がある？

現時点では、次のような人に向いている。

• 128GB以上のRAMを持ち、巨大GGUFを試したい
• RTX 5090など大容量VRAM GPUでオフロードの効果を検証したい
• 192GB / 256GB級RAMのワークステーションを組む理由を探している
• DeepSeek-V4のマルチモーダルエージェントをローカルで検証したい
• llama.cppの最新マルチモーダル対応を追える

逆に、

• 16GB〜24GB VRAMと32GB〜64GB RAMで快適な日常チャットをしたい
• セットアップに時間をかけたくない
• 速度を最優先する
• 画像理解より一般的なローカルLLM利用が目的

なら、もっと小さいモデルを選ぶ方が合理的だ。

動かせることと、普段使いに向くことは別だからだ。

PCを買い替えるなら何を優先する？

DeepSeek-V4-Flash-Vision-Expだけを理由にGPUを買うなら、GPU単体よりシステム全体を見るべきだ。

主目的	優先したいもの
一般的なローカルLLM	十分なVRAMと扱いやすい実行環境
巨大GGUF実験	システムRAM容量 + メモリ帯域 + GPUへのオフロード
Stable Diffusion / ComfyUI兼用	VRAMとCUDA エコシステム
300B級を本格サーバーとして実行	複数GPU / ワークステーション / サーバー級構成

「DeepSeek V4を使いたいから32GB GPUを買えば解決」とは限らない。

巨大モデルを主目的にするなら、128GBから192GB、256GBへシステムRAMを増やす価値が、通常の小型LLM環境より大きくなる。

一方で画像生成やゲームも兼用するなら、高価なRAM構成へ全振りするより、32GB級GPU＋より小さなモデルを使う方が総合的に満足しやすい場合もある。

今は「Experimental」であることも忘れない

モデル名自体にExpが入り、DeepSeekも実験版マルチモーダルモデルと説明している。

llama.cpp側でも対応が入った直後であり、モデル変換や下流 app側の追従状況は変化しやすい。

今の段階で固定的な「必要VRAM一覧」や「Ollama/LM Studio完全対応」を断定すると、すぐ古くなる可能性がある。

• 公式チェックポイント側の仕様
• llama.cpp / Ollama / LM Studio側の対応
• GGUF 変換の世代
• 量子化
• 実測メモリと速度

が揃った段階で更新していく。