上級 20 分llama.cpp

DeepSeek V3.2 でローカル実行:671BのMoEが利用可能 mortels

DeepSeek V3.2をローカルにインストールするには、総パラメータ数6710億、トークンごとに有効になるパラメータ数370億、そして長いコンテキストで状況を一変させる新しいスパースアテンション機構という現実を受け止める必要があります。このガイドでは、宣伝文句ではない実際のハードウェア要件を示し、ik_llamaのQ2_K_XL量子化を説明し、--override-tensorによる選択的オフロードの巧みな手法を紹介します。最後に、2026年に自宅のワークステーションで測定したトークン/秒の値を示します。

著者 Mohamed Meguedmi·更新 2026-08-27·Windows・macOS・Linuxでテスト済み

#DeepSeek V3.2 をローカルにインストールする理由

DeepSeek V3.2は、DeepSeek AIが2025年末にMITライセンスで公開した中間アップデートで、V3から2つの重要な変更が加えられています。1つはDeepSeek Sparse Attention(DSA)というスパースアテンション機構で、長いコンテキストに伴うメモリコストの増え方を二次関数より緩やかにします。もう1つは、マルチトークン予測の学習方法の改良です。理論上は、V3の品質を維持しながら、128k以上のトークンで効率が向上します。

ローカルにインストールすることで、3つの具体的なニーズに応えられます。完全なプライバシー(文書がDeepSeekに一切送信されない)、再現性(モデルの重みがある日突然消えることがない)、自由な実験(レート制限も、強制されるモデレーションフィルターもない)です。

i
目指すところを率直に確認しましょう
ローカルに導入したDeepSeek V3.2は、リアルタイムで使えるChatGPTの代替にはなりません。目指すのはむしろ、強力な自宅用ワークステーションで実用的な生成速度(5〜15トークン/秒)を確保し、応答の速さより品質を重視する、推論のバッチ処理、長い文書の要約、複雑なコードの作業に使うことです。

#MoE 671B / アクティブパラメータ37B + DeepSeek Sparse Attention

ローカルAIキット

お使いのマシンで、プライベートかつ無料のChatGPTを1時間で構築 — LM Studio、Ollama、Open WebUI、ご自身のドキュメント、クラウド不要。

  • 永久に利用できるオンラインスペース
  • PDF + ファイル
  • 生涯アップデート

DeepSeek V3.2はV3のMoEアーキテクチャを維持しています。各層でルーターが256個のエクスパートから8個を選択するため、生成される各トークンごとに約370億パラメータのみが動作します。残りの6,340億パラメータは待機状態ですが、アドレス可能でなければ、ルーターは読み込まれていないエクスパートへのアクセスを失います。

総パラメータ数
約6,710億(ビット数にかかわらず、この膨大な量のパラメータをRAM、VRAM、またはmmap経由のSSDのどこかに収める必要があります)。
トークンごとのアクティブパラメータ
約37B。この数値が理論上の速度を決定します。671BのMoEは、37BのDenseモデルと同等の計算コストを伴います。
層ごとのエキスパート
256個のMoEエキスパート+1個の共有エキスパート、top-8ルーティング。RAMが多いほど、より多くのエキスパート層がメモリに常駐し、生成がより安定します。
アテンション
Multi-Head Latent Attention (MLA) はV3から継承され、現在は32kトークンを超えるコンテキストでは DeepSeek Sparse Attention (DSA) と組み合わされています。
コンテキスト
公称128kトークンで、DSAのおかげで実際に活用できます。Qwen 3.5やGemma 4のような従来の密なモデルとは異なり、KVキャッシュが線形に膨れ上がることはなくなります。
→
DSAが本当に変えた点
DeepSeek Sparse Attention は、各トークンに対してコンテキスト全体をスキャンするのではなく、特定の位置のサブセットを待機させるように選択します。128kの場合、KVキャッシュのメモリ消費量は設定により3倍から5倍まで削減され、prefillの速度もそれに応じて向上します。これはV3.2をV3に比べて採用するための唯一の技術的根拠です。

