DeepSeek V3.2 でローカル実行:671BのMoEが利用可能 mortels
DeepSeek V3.2をローカルにインストールするには、総パラメータ数6710億、トークンごとに有効になるパラメータ数370億、そして長いコンテキストで状況を一変させる新しいスパースアテンション機構という現実を受け止める必要があります。このガイドでは、宣伝文句ではない実際のハードウェア要件を示し、ik_llamaのQ2_K_XL量子化を説明し、--override-tensorによる選択的オフロードの巧みな手法を紹介します。最後に、2026年に自宅のワークステーションで測定したトークン/秒の値を示します。
#DeepSeek V3.2 をローカルにインストールする理由
DeepSeek V3.2は、DeepSeek AIが2025年末にMITライセンスで公開した中間アップデートで、V3から2つの重要な変更が加えられています。1つはDeepSeek Sparse Attention(DSA)というスパースアテンション機構で、長いコンテキストに伴うメモリコストの増え方を二次関数より緩やかにします。もう1つは、マルチトークン予測の学習方法の改良です。理論上は、V3の品質を維持しながら、128k以上のトークンで効率が向上します。
ローカルにインストールすることで、3つの具体的なニーズに応えられます。完全なプライバシー(文書がDeepSeekに一切送信されない)、再現性(モデルの重みがある日突然消えることがない)、自由な実験(レート制限も、強制されるモデレーションフィルターもない)です。
#MoE 671B / アクティブパラメータ37B + DeepSeek Sparse Attention
お使いのマシンで、プライベートかつ無料の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キャッシュが線形に膨れ上がることはなくなります。
#実態に即したハードウェア要件
一般消費者向けのどのマシン構成でも、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トークン/秒。夜間のバッチ処理には使えますが、対話的な利用には向きません。
#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サーバー向けです。それ以上では、ローカル利用で得られる品質向上はわずかになります。
#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%向上します。
Apple Silicon 搭載 Mac では、GGML_CUDA を GGML_METAL に置き換える。AMD では、ROCm 6.3 以降と GGML_HIP を使用する。最近のマシンでもビルドには 10〜15 分を見込んでください。CUDA コードの生成を伴う C++ のビルドなので、ノート PC を AC 電源に接続せずに実行しないでください。
#3. GGUF V3.2をダウンロードする
DeepSeek V3.2のGGUF形式の重みはHugging Faceで公開されています。Q2_K_XL Unsloth(ほとんどの構成で推奨される選択肢)の場合、ダウンロード対象は約220GBの一式で、複数のファイルに分割されています。
一般家庭向けのインターネット回線では、ダウンロードに数時間かかります。安定した光回線と、250 GB以上の空き容量がある保存先ディスクを用意してください。このサイズのGGUFは5〜7個のファイル(split-00001-of-N.gguf)に分割されています。最初のファイルを指定すれば、ik_llama.cppが分割ファイルを自動的に検出します。
#4. --override-tensor による起動(ハイブリッドパフォーマンスの鍵)
DeepSeek V3.2をローカルにうまく導入する鍵は、--override-tensor(別名 -ot)という1つのオプションにあります。このオプションを使うと、正規表現で、どの層をCPU/RAMに残し、どの層をGPUに載せるかを指定できます。MoEでは、すべてをGPUに読み込むのは絶対に避けたいところです(VRAMが足りることはありません)。一方、アテンション層と共有層は、必ず高速化したい部分です。
正規表現 \.ffn_(up|down|gate)_exps\. は、各エキスパートの3つのFFNテンソル、つまり671Bパラメータの圧倒的多数を対象とし、それらをCPU側に留めます。GPUに配置されるのは、アテンション(MLA)、共有エキスパート、埋め込み、ヘッドです。32 GBのRTX 5090では約22 GBのVRAMを使用し、残りをKVキャッシュに使います。
#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トークン/秒です。正直なところ、実用になるのはバッチ処理だけです。
#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 に収まります。
#トラブルシューティング
- 「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年のエコシステムの進展を予測するのに役立ちます。
ご意見、誤りのご指摘、補足はありますか?ぜひお知らせください。皆さんにとってより良いガイドにするために役立ちます。