2 ビット量子化の MoE 「Nemotron 3.5 Bolt 74B-A9B」を DGX Spark で動かしてみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

NVIDIA が Nemotron 3.5 の新しいモデルを 3 つ発表しました。120B の Super VL、24GB に収めた Bolt 74B-A9B、そして 10 月 23 日に出る 4GB の Bolt E4B です。

https://blogs.nvidia.com/blog/nemotron-3-5-super-vl/

この中でまず最初に気になったのは Bolt 74B-A9B でした。総パラメータ 74B、1 トークンごとに使う重み（アクティブパラメータ）は 9B の MoE を、expert の重みを 2 bit まで削って 24GB に収めています。今回は NVIDIA が学習の段階から 2 bit を含めてリリースしています。

8 月に同じ Nemotron 3.5 の Lightning を公開当日に測っているので、今回も同じ課題・同じ条件で並べます（2026-08-12 時点の記事です）。

https://dev.classmethod.jp/articles/dgx-spark-nemotron-3-5-lightning-first-touch/

先に結論を書いておくと、2 bit の重みで日本語 8/9、コード生成 5 問 49 テスト全通過と、Lightning と同じか部分的に上の判定でした。公開当日の llama.cpp がすでに対応していて、モデルカードの DGX Spark 向けレシピをそのまま流すと 22 秒で立ち上がります。投機デコードを載せた単発の速さは 61.61 tok/s で、常駐は 31 GiB。128GB の DGX Spark で使うには余裕がありすぎるくらいで、むしろ「なぜこのサイズで出してきたのか」のほうが面白い問いになりました。

この記事では、公開翌日の Nemotron 3.5 Bolt 74B-A9B 24GB を DGX Spark の llama.cpp で動かした結果を紹介します。速度・日本語・コード生成・ツール呼び出し・画像を Lightning や GLM の 2 ビットと同じ条件で測り、最後に 24GB と 4GB というサイズの読み方を書きます。

Nemotron 3.5 Bolt 74B-A9B の素性

まず何者かを一次情報で押さえます。数字はモデルカードと config.json、GGUF のメタデータから取っています。

Lightning のときは 52 層のうち attention が 6 層でしたが、Bolt は 88 層で attention が 8 層です。親の Super VL と同じ層数で、config.json の llm_config を見ると NemotronHPuzzleForCausalLM という名前になっています。

Puzzle という名前のとおり、層ごとに MoE の形が違います。入力ごとに選ばれる expert の数は層によって 240 から 496 まで、中間層の幅も 1,536 から 2,560 まで 12 通りの組み合わせが並んでいます。Lightning は全層が 128 expert の top-6 で揃っていたので、ここは見た目からして別物です。モデルカードの説明では、「24GB 未満」という予算を与えた振り分け役（router）が層ごとに expert の数と幅を選び、親モデルから蒸留で削り出したとあります。親から子を切り出した跡が、そのまま層の凸凹として残っている形ですね。

2 ビットの中身も GGUF を開いて確かめました。

20.5 GiB のうち 16.3 GiB が 2 ビットの expert です。NVIDIA は量子化後に QAD（量子化を前提にした蒸留）で精度を戻したと書いています。公開後に外から削る GGUF との違いはここで、2 ビットで動くことを前提に親から学び直しているわけです。

公式ベンチの対照表は、Lightning と Qwen3.6-35B-A3B、Gemma4 26B-A4B が相手です。

Lightning の BF16 に対して、Bolt は 2 ビットの状態で Terminal-Bench が 2 倍です。アクティブが 3B から 9B に増えた分が、そのまま出ているように見えます。この看板が手元の課題でも出るかを見ていきます。

動かすまで

今回も拍子抜けするくらい、あっさり動きました。

llama.cpp の master には、公開当日の 10 月 15 日付で Bolt の対応が入っています。手元の DGX Spark には 8 月時点の llama.cpp があったので、master を取り直して GB10 向けに build しました。build の指定は -DCMAKE_CUDA_ARCHITECTURES=121 だけです。

