2026年7月31日、中国のAI企業DeepSeekが大規模言語モデル「DeepSeek V4 Flash」の正式版(0731ビルド)を無償公開しました。公式版のファイルサイズは約167GB、推奨実行環境はNVIDIA GB300を4基搭載したサーバーという、個人には縁遠く見えるモデルです。
しかし結論から言うと、このモデルはGPUなし・DDR4メモリだけの普通のデスクトップPCで動きます。
本記事では、5年以上前のCPUであるRyzen 5 3600とDDR4-2400メモリ96GBという構成で、DeepSeek V4 Flashを実際に動かし、ベンチマークとQwen3.8-27Bとの比較まで行った結果を紹介します。
DeepSeek V4 Flashとは
DeepSeek V4 Flashは、2026年4月24日にMITライセンスで初版が公開され、7月31日に再ポストトレーニングされた正式版がリリースされたオープンウェイトのLLMです。商用利用・改変・再配布が認められています。
主なスペックは以下のとおりです。
| 項目 | 内容 |
|---|---|
| 総パラメータ数 | 2,840億(投機的デコードモジュール込みで3,040億) |
| アクティブパラメータ数 | 130億(MoEアーキテクチャ) |
| コンテキスト長 | 100万トークン |
| ライセンス | MIT |
| 公式版サイズ | 約167GB(FP4+FP8混合) |
注目すべきはMoE(Mixture of Experts)という仕組みです。総パラメータは2,840億ありますが、1トークンを生成するときに実際に計算に使われるのは130億パラメータだけです。つまり「メモリにさえ載れば、計算量は13Bモデル並み」ということになります。これがCPUでも動く理由です。
性能面では、再ポストトレーニングだけで上位モデルのDeepSeek V4 Pro(Preview)をベンチマーク9項目すべてで上回ったと報告されており、特にエージェント用途の能力が強化されています。
量子化版なら82GBまで小さくなる
公式版の167GBはさすがに大きすぎますが、Unslothが公開している量子化版を使えば大幅に小さくできます。
| 量子化 | サイズ |
|---|---|
| 8bit | 約161.9GB |
| 4bit | 約155.1GB |
| 3bit | 約103GB |
| 1bit(UD-IQ1_S) | 約82.5GB |
今回は1.75bpwの「UD-IQ1_M」(約81GiB)を使用しました。
bpw(bits per weight)とは、モデルの重み1個を平均何ビットで記録しているかを表す単位です。LLMの重みは元々FP16(16ビット)などで学習されているので、1.75bpwは本来16ビットだった数値を約9分の1まで圧縮していることになります。なお1.75という値はメインの量子化タイプ(IQ1_M)の名目値で、Unsloth版は精度への影響が大きい層(埋め込み層やattention周りなど)を高いビット数のまま残しているため、ファイル全体の平均では約2.4bpwです。
1bit級の量子化と聞くと品質が心配になりますが、後述するとおり実用的な応答が返ってきます。
検証環境
今回使ったPCの構成です。
| パーツ | 内容 |
|---|---|
| CPU | AMD Ryzen 5 3600(6コア12スレッド、2019年発売) |
| メモリ | DDR4-2400 96GB(16GB+32GB×2チャネル) |
| GPU | Radeon RX 570(今回は不使用) |
| OS | Windows 10 Pro |
ポイントはメモリ容量だけです。モデルが約81GiBあるので、96GBのメモリにぎりぎり収まります。GPUは一切使いません。
llama.cppのビルド
DeepSeek V4のアーキテクチャ(deepseek4)対応は最近llama.cppに入ったばかりなので、必ず最新版を使ってください。古いバージョンではモデルの読み込みに失敗します。
まずリポジトリを取得します。
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
Windowsの場合、Visual Studio(C++ワークロード)をインストールした上で、開発者コマンドプロンプトから以下を実行します。
cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLAMA_CURL=OFF
cmake --build build --target llama-cli llama-server llama-bench -j 8
ビルドが成功すると build\bin に llama-cli.exe などが生成されます。CMakeが自動でCPUの命令セットを検出し、今回の環境ではAVX2が有効になりました。
モデルのダウンロード
Hugging FaceのUnslothリポジトリから、UD-IQ1_Mの分割GGUFファイル(3ファイル、合計約81GiB)をダウンロードします。

