Nemotron-3-Puzzle 75B-A9Bは手元のGPUで動かせるか

NVIDIA-Nemotron-Labs-3-Puzzle-75B-A9B（以下、Nemotron-3-Puzzle 75B-A9B）とは、NVIDIAがNemotron-3-Superを圧縮して作った、Mamba・MoE・Attention混成のハイブリッドMoEモデル。

「アクティブが9.3Bなら、手元の16GB GPUでも動くのでは」——そう考えて検索した人ほど、答えは期待とずれます。結論を先に置くと、このモデルを手元で気軽に動かすのは現時点で難しいです。理由はメモリと実行スタックの2つ。なお、この記事で示すメモリ値には、総パラメータ数からの概算・NVIDIA公式論文の評価値・llama.cpp対応PR投稿者によるGGUFの検証値が混在しますが、いずれも当サイトの実機で測定した値ではありません。出典と単位を分けて示していきます。以下、同じ疑問を持つ人がひっかかる論点を、質問ごとにまとめて答えていきます。

Nemotron-3-Puzzle 75B-A9Bとは何？何がどう圧縮されたモデル？

NVIDIA公式によれば、このモデルはNemotron-3-SuperというハイブリッドMoEを圧縮した派生版です。元のNemotron-3-Superは総パラメータ120.7B、アクティブパラメータ12.8B。これを圧縮した結果、総パラ75.3B・アクティブ9.3Bまで削られました。数字だけ見ると4割近く軽くなった計算になります。

圧縮に使われたのがIterative Puzzleと呼ばれる手法。ハードウェアを意識した構造的な圧縮と、短い知識蒸留による回復フェーズを交互に繰り返します。一気に削り切るのではなく、削っては学習で取り戻すサイクルを回すのが特徴。NVIDIAの説明では、一度で削り切る単発の手法より平均スコアで優れる結果が示されています。

圧縮後も、親モデルの88ブロックというハイブリッドレイアウトはそのまま維持される。（NVIDIA公式モデルカードおよびarXiv公開論文より）

構造そのものは元のまま。88ブロックの内訳はMamba 40・MoE 40・attention 8で、最大コンテキスト長は1Mトークン（Hugging Faceのデフォルト設定はVRAM使用量を抑えるため約256k）。変わったのは各ブロック内部の容量です。専門家の総数自体は維持したまま、1トークンあたりに選ぶアクティブ専門家数（22からレイヤー別の4〜18へ）、専門家内部の中間層サイズ（レイヤーごとに1280〜2688へ）、MambaのSSM状態サイズ（128から96へ）を絞り込むことで、レイアウトを崩さずにパラメータ数を落としています。

サーバ運用の指標としては、1ノードあたりのスループットを大きく引き上げ、扱える同時リクエスト数を伸ばしたと報告されています。ただしこれはデータセンター向けの多GPU構成での話。手元の1台で動かす文脈とは前提が違うため、この記事ではサーバ側の数値をそのまま持ち込みません。ここから先は「では自分のPCで動くのか」に絞って見ていきます。

アクティブ9.3Bなら、小さいVRAMで動く？

ここが最大の勘違いポイント。答えははっきり「現時点で公開されている量子化では、16GBのVRAMに全重みを載せて動かすことはできない」です（システムRAMへのオフロードを使えば動作そのものは可能だが、その話は後述）。アクティブ9.3Bという数字は、1トークンの処理で有効になるパラメータ量の目安です。モデル全体の保存容量ではなく、主にトークンあたりの計算コストを考えるための数字であって、メモリ常駐量の指標ではありません。

MoE（Mixture of Experts）は、モデル内に多数の専門家を持ち、トークンごとに一部だけを選んで計算する仕組み。計算そのものは軽くなります。ところが、どの専門家が呼ばれるかは入力トークンごとにルーターが動的に決めるため、事前に「この専門家しか使わない」と切り出せません。結果として、アクティブ9.3Bだけを保存すればよいわけではなく、通常の推論では総75.3B分の重み全体を、VRAMまたはシステムRAMなど実行時に参照できる場所へ保持しておく必要があります。すべてをVRAMへ常駐させられない場合は、CPUオフロードで一部をシステムRAM側に置くことになります。