起動コマンドは、モデルカードの「RTX Spark 128GB」向け 32GB レシピをそのまま使えます。

llama-server \
  --model "$MODEL" \
  --mmproj "$MMPROJ" \
  --batch-size 4096 \
  --ubatch-size 2048 \
  --ctx-size 262144 \
  --parallel 1 \
  -ngl 999 \
  --spec-type draft-dflash \
  --spec-draft-n-max 7 \
  --spec-draft-model "$SPEC_DRAFT" \
  --spec-draft-ngl 999 \
  --temp 1.0 \
  --top-p 0.95 \
  --flash-attn on \
  --jinja

投機デコードは DFlash 方式で、ドラフトは LiLiCorr という 0.93 GiB の別 GGUF です。llama.cpp の DFlash は --spec-type draft-dflash と --spec-draft-model の組で指定します。起動ログにドラフトの読み込みと n_max=7, block_size=8 が出るので、投機が載ったかはここで確かめられます。

ダウンロードから起動までの実測値です。

llama.cpp は重みを mmap で読むのでコンパイルも KV の事前確保もなく、GGUF を開いたらそのまま上がります。常駐の 31.4 GiB はモデルカードの「32GB レシピ」どおりです。設計目標の「batch 1、128K で 24GB 未満」より大きいのは、このレシピがコンテキストを 262,144 まで張っているためです。

モデルカードには vLLM のレシピもあります。nightly イメージに 2 bit 用の b12x カーネルを追加で入れる構成です。DGX Spark 向けの nightly-aarch64（10 月 15 日 push）でも起動しました。投機デコードなしの単発は 31.46 tok/s で、同じ条件の llama.cpp（39.47 tok/s）より 2 割遅い値でした。llama.cpp 側はさらに DFlash で 1.5 倍になります。この記事の数字は、速く上がって速く動く llama.cpp 側で揃えました。

測定条件

速度の章では、レシピ逐語の --parallel 1 と、他のモデルと揃えた --ctx-size 65536 --parallel 8 の 2 本を分けて測りました。日本語以降の課題はすべて後者で、投機デコードは載せていません。llama.cpp は --ctx-size を同時に処理する枠（スロット）の数で割るので、8 スロットでは 1 本あたり 8,192 トークンが上限です。サンプリングは推奨値の temperature 1.0 / top_p 0.95 です。予算（出力トークンの上限）は 8,192 を基本にし、打ち切りが出た課題だけ 2 スロット（1 本あたり 32,768）の起動で 16,384 の行を別に足しています。

比較対象は 2 つです。同じ llama.cpp で動く 2 bit の GLM-5.3-Flash（Unsloth UD-Q2_K_XL、320B-A18B）と、同じ Nemotron 3.5 の Lightning 30B-A3B（NVFP4、vLLM）です。GLM は別の DGX Spark で、Lightning は vLLM で測った値なので、速度は並べず品質の判定だけを並べます。GLM の思考の強さは最上位の max、Lightning と Bolt は high で揃っていません。その旨は各表の下に書きます。

速度

まずレシピ逐語の --parallel 1 で、投機デコードの効きを見ます。強制長 256 トークン・temperature 0 で 3 回測った中央値です。

1.56 倍です。ドラフトの受理率（先読みした候補のうち本体が採用した割合）は llama-server の統計で読めます。速度測定の固定文で 35%（511 本中 181 本、平均受理長 3.45）、日本語の 3 文説明で 39%、ツール呼び出しの短い応答で 56% でした。先読み 7 段のうち 3〜5 段が当たっている計算で、Lightning の DSpark で見た受理長 3.27 とほぼ同じ水準です。

同時実行数を変えた側は、他のモデルと揃えた --ctx-size 65536 --parallel 8、投機なしで測っています。

