この記事の要点
NVIDIA の Nemotron を低いビット数に詰めたこの GGUF は、検証機の GPU 一枚で、試したどの文脈長の設定でも、全部の層を GPU に置く指定のまま起動と生成ができた。
文脈長の設定を大きくしても、短い入力のあとの生成の速さはほとんど変わらず、入力の文章そのものを長くすると生成も遅くなった。
長い入力でも読み込みと生成は最後まで進み、待ち時間は文脈長の設定よりも、実際に入れた入力の長さで大きく変わった。
Ternary Nemotron 3.5 LightningはVRAM 12GBでどこまで使えるか
RTX 4070 SUPER (VRAM 12GB) 1 枚で、文脈長の設定を 368,640 トークン (この設定だけ -ub 512) まで伸ばしても、全部の層を GPU に置く指定 (-ngl 99) のまま起動と生成ができた。測定に使ったこの GPU は画面の表示に使っておらず、起動前の使用量は 0MiB だった。短い入力なら生成は速いが、入力そのものを長くすると、入力を読み終えるまでの時間がのび、そのあとの生成も遅くなった。答えの質 (要約が正しいか、長い文章の中から探し出せるか、日本語をどう扱うか) は、この記事では測っていない。
この記事では、llama-server の -c に渡した値を「文脈長の設定」、実際に入れた文章のトークン数を「入力の長さ」と呼び分ける。文脈長の設定は、スロット 1 つ (-np 1) で入力と生成の両方に使える長さの上限で、入力の長さはそのうち入力に使った分にあたる。生成したトークンも同じ枠を使う。
試した文脈長の設定は 32,768・131,072・262,144・368,640 トークンの 4 つで、どれも -ngl 99 (全部の層を GPU に置く指定) で動かした。読み込み直後の GPU 全体の使用量は、どの設定でもファイルの大きさ (8.82GiB) を上回っていた。サーバーが何層を GPU に置いたかを示すログは残していないので、配置は指定と使用量からの推定になる。使ったのは llama.cpp b11979、KV キャッシュは q8_0、-fa on で、-ub は 32,768〜262,144 の設定が 2048、368,640 の設定だけ 512 にした。生成のあとに読んだ GPU 全体の使用量は、一番多い回 (文脈長の設定 262,144・-ub 2048) でも 11,268MiB (11.00GiB) だった。12GiB (12,288MiB) との差は約 1GiB (1,020MiB) だが、これは生成のあとに 1 回読んだ値との差で、生成している最中の一番多い使用量や、あとから確保できる空きは測っていない。画面の表示にも使っている 12GB のカードでは、その分の使用量も加わる。ここで言う「GPU 全体の使用量」は nvidia-smi の memory.used で読んだ GPU 全体の値で、モデルが必要とする VRAM の量ではない。
短い入力 (1,024 トークンと 4,051 トークン) のあとの生成は、どの文脈長の設定でも 182.1〜201.8 tok/s だった (各 3 回の中央値、256 トークンを生成)。文脈長の設定を 32,768 から 368,640 に伸ばしても、短い入力の生成はほとんど遅くならなかった。同じ入力の長さで設定を比べると 7〜8% の差があるが、その理由は確かめていない。
入力を長くすると話が変わる。読み込みの速さから割り出すと、128,251 トークンの入力は読み終えるまで約35秒、29万トークン (293,491 トークン) の入力は約118秒、つまり約2分かかった。生成が始まるのはそのあとになる。この時間は入力のトークン数を読み込みの速さで割った計算値で、時計で測った値ではない。
同じ文脈長の設定 368,640 で比べると、293,491 トークンの入力のあとの生成 (57.9 tok/s) は、1,024 トークンの入力のあとの生成 (201.6 tok/s) の約3割だった。前者は 1 回だけ測った値で、後者は 3 回の中央値になる。
図「入力の長さと生成の速さ」は、文脈長の設定を 368,640 のまま、入力の長さだけを変えたときの生成の速さを並べたものだ。入力が長い回ほど棒が短い。
このファイルは主な線形の重みを三値 (ファイルでは Q2_0 として 1 つあたり 2.25 ビットで保存) にしたもので、Q4_K_M や Q8_0 のような 4 ビット・8 ビットの量子化とは別の形になる。量子化の形式の違いを先に押さえておくならローカルLLMの量子化フォーマットの選び方が、1bit や Ternary の量子化そのものの考え方と精度の代償については1bit・Ternary圧縮の実力と精度の代償を扱った記事が前提になる。
どんなモデルか: NVIDIAの30B-A3BをNota AIが三値にし、有志がGGUFにしたもの
Ternary Nemotron 3.5 Lightning は、3 者の手を順に経て llama.cpp で読める形になった。表「配布の流れ」に、誰が何を公開したかとライセンスをまとめる。
| 順 | 誰が | 何をしたか | 公開物 (Hugging Face) | 日付 | ライセンス |
|---|---|---|---|---|---|
| 1 | NVIDIA | 元のモデル Nemotron 3.5 Lightning 30B-A3B (BF16) を公開 | nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-BF16 | 2026年8月11日公開 | OpenMDW-1.1 (モデルカードの記載) |
| 2 | Nota AI | 重みを三値にし、Apple の MLX の形式 (2 ビットの入れ物) で公開。公開用の中間チェックポイント | nota-ai/Nemotron-3.5-Lightning-30B-A3B-Nota-Ternary-MLX-1014 | 2026年10月12日作成 | boro64 の README は元のモデル・元のチェックポイントと同じ OpenMDW-1.1 と記載 |
| 3 | boro64 (有志) | 三値の重みを llama.cpp の GGUF 形式の Q2_0 に詰め直して公開 | boro64/Ternary-Nemotron-3.5-Lightning-30B-A3B-GGUF | 2026年10月23日作成 | OpenMDW-1.1 (NVIDIA の著作権表示つきの LICENSE を同梱) |
日付は、NVIDIA のモデルはモデルカードに書かれた公開日 (Release Date)、Nota AI と boro64 のリポジトリは Hugging Face の API が返す作成日 (createdAt) による。
元のモデル: Nemotron 3.5 Lightning 30B-A3B
NVIDIA のモデルカードによると、Nemotron 3.5 Lightning 30B-A3B は総パラメータが 30B で、1 トークンあたりに動くのは 3B。Mamba-2 と MoE (Mixture-of-Experts) と注意 (Attention) の層を組み合わせた構成になっている。
同じモデルカードは、文脈長を最大 1M トークンとしている (H100 1 枚で動かすときは 256K を使う、とある)。対応言語には英語・スペイン語・フランス語・ドイツ語・イタリア語と並んで日本語が入っている。ただしこれは元のモデル (BF16) についての記載で、三値にしたファイルの日本語の能力は確かめていない。
ライセンスの OpenMDW-1.1 は、モデルと関連する資料を無償で制限なく扱うことを許すライセンスで、配布するときは契約書の写しと著作権・出所の表示を残す必要がある。モデルが特許や著作権を侵害していると主張する訴訟を起こす・続ける・自分から加わると、許諾が終わる条項もある (先に自分が訴えられ、それに対抗して起こした訴訟は除く)。第三者の権利の確認や必要な許諾の取得は利用者の責任で、権利を侵害しないことの保証も無い。boro64 の README は、商用利用ができると書いている。
Nota AI の三値のチェックポイント
Nota AI は、この元のモデルの主な線形の重みを、64 個ごとに決めたスケール a を使って {-a, 0, +a} の 3 つの値で表す三値にし、MLX の形式で公開した。スケールを除いた三値の符号だけを数えると、1 つあたり約 1.58 ビット (log2 3) になる。Nota AI はこれを「完全に回復させたモデルではなく、公開用の中間チェックポイント」と書いている。
Nota AI のカードの評価では、英語と韓国語の 7 つの課題の平均が元のモデルの 93.80 から 83.82 (元の 89.4%) へ下がっている。課題ごとの値は、後半の答えの質の節に載せる。
boro64 の GGUF: Q2_0 に詰め直した 1 ファイル
boro64 は、Nota AI の三値の重みを、値を変えずに llama.cpp の GGUF 形式の Q2_0 (三値、1 つあたり 2.25 ビット) へ詰め直したと README に書いている。線形の重みのテンソル 162 個が Q2_0 で、埋め込みと出力層は Q8_0。詰め直しで三値の重みの値が変わらないことは配布元の説明で (書き出した Q2_0 を戻すと MLX の値と一致したとある)、出力層の変換については README の変換表に「negligible」(わずかな差) とある。どちらもこの記事では確かめていない。
ファイルは Ternary-Nemotron-3.5-Lightning-30B-A3B-GGUF.gguf の 1 つだけで、手元に落としたファイルの大きさは 9,472,656,320 バイト、つまり 8.82GiB だった (README の表記は 8.82 GB、revision 570610701b08e16ffcfaa899a0bdec94f0cda819)。
公式の GGUF とのファイルの大きさの違い
NVIDIA のモデルカードは、ggml-org の公式の GGUF (ggml-org/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-GGUF、2026年8月11日作成) を案内している。表「ファイルの大きさ」は、そのファイルと Ternary Nemotron 3.5 Lightning の大きさを、GPU の容量と比べられるよう GiB を添えて並べたもの。公式のファイルの大きさは Hugging Face の API が返す値による。
| ファイル | 量子化 | バイト数 | GiB |
|---|---|---|---|
| Ternary Nemotron 3.5 Lightning (boro64) | Q2_0 (埋め込みと出力層は Q8_0) | 9,472,656,320 | 8.82GiB |
| 公式の GGUF (ggml-org) | Q4_0 | 18,898,091,584 | 17.60GiB |
| 公式の GGUF (ggml-org) | Q8_0 | 33,585,495,616 | 31.28GiB |
| 公式の GGUF (ggml-org) | BF16 | 63,181,504,576 | 58.84GiB |
公式の Q4_0 でもファイルだけで 17.60GiB あり、12GiB を超える。このため 12GB の GPU に全部の層は載らない (12GB の GPU の容量は 12GiB として比べた)。公式の GGUF はこの記事では動かしていないので、速さや答えの質の比較はしていない。Unsloth の日本語のドキュメントも、Nemotron 3.5 の 4 ビットは約 20GB、8 ビットは約 33GB のメモリが要ると書いている。
Ternary Nemotron 3.5 Lightning のファイル 8.82GiB に対して、文脈長の設定 32,768 で読み込んだ直後の GPU 全体の使用量は 9,586MiB (9.36GiB) だった。この値には、ファイルの分のほかに CUDA の初期化分や計算用のバッファも入っている。
低いビット数に詰めたほかのモデルを VRAM 16GB で測った記録としては、専用のビルドで PQ2_0・PTQ1_0 の形式を動かしたBonsai 2 27B の実測と、三値の重みを詰め直したものではなく、ふつうの 2 ビット台の量子化を使ったUnderdog Saluki 27B の実測がある。
12GBに長い文脈が収まった手がかり
手元のファイルの GGUF のメタデータを読むと、構成は nemotron_h_moe で、ブロックは 52 ある。そのうち KV ヘッド (head_count_kv) を持つのは 6 ブロックだけで、この 6 つが注意の層にあたる。残りのブロックは Mamba-2 か MoE の層で、README も「Mamba-2 + MoE + 6 attention layers」と書いている。エキスパートは 128 個で、1 トークンで動くのは 6 個、ほかに共有のエキスパートが 1 個ある。メタデータを読んだのは 2026年11月1日で、sha256 を照合したファイルのヘッダから取った。
-ub 2048 のまま文脈長の設定を 32,768 から 262,144 へ 8 倍にすると、モデルを読み込んだ直後の GPU 全体の使用量は 9,586MiB から 11,196MiB へ、1,610MiB (約 1.6GiB) 増え、12GB のカードに収まった。増えた分の内訳 (KV キャッシュと計算用のバッファの割合) は確かめていないので、収まった理由を、注意の層が 6 つという構成だけに帰すことはできない。
KV キャッシュの量子化と文脈長の関係を詳しく追った記録はVRAM 16GBでのコンテキスト長とKVキャッシュ量子化の実測にまとめてある。
文脈長の上限は資料によって書き方が違う
文脈長の上限は資料によって数字が違うが、どれも同じ種類の上限ではない。
- NVIDIA のモデルカード: 最大 1M トークンに対応すると案内している
- NVIDIA の設定ファイル (config.json) の max_position_embeddings: 262,144
- ファイルの GGUF のメタデータ (context_length): 1,048,576。公式の GGUF (ggml-org) の変換ログにも、262,144 をこの値に書き換えた記録がある
- boro64 の README: 262,144 が素の上限で、341K まで動作を確認し、約 400K まで使える
メタデータの値は、その長さまで答えの質が保たれることを示すものではない。この記事で確かめたのは、文脈長の設定 368,640 で入力 293,491 トークンまで読み込みと生成が最後まで進んだことで、答えの質は評価していない。それより長い設定は試していない。
llama.cppでの動かし方
測定には、llama.cpp b11979 の Windows x64 向け (CUDA 13.4) の配布物に入っている llama-server を使った。文脈長の設定 262,144 で動かしたときの起動コマンドは次のとおり。-m にはファイル名だけを書いてあるので、置き場所に合わせてパスを補う。コマンドは llama-server が PATH に入っているときの書き方で、Windows の PowerShell で配布物を展開したフォルダから動かすときは、先頭を .\llama-server.exe に替える。
llama-server -m Ternary-Nemotron-3.5-Lightning-30B-A3B-GGUF.gguf -c 262144 -np 1 -ngl 99 -fa on -ub 2048 --cache-type-k q8_0 --cache-type-v q8_0文脈長の設定 368,640 で動かしたときは、-c と -ub だけを替えた。-ub 512 は、配布元の README の調整の表が 262〜368K に示している値に合わせた。
llama-server -m Ternary-Nemotron-3.5-Lightning-30B-A3B-GGUF.gguf -c 368640 -np 1 -ngl 99 -fa on -ub 512 --cache-type-k q8_0 --cache-type-v q8_0表「起動の指定と意味」は、2 つのコマンドの指定がそれぞれ何を決めているかを、llama.cpp b11979 の tools/server/README.md の説明でまとめたもの。
| 指定 | 意味 |
|---|---|
-m Ternary-Nemotron-3.5-Lightning-30B-A3B-GGUF.gguf |
読み込むモデルのファイル (--model) |
-c 262144 / -c 368640 |
文脈の大きさ (--ctx-size)。この記事の「文脈長の設定」。0 ならモデルから読む |
-np 1 |
サーバーのスロットの数 (--parallel) |
-ngl 99 |
VRAM に置く層の数の上限 (--gpu-layers)。99 はこのモデルの 52 ブロックより大きいので、全部の層を GPU に置く指定になる |
-fa on |
Flash Attention を使う (--flash-attn。on / off / auto を選べ、既定は auto) |
-ub 2048 / -ub 512 |
物理的な最大のバッチの大きさ (--ubatch-size)。既定は 512 |
--cache-type-k q8_0 |
KV キャッシュの K のデータ型 (-ctk)。既定は f16 |
--cache-type-v q8_0 |
KV キャッシュの V のデータ型 (-ctv)。既定は f16 |
-ub の既定は 512 なので、2 つ目のコマンドの -ub 512 は既定と同じ値を書いたことになる。Web UI が要らなければ、--no-webui を足すと出さない指定になる。ポートを指定しないときの待ち受け先は、b11979 では 127.0.0.1:9931 になる。測定では、このコマンドにポート番号の指定と --no-webui を足して動かした (ほかの指定は同じ)。
llama.cpp b11979 は 2026年10月29日のリリースで、GitHub ではプレリリースの扱いになっている。llama-server を起動してからモデルが使えるようになる (/health が ok を返す) までは、最初の起動で 7.6 秒、2 回目以降の起動で 3.5〜4.6 秒だった (使えるようになったかは約 1 秒おきに確かめたので、1 秒ほどの幅がある)。2 回目以降は、ファイルが OS のキャッシュに載っていた可能性がある。
思考が長くなるときと、ほかの実行環境
配布元の README は、短い答えが欲しいときは chat_template_kwargs に reasoning_effort を low で渡すか、/v1/chat/completions ではなく /completion を使うように助言している。そうしないと何千トークンも考え続けることがある、とある。ただし、このファイルに入っているチャットのテンプレートは enable_thinking を見ていて、reasoning_effort を参照していない。NVIDIA のモデルカードも、思考の有無はテンプレートの enable_thinking で切り替えると書いている。llama-server (b11979) には、チャットで思考を使わない --reasoning off の指定もある。/completion はテンプレートを通さずに文章の続きを書かせる口で、チャットで思考を止める操作とは別になる。また、このファイルには MTP (複数トークン予測) の層が無い。この記事はチャットのテンプレートを通さずに /completion へ素の文章を渡して測ったので、思考の長さは確かめていない。
配布元の README の対応表では、素の llama.cpp (b11555 以降と b11796 で確認) と PrismML の llama.cpp の派生で読み込みと生成ができたとある。LM Studio と Ollama については、同じ形式なので動く見込みだが直接は試していない、と書かれている。この記事も Ollama・LM Studio では試していない。
入力の長さと速さ: 短い入力は速く、長い文書では遅くなる
文脈長の設定を 32,768 から 368,640 まで伸ばしても、短い入力のあとの生成の速さはほとんど変わらなかった。入力の読み込みは 368,640 (-ub 512) の設定で 1〜2 割低かったが、-ub も同時に変えているので、文脈長の設定だけの影響とは言えない。
表1と表2の「入力の読み込み」は入力の文章を読み終える速さ、「生成」は入力のあとに文章の続きを 256 トークン書き出す速さで (チャットで答えを最後まで返す速さは測っていない)、どちらも 1 秒あたりのトークン数 (tok/s) で表す。
自分の文書でどのくらい待つかは、入力のトークン数を入力の読み込みの速さで割ると目安が出る (長い入力では表2の値を使う)。手持ちの文書のトークン数は、llama-server の /tokenize に文章を渡すと数えられる。この記事の入力は英文なので、表のトークン数を日本語の文書の文字数に置き換えては読めない。
文脈長の設定を変えたとき
表1「文脈長の設定と入力の長さごとの速さ」は、4 つの文脈長の設定それぞれに長さの違う入力を入れ、各 3 回測った中央値を並べたもの。
| 文脈長の設定 | -ub |
入力の長さ | 入力の読み込み | 生成 | GPU全体の使用量 (読み込み直後) |
|---|---|---|---|---|---|
| 32,768 | 2048 | 1,024トークン | 5,360.3 tok/s | 189.3 tok/s | 9,586MiB |
| 32,768 | 2048 | 4,051トークン | 6,196.7 tok/s | 183.4 tok/s | 9,586MiB |
| 131,072 | 2048 | 1,024トークン | 5,384.3 tok/s | 187.5 tok/s | 10,276MiB |
| 131,072 | 2048 | 4,051トークン | 6,134.4 tok/s | 182.1 tok/s | 10,276MiB |
| 131,072 | 2048 | 32,086トークン | 6,274.8 tok/s | 148.3 tok/s | 10,276MiB |
| 262,144 | 2048 | 1,024トークン | 5,651.7 tok/s | 201.8 tok/s | 11,196MiB |
| 262,144 | 2048 | 4,051トークン | 6,562.2 tok/s | 196.2 tok/s | 11,196MiB |
| 262,144 | 2048 | 32,086トークン | 6,305.5 tok/s | 159.5 tok/s | 11,196MiB |
| 368,640 | 512 | 1,024トークン | 4,520.0 tok/s | 201.6 tok/s | 10,822MiB |
| 368,640 | 512 | 4,051トークン | 5,373.7 tok/s | 196.5 tok/s | 10,822MiB |
| 368,640 | 512 | 32,086トークン | 5,141.8 tok/s | 159.5 tok/s | 10,822MiB |
表1は RTX 4070 SUPER (VRAM 12GB) 1 枚、llama.cpp b11979 (Windows x64 向け CUDA 13.4)、-np 1 -ngl 99 -fa on、KV キャッシュ q8_0 で、/completion に入力を渡して 256 トークンを生成させた。-ub は文脈長の設定 368,640 だけ 512、ほかは 2048。入力は目標の長さ (1,024・4,096・32,768 トークン) で作って文章に戻したもので、表にはサーバーが数え直した長さ (1,024・4,051・32,086 トークン) を載せた。32,768 の設定には、目標 32,768 トークンの入力を入れていない。計測のスクリプトが、入力を作る前に目標の長さへ生成の 256 トークンを足して設定を超えるかで判定し、外したためだ。数え直した長さ (32,086 トークン) なら 256 を足しても 32,768 に収まるが、その組み合わせは測っていない。「GPU全体の使用量」はモデルを読み込んだ直後に nvidia-smi で読んだ GPU 全体の値で、モデルが必要とする量ではない。
サーバーを起動して最初に出した要求は、入力の読み込みが 2・3 回目より 3〜5 割低く出た (各設定の 1,024 トークンの 1 回目で 2,727.4〜3,545.9 tok/s)。このため表1は 3 回の中央値にしてあり、その回の値は載せていない。たとえば 32,768 の設定に 1,024 トークンを入れた回では、入力の読み込みが 1 回目 2,770.0 tok/s、2・3 回目が 5,360.3・5,581.8 tok/s だった。中央値で見ると、短い入力と 32,086 トークンの入力での入力の読み込みは 4,520.0〜6,562.2 tok/s に収まっている。
表1から読み取れるのは、生成の速さが文脈長の設定より入力の長さに左右されていることだ。短い入力 (1,024 トークンと 4,051 トークン) のあとの生成は、どの文脈長の設定でも 182.1〜201.8 tok/s で、設定を伸ばしてもほとんど遅くならなかった。32,086 トークンの入力のあとの生成は、文脈長の設定 131,072・262,144・368,640 で 148.3〜159.5 tok/s になり、短い入力より 2 割ほど遅かった。
入力を長くしたとき
表2「文脈長の設定 368,640 に長い入力を入れた回」は、128,251 トークンと 293,491 トークンの入力を入れた結果で、各 1 回だけ測った値だ。128,251 トークンの回は、その起動で最初に出した要求にあたる。表1で最初の要求が遅れた分は 1,024 トークンの回で 0.1〜0.2 秒ほどだったが、長い入力で最初の要求の影響が出るかは分けて測っていない。
| 入力の長さ | 入力の読み込み | 読み終えるまで | 生成 | GPU全体の使用量 (生成のあと) |
|---|---|---|---|---|
| 128,251トークン | 3,713.1 tok/s | 約35秒 | 97.5 tok/s | 10,864MiB |
| 293,491トークン | 2,479.9 tok/s | 約118秒 | 57.9 tok/s | 10,864MiB |
表2は文脈長の設定 368,640・-ub 512 で、ほかの指定は表1と同じ。「読み終えるまで」は入力のトークン数を入力の読み込みの速さで割った計算値で、時計で測っていない (128,251 ÷ 3,713.1 = 34.5 秒、293,491 ÷ 2,479.9 = 118.3 秒)。「GPU全体の使用量」は生成のあとに nvidia-smi で読んだ値。この待ち時間は、前の入力のキャッシュを使わない設定で読み込んだときの値で、同じ文書に続けて質問するときにキャッシュで短くなるかは測っていない。
入力が長くなると、入力の読み込みも生成も遅くなった。293,491 トークンの入力では、読み込みが 2,479.9 tok/s で、入力を処理し終えるまでに計算で約2分かかり、生成が始まるのはそのあとになる。この約2分はサーバーの中で入力を処理する時間で、要求を送ってから最初のトークンが届くまでや、答え全体を受け取るまでの時間は測っていない。そのあとの生成は 57.9 tok/s で、同じ文脈長の設定に 1,024 トークンを入れたときの 201.6 tok/s の約3割だった (前者は 1 回、後者は 3 回の中央値)。GPU 全体の使用量は、読み込み直後の 10,822MiB に対して生成のあとが 10,864MiB だった。同じ設定に 1,024 トークンを入れた回も生成のあとは 10,864MiB で、入力を 293,491 トークンまで長くしても、生成のあとの使用量は変わらなかった。
画面の表示に使っていない 12GB の GPU で、文脈長の設定 368,640・入力 293,491 トークンまでの範囲では、起動や生成が止まった回は無く、差が出たのは読み終えるまでの待ち時間とそのあとの生成の遅さだった。なお、入力は同じ英文を繰り返して作った文章なので、ふつうの文書を読ませたときと速さが違う可能性はある (作り方は測定の条件の節に書いた)。
配布元の README の数値との比べ方
配布元の README は冒頭で、12GB の GPU で文脈長 368K・生成 172 tok/s・読み込み 7,000 tok/s 以上と書いている。表3「README の調整の表」は、README の Tuning guide の値を写したもの。README はこの表を測った GPU も入力の長さも書いていない (RTX 4070 Ti (12GB) と書かれているのは、後ろの Benchmarks の節)。
| 文脈長 (README の表記) | -ub |
読み込み | 生成 |
|---|---|---|---|
| 262K 以下 | 2048 | 約 4,600 tok/s | 166〜172 tok/s |
| 262〜368K | 512 | 約 7,200 tok/s | 約 172 tok/s |
この記事の短い入力のあとの生成 (182.1〜201.8 tok/s) は、README の生成の数値 (166〜172 tok/s、約 172 tok/s) を下回らなかった。32,086 トークンの入力のあとの生成 (148.3〜159.5 tok/s) は、この数値を下回った。入力の読み込みは、368,640 の設定 (-ub 512) では 4,520.0〜5,373.7 tok/s で、README の同じ範囲の約 7,200 tok/s より低かった。262,144 以下の設定 (-ub 2048) では 5,360.3〜6,562.2 tok/s で、README の約 4,600 tok/s を下回らなかった。README の調整の表は測定機も入力の長さも書いていないので、差の理由はここでは書かない。README の読み込みの数値で待ち時間を見積もると、293,491 トークンを約 7,200 tok/s で割って約 41 秒になるが、この記事で測った読み込みの速さ (2,479.9 tok/s) で同じように割ると約 118 秒になる。同じ測定機・設定・繰り返しの英文なら表2の値が目安になるが、ふつうの文書でどこまで当たるかは確かめていない。
文脈長の設定と-ubで変わったもの
表1の「GPU全体の使用量」の列を見ると、一番多かったのは文脈長の設定 262,144 を -ub 2048 で動かした回 (11,196MiB) だった。それより長い 368,640 を -ub 512 で動かした回は 10,822MiB で、かえって少なかった。生成のあとに読んだ値は、同じ 262,144・-ub 2048 の回の 11,268MiB (11.00GiB) が一番多かった。
368,640 を -ub 512 で動かした回は、262,144 を -ub 2048 で動かした回より、GPU 全体の使用量が少なく (10,822MiB と 11,196MiB)、短い入力の読み込みは遅かった (4,520.0〜5,373.7 tok/s と 5,651.7〜6,562.2 tok/s)。ただし、この 2 つの回は文脈長の設定と -ub を同時に変えているので、この差を -ub だけの効果とは言えない。-ub を揃えた比較はしていない。また、長い入力 (128,251・293,491 トークン) を入れたのは 368,640・-ub 512 の組だけで、262,144・-ub 2048 の組には 32,086 トークンまでしか入れていない。
Windows の共有メモリについての配布元の注意
配布元の README は Windows について、GPU の専用メモリより多くを求めると Windows が黙って約 1GB を共有メモリへ移し、速さが約 20 分の 1 に落ちる (4,600 → 200 tok/s) と注意している。12GB のカードでは、重みと KV キャッシュと計算用のバッファの合計を約 11.7GB 未満に保つように、とある。README は単位を GB と書いていて、10 進の GB なら約 11,158MiB、GiB なら約 11,981MiB にあたる。ただし README の目安は重みと KV キャッシュと計算用のバッファの合計で、この記事の 11,268MiB は nvidia-smi で読んだ GPU 全体の使用量 (CUDA の初期化の分なども入る) なので、同じ量どうしの比較にはならない。内訳を分けて測っていないので、この記事の回が目安の内側だったかは判定できない。
README の 4,600 → 200 tok/s の 4,600 は、調整の表の読み込みの値 (約 4,600 tok/s) と同じ数字で、読み込みの速さの落ち方と読める。この記事の 35 回 (表1の 33 回と表2の 2 回) では、入力の読み込みも生成も、速さが急に 1 桁以上落ちた回は無かった。読み込みの最低は 293,491 トークンの入力の 2,479.9 tok/s で、ほかの回は 2,727.4 tok/s 以上だった。一番遅い生成は同じ回の 57.9 tok/s で、入力が長いほど遅くなる並びの中に収まっている。ただし、Windows が GPU のメモリの一部を共有メモリへ移したかどうかは、直接は確かめていない。
12GB からあふれたあとに速さがどう落ちるかは、VRAM 12GBの壁と、あふれた後の分かれ目を測った記事で扱っている。
答えの質について配布元とNota AIが書いていること
この記事は答えの質を測っていない。ここに載せるのは Nota AI と配布元 (boro64) がそれぞれ書いている評価で、この記事の結果ではない。
Nota AI の評価: 元のモデルとの比較
表4「Nota AI の評価」は、Nota AI のカードの表を写したもので、元のモデル (BF16) と三値にしたチェックポイントを並べている。設定は temperature 0.7・生成の上限 32k トークン。
| 課題 | 言語 | 元のモデル (BF16) | 三値 (Nota AI) |
|---|---|---|---|
| GSM8K | 英語 | 95.00 | 89.31 |
| MATH500 | 英語 | 97.60 | 81.60 |
| HumanEval | 英語 | 96.34 | 90.85 |
| IFEval | 英語 | 92.05 | 83.36 |
| HRM8K | 韓国語 | 91.05 | 83.24 |
| HumanEval-ko | 韓国語 | 95.12 | 85.37 |
| IFEval-ko | 韓国語 | 89.46 | 73.04 |
| 7 つの平均 | ― | 93.80 | 83.82 (元の 89.4%) |
課題は英語と韓国語だけで、日本語の課題は表4に無い。Nota AI の評価は MLX 形式のチェックポイントについてのもので、boro64 の GGUF は三値の重みを値を変えずに詰め直したと説明されているが、この記事ではそれを確かめていない。
配布元の README の長い文脈の試験
配布元の README には、長い文章の中の 3 か所 (文章の 10%・50%・90% の位置) に置いた事実を探させる試験の結果が載っている。表5「README の探し出しの試験」はそれを写したもので、README の Benchmarks の節は RTX 4070 Ti (12GB)・KV キャッシュ q8_0 を基本の条件にしている。ただし 492K の行には、KV キャッシュを q4 にしても q8_0 にしても、素の文脈長でも YaRN で 2 倍に伸ばしても外れた、と書かれている。この記事ではこの試験を再現していない。
| 文章の長さ (README の表記) | 3 問のうち正解 |
|---|---|
| 125K | 3 問 |
| 259K | 3 問 |
| 341K | 3 問 |
| 410K | 2 問 (README の表記で 90% の位置を外した) |
| 492K | 0 問 |
README はこの結果を「実用は約 350〜400K、保証は 262K」とまとめている。
配布元の README が書く得意・不得意
配布元の README は、このモデルが得意なのは長い文書の読解・検索・要約・文書への質問への答えだと書いている。苦手なのは、複雑なコーディング (仕様がはっきりしていても細かいバグが入る)、複雑な数学の推論、指示に正確に従うこと、とある。コーディングについては、正しいアルゴリズムを書くが、実装に細かいバグ (最後の処理の 1 つずれ等) が入った、と書かれている。どれも README の所見で、この記事では確かめていない。
測定の条件
測定は 2026年10月29日に行った。表「測定の条件」に、測定機と配布物と測り方をまとめる。
| 項目 | 内容 |
|---|---|
| GPU | RTX 4070 SUPER (VRAM 12GB) 1 枚。OCuLink (PCIe 4.0 x4) の外付けの箱に挿し、ほかの処理を載せない状態で測った。起動前の GPU の使用量は 0MiB で、llama-server は CUDA_VISIBLE_DEVICES にこの GPU の UUID を指定し、この 1 枚だけが見える状態で起動した |
| 測定中の状態 | ほかの GPU の処理と Ollama を止めていた |
| NVIDIA のドライバ | 610.88 |
| llama.cpp | b11979 (2026年10月29日のリリース、GitHub ではプレリリースの扱い) の Windows x64 向け CUDA 13.4 の配布物 (llama-b11979-bin-win-cuda-13.4-x64.zip)。zip の sha256 を照合してから使った。llama-server --version の表示は version: 0.8.0-dev (build 11979, commit bf48103ad) |
| モデルのファイル | Ternary-Nemotron-3.5-Lightning-30B-A3B-GGUF.gguf。sha256 を配布元の CHECKSUMS.txt と照合した |
| 入力 | 英語の 1 段落 (コンピューターの歴史と、メモリの容量と帯域の関係について書いた 2 文) を繰り返して作り、目標のトークン数で切って文章に戻したもの (表のトークン数は、サーバーが数え直した長さ)。チャットのテンプレートを通さず /completion に渡した |
| 生成 | temperature 0。生成の打ち切りを無視して 256 トークンを生成させた |
| キャッシュ | 前の入力のキャッシュは使わない設定 (cache_prompt false) |
| 回数 | 表1は各 3 回の中央値、表2は各 1 回。文脈長の設定と -ub の組ごとに llama-server を起動し直し、その起動の中ではモデルを読み込んだまま、入力の長さと回数を決まった順に続けて測った。seed は指定していない |
| 速さの値 | llama-server が返す timings の prompt_per_second (入力の読み込み) と predicted_per_second (生成) |
| GPU 全体の使用量 | nvidia-smi の memory.used。表1はモデルを読み込んだ直後、表2は生成のあとに読んだ |
入力は同じ文の繰り返しなので、ふつうの文書を読ませたときと速さが違う可能性はある。測るたびにモデルを読み込み直したり、測る順番を入れ替えたりはしていない。最初の要求の影響を切り分けておらず、長い入力は各 1 回なので、速さの数値はこの測定機・この順番・この入力での参考の値になる。
測定機のほかの部品や構成は検証環境のページに載せている。このモデルとは別のモデル群を使い、同じ PC・同じリクエストの設定で RTX 4070 SUPER と VRAM 16GB の GPU を比べた参考の記録はRTX 4070 Super と RTX 5060 Ti 16GB の比較に、ほかのモデルや GPU の実測はAIハードウェア実測データベースから探せる。
本記事の実測値は2026年10月29日に、上記の測定機・設定で計測したもの。
測っていないこと
- 答えの質 (長い文章の中から探し出せるか・要約の正しさ・日本語の文章の扱い)
- ふつうの文書 (同じ文の繰り返しでない文章) を入れたときの速さ
- チャットのテンプレートと思考を有効にしたときの速さと思考の長さ
- 368,640 より長い文脈長の設定
- 文脈長の設定 368,640 をほぼ満たす長さ (293,491 トークンより長い) の入力
- RTX 4070 SUPER 以外の GPU (VRAM 16GB の GPU を含む)
- Ollama・LM Studio での読み込み
- 公式の GGUF (Q4_0) との速さと質の比較
- 消費電力
-ubを揃えた比較- 画面の表示にも使っている GPU (ほかのプロセスが VRAM を先に使っている状態)
- 262,144・
-ub 2048の設定に 32,086 トークンより長い入力を入れたとき - 同じ文書に続けて質問したときに、キャッシュで待ち時間が短くなるか
参考資料
- nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-BF16 (Hugging Face)
- nota-ai/Nemotron-3.5-Lightning-30B-A3B-Nota-Ternary-MLX-1014 (Hugging Face)
- boro64/Ternary-Nemotron-3.5-Lightning-30B-A3B-GGUF (Hugging Face)
- ggml-org/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-GGUF (Hugging Face)
- Unsloth ドキュメント Nemotron 3.5
- OpenMDW License 1.1
- llama.cpp b11979 tools/server/README.md (GitHub)
- llama.cpp b11979 リリース (GitHub)