#実態に即したハードウェア要件

一般消費者向けのどのマシン構成でも、DeepSeek V3.2を動かすには無理な工夫が必要です。ここでは、2026年に現実的な3つの構成を、速度と予算の兼ね合いに応じて並べて紹介します。

構成A — 大容量DDR5(192~384 GB)
Threadripper 7960X / Xeon WまたはEPYC 9354Pを搭載したワークステーション、256GBのDDR5 ECCメモリ(8チャネル)。GPUは必須ではありません。Q2_K_XLは全体がRAMに収まります。速度はCPUのみで毎秒5〜9トークンです。
プロファイル B — RTX 5090 + 192GB DDR5(推奨)
2026年の最適な組み合わせ:RTX 5090(32 GB GDDR7、メモリ帯域幅1792 GB/s)+192 GB DDR5を搭載した新しい一般向けプラットフォーム。アテンション層と共有エキスパートをGPUに置き、残りはRAMに配置します。生成速度:10~15トークン/秒。
構成C — 控えめなRAM容量+Gen 4/5のNVMe SSD
96〜128 GBのDDR5+最低7 GB/sのNVMe SSD、空き容量1 TB以上。SSD上のエキスパートをmmapでメモリにマッピングします。速度は1.5〜3トークン/秒。夜間のバッチ処理には使えますが、対話的な利用には向きません。
!
192 GB DDR5(最低限)
RAM が 192 GB 未満の場合、Q2_K_XL 量子化(V3.2 で約 220 GB)は物理メモリに収まらず、SSD から常にページングが発生します。高速な NVMe Gen 5 を使用しても、2 トークン/秒を下回ることになります。RAM の予算が限られている場合は、SSD を飽和させるのではなく、IQ1_S に下げることをお勧めします。

#1. V3.2用の量子化を選択

DeepSeek V3.2のGGUFエコシステムを支える主な提供元は、Unslothとbartowskiの2者です。UnslothはUD(「Unsloth Dynamic」)版を公開しており、有名なQ2_K_XLもその一つです。UDは重要度行列を使い、精度低下の影響を受けやすい層(アテンション、共有エキスパート)を、ほかの部分より高い精度で保持します。これが最終的な品質に実際の差を生みます。

IQ1_S(~150 GB)
動的1ビット量子化。192 GBのRAMに余裕を持って収まります。品質は低下しますが、一般的なチャットには使えます。コーディング用途では避けてください。
Q2_K_XL(約220GB)
ik_llama / Unsloth Dynamicの定番。重要な層はQ4~Q5に保ち、エキスパートはQ2に圧縮します。推論ベンチマークではQ4の品質の約95%を維持します。RAM 256 GB、またはRAM 192 GBと少量のSSDへのオフロードで収まります。
Q3_K_S (~290 GB)
384GBのワークステーション向け。長文コンテキストにおいてほぼQ4レベルの品質を実現。128kトークンを本格的に利用する予定がある場合は推奨します。
Q4_K_M(約400GB)
フル仕様。512GB以上のDDR5メモリを搭載したデュアルソケットEPYCサーバー向けです。それ以上では、ローカル利用で得られる品質向上はわずかになります。
→
Q2_K_SではなくQ2_K_XLを選ぶ理由
671BのMoEでは、量子化の影響の受けやすさが部分によって大きく異なります。アテンション層とルーターはQ2で品質が落ちやすい一方、FFNエキスパートはよく耐えます。Q2_K_XLはこの違いに合わせて混合精度を使いますが、Q2_K_Sはすべての部分に同じビット数を適用します。メモリ使用量が約5%増える代わりに、コーディングタスクの品質が約10%向上します。

#2. ik_llama.cppをコンパイル(V3.2を扱うフォーク)