8 本同時で合計 102.45 tok/s、1 本あたりは 13.26 tok/s まで落ちます。単発の 39.30 から 3 分の 1 です。同じ llama.cpp の 2 ビット MoE である GLM-5.3-Flash は、別の機体で単発 17.72 tok/s、8 本合計 63.97 tok/s でした。アクティブ 18B の GLM に対して 9B の Bolt が 2.2 倍速いのは、動く重みの量の差がそのまま出ています。

Lightning のほうは vLLM で単発 79.59 tok/s、8 本合計 331.97 tok/s でした。エンジンが違うので同じ表には載せません。この差にはアクティブ 3B と 9B の差に加えて、llama.cpp の 2 ビット MoE のカーネルが 8 並列でどこまで伸びるか、という差も乗っています。並列で伸び悩むのは、モデルカードが「1 シーケンス」を前提に 24GB を設計していることとも整合します。この Bolt は 1 人で使うときに速いモデルで、チームで 1 台を共有するなら Lightning のほうが向いています。

日本語

日本語 10 課題を投げました。予算は 8,192、思考は high です。判定は機械で、文字数や必須語の有無、JSON がパースできるか、といった機械的に確かめられる条件で採点しています。

自由記述は機械で採点できないので合計から外しています。GLM の列は思考の強さが max、予算は同じ 8,192 です。

2 ビットの日本語は壊れていませんでした。GLM の 2 ビットが落とした 50 字制約と語彙制約を Bolt は通し、機械判定は Lightning と同じ 8/9 です。語彙制約の課題では、必須語 3 つを入れて禁止語 2 つを避けた 207 字の社内連絡文がそのまま使える出来でした。

落としたのは固有名詞を保ったまま要約する課題で、12,303 字考えたところで 8,192 トークンの枠を使い切り、本文が出ませんでした。この課題は Lightning も GLM も同じ落ち方をしていて、8,192 ではどのモデルも思考で紙を使い切ります。そこで Bolt だけ、スロットあたりのコンテキストを 32,768 に広げた別の起動で、予算 16,384 の行を測り直しました。

結果は変わりませんでした。16,384 トークンを丸ごと思考に使い、25,525 字考えたところで再び枠が尽き、本文は出ていません。他の 9 課題は 16,384 でも同じ判定です。Lightning は 16,000 まで広げると、20,678 字の思考のあとに本文を出して固有名詞を落とす落ち方でした。Bolt のほうはこの課題に限って思考が止まらない、と読むのが正直なところです。後で見る medium の設定では同じ課題を 1,105 字の思考で答えて 6 語中 4 語を残したので、この課題は思考の強さの選び方で見え方が変わります。

思考の長さに目を向けると、Bolt は Lightning よりだいぶ短く考えます。50 字で答える課題で Lightning が 7,245 字なのに対し Bolt は 652 字、敬語の言い換えでは 6,839 字に対して 558 字です。アクティブ 3B の Lightning は迷いながら長く考え、9B の Bolt は短く決めて答える。同じ 8/9 でも、答えにたどり着く道の長さが 10 分の 1 でした。生成速度は Lightning のほうが 2 倍速いのに、10 課題の合計時間は Bolt の 356 秒に対して Lightning が 307 秒とほぼ並んでいます。この思考の短さのおかげです。

思考の強さを変えた行も測りました。Bolt の思考は 3 段で、既定の high、最後の発話に「reasoning effort: efficient」を添える medium、そして思考を切る off です。

medium が面白いところで、消費トークンが 4 分の 1、所要が 4 分の 1 になっても機械判定は 8/9 のままでした。固有名詞の要約も、high が枠を使い切って本文を出せなかったのに対し、medium は 183 字で 6 語中 4 語を残しています。落ちはしたものの、答えは出ています。思考を切ると 6 語すべて残す代わりに 257 字まで膨らんで字数制限を破り、語彙制約でも必須語を 1 つ落としました。Lightning と同じで、思考は指示を守るために使われているようです。1 人で対話に使うなら medium が釣り合いのよい設定に見えます。