たとえるなら、実際に使う工具は毎回数本でも、どれを使うか作業してみるまで分からないので、工具箱ごと手元に置いておくようなもの。使う本数（アクティブ9.3B）は少なくても、置いておくスペース（総パラ75.3B）は箱まるごと要る、という構図です。

だからこそ、可否判定の基準は9.3Bではなく75.3B。速度や計算効率の話とメモリ容量の話を分けて考えるのが、MoEを扱うときの第一歩になります。次は、その75.3Bが量子化でどこまで軽くなるかを、概算と公式・第三者の報告値で見ていきます。

必要メモリは量子化でどれくらい？概算と公開値で確認する

具体的な数字を見ていきましょう。重みだけの必要量は「総パラメータ数 × 1パラメータあたりのバイト数」で概算できます。ただし、以下のメモリ値には性質の異なる3種類が混じります。総パラメータ数から算出した概算、NVIDIA公式論文の評価値、llama.cpp対応PR投稿者によるGGUFの検証値です。いずれも当サイトの実機で測定した値ではないため、出典と単位を分けて示します。

# 重み容量の目安（いずれも当サイトの実測ではない）

# ① パラメータ数からの概算（理論値）
BF16 理論値          : 75.3B × 2バイト   ≈ 150.6 GB
FP8  理論下限        : 75.3B × 1バイト   ≈  75.3 GB
4bit 生データ理論下限 : 75.3B × 0.5バイト ≈  37.7 GB

# ② 実際の量子化形式（スケール・メタデータ・非量子化テンソルが加わり①より増える）
公式NVFP4 評価値      : 約 44.5 GB        （NVIDIA公式論文の評価値）
GGUF 4bit系 PR報告値  : 約 41.6〜48.1 GiB （llama.cpp PR #25444 の検証値）

パラメータ数からの概算では、BF16の理論値で約150.6GB、FP8の理論下限で約75.3GB、4bitの生データ理論下限でも約37.7GB。ただしこの理論値はあくまで下限で、実際の量子化形式ではスケールやメタデータ、非量子化のまま残すテンソルが加わるため、これより増えます。NVIDIA公式論文では、公式NVFP4重みの評価値が約44.5GB。llama.cpp対応PRで報告されているGGUF容量も、UD-IQ4-XLで約41.6GiB、NVFP4で約45.0GiB、Q4_K_Mで約48.1GiB、Q8_0で約77.7GiBと、量子化方式によって幅があります（GGUF 4bit系でも約41.6〜48.1GiB。生データ理論下限の37.7GBより実際は大きくなります）。さらに、これは重みだけの数字で、実際にはここへコンテキスト分のメモリが上乗せされます。最大1M・デフォルト約256kという長いコンテキストに対応する以上、長文を扱うほどこの上乗せは無視できません。NVIDIA論文のNVFP4・1Mコンテキスト評価では、1リクエストあたり約4GBのKVキャッシュが加わると報告されています（この約4GBは論文の単体H100・NVFP4重み・FP8 KVキャッシュ・FP32 Mamba状態という評価条件での値で、ランタイムやKVキャッシュ精度によって変動します）。

ハイブリッド構成なので、この上乗せの性質は純粋なTransformerとは少し異なります。Mambaブロックは状態を圧縮して持つため、コンテキストが伸びてもメモリの増え方が緩やか。一方でattentionブロックは従来通りKVキャッシュを積むので、両者が混ざった分だけ増え方も両者の中間になります。純Transformerの早見表をそのまま当てても、正確には見積もれません。

表で挙げた公式チェックポイントとGGUF量子化は、いずれも一般的な単体GPUには収まりません。PRで報告されている最小容量はUD-IQ4-XLの約41.6GiBで、24GBのGPUでも重みが載り切らない計算です（GBとGiBは基準が異なります。GPUのVRAM表示やllama.cppのログはGiB表記が多いため、突き合わせる際は単位に注意してください）。重みが載ることと、コンテキストを積んで快適に動くことは別問題。これらの重み容量はあくまで「重みだけ」の数字であり、実運用ではKVキャッシュやランタイム領域の分、さらに余裕が要ると考えるのが安全です。

16GBのGPU1枚で動かせる？自社検証のGPU使用量と突き合わせる