執筆時点では、ggerganov/llama.cppのメインブランチはDeepSeek V3.2に対応していますが、DeepSeekのMoEルーティングに特化した最適化はありません。Iwan Kawrakowによるフォークik_llama.cppには、エキスパートテンソル向けの高速化されたCUDAカーネルと、DSAへの動的な対応が組み込まれています。構成によっては、V3.2のスループットが30〜50%向上します。

ik_llama.cppをクローンし、コンパイル(CUDA + Flash Attention)
git clone https://github.com/ikawrakow/ik_llama.cpp
cd ik_llama.cpp
cmake -B build \
  -DGGML_CUDA=ON \
  -DGGML_CUDA_FA_ALL_QUANTS=ON \
  -DGGML_CUDA_F16=ON
cmake --build build --config Release -j $(nproc)

Apple Silicon 搭載 Mac では、GGML_CUDA を GGML_METAL に置き換える。AMD では、ROCm 6.3 以降と GGML_HIP を使用する。最近のマシンでもビルドには 10〜15 分を見込んでください。CUDA コードの生成を伴う C++ のビルドなので、ノート PC を AC 電源に接続せずに実行しないでください。

i
ビルド済みバイナリではなくik_llamaを使う理由
ik_llama.cppのLinux/Windowsリリースは存在しますが、コンパイル時に生成されるCUDAカーネルはGPUのcompute capability(RTX 5090はsm_120、RTX 4090はsm_89など)に敏感です。汎用バイナリは汎用フォールバックに落ち、スループットが20〜30 %低下します。この規模では、15分のコンパイル時間は十分に価値があります。

#3. GGUF V3.2をダウンロードする

DeepSeek V3.2のGGUF形式の重みはHugging Faceで公開されています。Q2_K_XL Unsloth(ほとんどの構成で推奨される選択肢)の場合、ダウンロード対象は約220GBの一式で、複数のファイルに分割されています。

Hugging FaceからQ2_K_XLをダウンロード
pip install -U "huggingface_hub[cli]"
huggingface-cli download \
  unsloth/DeepSeek-V3.2-GGUF \
  --include "*UD-Q2_K_XL*" \
  --local-dir ./models/deepseek-v32-q2kxl

一般家庭向けのインターネット回線では、ダウンロードに数時間かかります。安定した光回線と、250 GB以上の空き容量がある保存先ディスクを用意してください。このサイズのGGUFは5〜7個のファイル(split-00001-of-N.gguf)に分割されています。最初のファイルを指定すれば、ik_llama.cppが分割ファイルを自動的に検出します。

!
チェックサムの確認
末尾が1バイト切り詰められた GGUF は、20トークンの間は筋の通った応答を出力しますが、その後は無限ループに陥ります。これは原因を突き止めるのが最も厄介なバグです。初回の推論前に、Hugging Face リポジトリで提供されている SHA ハッシュ値を必ず確認してください。sha256sum を使えば、ファイル1つにつき30秒で済みます。

#4. --override-tensor による起動(ハイブリッドパフォーマンスの鍵)

DeepSeek V3.2をローカルにうまく導入する鍵は、--override-tensor(別名 -ot)という1つのオプションにあります。このオプションを使うと、正規表現で、どの層をCPU/RAMに残し、どの層をGPUに載せるかを指定できます。MoEでは、すべてをGPUに読み込むのは絶対に避けたいところです(VRAMが足りることはありません)。一方、アテンション層と共有層は、必ず高速化したい部分です。

RTX 5090 + 192 GB DDR5(プロファイルB)の起動
./build/bin/llama-server \
  --model ./models/deepseek-v32-q2kxl/DeepSeek-V3.2-UD-Q2_K_XL-00001-of-00005.gguf \
  --ctx-size 65536 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --n-gpu-layers 999 \
  -ot "\.ffn_(up|down|gate)_exps\.=CPU" \
  --threads 16 \
  --flash-attn \
  --host 0.0.0.0 --port 8080