コードを書かせる

日本語の仕様書からゼロで書かせる 5 問と、バグの入ったミニリポジトリを修正させる課題の 2 本立てです。採点はこちらで pytest を回して判定し、モデルの自己申告は使いません。

仕様からゼロで書く

全問正解で、テストも 49 個すべて通りました。差が出たのは parse_duration（「1h30m」のような文字列を秒に直す問題）です。Lightning はこの問題だけ 8,192 の予算を思考で使い切ってコードを出せず、16,000 まで広げてようやく解いていました。GLM の 2 ビットも同じ落ち方です。Lightning は 26,056 字、GLM は 27,064 字考えたところで紙が尽きていて、Bolt は 8,696 字の思考と 2,792 トークンで解き切っています。同じ予算で、同じ問題を、3 分の 1 の思考で解いたことになります。

既存のバグを直す

12 個のテストのうち 5 個が失敗するミニリポジトリを渡して、ファイル読み書きのツールだけで直させる課題です。

3 つとも 12 テスト全通過まで持っていきます。Bolt は 5 ターンで直し切りました。Lightning は 13 ターンかけて同じ結果に届いていたので、1 ターンあたりに進む量が違います。壊れた呼び出し（パースできない出力）は 0 件でした。

ツールとして使えるか

エージェントの部品として使えるかを見ます。ツール呼び出しの形式は Lightning と同じ XML です。llama.cpp は --jinja を付けるだけでテンプレートからこの形式を読み取り、OpenAI 互換の JSON に直して返してくれます。vLLM のようにパーサ名を指定する必要はありません。

<tool_call>
<function=get_weather>
<parameter=city>
Tokyo
</parameter>
</function>
</tool_call>

基本的な呼び出しは 5 問すべて通りました。擬似ファイルシステムを渡してバグを探させる課題も 4 ターン・6 回のツール呼び出しで解け、壊れた呼び出しは 0 件です。ストリーミングでもツール呼び出しと思考の両方がチャンクに乗ってきます。

required で止まらなくなる問題は出なかった

Lightning で一番はっきりした問題は、「必ずツールを呼べ」と指定する tool_choice: required で同じ呼び出しを 159 回返し続けることでした。Bolt では出ません。

Lightning のときは vLLM の qwen3_coder パーサとの組み合わせを疑っていました。今回は同じ XML 形式を llama.cpp のテンプレート経由で読んでいて、1 件で止まります。モデルの世代差なのか、エンジン側の違いなのかはこの 1 観測では切り分けられませんが、llama.cpp で Bolt を使う限りはこの心配はなさそうです。

複数のツールをどう呼ぶかも見ました。「東京と大阪の天気を教えて」のような 2 か所への問い合わせで、Lightning は 1 件ずつ 2 ターンに分けていましたが、Bolt は 1 つのメッセージに 2 件まとめて返しました。親の Super VL と同じ呼び方です。場面依存なので 1 回の観測で性格と決めつけませんが、ツールの往復に時間がかかる環境では有利な向きです。

エージェントの部品としての適性

opencode や Hermes Agent のようなハーネスに載せられるかを、6 つのプローブで見ます。ここで測っているのは各ハーネスが依存する能力であって、ハーネス本体を動かした結果ではない点は先に断っておきます。

Lightning の列は予算 4,096 で測った値で、定型フォーマットは 16,000 まで広げると 10/15 まで改善していました。Bolt の 3 列は 8,192 です。

ツール選択は、40 個のツール定義を積んだ状態で 6 つの依頼を出し、期待どおりのツールを選ぶかを見ます。Bolt は 3 条件とも同じ 2 問を外しました。「毎朝 9 時に実行するよう設定して」で cron を作るツールを選ばないのは Lightning と同じ外し方で、Bolt はさらに「ファイルに追記して」で読み取りのツールを選びます。思考の強さを変えても同じ 2 問を外すので、思考の量より選び方の癖のようです。