DeepSeek-V4-Flash-UD-IQ1_M-00001-of-00003.gguf
DeepSeek-V4-Flash-UD-IQ1_M-00002-of-00003.gguf
DeepSeek-V4-Flash-UD-IQ1_M-00003-of-00003.gguf
分割ファイルは同じフォルダに置いておけば、1番目のファイルを指定するだけで残りは自動で読み込まれます。
実際に動かす
llama-cliで対話モードを起動します。
llama-cli.exe -m DeepSeek-V4-Flash-UD-IQ1_M-00001-of-00003.gguf
初回はディスクからの読み込みに数分かかりますが、その後は普通にチャットできます。メモリ96GBに対してモデルが81GiBなので、mmapによる読み込みでスワップも発生しませんでした。
ベンチマーク結果
llama-benchでプロンプト処理速度(pp512)と生成速度(tg128)を測定しました。
| model | size | params | backend | threads | test | t/s |
|---|---|---|---|---|---|---|
| deepseek4 IQ1_M – 1.75 bpw | 80.93 GiB | 284.33 B | CPU | 6 | pp512 | 3.16 |
| deepseek4 IQ1_M – 1.75 bpw | 80.93 GiB | 284.33 B | CPU | 6 | tg128 | 1.58 |
生成速度は約1.6トークン/秒です。正直、速くはありません。人間の読む速度よりだいぶ遅く、じっと待つ感覚です。
この遅さの原因はCPUの計算能力ではなくメモリ帯域です。DDR4-2400デュアルチャネルの理論帯域は約38GB/sで、1トークン生成するたびにアクティブな130億パラメータ分のデータをメモリから読む必要があるため、ここが上限になります。逆に言えば、DDR5環境(帯域約2.3倍)ならそのまま2倍以上の速度が見込めます。
Qwen3.8-27Bとの比較
「2,840億パラメータのモデルをわざわざ1bit量子化で動かす意味があるのか。普通に27Bモデルを動かせばいいのでは」という疑問が当然湧きます。そこで、Alibabaが2026年8月に公開したばかりの最新モデルQwen3.8-27B(Q4KM量子化、17GB)をOllamaで動かし、同じ質問で比較しました。
質問1: 算数の文章題
「1個120円のりんごと1個80円のみかんを合わせて10個買ったら、合計金額はちょうど1000円でした。りんごとみかんをそれぞれ何個買いましたか?」
| モデル | 結果 | 生成速度 |
|---|---|---|
| DeepSeek V4 Flash (IQ1_M) | 正解(りんご5個・みかん5個) | 1.5 t/s |
| Qwen3.8-27B (Q4KM) | 正解(りんご5個・みかん5個) | 2.62 t/s |
どちらも連立方程式を立てて正解しました。この程度の問題では差がつきません。
興味深かったのは思考プロセス(thinking)の違いです。DeepSeekは日本語の質問に対して日本語で思考し、簡潔に3行程度で解いたのに対し、Qwenは日本語の質問を一度英語に翻訳してから英語で思考していました。日本語ネイティブな使い心地はDeepSeekの方が上です。
質問2: ビジネス系の説明タスク
「日本の中小企業がローカルLLMを導入するメリットとデメリットを3つずつ挙げて、それぞれ1〜2文で簡潔に説明してください。」
| モデル | 生成トークン数 | 生成速度 |
|---|---|---|
| DeepSeek V4 Flash (IQ1_M) | 約550 | 1.5 t/s |
| Qwen3.8-27B (Q4KM) | 709 | 1.84 t/s |
DeepSeekの回答(抜粋)です。
メリット
- データ漏洩リスクの低減: クラウド経由ではなく自社サーバー内で処理するため、機密情報や顧客データが外部に流出するリスクを最小化できる。
- カスタマイズの自由度: 自社の業務や業界特有の用語・データに合わせてモデルをファインチューニングでき、より精度の高い業務支援が可能となる。
- 長期的なコスト安定性: クラウドAPIの従量課金が発生しないため、利用頻度が高くなっても予算が急激に増える心配がなく、月額固定費用で運用できる。
両モデルとも指示どおり「3つずつ・1〜2文」の形式を守り、内容の方向性もほぼ同じでした。ただ、DeepSeekは「モデル更新や脆弱性対応を自社で行う人材負担」といったデメリットまで踏み込んでおり、思考も回答も一貫して日本語で、文のまとまりが良い印象です。一方Qwenの回答には「参入障壁の高いハイエンドモデル」のようなやや不自然な言い回しが混ざりました。
質問3: コード生成
「Pythonで、整数のリストを受け取り、連続する整数の範囲をまとめた文字列に変換する関数 compress_ranges を書いてください。例: [1,2,3,5,7,8,9] は ‘1-3,5,7-9’ になります。」
範囲圧縮と呼ばれる定番の課題です。境界処理(単独の数、最後の範囲、空リスト)でバグが出やすく、コード生成力の差が見えやすい問題です。生成されたコードは、コピーしてそのままテストコードで検証しました。
| モデル | テスト結果 | 生成速度 | 回答完了までの時間 |
|---|---|---|---|
| DeepSeek V4 Flash (IQ1_M) | 全ケース合格 | 1.6 t/s | 約5分 |
| Qwen3.8-27B (Q4KM) | 全ケース合格 | 2.56 t/s | 約8分 |
テストは基本例のほか、空リスト・未ソート入力・負の数([-3,-2,-1,1,2] → “-3–1,1-2”)まで含めましたが、どちらも全ケース合格でした。
DeepSeekが生成したコードは以下のとおりです。
def compress_ranges(numbers):
"""
整数のリストを受け取り、連続する整数の範囲をまとめた文字列を返す。
例: [1,2,3,5,7,8,9] → '1-3,5,7-9'
"""
if not numbers:
return ""
sorted_nums = sorted(numbers) # 入力がソートされていなくても安全に処理
result = []
start = sorted_nums[0]
prev = sorted_nums[0]
for num in sorted_nums[1:]:
if num != prev + 1:
# 範囲を閉じる
if start == prev:
result.append(str(start))
else:
result.append(f"{start}-{prev}")
start = num
prev = num
# 最後の範囲を処理
if start == prev:
result.append(str(start))
else:
result.append(f"{start}-{prev}")
return ",".join(result)
細かい差はいくつかありました。
- 重複値の扱い: Qwenは
sorted(set(nums))で重複を除去しており、[5,5,6] のような入力でも “5-6” と綺麗に返します。DeepSeekは “5,5-6” になりました(問題文では未定義のケースです)。この点はQwenの方が丁寧です。 - 回答の分量と所要時間: Qwenは1,136トークン(思考込み)を生成して約8分かかったのに対し、DeepSeekは約半分の分量で簡潔にまとめ、生成速度が遅いにもかかわらず先に回答が完了しました。トークン単価の速さと、無駄なく答える能力は別物だという良い例です。
- 思考言語: この問題では両モデルとも英語で思考しました。DeepSeekが常に日本語で思考するわけではないようです。
比較のまとめ
- 品質は簡単なタスクでは互角、日本語の自然さと指示追従はDeepSeekがやや優位
- コード生成はどちらも境界ケース込みで完動コードを一発生成。細部の丁寧さはQwen、簡潔さと回答完了の速さはDeepSeek
- トークン生成速度はQwen 27Bの方が2〜7割速いが、DeepSeekは回答が簡潔なため体感の待ち時間は逆転することもある
- メモリ消費はDeepSeekが81GiB、Qwenが約17GBと桁違い
1.75bpwという極端な量子化にもかかわらず、284BのMoEモデルが27Bの4bit量子化モデルと互角以上に渡り合えるのは驚きです。より複雑な推論やエージェントタスクでは、パラメータ数の差がさらに効いてくると考えられます。
高速化するには
今回の1.6トークン/秒をどこまで改善できるか、目安をまとめます。
- DDR5環境への更新: メモリ帯域がボトルネックなので、DDR5-5600デュアルチャネル(約90GB/s)なら3〜4トークン/秒程度が見込めます。CPUとマザーボードの交換が必要です。
- 24GB級GPUの追加: MoEモデルは「attention層とKVキャッシュだけGPUに載せ、巨大なエキスパート層はメインメモリに残す」構成(
-ngl 99 --n-cpu-moe 99)が使えます。生成は2〜3倍、長文プロンプトの処理は5〜10倍になります。 - 多チャネルメモリのワークステーション: EPYCやThreadripperの4〜8チャネル構成なら10倍以上も狙えますが、費用は桁が変わります。
まとめ
- DeepSeek V4 Flash(284B MoE)は、Unslothの1bit級量子化(約81GiB)を使えばDDR4メモリ96GBの普通のPCで動く
- 速度は約1.6トークン/秒。実用ぎりぎりだが、リアルタイム性を求めない用途(文書の要約・下書き生成をバックグラウンドで走らせるなど)なら使える
- 品質は1.75bpw量子化でもQwen3.8-27B(Q4)と互角以上。日本語での思考・応答の自然さは明確に優位
- ボトルネックはメモリ帯域。DDR5化やGPUの追加で数倍の改善余地がある
「フラッグシップ級のオープンモデルが、グラボなしの手持ちのPCで動く」というのは、1年前には考えられなかった状況です。96GB(32GB×2+16GB×2など)のメモリはDDR4なら比較的安価に揃えられるので、大容量メモリを積んだPCをお持ちの方はぜひ試してみてください。

コメント