NVIDIA が 2026 年 10 月 15 日に公開した Nemotron 3.5 Super VL を、DGX Spark 1 台で測りました。当ラボの定型 4 軸（速度・日本語知識・コーディング・マルチモーダル）に加えて、AI エージェントとして企業サーバを調べて直す仕事をどこまでこなせるかを、当ラボの評価 GembaBench で Qwen3.8-Flash-Next と比べています。
TL;DR：概略まとめ
- サーバの調査・修正（GembaBench）では、Qwen3.8-Flash-Next に届かなかった。 18 本すべてを最後まで走り切り（Flash-Next は 3 本が報告まで届かず）、所要時間も短めでした。ただ、調べる課題で見落としが多く、現状調査の得点は 45 点中 28 点（Flash-Next は 43 点）でした
- 点が低い試行の多くは、途中から ssh を付け忘れていた。 最初の数回だけ対象サーバに入り、その後は自分の作業用コンテナを調べて「対象の状態」として報告していました。思考を最大にすると、この誤りは 6 本中 1 本から 3 本に増えました
- コーディング（Aider Polyglot）は当ラボの測定で最高の 65.8%（Flash-Next は 56.9%）。日本語知識は Flash-Next と互角（JamC-QA 64.01% 対 64.57%）でした
- 速度は、投機的デコーディング（LiLiCorr）を入れると同時 1〜16 本で Flash-Next を上回る。 モデルカードの「同時実行 1」の設定は外して使えます
単発の課題を解かせると強いのに、複数のサーバを行き来しながら調べて直す仕事では、手元と対象を取り違える。ベンチマークの点数と現場の仕事の出来は別物だ、ということがまた一つ確かめられました。
1. Nemotron 3.5 Super VL とは
1-1. Nemotron シリーズの位置づけ
Nemotron は、NVIDIA が自社で作って配っているオープンモデルのシリーズです。GPU を売る会社が、その上で動くモデルまで用意しているわけです。2023 年の Nemotron-3（8B）に始まり、2024 年の Nemotron-4 340B（合成データ作りが主用途）、2025 年の Llama Nemotron（Meta の Llama を推論向けに鍛え直したもの）を経て、2025 年 12 月から自前設計の Nemotron 3 世代が出そろいました。今回の 3.5 Super VL は、その流れの最新版です。
| 公開 | モデル | 規模（総／毎トークン） | 役割 |
|---|---|---|---|
| 2025-12 | Nemotron 3 Nano | 30B / 3B | 軽量なエージェント向け |
| 2026-03 | Nemotron 3 Super | 120B / 12B | エージェント向けの主力 |
| 2026-04 | Nemotron 3 Nano Omni | 30B / 3B | テキスト・画像・動画・音声 |
| 2026-06 | Nemotron 3 Ultra | 550B / 55B | 最上位 |
| 2026-08 | Nemotron 3.5 Lightning | 30B / 3B | 3.5 世代の軽量版 |
| 2026-10 | Nemotron 3.5 Super VL | 120B / 12B | 3.5 世代の主力。画像・動画に対応 |
| 2026-10 | Nemotron 3.5 Bolt | 4B 級 | 端末・PC 向け |
Nemotron 3 世代は、どのサイズも Mamba-2 と Transformer のハイブリッドに MoE を組み合わせた同じ設計で、毎トークン使うパラメータを総量の 1 割ほどに抑えています。3.5 Super VL は、3 Super を土台に、上位の Ultra から 1 兆トークン分の蒸留で鍛え直し、画像・動画の入力と、思考を中程度に抑えるモードを足したものです。
このシリーズの特徴は、重みだけでなく、学習データ・学習手順・評価手順まで公開していることです。学習に使ったデータセット（事前学習用、事後学習用、合成ペルソナなど）は Hugging Face に置かれ、学習と評価のレシピも GitHub にあります。ライセンスは OpenMDW-1.1 で、商用利用に制限がありません。企業が自社データで作り替えるための「素材一式」として配っている、と見るのが分かりやすいと思います。
実際に、Nemotron を土台にした他社のモデルや取り組みが出ています。当ラボで確かめられた範囲では次のとおりです。
- Salesforce の Koa（CRM 向けの推論モデル）は Nemotron 3 Super を土台にしていて、重みは Salesforce が持っています
- ストックマークは Nemotron 3 Nano Omni を土台に、日本語の文書を読み解くモデルを作っています
- ソフトバンクの通信事業者向け基盤モデル（LTM）は、Sarashina と Nemotron を使っています
- 東京科学大学の Swallow と NTT データの tsuzumi 2 は、重みではなく Nemotron のデータセットや NeMo の学習手順を取り込んでいます
- NVIDIA 自身も、日本語に特化した Nemotron 2 Nano 9B Japanese を出しています
- 2026 年 3 月には、Mistral AI・Perplexity・Cursor・LangChain・Sarvam AI（インド）・Naver Cloud（韓国）などが参加する Nemotron Coalition が始まり、次の Nemotron 4 の土台モデルを NVIDIA と Mistral が共同で作ることになっています
「各国の企業が独自モデルを作るときの土台になっている」という見方は、おおむね当たっています。ただし、重みをそのまま継続学習したケースだけではなく、公開データセットや学習手順を部品として使うケースも多い。NVIDIA が配っているのはモデルというより「モデルの作り方一式」で、その一部を使う企業が増えている、という状況です。
参考: NVIDIA ブログ（日本企業の事例、2026-07）、Constellation Research（Salesforce Koa ほか、2026-09）、Nemotron 3.5 Super and Lightning（NVIDIA Research）
1-2. 同じ規模のオープンモデルとの比べ方
DGX Spark 1 台（128GB）に載る 100B 級のオープンモデルとしては、次のあたりが並びます。
| モデル | 出どころ | 規模（総／毎トークン） | 作り | ライセンス |
|---|---|---|---|---|
| Nemotron 3.5 Super VL | NVIDIA（米国） | 120B / 12B | Mamba-2＋Transformer のハイブリッド MoE | OpenMDW-1.1 |
| Qwen3.8-Flash-Next | Alibaba（中国） | 125B / 6B | Transformer 系のハイブリッド MoE | Apache-2.0 |
| gpt-oss-120b | OpenAI（米国） | 117B / 5B | Transformer MoE | Apache-2.0 |
| Nemotron 3 Super（前世代） | NVIDIA（米国） | 120B / 12B | Mamba-2＋Transformer のハイブリッド MoE | NVIDIA Open Model |
本記事で比較の基準にしたのは Qwen3.8-Flash-Next です。総パラメータはほぼ同じですが、毎トークン使う量は Nemotron が 2 倍です。これは §4-1 の速度に効いてきます。gpt-oss-120b は当ラボではまだ測っていません。米国発で DGX Spark に載るオープンモデルとして、Nemotron の競合にあたります。
1-3. 仕組み — Mamba-2 が主役、Attention は少数、MoE は 512 個から 22 個
| 要素 | 内容 |
|---|---|
| 規模 | 総パラメータ 120B、毎トークン使うのは 12B |
| 層の構成 | 全 88 層。大半が Mamba-2 で、少数の Attention 層が全体を見渡す役。MoE 層が Mamba-2 と交互に入る |
| MoE | 1 層あたり 512 個のエキスパートから 22 個を選び、毎回使う共有エキスパートを 1 つ足す。エキスパートの計算は 4096 次元を 1024 次元に縮めて行う（LatentMoE） |
| 視覚 | C-RADIO エンコーダ。画像・文書ページ・2 分までの動画を入力できる（出力はテキスト） |
| コンテクスト長 | 最大 1M トークン |
| 思考 | オフ／中程度／オンの 3 段階。ツール呼び出しに対応 |
| 公開形式 | BF16 と NVFP4（約 75GB）。DGX Spark 1 台には NVFP4 版が載る |
| ライセンス | OpenMDW-1.1（商用利用可） |
図の (a) が層の構成です。Transformer だけでできたモデルは、過去のトークンをすべて KV キャッシュに持ちます。Mamba-2 は、読んだ内容を一定の大きさの「状態」にまとめて持ち続ける仕組みで、コンテクストがどれだけ長くなってもメモリが増えません。Nemotron は大半の層を Mamba-2 にし、少数の Attention 層だけを「全体を見渡す役」として残しています。その Attention 層も KV ヘッドが 2 つしかなく（GQA）、KV キャッシュは小さい。図の (c) はこの違いを概念的に描いたもので、1M トークンのコンテクストが Spark 1 台に載るのは、この設計のおかげです。
図の (b) が MoE 層の中身です。512 個のエキスパートから毎トークン 22 個を選ぶので、総パラメータ 120B のうち実際に動くのは 12B で済みます。もう一つの工夫が LatentMoE で、エキスパートの計算を 4096 次元から 1024 次元に縮めた空間で行います。エキスパート 1 個あたりの計算とメモリの読み出しが減るので、同じ 12B でも速く回せます。
一方で、Mamba-2 の「状態」は投機的デコーディングと相性が悪い面があります。下書きが外れたときに状態を巻き戻せるよう、下書きの位置ごとに状態を持つ必要があるからです。この点が §5 の「なぜ同時実行 1 なのか」に効いてきます。
NVIDIA は Spark 向けに、投機的デコーディング用の小さなドラフトモデル（下書き役）LiLiCorr（1.2GB）も同時に公開しました。投機的デコーディングは、小さなモデルに数トークン先を下書きさせ、本体がまとめて検証して当たった分だけ採用する高速化の手法です。本体にも MTP（複数トークンを一度に予測する仕組み）が組み込まれていますが、当ラボの測定では LiLiCorr を使いました。
2. AI エージェントとしての実力 — GembaBench
2-1. GembaBench とは
GembaBench は、当ラボが作った「現場仕事」の評価です。架空の中小企業の Web サーバと DB サーバをコンテナで用意し、ハーネス（今回は OpenCode）につないだモデルに、調査から修正までを任せます。サーバには、退職者の鍵やアカウントの残り、侵入の痕跡、設定を毎時元に戻す cron、SQL インジェクションを持つコードなどを仕込んであります。採点はすべて自動で、T4〜T6 は報告書ではなくサーバの実際の状態を確かめます。
| 課題 | 内容 | 採点 |
|---|---|---|
| T1 | 現状調査 | 拾えた事実（45 点） |
| T2 | 侵入痕跡の調査 | 拾えた事実（8 点） |
| T3 / T3b | OS 更新の計画と、途中の方針変更への追従 | 8 点 / 6 点 |
| T4 | 更新の実施 | サーバの状態の確認（31 項目） |
| T5 | 設定の是正 | 同（45 項目） |
| T6 | SQL インジェクションの修正 | 同（23 項目） |
出力は毎回同じにはならないので、各課題を 3 回ずつ走らせ、中央値と範囲で示します。詳しい作りと、基準にした Qwen3.8-Flash-Next の結果は前回の記事にまとめました。
2-2. 条件
前回の記事の DGX Spark の列と、モデル以外の条件をそろえました。
| 項目 | 値 |
|---|---|
| ハーネス | OpenCode 2.0.25 |
| 思考 | 中程度。Nemotron は chat_template_kwargs: {"enable_thinking": true, "medium_effort": true}、Flash-Next は reasoning_effort: medium
|
| 思考トークンの上限 | 8192（中継サーバで強制） |
| 出力上限／コンテクスト | 16384 ／ 245,760 トークン（足すとちょうど 262,144） |
| 同時実行 | 1 本ずつ |
| 回数 | 各課題 3 回（計 18 本） |
| タイトル・要約用の補助モデル | 別のマシンに置き、Spark には向けない |
思考の指定方法だけはモデルによって違います。Nemotron の medium_effort が何をしているかは、vLLM にプロンプトを組み立てさせて確かめました。最初のユーザーメッセージの末尾に「推論は効率よく（{reasoning effort: efficient}）」という一文を足すだけで、それ以外は変わりません。
思考トークンの上限は、ハーネスとモデルの間に置いた中継サーバで、思考が 8192 に達したら打ち切る仕組みで強制しています。Nemotron でも打ち切りと、打ち切った後の続き（ツール呼び出しを含む）が正しく動くことを、本番の前に確かめました。結果として、18 本を通じて思考が上限に届いたことは一度もありません。いちばん長い思考でも、上限の半分ほどでした。
Spark の Nemotron は、エージェント用にコンテクスト 256K・同時 4 本で起動し、LiLiCorr は外しました。LiLiCorr を入れると Mamba-2 の状態のメモリが増え（§5）、256K のリクエスト 4 本が載らないためです。LiLiCorr ありでは、プレフィックスキャッシュの効き方も安定しませんでした。代わりにプレフィックスキャッシュを有効にしています。ハーネスは毎回同じ長い前置き（システムプロンプトやツール定義、それまでの会話）を送るので、これが効きます。2 回目以降に最初のトークンが返るまでの時間は、6.3 万トークンの前置きで 13.7 倍、24.3 万トークンでは 60.9 倍速くなり、1〜2 秒で返りました。
2-3. 成績 — 調べる課題で見落としが多い
| 課題 | Spark・Flash-Next | Spark・Nemotron | 参考: RTX 4060 Ti 16GB 1 枚・Flash-Next |
|---|---|---|---|
| T1 現状調査（/45） | 43 [38–45] | 28 [23–41] | 40 [39–45] |
| T2 侵入痕跡（/8） | 6 [6–8] | 5 [4–6] | 7 [5–8] |
| T3 更新の計画（/8） | 8 [8–8] | 7 [7–8] | 8 [0–8] |
| T3b 方針変更への追従（/6） | 2 [2–4] | 2 [2–4] | 4 [0–4] |
| T4 更新の実施（/31） | 31 [27–31]、満点 2/3 | 28 [25–31]、満点 1/3 | 31 [31–31]、満点 3/3 |
| T5 設定の是正（/45） | 41 [11–43] | 27 [11–34] | 39 [38–42] |
| T6 SQL インジェクションの修正（/23） | 23 [8–23]、満点 2/3 | 23 [23–23]、満点 3/3 | 23 [23–23]、満点 3/3 |
（3 回の中央値 [最小–最大]。参考列は前回の記事の 16GB 構成で、Flash-Next を 3bit 量子化して Strata で動かしたもの）
調べる課題（T1・T2）と、設定の是正（T5）で、Nemotron は Flash-Next を下回りました。T1 の 28 点は、16GB の普及帯 GPU 1 枚で動かした Flash-Next（40 点）にも届いていません。T4 の更新も、満点は 3 回中 1 回でした。
一方で、T6（SQL インジェクションの修正）は 3 回とも満点でした。コードを読んで直す仕事は確かで、§4-3 の Aider Polyglot の結果と同じ傾向です。
報告と実際にやったことの食い違いは、Nemotron では 18 本とも 0 件でした。
2-4. 所要時間と止まり方 — 最後まで走るが、短く切り上げる
| Spark・Flash-Next | Spark・Nemotron | 参考: 16GB・Flash-Next | |
|---|---|---|---|
| 6 課題の中央値の合計（分） | 約 257 | 約 151 | 約 106 |
| 最後まで走った試行 | 15/18 | 18/18 | 17/18 |
| 途中で止まった試行 | 2（T5・T6） | 0 | 1（T3） |
| 時間切れ | 1（T5） | 0 | 0 |
Nemotron は 18 本すべてを、自分で「完了」として終えました。 Flash-Next の Spark では、思考の途中で応答が終わったり、「検証します」と宣言したままツールを呼ばずに止まったりした試行が 2 本、時間切れが 1 本ありました（前回の記事 4.3）。止まらないという点では、Nemotron のほうが扱いやすいモデルです。
所要時間も T4 以外では短めです。T1 は 17.9 分（Flash-Next は 30.3 分）、T3 は 18.2 分（同 35.6 分）でした。ただしこれは速いからではありません。Spark での生成速度は Nemotron が約 18.5 tok/s、Flash-Next が約 27 tok/s で、Nemotron のほうが遅い（エージェント用には LiLiCorr を外しているため、§4 の「LiLiCorr なし」と同じ水準です）。短く済んだのは、作業の量が少ないからです。 T1〜T3 では、ステップ数も出力トークン量も Flash-Next の半分以下でした。コンテクストの使用率も、最大で 48.9%（Flash-Next は 84.1%）にとどまっています。
T4 だけは Nemotron のほうが長くかかりました（中央値 70.4 分。cron の実行を待つ時間を除いても 67.4 分）。いちばん長い試行は 116.5 分で、そのうち 49 分は cron が走るのを待つ sleep でした。
まとめると、Nemotron は止まらずに最後まで走るが、短く切り上げて見落とす。T5 では時間切れも途中停止もないのに、どの試行も自分で「終わった」と判断して早めに切り上げていました。
2-5. 点が低い理由 — 途中から ssh を付け忘れる
見落としの中身を試行ごとに調べたところ、点が極端に低い試行には共通の誤りがありました。
GembaBench では、エージェントは自分の作業用コンテナから ssh target-web "…" や ssh target-db "…" の形で対象サーバに入って調べます。点の低い試行では、最初の 2 回だけ ssh で対象に入り、3 回目からは ssh を付けずに hostname、cat /etc/passwd、dpkg -l などを打っていました。 調べているのは自分の作業用コンテナです。hostname が対象とは違う名前を返しても気づかず、その結果を「対象サーバの状態」として報告書に書いていました。ある試行の報告書には「Web サーバに Nginx も PHP も無い」「DB サーバに MySQL が無い」「バックアップが取られていない」とあります。手元のコンテナには、どれも最初から入っていません。
この誤りは、思考の強さを変えて測った追加の 6 本（次の 2-6）にも出ました。T1 と T5 の計 12 本を、シェル呼び出しのうち ssh で対象に入った割合と得点で並べます。
はっきり 2 つに分かれています。ssh を付け忘れた 4 本は 0〜11 点、対象に入り続けた 8 本は 23〜42 点でした。Nemotron の見落としの大きな部分は、考える量の不足ではなく、手元と対象の取り違えから来ています。
付け忘れた試行も、対象の外に影響する操作はしていません。手元のコンテナを読んだだけです。
2-6. 思考を最大にしたら直るか — 付け忘れが増えた
「早めに切り上げて見落とす」なら、もっと考えさせれば直るのではないか。そう考えて、差の大きかった T1 と T5 を、思考を最大（{"enable_thinking": true} だけを指定し、medium_effort を外す）にして 3 回ずつ測りました。ほかの条件は同じです。
| 中程度 | 最大 | |
|---|---|---|
| T1 現状調査（/45） | 28 [23–41] | 6 [0–37] |
| T5 設定の是正（/45） | 27 [11–34] | 35 [11–42] |
| ssh を付け忘れた試行 | 1/6 | 3/6 |
| ssh を続けた試行の得点 | T1 23・41・28、T5 27・34 | T1 37、T5 35・42 |
| 1 リクエストの思考（試行ごとの中央値の範囲） | 約 120〜390 トークン | 約 200〜720 トークン |
| 思考トークンの上限（8192）に届いた回数 | 0 | 0 |
思考は 1.5〜2 倍ほど長くなりましたが、見落としが減るとは言えません。 ssh を続けた試行に限れば、点は中程度より上がりました（T1 37 点、T5 42 点）。ところが付け忘れが 6 本中 3 本に増え、その 3 本が 0・6・11 点だったため、中央値では T1 が大きく下がっています。3 回ずつなので断定はできませんが、思考を増やすことは対策になりませんでした。
Classmethod の検証でも、エージェントへの向き不向きを見る確認問題 6 問は、思考を中程度にしたほうが良く（6 問中 6 問）、最大（モデルの既定）では 6 問中 4 問に下がったと報告されています。
エージェントで使うなら、思考は中程度がおすすめです。
2-7. 使うときの工夫
ssh の付け忘れは、モデルの癖として受け止め、ハーネスの側で防ぐのが現実的だと考えています。
-
作業ルールで、対象のコマンドは毎回
ssh target-…で実行するよう強く求める。 OpenCode なら AGENTS.md などのルールファイルに書いておきます - ツールの側で接続先を固定する。 対象サーバ専用のシェル実行ツールを用意し、手元でのコマンド実行は許可しない、といった形です
-
報告の前に
hostnameを確かめさせる。 調べた相手が対象かどうかを、報告書に書かせて残します
当ラボの評価では、これらの工夫をあえて入れていません。モデルの素の振る舞いを比べるためです。実際の現場で使うときは、入れたほうがよいと考えています。
3. DGX Spark で動かすレシピ
3-1. 構成
| 内容 | |
|---|---|
| ハード | DGX Spark（GB10、128GB 統合メモリ） |
| ランタイム | vLLM v0.32.0（公式 Docker イメージ vllm/vllm-openai:v0.32.0） |
| 重み | nvidia/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-NVFP4 |
| ドラフト | nvidia/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-NVFP4-LiLiCorr |
モデルカードは nightly ビルドか v0.32.0 を指定しています。公開時点では v0.32.0 が出ておらず nightly を使う人が多かったのですが、10 月 18 日に v0.32.0 がリリースされました。リリース版ならタグで固定できるので、当ラボは v0.32.0 を使いました。起動ログで、NVFP4 の計算がネイティブのカーネル（FlashInferCutlassNvFp4LinearKernel）で動いていることを確認しています。
3-2. 速度測定の設定
モデルカードの Spark 向けクイックスタートは --max-num-seqs 1、つまり同時に 1 リクエストしか処理しない設定です。当ラボはこれを 32 に上げて測りました。そうしてよい理由は §5 で説明します。
vllm serve nvidia/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-NVFP4 \
--served-model-name nemotron-3.5-super-vl \
--trust-remote-code \
--max-num-seqs 32 \
--max-model-len 32768 \
--max-num-batched-tokens 8192 \
--gpu-memory-utilization 0.75 \
--speculative_config.model nvidia/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-NVFP4-LiLiCorr \
--speculative_config.method dflash \
--speculative_config.num_speculative_tokens 7 \
--mamba-backend flashinfer \
--mamba-ssm-cache-dtype float16 \
--enable-mamba-cache-stochastic-rounding \
--mamba-cache-philox-rounds 5 \
--block-size 64 \
--enable-auto-tool-choice \
--tool-call-parser qwen3_coder \
--reasoning-parser nemotron_v3 \
--no-enable-prefix-caching \
--mm-processor-cache-gb 0
LiLiCorr を使わないときは、--speculative_config.* の 3 行を外します。
要点を挙げます。
--gpu-memory-utilization 0.75 — モデルカードの値のまま。起動後の空きメモリは約 17GiB、32 並列で負荷をかけたときは 13〜15GiB でした。余裕は大きくありません。同じ Spark で埋め込みモデルなどを同居させて落ちた、という報告もコミュニティにあります。
最後の 2 行は速度測定のための指定 — プレフィックスキャッシュと、画像の前処理結果のキャッシュを切っています。実際に使うときは 2 行とも外してください。キャッシュを切るには、--no-enable-prefix-caching だけでは足りません。画像のキャッシュは別の仕組みなので --mm-processor-cache-gb 0 も要ります。片方だけでは、同じ画像を送り直したときに速く見えてしまいます。
画像の枚数制限は気にしなくていい — 「1 会話に画像 1 枚までしか送れない」という報告がありましたが、v0.32.0 では既定の上限が 999 枚でした。1 リクエストに実写 8 枚を入れて問題なく通っています。
起動に約 10〜12 分 かかります。大半は重み（約 70GiB）の読み込みです。
3-3. エージェント用の設定
§2 のエージェントの測定では、上のコマンドを次のように変えて起動しました。
| 項目 | 速度測定 | エージェント用 |
|---|---|---|
コンテクスト長（--max-model-len） |
32,768 | 262,144 |
同時実行（--max-num-seqs） |
32 | 4 |
| LiLiCorr | あり／なしの両方を測定 | なし |
| プレフィックスキャッシュ | 無効（測定のため） | 有効 |
4. 定型 4 軸のベンチマーク
当ラボはモデルを 4 つの軸で測っています。①速度、②日本語知識、③コーディング、④マルチモーダルです。今回は DGX Spark で測ってきた過去のモデルを、できるだけ多く並べました。ランタイム・量子化・測定日は行ごとに違います。 条件をそろえられないものは、そろえないまま条件を書いて並べています。数字は測ったときの版（vLLM v0.32.0）のものです。
4-1. ①速度 — LiLiCorr を入れると、c=16 まで Flash-Next を上回る
c は同時リクエスト数です。c≦4 は個人が対話やエージェントで使う規模、c≧8 はチームや部門で複数人が同じサーバを使う規模にあたります。Qwen3.8-27B は c=1・8・16・32 だけを測っているので、c=1〜8 の線は途中の点がありません。
| c | Nemotron LiLiCorr なし | Nemotron LiLiCorr あり | Flash-Next（senfu 版） | LiLiCorr の効果 |
|---|---|---|---|---|
| 1 | 19.20 | 32.91 | 26.97 | 1.71 倍 |
| 2 | 30.22 | 44.94 | 38.31 | 1.49 倍 |
| 4 | 44.12 | 62.16 | 51.64 | 1.41 倍 |
| 8 | 59.06 | 88.15 | 67.68 | 1.49 倍 |
| 16 | 78.55 | 129.53 | 77.48 | 1.65 倍 |
| 32 | 105.67 | 130.20 ※ | 89.35 | — |
（合計の出力 tok/s、vllm bench serve・ShareGPT 200 件・思考なし。Nemotron は vLLM、Flash-Next は SGLang）
※ LiLiCorr ありの c=32 は、メモリの都合で実際には 16 本しか同時に走らず、残りがキューで待たされました。速度は c=16 と同じで、最初のトークンが返るまで 25.9 秒かかっています。c=32 の速度としては扱いません（理由は §5）。
読みどころは 3 つあります。
LiLiCorr なしの素の速さは、低並列では Flash-Next に負ける。 c=1 で 19.2 対 27.0 です。毎トークン使うパラメータが Nemotron は 12B、Flash-Next は 6B なので、メモリ帯域がボトルネックになる低並列で差が出るのは理屈どおりです。
LiLiCorr を入れると逆転し、その効果が並列を上げても消えない。 投機的デコーディングは、並列数を上げると下書きの検証が本体の計算と取り合いになり、効かなくなるのが普通です。当ラボの過去の測定でも、Flash-Next（RadixArk 版）の MTP は c=1 で +44% だったものが c=16 では −8% に、Muse Glimmer の DFlash は c=32 で投機的デコーディングなしに逆転されていました。LiLiCorr は c=1〜16 で 1.4〜1.7 倍を保っています。採用率（下書きが採用された割合）も、c に関係なく 0.37〜0.38 で一定でした。
最初のトークンが返るまでの時間（TTFT）は悪くなる。 c=1 で 299ms が 401ms に、c=16 で 727ms が 1,354ms になりました。下書きモデルの分だけ前処理が重くなるためと見ています。対話で「反応の早さ」を重視する場合は、この点を差し引いてください。
なお高並列の土俵では、dense の Qwen3.8-27B（vLLM＋MTP）や Muse Glimmer 30B（vLLM）がまだ速い（c=32 で 236、251 tok/s）。Nemotron が強いのは c=1〜16 の範囲です。
TTFT と TPOT（2 個目以降のトークンの間隔）も挙げておきます。
| c | LiLiCorr なし TTFT / TPOT（ms） | LiLiCorr あり TTFT / TPOT（ms） |
|---|---|---|
| 1 | 299 / 50.9 | 401 / 30.8 |
| 4 | 473 / 87.3 | 757 / 67.7 |
| 8 | 575 / 130.2 | 971 / 93.6 |
| 16 | 727 / 192.5 | 1,354 / 120.0 |
下書きのトークン数は減らすと速くなる可能性があります。 当ラボはモデルカードのクイックスタートどおり下書き 7 トークンで測りました。ところがモデルカードの中でも、構成の一覧表では Spark 向けに 5 トークンとなっていて、値がそろっていません。他の検証では、下書き 7 トークンで 1 本 25〜28 tok/s だったのが、4 トークン以下にすると 43〜46 tok/s になったという報告や、別の設定で 1 本 48 tok/s が出たという報告があります。当ラボは 7 トークンでしか測っていないので、ここでは測った値のまま載せています。
- https://github.com/kindlingai/nemotron-3.5-super-vl-dgx-spark
- https://github.com/sfxnz/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-NVFP4-DGX-SPARK
4-2. ②日本語知識 — Flash-Next と互角
JamC-QA（SB Intuitions 構築、日本固有の知識を問う 4 択、全 2,309 問）で、思考なし・3-shot・4 択一致判定で測りました。
64.01%（1,478/2,309）。当ラボが DGX Spark 1 台で測った 11 モデル中 3 位です。 2 位の Flash-Next（senfu 版、64.57%）との差は 0.56pt です。当ラボの過去の測定では、同じモデルのランタイムと量子化を変えただけで 0.34pt 動いたことがあるので（Gemma4-31B の llama.cpp 版と vLLM 版）、互角と見るのが妥当だと思います。形式の崩れ（答えを読み取れなかったもの）と打ち切りはゼロでした。
前世代の Nemotron 3 Super 120B（59.33%）からは 4.7pt 伸びました。 規模は同じ 120B 級なので、世代が変わって日本語の知識が厚くなったと言えます。GembaBench でも、18 本の報告書はすべて日本語で書かれていました。前世代の Nemotron は成果物を英語で書くことがありましたが、今回はありません。
カテゴリ別では、医療（70.8%）・行政（68.2%）・歴史（67.9%）が高く、地理（53.3%）・地域のアイデンティティ（57.9%）が低めでした。地理と地域のアイデンティティが低いのは、これまで測ったどのモデルにも共通する傾向です。
比較したモデルはすべて同じ方式（同じハーネス、思考なし、temperature 0、3-shot）で測っています。量子化とランタイムはモデルごとに違い、DeepSeek-V4-Flash-0731 は 3bit（UD-IQ3_XXS）まで落として 1 台に載せた値です。
4-3. ③コーディング — 当ラボの測定で最高
Aider Polyglot は、Exercism 由来の 225 題を C++ / Go / Java / JavaScript / Python / Rust の 6 言語で解かせるベンチマークです。白紙から書かせるのではなく、既存のファイルを渡して直させ、テストが落ちたらエラー出力を見せてもう 1 回直させます。
pass_rate_1 = 27.1%（61/225）、pass_rate_2 = 65.8%（148/225）。 2 回目までの正解率で、当ラボのこれまでの最高を更新しました。
条件は Flash-Next を測ったときとそろえています（編集形式 whole、8 並列、max_tokens 32768、2 回まで試行、思考はモデルの既定のオン）。
| 指標 | Nemotron 3.5 Super VL | Flash-Next（senfu 版） |
|---|---|---|
| pass_rate_1 | 27.1% | 32.4% |
| pass_rate_2 | 65.8% | 56.9% |
| コンテクスト超過（延べ 450 試行中） | 1 回（0.2%） | 198 回（44.0%） |
| 1 問あたりの所要時間（8 並列） | 約 26 分 | 約 59 分 |
読みどころは 2 つです。
1 回目は Flash-Next のほうが当てるが、直す力は Nemotron が上。 1 回目の正解率は Flash-Next が 5.3pt 高い。ところが 2 回目までだと Nemotron が 8.9pt 上回ります。1 回目に落ちた 164 問のうち 87 問（53%）を、テストのエラーを読んで直しています。Flash-Next は 152 問中 55 問（36%）でした。
思考が短く、上限に当たらない。 Flash-Next は延べ試行の 44% で、思考だけで max_tokens（32768）を使い切ってコンテクストを超えていました。Nemotron は 450 試行中 1 回だけです。そのぶん所要時間も半分以下で済みました。
この「思考が短い」は、GembaBench では裏目に出ました。1 つの問題を直す仕事では短く切り上げても困りませんが、サーバを行き来しながら調べ尽くす仕事では見落としにつながります。同じ性質が、課題によって長所にも短所にもなっています。
言語別では Python（82.4%）と Rust（80.0%）が高く、Java（51.1%）と C++（57.7%）が低めでした。
図の下半分（diff 系）は、変える前と後の行だけを決まった書式で返させる難しい形式（Aider 0.86.3、2 回まで試行、1 並列）で測ったもので、whole 系とは直接比べられません。diff 系のうち Qwen3-Coder-480B・GLM-5.2・MiniMax-M3 は 1 台に載らないため、DGX Spark 2 台を連結して測っています。Qwen3.6 は DGX Spark と同じ GB10 チップを積んだ Dell Pro Max で測りました。
4-4. ④マルチモーダル — 形式を守り切る
当ラボの画像向けベンチは、実写画像 8 枚に対する 3 タスク（キャプション生成、JSON 構造化抽出、PPE（安全装備）検出）です。測るのは、視覚情報を機械で読める形式で返し続けられるかです。
| 設定 | JSON 抽出 | PPE 検出 | 平均所要時間（キャプション / JSON / PPE） |
|---|---|---|---|
| 思考なし（max_tokens 4096） | 100% | 100% | 41.7 / 8.1 / 13.3 秒 |
| 思考あり（max_tokens 16384） | 100% | 100% | 85.7 / 44.1 / 97.2 秒 |
| 参考: Flash-Next（senfu 版、思考なし） | 100% | 100% | 50.5 / 18.2 / 18.3 秒 |
どちらの設定でも、形式の崩れ・空の応答・打ち切りはゼロでした。 思考なしでは Flash-Next より速く、JSON 抽出は半分以下の時間で返しています。キャプションは展示物の製品名を正しく読み取り、PPE の画像では「ヘルメットは手に持っているだけ」と所見を書き分けていました。
思考ありにすると、1 枚に最大 2,314 トークンを思考に使いました。このベンチの既定の max_tokens（1024）のままだと、思考だけで上限に届いて答えが出ない規模です。画像タスクで思考をオンにするなら、max_tokens を大きめに取る必要があります。
5. なぜモデルカードは「同時実行 1」なのか
5-1. 方式の制約ではなく、メモリの都合
モデルカードのクイックスタートは、同時実行 1・LiLiCorr・下書き 7 トークンという設定です。なぜ 1 なのかは書かれていません。当ラボでは、vLLM v0.32.0 のソースコードを読んで確かめました。
まず、LiLiCorr（vLLM での方式名は dflash）の実装に、同時実行 1 を前提にしたコードはありませんでした。同時に処理するリクエストの数だけバッファを確保する作りになっています。実機でも 32 本を受け付けて、全件正しく応答しました。
効いていたのはメモリです。投機的デコーディングでは、Mamba-2 の「状態」をリクエストごとに (1＋下書きトークン数) 倍確保します（vllm/v1/kv_cache_interface.py）。下書き 7 トークンなら 8 倍です。下書きが外れたときに状態を巻き戻せるよう、各位置の状態を持っておく必要があるためです。
その影響は実測ではっきり出ました。
| LiLiCorr なし | LiLiCorr あり | |
|---|---|---|
| 約 9,000 トークンのリクエストを同時に流せる本数 | 32 本以上（メモリ使用率 18%） | 8 本（メモリ使用率 89%） |
| 短いリクエスト（ShareGPT）を同時に流せる本数 | 32 本 | 16 本 |
つまり同時実行 1 は、「どんなに長いプロンプトが来ても、0.75 のメモリ設定で確実に収まる」安全を見た値だと考えられます。プロンプトがそれほど長くない使い方なら、同時実行は 8〜16 まで上げられます。 それ以上が必要なら、投機的デコーディングを外すか、メモリの割り当てを増やすことになります（後者は今回は試していません）。他の検証でも、同時 32 本で動かした報告や、同時 1〜8 本で測った報告が出ています。
5-2. 下書きの当たり方
LiLiCorr の下書き 7 トークンが、位置ごとにどれだけ当たったかも記録しました（c=8）。
| 位置 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|
| 採用率 | 76.8% | 57.5% | 41.9% | 30.8% | 22.7% | 17.1% | 12.5% |
本体が 1 回検証するたびに、平均 3.6 トークン進みます。この値は c=1〜32 でほとんど変わりませんでした。後ろの位置ほど当たらないので、下書きのトークン数を減らすと速くなるという他の報告（§4-1）とも合う結果です。なお ShareGPT（主に英語）での値で、日本語での採用率は測っていません。Flash-Next の MTP では、日本語の採用率が英語のコードの半分以下に落ちることが分かっているので、日本語中心の使い方では効果が下がる可能性があります。
5-3. 使い分け
| 使い方 | おすすめ |
|---|---|
| 個人が対話で使う（c≦4） | LiLiCorr あり。生成が 1.4〜1.7 倍速い |
| チームで同時に使う（c=8〜16） | LiLiCorr あり。プロンプトが長いなら同時実行の上限に注意 |
| 多人数で常時使う（c≧32） | LiLiCorr なし。LiLiCorr ありは 16 本で頭打ちになる |
| 最初の反応の早さを最優先 | LiLiCorr なし。TTFT が短い |
| エージェントで長いコンテクストを使う | LiLiCorr なし＋プレフィックスキャッシュ。思考は中程度 |
6. まとめ
| 軸 | 結果 |
|---|---|
| エージェント（GembaBench） | 18 本すべて最後まで走ったが、調べる課題で見落としが多い（T1 28/45、Flash-Next は 43/45）。主な原因は途中からの ssh の付け忘れ。T6 の修正は 3 回とも満点 |
| ①速度 | LiLiCorr ありで c=1 は 32.9 tok/s、c=16 は 129.5 tok/s。c=1〜16 で Flash-Next を上回る。TTFT は 1.3〜1.9 倍に悪化 |
| ②日本語知識 | JamC-QA 64.01%、11 モデル中 3 位（Flash-Next と互角、前世代から +4.7pt） |
| ③コーディング | Aider Polyglot pass_rate_2 65.8%、当ラボの測定で最高 |
| ④マルチモーダル | JSON・PPE とも形式崩れゼロ、思考なしでは Flash-Next より速い |
単発の課題では強く、止まらずに最後まで走る。ただし調べて直す仕事では、短く切り上げ、手元と対象を取り違える。 コーディングのベンチマークでは当ラボの最高を出したモデルが、サーバの現場仕事では 16GB の GPU 1 枚で動かした Qwen3.8-Flash-Next に届きませんでした。ベンチマークの点数だけでエージェント用のモデルを選ぶと外れる、という当ラボの経験がまた一つ増えました。
エージェントで使うなら、思考は中程度にし、§2-7 のように ssh の付け忘れをハーネスの側で防ぐことをおすすめします。コードを読んで直す仕事や、画像を読んで決まった形式で返す仕事なら、今すぐ戦力になるモデルです。
おわりに — 当ラボについて
NVIDIA という米国発のモデルが、DGX Spark 1 台で動き、日本語で成果物を書き、コーディングでは Qwen3.8 を上回るところまで来ました。中国製のモデルを避けたい組織にとって、オープンなモデルの選択肢が増えたことになります。一方で、エージェントとして現場の仕事を任せる用途では、現時点では Qwen3.8 に届いていません。次の世代に期待しています。
筆者は NPO法人 IoTメディアラボラトリーで、IoT 研究とあわせて AI 分野の検証を担当しています。東京大学・本郷キャンパス 大学院工学系研究科のラボで行っていた IoT 研究が独立し、研究機関として活動を続けている組織です。
やっていることは、本記事のようなローカル LLM の実機検証が中心です。新しいモデルが出るたびに手元のハードで動かし、速度・日本語知識・コーディング・マルチモーダルの 4 軸と、エージェントとしての現場仕事とで測り、動かなければ原因を突き止めるところまでやります。ベンダーの公称値ではなく、実際に自分の機械で何が起きるかを知りたいからです。
そのぶん、計算資源はいくらあっても足りません。機材の提供、検証のご依頼、共同研究など、お声がけいただけると喜びます。