DeepSeek V4.1-Flashが動かない〜ローカル動作を試みた
DeepSeek V4.1-Flash が話題になっていました。総パラメータは552Bと巨大ですが、実際に動くのは1トークンあたり8B(読み込み時)・16B(生成時)だけという効率の良い作りで、文脈窓は最大100万トークン。コーディング系のベンチマークでも高い数字が出ていました。
調べてみると、どうやらOllamaで動かすことができるらしい、ということで、手元の128GBのユニファイドメモリーを積んだミニ PCのEVO-X2で試してみました。現状では、EVO-X2では動作させれていません。ただし、これは当方が実際に試した1つの配布ファイルについての結果です。後述の通り、他にも配布は複数あり、そのすべてを試せたわけではありません。
2026年9月時点の調査です。当方は実機で読み込みを試み、失敗を確認しています。生成された文章の品質までは測っていません。
何を、どこまで調べたか
調べたのは4つです。何が話題になっているのか。公開日はいつか。配布されているファイルの大きさはいくつか。手元の機体で読み込めるか。
何が話題だったのか
配布元(Hugging Face)のモデルカードと、あわせて公開されている技術レポートを確認しました。ここに載せる数字は、すべて開発元(DeepSeek)が自己申告しているものです。
作りの効率がよい
- 総パラメータ552Bのうち、1トークンあたり実際に動くのは8B(読み込み時)・16B(生成時)だけ(Causal Encoder-Decoderという設計。前の世代のDeepSeek-V4-Proは1.6Tパラメータ中49Bを毎回動かす作りだったので、動かす量そのものを大きく減らしている)
- 384個の「専門家」を用意しておき、1トークンごとに共有1個+選ばれた6個だけを動かす、MoE(Mixture of Experts)という作り
- 会話の記憶を長く保つための追加の仕組み(Engram、196B相当)や、生成を先読みして速くする仕組み(DSpark)も積んでいる
長い会話を、軽い記憶容量で保てる
この技術レポートの表題は「KV Cache Compression(会話の記憶領域の圧縮)」で、これが今回の目玉のようです。文脈窓は最大100万トークン。会話1トークンあたりの記憶領域は890バイトとされ、前の版(DeepSeek V4-Flash)の約1/4、さらに前の世代(DeepSeek-V1)と比べると約437分の1という圧縮率が書かれていました。
ベンチマークで名前の知られたモデルと張り合っている
いくつかの項目で、他の有名なモデルとの数字が並べて書かれていました(いずれも開発元の発表値)。
| 項目 | DeepSeek V4.1-Flash | 比較対象 |
|---|---|---|
| Terminal-Bench 2.1(端末操作系のエージェント課題) | 90.6% | Opus-5.0: 89.1%/GPT-5.6 Sol: 88.8% |
| DeepSWE v1.1(コード修正の解決率) | 74.2% | Opus-5.0: 74.0%/GPT-5.6 Sol: 73.0%/前版(V4-Flash): 54.4% |
| CyberGym(セキュリティ系タスク) | 88.1% | GPT-5.6 Sol: 84.5% |
| GPQA Diamond(大学院レベルの専門知識) | 90.9% | Opus-5.0: 93.4%/GPT-5.6 Sol: 94.1% |
コーディング・端末操作系のいくつかの項目でOpus-5.0やGPT-5.6 Solといった名前の知られたモデルと並ぶか上回る数字を出す一方、専門知識を問うGPQA Diamondではやや下回っており、全部で勝っているわけではありません。
文章と画像の両方を扱える
文章だけでなく画像も扱えるモデルで、画像を理解する問題(DocVQA)で95.6%、物の位置を答える問題(RefCOCO)で86.0%という数字が出ていました。「考える深さ」を1〜100の数値で連続的に調整できる機能も、エージェント用途(ツールを使いながら作業を進める用途)向けの新しい要素として挙げられていました。
配布時点で、llama.cpp・Ollama・LM Studio・Jan向けに59種類の量子化版が既に用意されていたとも書かれていました。数だけ見れば対応は手厚いのですが、今回つまずいたのはその先——道具側が新しい構造を読めるかどうか、というところでした。
実際にどこで動かされているかも見ておきました。目立ったのは、データセンター向けの大規模GPU構成(8基のRTX PRO 6000での動作報告など)でしたが、その中に、大容量のユニファイドメモリを積んだ個人向け機(192GBのMac Studio)で動かそうとしている記録も見つかりました。EVO-X2(128GBユニファイドメモリ)は、この後者に近い立ち位置です。手元で試す動機はここにありました。
V4の公開から5か月、何が変わったか
| モデル | 公開 |
|---|---|
| DeepSeek V4-Flash | 2026年4月22日 |
| DeepSeek V4.1-Flash | 2026年9月10日 |
前の版から約5か月です。配布元の Hugging Face 上のモデル種別(architecture)を確認したところ、V4.1-Flash は DeepseekV41ForCausalLM(deepseek41)という新しい種別で登録されていました。
変わった点
前の版(DeepSeek V4-Flash)と、配布元の設定ファイルとモデルカードを突き合わせました。以下は、どちらも Hugging Face に公開されている記載です。
| 項目 | V4-Flash(2026年4月) | V4.1-Flash(2026年9月) |
|---|---|---|
| 総パラメータ | 284B | 552B |
| 1トークンで動く量 | 13B | 8B(読み込み時)/16B(生成時) |
| 扱えるもの | 文章のみ | 文章と画像 |
| 文脈窓 | 100万トークン | 100万トークン(据え置き) |
| 層の数 | 43層 | 40層(20層+20層の2段構え) |
| 専門家の数 | 256個 | 384個(1トークンで動かすのは6個のまま) |
| 学習に使った量 | 32兆トークン超 | 45兆トークン |
目を引いたのは、総パラメータが約2倍になっているのに、1トークンあたりに動く量は減っているところです。読み込みの段階では13Bから8Bへ下がっています。長い入力を読ませる使い方を想定した作りだと説明されていました。
もうひとつは、画像を扱えるようになった点です。V4-Flash は文章だけのモデルでした。V4.1-Flash には画像用の部分が加わり、文章と画像を最初から一緒に学習させたと書かれています。
文脈窓は100万トークンのまま変わっていません。前の版ですでに100万トークンに対応していて、今回の版で伸びたわけではない、という並びです。変わったのは、その100万トークンを保つのに要る記憶領域のほうでした。
設定として増えたものもあります。答える前にどれくらい考えるかを、1から100までの整数で指定できる仕組みが入りました。考える量と費用を、使う側が振れるという形です。
成績は、全部が上がったわけではない
モデルカードには、前の版と同じ条件で測ったという成績表が載っています。素の状態(Base)どうしの比較を抜き出しました。いずれも開発元の発表値です。
| 項目 | V4-Flash-Base | V4.1-Flash-Base | 差 |
|---|---|---|---|
| HumanEval(コードを書く) | 69.5 | 79.4 | +9.9 |
| SimpleQA-Verified(事実を知っているか) | 30.1 | 42.3 | +12.2 |
| MMLU-Pro(広い範囲の知識) | 68.3 | 74.1 | +5.8 |
| BigCodeBench(コードの課題) | 56.8 | 60.6 | +3.8 |
| GSM8K(文章題の算数) | 90.8 | 93.0 | +2.2 |
| MGSM(多言語の算数) | 85.7 | 80.2 | −5.5 |
| DROP(文章の読み取り) | 88.6 | 87.9 | −0.7 |
| BBH(推論の詰め合わせ) | 86.9 | 86.1 | −0.8 |
| AGIEval(試験問題) | 83.9 | 83.4 | −0.5 |
コードと事実の知識は伸びています。一方で、多言語の算数は5.5ポイント落ちています。読み取りや推論の項目も、わずかですが下がりました。新しい版に替えれば何でも良くなる、という並びにはなっていません。
画像を扱う項目は、V4-Flash に対応する数字がありません。文章だけのモデルだったので、比べる相手がいない形です。
配布ファイルの大きさについて
量子化違いのGGUF(ローカルで動かす形式)が複数の配布元から出ていました。分割ファイルの一部だけが上がっていて全体がそろっていないものも混じっていたため、そろっている分割ファイルの数を数えたうえで最小のものを確かめました。
| 量子化 | サイズ | 状態 |
|---|---|---|
| Q1_0 | 98.6GiB | 分割ファイルがそろっている最小 |
| MixedQ2 | 157.3GiB | そろっている |
| Q2_K | 246.3GiB | そろっている |
手元のEVO-X2は128GBのユニファイドメモリを積んでいます。GPU側に割り当てている実際の上限は約112GiBです(起動時の設定 amdgpu.gttsize と ttm.pages_limit を、実機で /proc/cmdline から直接確認。両方とも112GiB相当に設定済み)。
最小のQ1_0(98.6GiB)は、この112GiBという上限には収まります。容量だけで見れば、載るはずです。
どれくらいの量子化ならEVO-X2で動きそうか、計算してみた
配布されている3種類の量子化を、パラメータ1個あたり何ビットに削っているかで並べ直しました(総パラメータ552Bから逆算)。
| 量子化 | サイズ | 1パラメータあたり | 112GiBに収まるか |
|---|---|---|---|
| Q1_0 | 98.6GiB | 約1.53ビット | 収まる(余白 約13GiB) |
| MixedQ2 | 157.3GiB | 約2.45ビット | 収まらない |
| Q2_K | 246.3GiB | 約3.83ビット | 収まらない |
112GiBという上限を1パラメータあたりのビット数に換算すると、約1.74ビットです。現状いちばん軽いQ1_0(1.53ビット)は、すでにこの基準をクリアしています。逆に言うと、容量の面だけで見れば、これ以上軽い量子化が新しく出てくるのを待つ必要はありません。
ただし、Q1_0とMixedQ2の間には1.53〜2.45ビットという大きな空白があり、間を埋める量子化は今のところ配布されていません。会話を長く続けたときに使う記憶領域(KVキャッシュ)の分も別途必要になるため、13GiBという余白は、余裕として大きいとは言えません。
容量は足りていたのに、読み込みそのものが止まる
容量は足りてい流のですが、llama.cppにはこのモデルの記載がありません。一応、手元で動作確認に使っている llama.cpp(ビルド b10605)へ、GGUFのファイルだけを読ませてみましたが、読み込みの段階から失敗しました。やはり、llama.cppに対応していない以上、動作がしないようです。
ちなみに、別の新しいモデル(Spark-X2.5-4B・4B級・2.42GiB)でも、同じ形の失敗をしています。こちらは、容量は十分余裕があるのですが、llama.cpp が対応しておらず、動作しませんでした。
Ollama に掲載されているモデルは「クラウド版」
Ollamaのモデル一覧に DeepSeek V4.1-Flash が出ていたので、ollama run deepseek-v4.1-flash を試してみました。結果は、惨敗。動きませんでした。
よくよく調べてみると、これはローカルで動くOllamaのモデルではなく、Ollamaクラウドのモデルとのことです。公開から3日で12,200件の pull(ダウンロード相当の指標)を集めていたので、てっきり手元で動くものだと思い込んでいました。念のため、タグの一覧も確かめました。
用意されていたタグは deepseek-v4.1-flash:cloud の1つだけでした。この cloud は、Ollama がクラウド上のモデルへ取り次ぐ機能で、重みが手元のパソコンに置かれるわけではありません。「Ollamaで使える」と「手元のGPUで動く」は別のことだった、という一例です。
Ollama Cloud がどういうものかも、あらためて公式ページで確認しました。アカウント登録が要り、無料枠のほかに月20ドル・月100ドルのプランがあります。計算そのものはOllamaのサーバー(主に米国、場合によっては欧州やシンガポール)で行われるとのことで、入力した内容はOllama側に送られます。公式ページには「入力や出力のやり取りは記録・学習に使わない」という説明もありましたが、これは相手側の運用方針であって、当方が確かめられるものではありません。
このブログで「ローカルLLM」と呼んでいるのは、外にデータを送らずに、自分のパソコンの中だけで動かす使い方です。Ollama Cloudは、Ollamaという同じ道具を使ってはいますが、動く場所は外のサーバーであり、今回確かめたかった「うちのEVO-X2で動くかどうか」とは、趣旨が異なってきます。
今すぐ動かす代案はあるか、調べた
読み込めない理由がはっきりしたところで、今すぐ何か動かす方法が無いかを調べました。
- 本家 llama.cpp への対応PR(
convert : add DeepSeek V4.1)は、2026年9月10日に提出され、9月14日時点でまだ取り込まれていません(GitHub上で状態を確認) - Ryzen AI Max系(EVO-X2と同じ系統のチップ)向けに特化した有志のllama.cpp派生も見つかりましたが、そちらでも「DeepSeek V4.1に対応してほしい」という要望が未解決のまま残っており、今すぐ使える状態ではありません
- 前の版(DeepSeek V4-Flash)は、今回とは別の種別(
DeepseekV4ForCausalLM)で登録されており、本家llama.cppのコードに既に対応する処理が存在します。試してはいませんが、V4.1-Flashが読めるようになるまでの間、前の版であれば読み込める見込みがあります - 探している途中で、Q1相当の軽い量子化を有志がすでに配布していることも見つかりました。ただし配布元がどこまで信頼できるか当方では判断できなかったため、今回は試すこと自体を見送っています。そのため、これらの版で実際に読み込めるかどうかは分かっていません
容量が足りていても、動かす道具(llama.cpp)がそのモデルの構造に対応していなければ、読み込みの時点で止まります。新しいモデルほど、新しい構造を採用している場合があり、道具の対応が追いつくまでに時間差があります。ただし、これは当方が試した配布ファイルにあてはまる話です。有志による別の配布ファイルでは、事情が違う可能性が残っています。
この記事で確かめていないこと
- ollama など、別の実行方法では動く可能性があります。当方は llama.cpp(b10605)でのみ確認しました
- より新しいビルドの llama.cpp で対応が入っているかどうかは、対応PRの状況(未取り込み)から見て変わらないと推測していますが、実際に試してはいません
- 前の版(DeepSeek V4-Flash)が実際に手元で読み込めるかどうかは、試していません
- 有志が配布しているQ1相当の量子化が、実際に読み込めるかどうかは試していません。配布元の信頼性を確認できなかったためです
- 賢さ・速さは測っていません。読み込みの可否のみを確認しています
まとめ〜止まったのは容量の手前だった
DeepSeek V4.1-Flash は、最小の量子化でも98.6GiBありますが、手元の128GB機(実際のGPU割り当て上限は約112GiB)では、容量の面では収まる大きさでした。当方が試した配布ファイルでつまずいたのは容量ではなく、その手前の読み込みの段階です。ただし、これは「動かない」の確定ではなく、「当方が試した範囲では動かなかった」という話です。有志によるQ1相当の別配布がすでにあり、そちらは試せていません。
ただし、容量の話も切り離して書いておきます。現状で配布されている最小の量子化が98.6GiBである以上、これを手元で動かすには最低でも約99GBのメモリが要ります。128GBのユニファイドメモリを積んだEVO-X2でも、実際に使える上限(約112GiB)との差は13GiBほどしかなく、余裕があるとは言えません。一般的なパソコン(多くは16〜64GB程度)では、この時点で選択肢に入らないというのが実情です。
「容量が足りるか」だけを見て判断すると、今回のような読み込みの失敗は見落とします。一方で、容量の壁がもともと高いモデルでもあります。新しいモデルを試すときは、容量の計算と、動かす道具がそのモデルの構造(architecture)に対応しているかの、両方を確認したほうがよさそうです。対応が入るまでの間は、前の版を試すという選択肢も残っています。
もっと軽い量子化や、より少ないメモリで動く軽量版が出てくるかどうかも含めて、しばらく様子を見ながら待つことにします。