正規表現 \.ffn_(up|down|gate)_exps\. は、各エキスパートの3つのFFNテンソル、つまり671Bパラメータの圧倒的多数を対象とし、それらをCPU側に留めます。GPUに配置されるのは、アテンション(MLA)、共有エキスパート、埋め込み、ヘッドです。32 GBのRTX 5090では約22 GBのVRAMを使用し、残りをKVキャッシュに使います。

CPUのみで起動(構成A、256GB DDR5)
./build/bin/llama-server \
  --model ./models/deepseek-v32-q2kxl/DeepSeek-V3.2-UD-Q2_K_XL-00001-of-00005.gguf \
  --ctx-size 32768 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --threads 32 \
  --flash-attn \
  --host 0.0.0.0 --port 8080
→
32kでもKVキャッシュを量子化する
V3.2では、--cache-type-k q8_0 --cache-type-v q8_0 により、KVキャッシュの消費量が2倍になり、品質の低下は目立たないため、32GBのGPU上で64kのコンテキストを保持できるようになります。24kではOOMエラーが発生するのを回避できます。

#5. 自宅のワークステーションで測定したトークン/秒

ik_llama.cppの2026年5月のビルドを使い、Q2_K_XL、コンテキスト32k、フランス語とコードを混在させたプロンプトで測定した参考値です。数値は、プロンプトやメモリページのウォームアップ状況に応じて±15%の範囲で安定しています。

RTX 5090 + Ryzen 9 7950X3D + 192 GB DDR5-6000
プリフィルは約110トークン/秒、生成は12~15トークン/秒。2026年の家庭用推奨構成。
RTX 4090 + Threadripper 7960X + 256 GB DDR5 ECC
プリフィルは約90トークン/秒、生成は9〜12トークン/秒です。このハイブリッド構成では、4090は5090と同等の性能を発揮します。ボトルネックがGPUではなくRAMにあるためです。
EPYC 9354P + 384 GB DDR5 ECC (12チャンネル)、GPUなし
プリフィルは約70 tok/s、生成は7〜9 tok/s。総メモリ帯域幅(約460 GB/s)が、GPUがない分を補います。
Mac Studio M3 Ultra 192GB
Q2_K_XL ではプリフィルが約55トークン/秒、生成が6~8トークン/秒。統合メモリの帯域幅(約820 GB/秒)が助けになります。
Ryzen 9 7950X + 128 GB DDR5 + SSD Samsung 990 Pro
プリフィルは約25トークン/秒、生成は1.5〜2.5トークン/秒です。正直なところ、実用になるのはバッチ処理だけです。
i
プリフィルは速く、生成は遅い理由
プリフィルはプロンプトをバッチ処理し、行列演算の並列処理を活用します。この段階でメモリ帯域幅とGPUが真価を発揮します。生成ではトークンを1つずつ出力し、そのたびにルーティングで選ばれた約37Bのパラメータを読み直す必要があります。これはMoEに本質的な特性であり、llama.cppのどのフォークでも劇的な改善は望めません。

#DeepSeek V3.2 と DeepSeek R1:どちらをインストールすべきか?

よくある質問です。両モデルは同じ MoE 671B / アクティブ 37B アーキテクチャと、同じ MIT ライセンスを共有しているためです。違いは骨格ではなく、後学習(ポストトレーニング)にあります。

