要点
NVIDIA の Nemotron 3.5 Bolt(総74B・アクティブ9B、2bit 量子化)は、「24GBに収まる」とうたわれたモデルです。手元の RTX 5070 Ti(VRAM 16GB)で動かし、速度、日本語の品質、エージェントの部品としての実力を、同じ条件で Lightning(30B)と nano(4B)と比べました。
-
16GB でも動きました。 生成速度は、Ollama の既定設定で約 36〜46 tok/s(プロンプトにより変動)、投機的デコードを無効にすると約 60 tok/s でした。
num_ctxの設定値を 8,192 から 65,536 に上げても、速度の差は誤差の範囲(−2%〜+3%)でした(プロンプトは短いままで、長い入力を実際に与えた場合は未測定です)。 - 日本語の品質は、この条件では Bolt が概ね最上位でした。 llm-jp-eval の平均は Bolt 0.63、Lightning 0.56、nano 0.46。相対 Japanese MT-Bench(審査員 qwen3:14b)は 8.20、7.78、5.99 でした。ただし Bolt と Lightning の差が確かと言えるのは一部の項目だけで、MT-Bench の差はほぼ reasoning カテゴリだけから来ています。
- エージェントの部品としては、Bolt は Lightning より良い傾向があり、nano とは区別できませんでした。 管理なしの条件(B0)で、全体の成功率は Bolt 0.81、nano 0.76、Lightning 0.68。Bolt と nano の全体の差は、平均 4.7 タスク分で、そのうち 4 タスクは正常区間の差です。1タスクの所要時間は nano の約 3 倍です。
- 条件つきの結果です。すべて思考(thinking)オフで、MT-Bench の審査員は GPT-4 ではありません。限界は 5 章にまとめました。
1. はじめに
ローカル LLM を使う動機は人それぞれですが、私の場合は「手元の 1 台で、できるだけ精度を出したい。特に日本語で」です。クラウドの API に頼らず、自分の PC で動かせることには、費用と情報の扱いの両面で意味があります。
ただ、手元のハードには制約があります。私の PC は VRAM 16GB・RAM 64GB です。モデルの量子化を進めれば大きなモデルも載りますが、削りすぎると品質が落ちるのではないか、という心配があります。
以前の記事では、Nemotron 3.5 Lightning(総30B・アクティブ3B)を 16GB の環境で動かしました。
今回は、その上の Bolt(総74B・アクティブ9B)です。NVIDIA が「2bit 量子化で 24GB に収まる」とする、推奨 24GB のモデルです。VRAM 16GB のこの PC では、そのままでは載りません。とはいえ指をくわえて悔しがるだけでは残念過ぎます。そこで次の3点を試しました。
- 推奨 24GB のモデルが、16GB で実用的な速度で動くのか。
- 2bit まで削っても、日本語の品質は保てるのか。
- 複数の LLM を連ねたエージェントの部品として使えるのか。
結果を先に書くと、1 つ目は「はい」でした。2 つ目と 3 つ目は、「この条件では、他のモデルと比べて悪くなかった」という答えです(2 bit 化そのものの影響は、高精度版と比べていないため、分かりません)。条件は 3 章に、結果は 4 章に、限界は 5 章に書きます。
なお、この記事は、手元の環境(Windows 11、RTX 5070 Ti 16GB、RAM 64GB)での検証です。モデルの優劣を一般に決める記事ではありません。
2. Bolt 概要
2.1 どんなモデルか
NVIDIA は 2026 年 10 月 15 日に、Nemotron 3.5 の Super VL と Bolt を発表しました(NVIDIA の発表ブログ)。ブログに書かれているモデルの位置づけは、次のとおりです。
| モデル | 位置づけ(ブログの記述) | 公開 |
|---|---|---|
| Nemotron 3.5 Super VL(120B) | 常時稼働のエージェントや、マルチモーダルなエージェント作業向け | 公開済み |
| Nemotron 3.5 Bolt 74B-A9B 24GB | RTX や DGX Spark で、日常的なエージェント作業をローカルで動かす | 公開済み |
| Nemotron 3.5 Bolt E4B 4GB | 高速な会話型エージェント(音声アシスタント、対話型キャラクター、組み込み)向け。「1GB あたりの知能」を重視 | 2026 年 10 月 23 日(予定) |
| Nemotron 3 Lightning | 高スループットのワークロード向け | 2026 年 8 月に公開済み |
| Nemotron Ultra | 最も難しい推論タスク向け | ブログに記載なし |
この記事で扱うのは、太字の Bolt 74B-A9B です。ブログは、Bolt を「ネイティブ 2bit 量子化で 24GB のメモリに収め、他のアプリと並行して動かせる」モデルと説明し、同クラスのオープンモデルの中で、PinchBench で 1 位、BrowseComp で 2 位とも述べています(NVIDIA の主張で、この記事では検証していません)。対応ツールには、llama.cpp、Ollama、LM Studio、Unsloth、vLLM が挙げられています。
なお、比較に使った Lightning は、Ollama の nemotron-3.5-lightning:30b-a3b(Hugging Face では NVIDIA-Nemotron-3.5-Lightning-30B-A3B)で、ブログでは「Nemotron 3 Lightning」として紹介されています。サイズ(30B、アクティブ 3B)は、モデルのメタデータによるものです。
Bolt 74B-A9B は、GGUF(llama.cpp や Ollama で使われる、量子化済みのモデルファイルの形式)のメタデータから読み取れる範囲では、次のような構成です。
- 総パラメータ 74B、1 トークンで使うのは約 9B の MoE(Mixture of Experts)。
- Mamba とアテンションを組み合わせたハイブリッド構成で、88 層のうち、アテンション(KV キャッシュを持つ層)は 8 層です。
- MoE 層は 40 層で、各層に 240〜496 個の専門家(エキスパート)があり、1 トークンで使うのは 9 個です。共有専門家も 1 つあります。
- 画像入力に対応しています(マルチモーダル)。
- 公式が配布する GGUF は 2bit(IQ2)です。ブログでは「ネイティブ 2bit 量子化」、モデルカードでは QAT(量子化を意識した学習)とされています。ファイルは約 20.5GiB でした。
2.2 比べた 3 モデル
| 略称 | Ollama のタグ | 量子化 | 総 / アクティブ |
|---|---|---|---|
| nano | nemotron-3-nano:4b |
Ollama の表示は Q4_K_M(実際のテンソルは Q5_0・Q4_K・Q8_0 などの混在で、平均約 5.7bit/重み) | 4B |
| Lightning | nemotron-3.5-lightning:30b-a3b |
Ollama の表示は Q4_K_M(実際のテンソルは Q5_0・Q8_0 が中心で、平均約 6.2bit/重み) | 30B / 3B |
| Bolt | nemotron-3.5-bolt:74b-a9b-iq2 |
IQ2_XXS(専門家の重みの方式。ファイル全体の平均は約 2.4bit/重み) | 74B / 9B |
「Q4_K_M」は、Ollama が表示するファイル全体の区分で、実際のテンソルの量子化は、GGUF のテンソルを集計すると上のとおりでした。nano と Lightning は約 6bit で、Bolt とは 2 倍以上の差があります。量子化の方式がそろっていない点は、5 章の限界でも触れます。
2.3 「推奨 24GB」の意味
公式の「24GB に収まる」は、本体(20.5GiB)に、画像用のプロジェクター(約 1.6GiB)と投機的デコード用のドラフター(約 0.9GiB)を足した合計(約 23GiB)に近い、容量の目安と考えられます。KV キャッシュなどの作業領域まで含めて、すべて GPU に載せる公式のレシピは、メモリ予算 28GB(GPU 32GB 以上向け)と 32GB(48GB 以上向け)のものです。いずれも「全部を GPU に載せる」ための容量であり、「24GB 未満では動かない」という意味ではありません。
では 16GB だとどうなるか。重みの一部がホストの RAM に置かれます。それでも速度が出る理由は、4.1 節で数字を使って説明します。
2.4 動かし方
Ollama の公式ライブラリに登録されているので、手順は簡単です。サイズは約 25GB のダウンロードになります。
ollama pull nemotron-3.5-bolt:74b-a9b-iq2
この記事の検証では、Ollama 0.40.5 を使いました。Bolt は思考(thinking)が既定でオンです。比較のため、後述のとおり OpenAI 互換 API の reasoning_effort: "none" でオフにしています。
3. 検証概要(性能・品質・ABD)
3.1 3 つの検証
| 検証 | 見たいこと | 指標 | 使ったもの |
|---|---|---|---|
| 性能 | 16GB で実用的な速度か | tok/s、VRAM | Ollama の API、nvidia-smi |
| 品質(a) | 日本語の知識と理解 | 正答率(完全一致) | llm-jp-eval(11 データセット) |
| 品質(b) | 日本語の自由記述 | 1〜10 点の審査員採点 | Japanese MT-Bench(60 問) |
| エージェント | 部品として使えるか | タスク成功率(正解採点) | 自作の ABD 実験(B0) |
3.2 共通の条件
3 モデルで、同じ問題・同じプロンプト・同じ設定を使いました。
-
思考オフ。 モデルごとに思考の仕組みが違うため、オフで揃えました。OpenAI 互換のチャット API に
reasoning_effort: "none"を渡すと、3 モデルすべてで思考が止まることを確認しています(think: falseは、この経路では効きませんでした)。 - 温度 0。 再現性のためです。ただし MT-Bench の回答生成は、公式の設定にならってカテゴリ別の温度にしています。
- Ollama の同じバックエンド(0.40.5)で、3 モデルを順に実行しています。
評価の種類によって目的が違うため、出力の上限などは、評価ごとに決めました。モデル間では揃えています。
3.3 進め方
まず各データセット 50 問で試運転をして、不具合を洗い出しました。次に 100 問で本番を回し、差が接近したデータセットだけを 300 問に増やして再評価しました。
試運転では、つまずきがいくつかありました。同じ環境で試す方の参考に、まとめておきます。
-
think: falseが効かない。 OpenAI 互換の/v1/chat/completionsでは、reasoning_effort: "none"を使います。llm-jp-eval のvllm-openaiプロバイダは旧来の/v1/completionsを使うため、思考を止められません。そこでopenaiプロバイダ(チャット API)を Ollama に向けました。 -
モデル名が渡らない。
openaiプロバイダは、設定したモデル名をnameに渡しており、リクエストのモデルは既定のgpt-3.5-turboになります。generation_configにmodelを書いて対処しました。 - mgsm が全モデルで 0.00。 標準の数式採点(math-verify)が、この Windows 環境で動かず、正答でも不正解になっていました。mgsm のみ、完全一致での採点に変えています。
-
生成の暴走。 Lightning の 1 データセットだけ所要時間が 421 秒になりました。生成長に上限がなかったためと見られ、全モデルに
max_tokens256 を入れました。
3.4 ABD 実験の位置づけ
ABD(Agent Behavior Degradation、振る舞い劣化)は、応答や出力形式は正常なのに、結論の質だけが下がる状態を指します。死活監視では見えず、後続のエージェントに誤りが伝わります。以前の記事では、その劣化を疑似的に注入し、切り替え・隔離・復帰で守る仕組みを、手元のローカル LLM で試しました。実験の設計(6 体のエージェント、劣化の種類、戦略)は、こちらを参照してください。
この記事では、その実験を次のように使っています。
- 入れ替えたもの。 以前の実験(D1: 指示の脱落、100 タスク)の、生産役のモデルだけを nano / Lightning / Bolt に入れ替えました。
- B0 のみ。 守りの仕組みを入れない条件(B0)で、モデル自体の強さを見ました。B1〜B3 は、レビュー役(qwen3:14b)と Bolt が同時に VRAM に載らないため、外しています。
- シードの意味。 シード 1〜3 は、劣化を注入する乱数だけを変えます。タスクの内容は同じなので、独立な反復ではありません。
以前の記事は 10 シードの実験でした。今回はタスクの集合を固定した 3 シードなので、今回の数値は、その記事の数値と直接は比べられません。なお本文では、タスク 31〜80(L1・L3・L4 の 50 タスク)を「劣化区間」と呼びます。
4. 検証結果
4.1 性能:16GB で実用的な速度で動いた
同じ PC・同じ条件(300 トークンの自由な日本語生成、思考オフ、num_ctx 8,192)で測った生成速度です。
| モデル | 実測 tok/s | 備考 |
|---|---|---|
| nano | 約 220 | 全層が GPU に載る |
| Lightning | 約 74〜81 | |
| Bolt(Ollama 既定) | 約 36〜46 | 内蔵ドラフターの投機的デコードが有効。プロンプトにより変動(図 1 は 46) |
Bolt(draft_num_predict=0) |
約 60 | 投機的デコードを無効化 |
Bolt(draft_num_predict=3) |
約 52〜75 | プロンプトにより大きく変動(図 1 は 1 回の測定値 68) |
Bolt の VRAM 使用量は、ピークで約 15,300 MiB(約 15.0GiB。搭載 16,303 MiB のほぼ上限)でした。num_ctx の設定値を 8,192 から 65,536 に上げても、VRAM はほぼ同じ(15,282 → 15,302 MiB)で、速度も誤差の範囲(測定により約 −2%〜+3%)でした。ただし、これは確保する領域を増やしただけで、プロンプトは短いままです。長い入力を実際に与えたときの生成速度や、入力の処理時間は測っていません。
図 1: 左は自由な日本語 300 トークンの生成速度。右は 1 トークンで読む重み(次のコラムで説明します)。右を見ると重みと速度が比例しそうですが、nano と Lightning は読む重みがほぼ同じでも速度が違います(コラム参照)。
コラム:なぜ 16GB で速度が出るのか
当初、私は Bolt の速度を「数〜十数 tok/s」と見積もっていました。重みの一部が VRAM に載らず RAM に置かれると、そこが足を引っ張って大きく遅くなるだろうと考えたためです。NVIDIA の公開レシピは全層を GPU に載せる構成で、16GB での Bolt の実測は、調べた範囲では見つかりませんでした。後から調べると、VRAM 16GB(RTX 4080)と DDR5 の環境で、gpt-oss-120b(MoE)が約 12.6 tok/s、全量が GPU に載る gpt-oss-20b が約 140 tok/s という報告がありました(Comparing LLMs performance on Ollama on 16GB VRAM GPU)。大きな MoE を RAM に溢れさせると、全量が GPU に載る場合の十分の一前後になる、という見立ては、この報告と近いものでした。ただし gpt-oss-120b は重みの約 8 割が CPU 側にあり、Bolt より RAM に溢れる割合がかなり大きい点は、違いです。Bolt の実測は 46 tok/s で、予想を大きく外しました。理由を調べると、次のことが分かりました。
1 トークンで読む重みは、全体の約 2 割です。 GGUF のテンソルから計算すると、Bolt の 20.5GiB のうち、ルーティング専門家(routed experts)が約 15.9GiB(77.5%)を占めます。ところが 1 トークンで使うのは各層 9 個だけで、専門家の重みの約 2.6%(約 0.41GiB)しか読みません。常に読む部分(Mamba、lm_head、共有専門家など)を合わせても、1 トークンで読む重みは約 4.5GiB(ファイルの約 22%)です。
RAM に置いた分の影響が小さい。 Ollama のログでは、重みの置き場所は GPU 約 8.8GiB とホスト RAM 約 11.7GiB に分かれていました。ホスト側は主にルーティング専門家です。1 トークンで RAM から読むのは約 0.3GiB(ホスト側がすべてルーティング専門家だと仮定した概算)で、DDR5-5600 のデュアルチャネル(理論値で約 90GB/s)の帯域には、余裕があると考えられます。ただし、ホスト側の専門家の計算や、GPU との受け渡しに実際にどれだけ時間がかかっているかは、測っていません。常に読む部分が GPU に残るよう、Ollama(llama.cpp)の自動配置が、あふれた層の専門家テンソルだけをホストに置いています。
「アクティブが 3 倍」でも、速度は 3 分の 1 にならない。 Lightning と比べると、次のとおりです。
| 項目 | nano | Lightning | Bolt |
|---|---|---|---|
| ファイルサイズ | 2.64GiB | 23.68GiB | 20.51GiB |
| 重みの配置(GPU / ホスト) | 2.4 / 0.3GiB | 11.9 / 11.8GiB | 8.8 / 11.7GiB |
| ルーティング専門家の割合 | なし(密) | 93% | 77.5% |
| 1 トークンで読む重み | 2.37GiB | 2.41GiB | 4.49GiB |
| 実測 tok/s | 約 220 | 約 74〜81 | 約 36〜75 |
Bolt の専門家(パラメータ数で約 9 割)は 2bit(約 2.06bit/重み)で、ファイル全体の平均は約 2.4bit/重みです。一方、Lightning は、Ollama の表示は Q4_K_M ですが、実際のテンソルは Q5_0 や Q8_0 が中心で、平均は約 6.2bit/重みです。アクティブなパラメータが約 3 倍でも、読む重みは Lightning の約 1.9 倍にとどまります。読む重みの比の逆数は約 0.54 で、Bolt の既定設定の速度比(約 0.45〜0.57)と同じ桁です。投機的デコードを調整した場合の約 0.8 は、重みの量では説明できず、ドラフターの効果です。
ただし、重みの量だけで速度が決まるわけではありません。nano と Lightning は、読む重みがほぼ同じ(2.37GiB と 2.41GiB)なのに、速度は約 2.7 倍違います。違いは、Lightning では重みの半分近く(11.8GiB)がホスト側にあることで、その読み出しと計算の影響が出ていると考えられますが、確かめてはいません。
もう一つ訂正があります。検証の途中で、私は「Bolt は Lightning より 1〜2 割遅い程度」と見ていました。以前の Lightning の記事の値(約 48〜56 tok/s、Ollama 0.32.9)と、今回の Bolt の実測を比べていたためで、環境の違う値の比較でした。今回の Ollama 0.40.5 で、同じ条件で測り直すと、Lightning は約 74〜81 tok/s でした。環境を揃えて比べる大切さを、改めて感じました。
コラム:投機的デコードは、自由な日本語生成では逆効果だった
投機的デコードとは。 LLM は通常、1 トークンずつ生成します。1 トークンごとに巨大なモデルを動かすため、重みの読み出しが速度の壁になります。投機的デコードは、これを避ける工夫です。小さくて速い「ドラフター(下書き役)」が、続きの数トークンをまとめて予想します。本体のモデルは、その予想を 1 回の計算でまとめて検証し、本体が出すはずだった内容と一致する分だけを採用します。外れたところから先は捨てて、本体が正しいトークンを出します。原理的には、出力の内容は通常のデコードと変わらず、速さだけが変わります。
予想がよく当たれば、1 回の検証で何トークンも進めるので速くなります。当たらなければ、ドラフターと検証の分だけ余計に計算するので、かえって遅くなります。予想が当たった割合を、受理率と呼びます。
Bolt の GGUF には、投機的デコード用のドラフター(DFlash、約 1.1B)が内蔵されていて、Ollama の既定で有効です(1 回に予想するのは最大 7 トークンです)。DFlash は、本体モデルの内部の特徴を使い、軽量な拡散モデルで複数のトークンを 1 回の計算で予想する手法として提案されています(DFlash: Block Diffusion for Flash Speculative Decoding)。Bolt のドラフターがこの論文の実装そのものかは、確認していません。ログに出る受理率は、用途によって大きく違いました。
- 構造化された出力(ABD 実験など): 受理率は約 75%、1 回の検証で進むトークン数は平均約 6.2。
- 自由な日本語の生成: 受理率は約 26%、1 回の検証で進むトークン数は平均約 2.8。
(1 回の検証で進むトークン数には、本体が出す 1 トークンを含みます。ドラフターの予想が受理された分だけなら、約 5.2 と約 1.8 です。)
後者では、検証のコストのほうが上回り、無効にしたほうが速くなりました(46 → 60 tok/s)。用途によって、設定を変える価値があります。この記事の Bolt の速度と所要時間は、特記がなければ Ollama 既定(ドラフトあり)での値です。
コラム:コンテキストを伸ばしても VRAM が増えない理由
Bolt は 88 層のうち、KV キャッシュを持つアテンション層が 8 層だけで、num_ctx 8,192 の KV は 64MiB と小さい構成です。残りは Mamba 層(40 層)と MoE 層(40 層)で、Mamba 層の再帰状態は、既定のドラフター設定で約 1.3GiB(ドラフターを無効にすると約 0.16GiB)で、コンテキスト長には依存しません。
ただし、VRAM がほぼ同じだった理由は、それだけではありません。Ollama の自動配置は、空き VRAM を使い切るように調整します。KV が増えた分は、専門家のホスト側への移動で吸収され、VRAM の使用量は常に上限近く(約 15,300 MiB)に保たれます。「コンテキストが無料」なのではなく、増えた分が RAM 側に回っています。
4.2 品質(a):llm-jp-eval
日本語の知識と理解を、短答式の自動採点で測りました。
条件
- 11 データセット: jnli、janli、jsick(NLI)、jemhopqa、niilc、aio(QA)、jsquad(読解)、jcommonsenseqa、kuci(常識)、jmmlu(日本語の知識)、mgsm(数学)。
- 各データセットの先頭 N 問(3 モデルで同じ問題)、4-shot、温度 0、
max_tokens256、思考オフ。 - 採点は完全一致(mgsm も完全一致。3.3 節のとおり)。
結果(N = 100、完全一致)
| データセット | 区分 | nano | Lightning | Bolt |
|---|---|---|---|---|
| jnli | NLI | 0.60 | 0.65 | 0.78 |
| janli | NLI | 0.88 | 0.86 | 0.89 |
| jsick | NLI | 0.65 | 0.79 | 0.84 |
| jemhopqa | QA | 0.20 | 0.26 | 0.37 |
| niilc | QA | 0.05 | 0.18 | 0.28 |
| aio | QA | 0.04 | 0.43 | 0.44 |
| jsquad | 読解 | 0.58 | 0.73 | 0.76 |
| jcommonsenseqa | 常識 | 0.74 | 0.88 | 0.93 |
| kuci | 常識 | 0.61 | 0.66 | 0.73 |
| jmmlu | 知識 | 0.57 | 0.49 | 0.63 |
| mgsm | 数学 | 0.15 | 0.29 | 0.36 |
| カテゴリ平均 | 0.464 | 0.556 | 0.630 |
(太字は各行の最高値で、数ポイント差のものも含みます。優劣の判断は、下の読み取りに従ってください。)
図 2: llm-jp-eval の正答率(各 100 問、完全一致)。
差が接近した 4 つのデータセットは、300 問に増やして再評価しました。
| データセット | nano | Lightning | Bolt |
|---|---|---|---|
| janli | 0.767 | 0.843 | 0.797 |
| aio | 0.077 | 0.460 | 0.463 |
| jsquad | 0.623 | 0.697 | 0.783 |
| jmmlu | 0.517 | 0.487 | 0.623 |
図 3: 300 問での再評価。棒の線は 95% 区間(Wilson 法)です。
読み取り
- Bolt は多くの項目で Lightning を上回りました。jsquad と jmmlu は、300 問でも差が残っています(jmmlu は、下の形式エラーの影響を含みます)。
- janli は、300 問では Lightning のほうが高い値(0.84 対 0.80)で、100 問の傾向とは逆でしたが、差は約 4.6 ポイントで、下の誤差の範囲に近いです。aio は Lightning と Bolt でほぼ同じです。
- nano は aio(知識を問う課題)で大きく劣ります。
- 誤差の目安は、正答率 0.5 付近の 1 モデルの 95% 区間で、N = 100 のとき約 ±10 ポイント、N = 300 で約 ±6 ポイントです。2 モデルの差で見ると、約 ±14 ポイント(N = 100)と約 ±8 ポイント(N = 300)です。差が数ポイント以内の項目は、優劣を言えません。
完全一致の厳しさと、形式エラー。 採点は完全一致なので、答えの形式を守れないモデルが不利になります。特に jmmlu では、選択肢以外の出力(選択肢の記号のあとに本文が続く、など)の割合が、300 問で nano 0%、Bolt 11%、Lightning 28% でした(100 問でも Lightning 27%、Bolt 14%)。つまり jmmlu の Lightning の低さは、知識の差だけでなく、形式の不遵守を含みます。nano が jmmlu で Lightning を上回ったのも、同じ理由を含む可能性があるため、「知識で勝った」とは言えません。選択肢外の出力を除いた正答率は、結果に全件の出力が保存されていないため、計算できていません。
文字列の部分一致を見る char F1 では、差が縮みます。たとえば jsquad(300 問)は、完全一致が nano 0.62、Lightning 0.70、Bolt 0.78 なのに対し、char F1 は 0.82、0.87、0.92 です。順位は同じですが、完全一致のほうが差が大きく見えます。
4.3 品質(b):相対 Japanese MT-Bench
自由な記述の品質を、審査員による採点で測りました。
条件と、公式との違い
質問は Japanese MT-Bench(Stability-AI/FastChat の jp-stable ブランチ)のデータにある 60 問(6 カテゴリ × 10 問、各 2 ターン)です。1〜10 点の単独採点で、公式の審査プロンプトを使い、reasoning は参照回答つきで採点しました。
公式との違いは 2 点あります。
- 審査員は GPT-4 ではなく、qwen3:14b(温度 0、思考オフ)です。そのため、公開されているスコアとは比べられません。 ここで意味があるのは、同じ審査員で 3 モデルを採点した相対的な差だけです。
- 質問は 60 問で、公式の 80 問のうち数学・コーディングは含まれません。
回答の生成は、思考オフ、最大 1,024 トークン、カテゴリ別の温度(公式の設定にならう)です。
結果
| モデル | 平均 ± SE | 1 ターン目 | 2 ターン目 |
|---|---|---|---|
| nano | 5.99 ± 0.28 | 6.62 | 5.37 |
| Lightning | 7.78 ± 0.23 | 8.05 | 7.52 |
| Bolt | 8.20 ± 0.21 | 8.52 | 7.88 |
| カテゴリ | nano | Lightning | Bolt |
|---|---|---|---|
| extraction | 7.10 | 7.90 | 7.75 |
| humanities | 6.45 | 8.85 | 8.85 |
| reasoning | 3.75 | 4.85 | 7.05 |
| roleplay | 5.20 | 8.50 | 8.65 |
| stem | 7.25 | 8.53 | 9.05 |
| writing | 6.20 | 8.10 | 7.85 |
図 4: カテゴリ別の平均得点。右端は全体の平均です。
質問ごとの対比較(2 ターンの平均点で勝敗)は次のとおりです。
| 比較(A 対 B) | A 勝 | 引分 | B 勝 | 平均差(A − B) ± SE |
|---|---|---|---|---|
| nano 対 Lightning | 12 | 5 | 43 | −1.80 ± 0.31 |
| nano 対 Bolt | 6 | 7 | 47 | −2.21 ± 0.30 |
| Lightning 対 Bolt | 17 | 14 | 29 | −0.41 ± 0.26 |
読み取り
- nano は、他の 2 モデルより明確に低く、特に 2 ターン目の低下が大きいです。
- Lightning と Bolt の平均差(0.41)は、標準誤差の約 1.6 倍で、確かとは言い切れません。 質問単位では Bolt が多く勝ちますが(29 勝 17 敗)、引分も 14 あります。
- カテゴリ別では、reasoning で Bolt が Lightning を大きく上回りました(7.05 対 4.85)。extraction(7.75 対 7.90)と writing(7.85 対 8.10)では、Bolt のほうがわずかに下回っています。ただし 1 カテゴリ 10 問なので、参考値です。
- Bolt と Lightning の平均差は、ほぼ reasoning だけから来ています。 6 カテゴリのうち reasoning の差が +2.2 で、残りの 5 カテゴリの差は −0.25〜+0.5 でした。reasoning を除いた 5 カテゴリの平均差は +0.05 で、ほぼ 0 です。reasoning は参照回答つきの採点で、思考オフでの推論の力の差が出やすい領域と考えられます。ただし reasoning は 10 問の結果で、差の合計(約 22 点)のうち 2 問だけで約 14 点を占めるため、確かな差とまでは言えません。
注意点
- 審査員が 14B の qwen3:14b なので、GPT-4 のような採点精度は期待できません。審査員自身の癖(長い回答を好むなど)の影響も受けます。
- 約 4 割の質問(60 問中 24〜26 問)で、いずれかのターンが出力上限の 1,024 トークンに達し、回答が途中で切れました。3 モデルに同じ条件ですが、冗長なモデルほど不利になります。
- Lightning は、審査員の出力から点数を読み取れなかった評価が 1 件あり、119 件の平均です。
- 平均の列の標準誤差(SE)は、2 ターン分の評価を独立に数えた値で、質問単位で数えると、やや大きくなります(約 0.33、0.27、0.25)。対比較の表の ± は、質問単位です。
4.4 エージェントの部品として:ABD 実験(B0)
3.4 節のとおり、以前の ABD 実験(D1: 指示の脱落)の生産役のモデルを入れ替えて、守りなし(B0)の条件で 100 タスクを実行しました。最終出力の正誤で採点する、正解採点です。劣化の注入のスケジュールは、3 モデルで同じです。
結果(シード 1〜3 の平均)
| 区間 | nano | Lightning | Bolt |
|---|---|---|---|
| 正常(タスク 1〜30) | 0.97 | 0.90 | 1.00 |
| L1(31〜45) | 0.89 | 0.76 | 0.89 |
| L3(46〜60) | 0.58 | 0.40 | 0.62 |
| L4(61〜80) | 0.42 | 0.42 | 0.42 |
| 正常(81〜100) | 0.85 | 0.75 | 1.00 |
| 劣化区間の成功率 | 0.607 | 0.513 | 0.620 |
| 全体の成功率 | 0.763 | 0.677 | 0.810 |
| 1 タスクの時間(6 エージェント分) | 3.0 秒 | 7.3 秒 | 9.0 秒 |
シードごとの全体の成功率(劣化区間の成功率)は、次のとおりです。
| シード | nano | Lightning | Bolt |
|---|---|---|---|
| 1 | 0.76(0.60) | 0.67(0.50) | 0.81(0.62) |
| 2 | 0.74(0.56) | 0.66(0.48) | 0.78(0.56) |
| 3 | 0.79(0.66) | 0.70(0.56) | 0.84(0.68) |
図 5: 左は区間別の成功率(3 シードの平均、線は最小〜最大)。正常区間は 3 シードで同じ値になるため、線は見えません。右は全体の成功率(点は各シード、横線は平均)。右の縦軸は 0.5 から始まっています。
読み取り
- 劣化を入れた区間では、3 モデルとも成功率が 0.5〜0.6 に下がりました。守りがないので、劣化がそのまま出力に出ます。L4(注入確率 0.8)では、モデルによる差がありません。
- 全体の成功率は、どのシードでも Bolt > nano > Lightning でした。ただし、これは 3 回の独立な裏づけではありません。 劣化の注入されるタスクは 3 モデルで同じで、正常区間は 3 シードで全く同じ結果です。順位を決めているのは、正常区間の少数のタスクの差です(下の「注意点」)。
- 劣化区間での Bolt と nano の差(0〜0.02)は、実質的にありません。 全体の差(0.04〜0.05)は、正常区間の差(Bolt 1.00、nano 約 0.92)によるものです。
- nano が Lightning を上回った点は、日本語のベンチマークの順位(Lightning > nano)と逆です。ABD は、構造化された JSON を出す手順のタスクで、知識の量より、指示への追従性が効くためと考えられます。ただし、要因の切り分けまでは行っていません。
- 時間は、nano が約 3 秒、Bolt が約 9 秒です。品質と速度のバランスは、用途で変わります。
注意点
3 シードは独立な反復ではありません。温度 0 でタスクの内容も同じなので、正常区間の成功率は 3 シードで全く同じ値になります。
正常区間の 50 タスクを数えると、Bolt は全て成功、nano は 4 タスクで失敗、Lightning は 8 タスクで失敗しました。Bolt と nano の全体の差(平均 4.7 タスク分)のうち、4 タスクがこの正常区間の差です(残りは、劣化区間でシードによって Bolt だけが成功した 1 タスクです)。逆向き(nano だけが成功したタスク)は、3 シード・100 タスクを通して 1 件もありません。符号検定(4 対 0)では、両側で p ≈ 0.125 で、偶然と区別できません。Bolt と Lightning は 8 対 0(p ≈ 0.008)で、Lightning が劣る傾向が強く出ています。ただしこれも、1 つのタスク集合での 8 件の差にもとづく結果で、別のタスク集合では変わりえます。したがって、「Bolt は Lightning より良い傾向があり、nano とは区別できない」というのが、このデータから言える範囲です。
4.5 結果を並べて見る
| 観点 | nano | Lightning | Bolt |
|---|---|---|---|
| llm-jp-eval(カテゴリ平均、N = 100) | 0.46 | 0.56 | 0.63 |
| MT-Bench(審査員 qwen3:14b) | 5.99 | 7.78 | 8.20 |
| ABD 全体の成功率(B0、シード 1〜3 の平均) | 0.76 | 0.68 | 0.81 |
| 生成速度(自由な日本語、tok/s) | 約 220 | 約 74〜81 | 約 36〜75(設定とプロンプトで変動) |
| ABD 1 タスクの時間 | 3.0 秒 | 7.3 秒 | 9.0 秒 |
| VRAM 16GB での動作 | 全量が載る | 一部が RAM へ | 一部が RAM へ(約 15,300 MiB 使用) |
5. まとめ
5.1 分かったこと
- 推奨 24GB のモデルは、16GB でも実用的な速度で動きました。 MoE で 1 トークンに触れる重みが少なく、RAM に置いた専門家の読み出しが、帯域の負担になりにくいためと考えられます(ホスト側の計算や受け渡しの時間は測っていません)。速度は nano の約 3〜6 分の 1 ですが、対話などの用途には十分な速さでした。
- 2bit の Bolt は、約 6bit の nano や Lightning と比べて、日本語の品質が劣っていませんでした。 短答式(llm-jp-eval)と自由記述(MT-Bench)の両方で、Bolt は概ね Lightning 以上でした。ただし Lightning との差が確かと言えるのは、jsquad など一部です(jmmlu は形式エラーの影響を含みます。MT-Bench の差はほぼ reasoning だけから来ていて、reasoning は 10 問のため、確かな差とまでは言えません)。2bit 化そのものの影響は、高精度版と比べていないため、分かりません。
- エージェントの部品としては、Bolt は Lightning より良い傾向があり、nano とは区別できませんでした。 守りなしの条件での成功率は Bolt が最も高く、正常区間では 1.00 でしたが、nano との差は小さく(平均 4.7 タスク分、うち 4 タスクが正常区間)、劣化区間では差がありません。時間は nano の約 3 倍です。
5.2 使い分けの目安
- 品質を優先する場合： Bolt。MT-Bench の reasoning で差が大きく出ましたが、10 問の結果なので、参考程度に見てください。
- 速度やコストを優先する場合： nano。エージェントの手順タスクでは、劣化区間で Bolt とほぼ同じ成功率でした。
- Lightning： 日本語のベンチマークでは nano と Bolt の中間ですが、ABD では Bolt を下回り(4.4 節の符号検定)、nano に対しても低い傾向でした(こちらは検定していません)。速度は nano と Bolt の中間です。この検証の範囲では、品質を取るなら Bolt、速度を取るなら nano で、Lightning を選ぶ決め手は見つかりませんでした。
5.3 この検証で言えないこと
- 思考オンでの性能： 3 モデルとも、思考オフで測りました。reasoning や数学では、思考オンの性能とは別物の可能性があります。
- ABD の B1〜B3： レビュー役を入れた条件は、VRAM の競合で実施していません。守りを入れたとき、Bolt と nano の差がどうなるかは不明です。
- タスク集合を変えた反復： ABD は、タスクの集合を 1 つに固定しています。
- 公開スコアとの比較： MT-Bench の審査員が GPT-4 ではありません。
- 量子化の影響の切り分け： nano と Lightning は、Ollama の表示は Q4_K_M ですが、実際のテンソルは平均約 5.7〜6.2bit/重みです。Bolt は専門家が 2bit(ファイル全体で約 2.4bit/重み)で、量子化の方式が大きく違います。Bolt を高精度で動かした比較はないので、2bit 化で何が失われたか(あるいは失われなかったか)は、分かりません。モデル本来の優劣と、量子化の影響は分離できません。
-
長い入力での速度：
num_ctxの設定値を上げた場合の速度は測りましたが、長い入力を実際に与えた場合の生成速度と、入力の処理時間は測っていません。 - 速度の内訳： ホスト側の専門家の計算や、GPU との受け渡しの時間は測っていません。重みの量だけでは、nano と Lightning の速度差は説明できません。
- 評価の範囲： llm-jp-eval は 11 データセットで、各 100〜300 問(先頭から)です。コード実行、翻訳、wiki 系、要約は対象外です。
5.4 次にやりたいこと
- Bolt の思考オン・オフの比較(特に reasoning と数学)。
- 10 月 23 日に公開予定とされる Nemotron 3.5 Bolt E4B 4GB(会話型エージェント向けの 4GB モデル)の検証。4GB なので、16GB の VRAM に全量が載るはずです。今回の nano(4B)との比較は、公開後に試したいです。
- ABD の B1〜B3(レビュー役を分けた条件)での、モデル間の比較。
- タスクの集合を変えた複数回の反復。
付録:条件の一覧
| 項目 | 内容 |
|---|---|
| ハードウェア | Core Ultra 7 270K Plus、RAM 64GB(DDR5-5600、2 枚)、RTX 5070 Ti 16GB |
| OS / ランタイム | Windows 11、Ollama 0.40.5(ABD 実験は WSL 経由で Ollama に接続) |
| llm-jp-eval | データセット版 2.1.5、openai プロバイダを Ollama の /v1 に接続、温度 0、max_tokens 256、4-shot、思考オフ |
| MT-Bench | 60 問、審査員 qwen3:14b(温度 0、思考オフ)、回答は最大 1,024 トークン、num_ctx 8,192 |
| ABD 実験 | D1、B0、100 タスク、温度 0、num_predict 700、num_ctx 4,096、シード 1〜3、データセットシード 1 |
| ライセンス | Bolt は OpenMDW-1.1 で公開されています。詳細はモデルカードで確認してください |
| データセット | llm-jp-eval は、非商用データセットを除外した設定(include_non_commercial: false)で実行しました。各データセットのライセンスは、llm-jp-eval の案内に従います |
参考
- NVIDIA の発表ブログ(Nemotron 3.5 Super VL と Bolt)
- NVIDIA Nemotron 3.5 Bolt 74B-A9B(Hugging Face)
- llm-jp-eval
- Stability-AI/FastChat(jp-stable)
- Comparing LLMs performance on Ollama on 16GB VRAM GPU(RTX 4080 16GB 環境での gpt-oss-120b / 20B の実測)
- DFlash: Block Diffusion for Flash Speculative Decoding(投機的デコードの手法の論文)
- Nemotron 3.5 Lightning を VRAM 16GB で動かした記事
- マルチエージェントを自律的に運用する -振る舞い劣化の隔離と回復-