定型フォーマットの再現は、日報のテンプレートを 5 回書かせて毎回同じ構造になるかを見る課題です。Lightning は 4,096 の予算で 5 回とも本文 0 文字でしたが、Bolt は high で 4/5、medium では 5 回とも同じ構造で書けました。high で崩れた 1 回は見出しの順も揃っていて、1 つの節が 3 行のところを 2 行で書いただけです。思考を切ると 2〜3 秒で返ってくるものの、5 回のうち 3 通りの形に揺れて、長い system prompt の「最後に要約の 1 行を置く」というルールも落とします。思考を切ったときの崩れ方も Lightning と同じでした。

一方で medium は、長い system prompt の要約行のルールを 1 つ落としています。定型を安定させたい用途と、長いポリシーを守らせたい用途で、釣り合う思考の強さが違うわけです。

ハーネス別の判定は、3 条件とも opencode・Hermes Agent・OpenClaw のすべてで「厳しい」でした。引っかかっているのはツール選択の 2 問と、条件によって定型か長い system prompt のどちらかです。実行層の仕事（ツールを呼び、結果を確かめ、バグを直す）は 5/5 で通しているので、Lightning のときと同じく、落とすのは書類仕事と選択の癖の側です。繰り返しになりますが、これは能力のプローブで、ハーネス本体を載せた結果ではありません。

画像

Bolt は画像も読めるモデルなので、GGUF 同梱の mmproj を付けて 3 つのプローブを通しました。

3 つとも通りました。幻覚（写っていない物を挙げる）は 0 件です。GGUF と mmproj の経路で通るのは静止画だけで、モデルカードにある動画入力は今回は測っていません。Lightning はテキスト専用だったので、同じ Nemotron 3.5 で画像を読めるのは Bolt の側の強みです。

なぜ 24GB と 4GB で出してきたのか

ここからは実測を離れて、サイズの読み方です。

モデルカードには設計目標が一文で書いてあります。「batch size 1、128K コンテキストで、配備時の常駐メモリを 24GB 未満にする」。量子化後の重みと、推論中に持つ状態（2 ビットの expert と 16 ビットの Mamba の状態）まで含めた予算です。この数字が狙っているのは、同じ日に発売された RTX Spark のノート PC と、32GB の GeForce RTX 5090 でしょう。発表ブログも「24GB に収めて、他のアプリと並行して動かす」と書いています。ゲームや動画編集の隣に常駐させる前提の数字で、128GB の DGX Spark で動かすと 90GB 以上が余るのはそのためです。

もうひとつの読み方は、作り方のほうにあります。Bolt は、Super VL 120B-A12B から Star Elastic という手法で切り出した子です。親の重みを 8K コンテキストで 72B トークン、128K で 48B トークンぶん蒸留して回復し、そのあと 2 ビットに削ってもう一度蒸留しています。Lightning は別の骨格（52 層、128 expert）で、Super VL の直系は Bolt のほうです。親を 1 つ育てておけば、予算を変えるだけで別のサイズの子を切り出せる。E4B 4GB が同じ手法かは公開されていませんが、サイズの階段を増やすコストが下がっているのは確かです。

階段を手元の機材で並べると、こうなります。

自分が最初に期待した「ドメイン特化のファインチューニングの受け皿」としては、Bolt 74B は少し違うところにいます。学習の起点になるのは量子化前の BF16 版で、Hugging Face の safetensors は 149.8GB あり、128GB の DGX Spark には載りません。2 ビットの GGUF は学習の起点ではなく、学習済みを配るための形です。手元で特化学習をするなら、BF16 が 65.8GB に収まる Lightning のほうが現実的で、4B 級の E4B が出れば Jetson 込みでそちらが本命になるでしょう。Bolt 74B は「賢い実行役を 24GB で配る」側のサイズだと読んでいます。