「うちのRTX 5080は16GBある。1枚でなんとかならないか」——この疑問には、率直に「現時点で公開されている量子化では無理」と答えます。前のセクションが示す通り、公式NVFP4でも重みは約44.5GB、GGUF 4bit系でも約41.6〜48.1GiB（PRで報告された公開GGUFは41.6〜77.7GiB）。最小のUD-IQ4-XLでも16GB VRAMの約2.6倍で、現在公開されているどの形式でも単体では重みだけで収まりません。

判断の材料として、当サイトのRTX 5080 16GB環境で記録したGPU使用量を突き合わせてみます。qwen3-coder:30b実行時に約10.6GiB、qwen3.6:35b-a3b実行時に約13.3GiBといった値です。ただしこれは「モデル全体がVRAMに常駐した」という意味ではありません。これらは量子化後でも約19〜24GB規模のモデルで、16GB VRAMには全重みが収まらず、CPU／システムRAMへの部分オフロードを含む実行条件でのGPU使用量です。つまりGPU使用量とモデル全体の重み容量は別物で、前者だけから「16GBに載った」とは判定できません。いずれにせよNemotron-3-Puzzle 75B-A9Bは、これら30〜36B級モデルの約2倍以上の総パラメータを持つ75B級。当サイトはこのモデル自体を実機では動かしていません。

では逃げ道はないのか。現実的な選択肢は2つ。1つは、対応ランタイムを使ってモデルを複数GPUへ分割する構成。もう1つは、VRAMに載り切らない分を大容量のシステムRAMへオフロードする運用です。ただし一般的なデスクトップPC（DDR5＋CPUオフロード）で重みの多くをシステムRAM側に置くと、GPU内で完結する構成より速度が落ちやすくなります。動くことと実用的な速さで動くことは別、という前提は外せません。大型モデルをRAMオフロードで動かす手法自体は確立されていますが、75B級ともなれば相応のRAM容量と、速度低下を受け入れる覚悟が要ります（低下の度合いはメモリ帯域と実行方式に左右されます。詳細は後述）。

第三者のGGUFがあるなら、もうすぐ動く？実行スタックの壁

メモリの目処が立っても、もう1つ壁があります。実行スタック、つまりモデルを動かすソフトウェア側の対応です。ここで多い誤解が「GGUF形式のファイルが公開されているなら、llama.cppやOllamaですぐ動く」というもの。第三者によるGGUF変換の存在と、mainline llama.cppの正式対応は、はっきり別物です。

llama.cppでこのモデルに対応する作業は、対応PR（ggml-org/llama.cpp #25444）で進められていますが、現時点でmainlineには未マージです。このPRでは、レイヤーごとに異なるMoE構成の扱い、PuzzleのGGUF読み込み、MTP対応が実装されています。逆に言えば、既存の一様な読み込み処理ではこのモデルを扱えないということ。理由は主に2つで、1つはper-layerで異なるMoE配列を持つ構造、もう1つはMTP（マルチトークン予測）のドラフトヘッドを備えていること。これらに対応するには、mainlineではなく専用のpuzzle-portブランチが必要な状態です。

さらに投機的デコードにも制約があります。ただしこれはモデル固有の恒久的な欠点ではなく、現在のpuzzle-port実装の段階的な制約です。同実装ではMamba2状態のロールバック処理が未完成なため、MTP（マルチトークン予測）を有効にすると通常デコードより遅くなる場合があります（対応PRの報告値でMTP時が約13 tokens/s、通常デコードが約16.6 tokens/s）。速くするための機能が、実装が追いつかないうちは足を引っ張る形。この点も「GGUFがある＝快適に回る」ではない証拠です。なお、PR投稿者は別のWIPブランチでMamba2のロールバック対応による高速化（MTP有効時に通常デコードを上回る報告）も示していますが、この変更は現時点のpuzzle-port本体やmainlineには未統合です。改善の見込み自体は示されている、という段階です。

ここで区別が要ります。実行スタックが「まだ全く動かない」わけではありません。NVIDIA公式モデルカードには、Hugging Face TransformersとvLLMでの実行手順が示されており、公式の想定環境（LinuxとHopper／Blackwell系GPU）では動かせます。追いついていないのは、一般的なローカルGGUF環境で使われるmainline llama.cppであり、そのためOllamaの標準経路でもそのまま利用できる段階とは言いにくい——というのが正確な温度感です。公式サーバ向けスタックでは動くが、手元のGGUF／Ollama環境の対応が待ち、という状況を分けて捉えてください。