DeepSeek V3.2
汎用モデル(チャット)で、端的に回答します。フランス語に非常に強く、コーディング能力も高いモデルです。長いコンテキストに対応するためにDSAを追加しています。日常のアシスタント、要約、文章作成におすすめです。
DeepSeek R1
推論モデル(o1のように思考連鎖を明示します)。最終回答の前に、多数の内部トークン(<think>...</think>)を出力します。数学、論理、複雑なアルゴリズムのデバッグに優先して使うモデルです。
推論コスト
R1 は、思考プロセスにより同じ最終回答を生成するために、3から10倍のトークンを生成します。同じ出力速度で、R1は5分かかりますが、V3.2は30秒で完了します。ローカル環境での評価において、各トークンの処理速度は重要です。
長コンテキスト
V3.2 は DSA により、KV キャッシュの容量を抑えながら128kトークンを処理できます。R1 には DSA がなく、64kトークンを超えるとメモリ使用量が急増します。
必要なVRAM/RAM
同じです。両モデルは 671B/37B のアーキテクチャを共有しており、どちらも同じ Q2_K_XL 量子化で約220 GB に収まります。
→
実用的な結論
デフォルトでV3.2をインストールし、数学的な証明や複雑なデバッグ作業など、明示的な思考プロセスが必要なタスクではR1に切り替えてください。多くのローカルユーザーは、NVMeに両方のGGUFモデルを保持し、シンプルなルーティングワッパーを使用しています。

#トラブルシューティング

「unknown model architecture: deepseek2」
お使いのllama.cppが古すぎるか、deepseek2のサポートなしでコンパイルされています。ik_llama.cppを更新し(2026年4月より後のmainブランチ)、再コンパイルしてください。標準のビルド済みバイナリでは不十分な場合があります。
読み込み時点でCUDAのOOM(メモリ不足)が発生
-ot に指定した正規表現では、CPU に十分な数のエキスパートが割り当てられていません。ik_llama-bench を使い、ollama-style の方法でテンソルの実際の割り当てを確認してください。V3.2 用の適切な正規表現では、ffn_exps だけでなく、ffn_(up|down|gate)_exps を対象にする必要があります。
192GB RAMで1トークン/秒の生成
カーネルは、頻繁に使われるページをすべて読み込むまで、GGUFからページを読み込んでいきます。最初に200トークンのウォームアップ用プロンプトを実行すると、エキスパートが事前に読み込まれます。それでも改善しない場合は、--threadsを物理コア数(論理コア数ではありません)まで増やしてください。
理由もなく回答が中国語に切り替わる
チャットテンプレートが正しくありません。--chat-template が auto モードになっており、GGUFにDeepSeek用のJinjaテンプレートが含まれていることを確認してください。そうでない場合は、--chat-template deepseek3 を明示的に指定してください。
DSAが有効になっていないように見える(KVキャッシュが線形)
DSAが有効になるのは、コンテキスト長が設定可能な最小値に達してからです。16k未満のコンテキストでは、モデルは従来の密なアテンションを使います。これは想定どおりの動作で、品質には影響しません。
ウォームアップ後、長いプロンプトでクラッシュする
おそらくスワップ領域を使い切っています。DeepSeek V3.2はスワップとの相性がよくありません。物理RAMが足りない場合は、スワップを無効にし(sudo swapoff -a)、mmapによるページング管理をllama.cppに任せてください。そのほうが高速で安定しています。

#さらに詳しく

DeepSeek V3.2 をローカルで実行することは、「セルフホスト可能なフロンティアモデル」クラスを探索するための出発点です。3つの補完的なアプローチがあります。

llama.cppのビルドをさらに最適化する
ガイド「llama.cppをCUDAでコンパイルする」では、MoEの性能を実際に左右する高度なフラグ(Flash Attention、MMQ、テンソルのオフロード)を詳しく解説しています。
現在使われている量子化手法を理解する
「量子化の選択(Q4、Q5、Q8、FP16)」ガイドでは、通常の Q2 ではうまくいかない場面で Q2_K_XL が機能する理由と、Q3やQ4に上げるべきタイミングを説明しています。
サイズをさらに拡大する
「Kimi K2 ローカルガイド」は、1TパラメータのMoEモデルにも同様の手法を適用しており、2026〜2027年のエコシステムの進展を予測するのに役立ちます。
このガイドは役に立ちましたか?

ご意見、誤りのご指摘、補足はありますか?ぜひお知らせください。皆さんにとってより良いガイドにするために役立ちます。