その読みで手元の数字を見直すと、収まりがよくなります。1 人で使う単発は投機デコード込みで 61.61 tok/s。Lightning より短い思考で同じ判定に届き、parse_duration のような 1 万字級の思考が要る問題も 8,192 の予算で解く。コーディングエージェントを 1 人で回す用途に寄せた調整に見えます。逆に 8 並列で 1 本あたり 13 tok/s まで落ちるので、チームで 1 台を共有する用途は Lightning に任せる。同じ Nemotron 3.5 でも、置き場で選び分ける設計です。

まとめ

Nemotron 3.5 Bolt 74B-A9B 24GB は、2 bit の重みでも日本語 8/9、コード生成 5 問 49 テスト全通過、ツール呼び出し 5/5 でした。2 bit は精度の劣化を覚悟して選ぶ数字のはずでしたが、手元の課題ではその劣化が出ませんでした。学習の段階で 2 bit を織り込む QAD の効きは、手元でも確かめられたと思います。

動かすのは簡単でした。公開当日の llama.cpp master が対応していて、モデルカードのレシピをそのまま流すと 22 秒で上がり、常駐は 31 GiB。DFlash の投機デコードで単発 61.61 tok/s です。一方で 8 並列は合計 102 tok/s と伸びず、設計が 1 シーケンス前提なのが数字に出ています。

24GB は DGX Spark のためのサイズではなく、RTX ノートや 32GB の GeForce で他のアプリと同居するための予算でした。ファインチューニングの起点は BF16 の 149.8GB で手元には載らないので、特化学習の受け皿は Lightning か、10 月 23 日に出る E4B に回ります。Bolt 74B は、賢い実行役を 24GB に詰めて配るためのモデル、というのが今回の読みです。

続きとしてやりたいのは、10 月 23 日に出る Bolt E4B 4GB です。手元には Jetson Orin Nano Super があるので、4GB が本当にエッジで動くのか、特化学習の受け皿になるのかを、同じ課題で測ってみる予定です。

参考リンク

• NVIDIA の発表ブログ（Super VL と Bolt）（2026-10-15）
• nvidia/NVIDIA-Nemotron-3.5-Bolt-74B-A9B-24GB — モデルカード。設計目標、Star Elastic、QAD の説明と公式ベンチはこちら
• nvidia/NVIDIA-Nemotron-3.5-Bolt-74B-A9B-24GB-GGUF — 今回動かした GGUF。RTX Spark 向けの 32GB / 28GB レシピもここ
• nvidia/NVIDIA-Nemotron-3.5-Bolt-74B-A9B-24GB-LiLiCorr-GGUF — DFlash 投機デコード用のドラフト
• nvidia/NVIDIA-Nemotron-3.5-Bolt-74B-A9B-BF16 — 量子化前の本体。ファインチューニングの起点はこちら
• llama.cpp PR #30520 — Nemotron Super 3.5 VL / Bolt 74B A9B 対応（2026-10-15 merge）
• Star Elastic（arXiv 2605.07182） — 親モデルから予算別に子を切り出す手法
• QAD: Quantization-Aware Distillation（arXiv 2601.20088）
• RTX Spark ノート PC の発売ブログ（2026-10-16 発売、Bolt の置き場）
• Unsloth の Nemotron 3.5 Bolt ガイド — Unsloth 版 GGUF（IQ2_XXS 22GB、1-bit もあり）と RAM 24〜32GB の目安。コンテキストは 128K 表記で公式の 256K と食い違う
• OpenMDW-1.1 ライセンス
• Nemotron 3.5 Lightning を DGX Spark で測った記事 — 比較表の Lightning の数値はここで測ったもの
• GLM-5.3-Flash の 2 ビット GGUF を DGX Spark で測った記事 — 外から削った 2 ビットとの比較