結局、手元で動かすならどんな構成が要る？

ここまでの数値と物差しを逆算すると、現実的なハードウェア像が見えてきます。単体の一般向けGPUでは容量が足りないため、方向性は「VRAM総量を稼ぐ」か「大容量RAMでオフロードする」かの2択に絞られます。

VRAM総量で攻めるなら、24GB級GPUを複数枚使い、対応ランタイムでモデルを分割する形になります。ここで注意したいのは、VRAMは複数枚挿せば自動で合算されるわけではないという点。テンソル並列・パイプライン並列・レイヤー分割などにランタイム側が対応している必要があります。しかも24GB級GPUを2枚使っても余裕はありません。最も軽いUD-IQ4-XLの約41.6GiBなら重み容量の上では収まる可能性がありますが、NVFP4（約44.5GB）でもランタイムやキャッシュ用の余裕は限られます。Q4_K_Mの約48.1GiBに至っては、48GiB相当の総VRAMを重みだけでわずかに上回ります。さらに、実際に分割できるかどうかはランタイムの対応とGPU間の割り当て方法に依存します。より大容量のプロ向けGPUや枚数増を検討する形になりますが、価格も消費電力も跳ね上がるため、動かす目的と釣り合うかは冷静に見極めたいところです。

RAMオフロードで攻めるなら、GPUに載り切らない部分をCPU側で処理させます。必要なRAM量は量子化形式・GPUへの配置量・コンテキスト長次第で、最小GGUF（UD-IQ4-XL約41.6GiB）なら16GB GPUへの部分オフロードを併用して64GB RAMでも収容できる余地はあります。ただしOS・ランタイム領域・KVキャッシュまで含めて余裕を持たせるなら96GB以上が現実的です。導入コストは抑えられる反面、速度の低下は避けられません。もっとも低下の度合いはメモリ帯域と実行方式に左右され、一般的なDDR5＋CPUオフロード構成だと、バッチ処理や非対話用途なら許容できても対話的にサクサク使いたい用途には向きにくくなります。一方、広帯域の共有メモリを持つ環境（例：PR投稿者のStrix Halo 128GB＋ROCm環境ではQ4_K_Mが19.9・UD-IQ4-XLが17.7・NVFP4が16.6 tokens/sと報告）ではもう少し実用に近づきます。

そして押さえておきたい前提は、公式のTransformers・vLLM環境（Linux＋Hopper／Blackwell）ではすでに実行できる一方、一般的なローカルGGUF／Ollama環境ではmainline llama.cppの対応待ちで、今すぐ標準スタックのまま動かせるわけではない点。メモリを揃えても、手元のGGUF／Ollama経路ではこの対応が要ります。逆に言えば、llama.cpp mainlineへの対応がマージされれば、GGUFやOllamaを中心とした一般的なローカル実行環境での扱いやすさは大きく変わります。今は「メモリの目処を立てつつ、対応状況を追う」フェーズと捉えるのが妥当です。

まとめ：手元で動かせるかの疑問を一気に整理

Nemotron-3-Puzzle 75B-A9Bを手元で動かせるか、という問いへの答えを整理します。まずメモリの壁。アクティブ9.3Bという軽さに惑わされず、総パラ75.3B分の重み全体を保持する必要があるため、現時点で公開されている量子化では単体16GB VRAMに収まりません。公式NVFP4でも約44.5GB、GGUF 4bit系でも約41.6〜48.1GiBあり、複数GPUか大容量RAMオフロードが前提になります。数値の性質は分けて読んでください。BF16・FP8の値は公表パラメータからの概算です。一方、NVFP4約44.5GBはNVIDIA公式論文の評価値、GGUF約41.6〜48.1GiBはllama.cpp対応PR投稿者の検証値であり、いずれも当サイトの実測ではありません。

次に実行スタックの壁。公式のTransformers・vLLM環境では実行できる一方、一般的なローカル環境で使う第三者GGUFは、mainline llama.cppが未対応（対応PRは進行中だが未マージ）でpuzzle-portブランチが要ります。公式Ollamaライブラリや一般的な標準ビルドでそのまま動作することは確認できません（公開GGUFは少なくともPR #25444のpuzzle-portブランチを含む対応ビルドを前提としています）。ただしこれは執筆時点のスナップショット。llama.cpp mainlineの対応が進めば、GGUF／Ollama中心の環境で動かせる条件は変わっていきます。自分のケースがどこで詰まるか——容量なのか、手元のGGUF／Ollama経路のスタック対応なのか——を切り分けて、対応状況を追いかけるのが次の一手になります。

同ブランドの小型版Nemotron 3 Nanoには4Bと30B-A3Bがあり、当サイトの検証では4B版は16GB GPUに収まる一方、30B-A3BのQ4_K_M版はモデル容量が24GBあり、単体16GB環境ではクラッシュしました（Ollama公式でも4B標準版は2.8GB、30B-A3B Q4_K_M版は24GB。動かすには2枚目のGPUや部分オフロードが要る）。まず手元でハイブリッドMoEの挙動を確かめたいなら、確実に載る4B版から入るのが現実的です。Dense/MoE別の必要VRAMの整理は、別記事のOrnith-1.0解説でも扱っています。

よくある質問

Q. アクティブ9.3Bなら、小さいVRAMで動きますか？

16GB VRAMに全重みを常駐させることはできません。MoEは推論時に一部の専門家しか計算しませんが、どの専門家が呼ばれるかは事前に決まらないため、アクティブ9.3Bだけを保存すればよいわけではなく、総75.3B分の重み全体を、VRAMまたはシステムRAMなど実行時に参照できる場所へ保持しておく必要があります。アクティブ9.3Bは計算量の指標であって、必要メモリの指標ではないためです。すべてをVRAMへ常駐させられない場合は、十分なシステムRAMと対応ランタイムを使ってCPUへオフロードすれば、動作そのものは可能になる場合があります（GPU内で完結する構成より大幅に遅くなります）。「動く」と「全層をGPUに常駐させて快適に動く」は分けて考え、可否判定は必ず総パラ側で行ってください。

Q. 第三者のGGUFがあるなら、すぐ動きますか？

第三者によるGGUF変換の存在と、mainline llama.cppの正式対応は別物です。対応PR（llama.cpp #25444）は進行中ですが、現時点でmainlineには未マージで、動かすにはpuzzle-portブランチが必要な状態です。per-layerで異なるMoE配列とMTPヘッドが対応を阻む要因。なお公式のTransformers・vLLMではすでに実行できるため、「どこでも動かない」わけではなく、詰まっているのは手元のGGUF／Ollama経路です。GGUFファイルの有無だけで動作可否を判断しないのが安全です。

Q. 16GBのGPU1枚で動かせますか？

単体16GBでは厳しいです。公式NVFP4でも重みは約44.5GB、GGUF 4bit系でも約41.6〜48.1GiBあり、16GB VRAMの約2.6倍以上。現時点で公開されている量子化では、単体16GBに全重みは載りません。対応ランタイムによる複数GPUへのモデル分割か、大容量RAMへのオフロード運用が前提になります。RAMオフロードは速度低下を伴い、一般的なDDR5＋CPUオフロード構成では対話用途に向きにくくなります（速度低下の度合いはメモリ帯域と実行方式次第です）。

Q. 記事中の必要メモリの数字は実測ですか？

当サイトによる実測ではありません。記事中には、パラメータ数からの概算値（BF16・FP8・4bit生データ理論下限）、NVIDIA公式論文の評価値（NVFP4約44.5GB）、llama.cpp対応PRで報告されたGGUF容量（約41.6〜48.1GiB）が含まれます。いずれも当サイトの実機で測定した値ではないため、出典を分けて示しています。実際の必要量はランタイムやコンテキスト長で変動します。

参考資料

• NVIDIA公式: Nemotron-Labs-3-Puzzle-75B-A9B BF16 モデルカード（Hugging Face）
• NVIDIA公式: Nemotron-Labs-3-Puzzle-75B-A9B FP8 モデルカード（Hugging Face）
• llama.cpp PR #25444: Nemotron-3-Puzzle 75B-A9B 対応（per-layer異種MoE / GGUF読み込み / MTP、GGUF容量・MTP制約の報告値の根拠）