NVIDIA Nemotron 3.5 Lightning 30B-A3B-NVFP4 を試してみた

はじめに

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

NVIDIA が Nemotron 3.5 Lightning を公開しました。30B の MoE でトークンあたりの稼働は 3B、コンテキストは 1M トークンです。

https://blogs.nvidia.com/blog/nemotron-lightning-switchyard-rtx-dgx/

これまで Nemotron ファミリーは Nano から Super、Ultra まで DGX Spark で追いかけてきました。前回の Ultra は 550B で、NVFP4 でも重みが 335GB あり、128GB の DGX Spark には重みすら載りませんでした。

https://dev.classmethod.jp/articles/dgx-spark-nemotron3-ultra-nvidia-api/

今回の Lightning は逆です。モデルカードに「1x DGX Spark (GB10)」という専用の起動レシピが載っていて、投機デコード用のドラフトまで DGX Spark 向けに調整されたものが同時公開されました。ベンダーが手元のマシンを名指しして「こう動かせ」と書いてきたわけです。これは試すしかありません。

先に結論を書いておくと、速さは看板どおりでした。投機デコードを載せた状態で単独 115.75 tok/s、8 本同時なら合計 421.85 tok/s。同じ骨格の前世代より単独で 27% 速く、KV キャッシュのプールは Gemma 4 の 24 倍あります。ただし、この速さには使い方の前提があります。とにかくよく考えるモデルで、トークン予算を渋ると思考だけで予算が尽きて本文が出てきません。NVIDIA の想定（16,000）まで開けると力が出る。「速いが、使い方に前提のあるモデル」というのが正直な所感です。

もうひとつ、測る前に押さえておきたい前提があります。NVIDIA はこのモデルを「なんでも 1 台でこなすモデル」として出していません。開発者向けの解説では、役割をはっきり分けています。

Frontier reasoning models such as Nemotron 3 Ultra handle orchestration and complex planning, while smaller, more efficient models handle the high-volume execution layer.

（Nemotron 3 Ultra のようなフロンティア推論モデルが指揮と複雑な計画を担い、より小さく動かす手間のかからないモデルが、量をこなす実行層を担う）

Lightning に任せる想定は、ツールの呼び出し、その結果の検証、サブエージェントへの委任、整形といった手数の多い実行です。計画は上位モデルへ、実行は Lightning へ振り分ける。その振り分け役が、同時に発表された NeMo Switchyard です。この前提を頭に置いて読むと、実測の見え方がだいぶ変わりました。

この記事では、公開当日の Nemotron 3.5 Lightning を DGX Spark で動かし、速度・日本語・コード生成・ツール呼び出しを同じ条件で測った結果を紹介します。

Nemotron 3.5 Lightning の素性

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

層の並びを config.json の layers_block_type で見ると、mamba と moe が交互に来て、その間に attention が 6 箇所だけ挟まっています。52 層のうち attention が 6 層しかない構成です。この比率が後で効いてきます。

比較対象を選ぶために前世代の config.json も開いてみたところ、思っていた以上に近い関係でした。

骨格はそのままで、コンテキストだけが 4 倍になっています。世代差がどこに出るのかを見るには、ちょうどいい比較対象です。この記事では、この 2 つを同じ vLLM・同じ課題・同じ条件で並べていきます。

公開されているチェックポイントは 1 つではありません。

末尾の 2 つは本体ではなくドラフトです。DSpark のほうは 967M パラメータで、モデルカードに「DGX Spark と低同時実行のデータセンター GPU 向け」と書かれています。

量子化による劣化は、モデルカードが BF16 版との対照表を出しています。

長文読解の AA-LCR が 2.8 ポイント落ちる以外は誤差の範囲で、SWE-bench に至っては NVFP4 のほうが高く出ています。量子化版を常用する側としては安心できる並びです。

動かすまで

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

これまで DGX Spark で新しいモデルを動かすときは、arm64 のイメージを自分でビルドするか、有志が GB10 向けに移植したイメージを探すのが定番でした。今回はモデルカードが vllm/vllm-openai:v0.27.1 を指定していて、公式イメージに arm64 版が用意されています。v0.27.1-aarch64 というタグもあり、モデルの公開と同じ日に push されていました。

起動コマンドもモデルカードの「1x DGX Spark (GB10)」ブロックをほぼそのまま使えます。

vllm serve --model $MODEL_CKPT \
  --moe-backend marlin \
  --kv-cache-dtype fp8 \
  --max-model-len 1048576 \
  --enable-prefix-caching \
  --speculative_config.num_speculative_tokens 3 \
  --mamba-backend flashinfer \
  --mamba-cache-mode align \
  --reasoning-parser nemotron_v3 \
  --speculative_config.method dspark \
  --tool-call-parser qwen3_coder \
  --enable-auto-tool-choice

--moe-backend marlin と --mamba-backend flashinfer が GB10 向けの指定です。今回は他のモデルと条件を揃えるため --max-model-len を 65536 に落とし、投機デコードは別条件として分けました。--kv-cache-dtype は指定せずエンジンに任せています（起動ログを見ると、指定しなくても fp8_e4m3 が選ばれていました。モデル側の量子化設定から決まるようです）。

起動にはドラフトの名指しが要ります

ひとつだけ、そのままでは通らない箇所があります。上のコマンドを実行すると、このエラーで止まります。

ValueError: Model config must specify `dflash_config.mask_token_id`, `mask_token_id`,
`dspark_noise_token_id`, `pard_token`, or `ptd_token_id` for parallel drafting.

投機デコードの方式（dspark）だけを指定して、どのドラフトを使うかを書いていないためです。指定がないと vLLM は本体に同梱されている MTP ヘッドをドラフトに選ぶのですが、DSpark 方式が必要とする専用のトークン ID を持っていないので止まります。

ドラフトを名指しすれば通ります。

  --speculative_config.method dspark \
  --speculative_config.model nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4-DSpark \
  --speculative_config.num_speculative_tokens 3

この記事の投機デコードの数字は、すべてこの書き方で測っています。

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

Muse Glimmer を vLLM で起動したときが 371 秒だったので、それより 1.3 倍ほど速い立ち上がりです。

KV キャッシュが桁違いに大きい

起動ログで目を引いたのがここでした。

GPU KV cache size: 18,448,384 tokens

同じ DGX Spark で、同じ --max-model-len 65536 / --gpu-memory-utilization 0.85 で測った他のモデルと並べます。

Gemma4 の 24 倍、Muse Glimmer の 3.8 倍です。理由は config.json を見れば分かります。52 層のうち attention 層が 6 つしかなく、残りは Mamba-2 と MoE だからです。KV キャッシュを持つのは attention 層だけなので、層の比率がそのままプールの大きさに出ています。

1M トークンのコンテキストを謳うモデルは他にもありますが、実際に 1M を張ったときにメモリが足りるかは別の話です。このプールなら、1M トークンの文脈を 17 本以上同時に抱えられる計算になります。看板の 1M が、少なくとも容量の面では現実的だと分かります。

ちなみに Lightning が特別なのではありません。同じ骨格の前世代 Nemotron 3 Nano 30B-A3B もほぼ同じ 18,298,197 トークンでした。Mamba ハイブリッドという設計の性質です。

測定条件

以降の数値は、断りがない限り同じ vLLM（v0.27.1-aarch64）・同じ最大長（65,536）・同じスロット数（8）で測っています。SGLang との比較だけは専用イメージ（dev-nemotron3-5-lightning）を使い、最大長とスロット数を vLLM 側に揃えました。両モデルを載せているのは別々の DGX Spark なので、速度の比較は同じ機体の中だけで完結させました。

サンプリングは、それぞれのモデルの公式推奨値を使っています。Lightning が temperature 1.0 / top_p 0.95、Nano が temperature 1.0 / top_p 1.0 です。速度の測定だけは temperature 0 の固定条件で揃えているので直接比較できますが、日本語やコードの比較には推奨値の差が乗っている点はご承知おきください。

トークン予算は 16,000 を基本にしました。NVIDIA のモデルカードに載っているサンプルコードがこの値を使っていて、このモデルはそれを前提に作られているためです。他のモデルと横並びにする表だけは、過去の記事と揃えるために 4,096 で測った値を使っています。このモデルは思考が長いので、予算を狭くすると実力が出ません（そのことは後述します）。

速度

強制長 256 トークン・temperature 0 で、同時実行数を変えながら測りました。

同じ DGX Spark・同じハーネスで測った他のモデルと並べます。

Muse Glimmer の 6.8 倍、Gemma4 の 11.6 倍です。

NVIDIA はこのモデルを「同等サイズのモデルと比較して、最大 4 倍の出力速度」と説明しています。手元の実測はその主張を上回りました。ただしこれはフェアな比較ではありません。下 3 つは dense モデルで、1 トークン生成するのに 30B 相当の重みを全部通します。Lightning は MoE なので実際に動くのは 3B ぶんだけです。同じ「30B クラス」でも、動く量が 10 分の 1 なら速いのは当たり前とも言えます。

実際、同じ Active 3B の MoE である Qwen3.6-35B-A3B は、以前べつの条件で測ったときに素の状態で 76.7 tok/s でした。今回の Lightning の 79.59 tok/s とほぼ並びます（vLLM の版も KV の設定も違うので、参考値として見てください）。速さの大半は「MoE で Active 3B」という設計から来ていて、Lightning 固有の魔法ではない、というのが正直なところです。

とはいえ、DGX Spark に載せて使う側からすると「同じくらいのメモリを食うモデルのうち、どれが速いか」は実用的な問いです。その意味では、この差はそのまま体感差になります。

面白いのは TTFT（最初の 1 トークンまでの待ち時間）で、C=1 で 0.071 秒です。Muse Glimmer の 0.406 秒と比べて 5.7 倍速く、対話で使ったときの「返事が来た」までの体感がまったく違います。しかも同時実行を 8 まで増やしても 0.212 秒に収まっていて、8 本同時でも 1 本のときより待たされません。

同時実行 8 本での 1 本あたり 43.0 tok/s は、他のモデルの単独実行時（6.8〜12.4 tok/s）より速い水準です。チームで 1 台を共有する使い方だと、この差はさらに効いてきます。

DSpark 投機デコードを載せる

ここからが本題です。NVIDIA は Lightning 本体と一緒に、DGX Spark 向けに調整した投機デコード用のドラフトを公開しています。公式の GB10 レシピにも最初から入っている構成なので、これを載せた状態が本来の姿と言えます。

ドラフトは 967M の小さなモデルで、これが先読みした候補を本体が検証します。当たれば 1 回の計算で複数トークン進むので速くなる、という仕組みです。

単独実行で 115.75 tok/s、8 本同時なら合計 421.85 tok/s に届きました。ドラフトのぶんメモリは 17.62 GiB から 19.14 GiB に増えますが、128GB の統合メモリからすれば誤差の範囲です。

品質が落ちていないことも確認しました。日本語 10 課題を投機ありでもう一度通したところ、10 問すべてで判定が投機なしと一致しています。このモデルの想定予算である 16,000 でも取り直しましたが、日本語（8/9）・コード生成（5 問完答・テスト 49 個全通過）・エージェント適性の 6 プローブまで、すべて投機なしと同じ判定でした。投機デコードは「速く出す」だけで出力を変えない、という理屈どおりの結果です。

なお、ドラフトの公称性能は SPEED-Bench での受理長 3.75（先読み 7 段）です。受理長 3.75 なら理論上 3.75 倍まで伸びる計算になりますが、手元では 1.45 倍でした。起動時にこんな警告が出ています。

max_num_scheduled_tokens is set to 2032 based on the speculative decoding settings.
This may lead to suboptimal performance. Consider increasing max_num_batched_tokens
to accommodate the additional draft token slots, or decrease num_speculative_tokens
or max_num_seqs.

投機デコードを有効にすると、1 回のスケジューリングで扱えるトークン数が制限されるという内容です。

先読みの段数は 3 のままがよさそう

先読みの段数（num_speculative_tokens）はモデルカードが 3 を指定していますが、ドラフトの config.json には block_size が 8 と書かれています。増やしたほうが速いのか気になったので、8 でも測ってみました。

速いのは 3 のほうでした。8 にすると単独実行で 115.75 → 93.54 tok/s まで落ちます。先読みを伸ばすほど外したときの無駄が増えるので、このモデルとこのハードウェアでは 3 のあたりが釣り合うのだと思います。素直にモデルカードの値を使うのがよさそうです。

SGLang でも DSpark が動く

DSpark は vLLM 専用ではありません。モデルカードの SGLang 節に載っているのは EAGLE 構成だけですが、公式 cookbook まで降りると DSpark の起動コマンドがあり、それを DGX Spark 向けのパラメータで包んだコミュニティレシピ（MiaAI-Lab）も公開当日に出ていました。SGLang 側は lmsysorg/sglang:dev-nemotron3-5-lightning という専用イメージで、arm64 版もモデルと同じ日に push されています。

投機まわりの指定はフラグ 3 つで足ります。vLLM と違ってドラフトの指定が独立した必須フラグになっているので、ドラフトの名指しを忘れて落ちる、という先ほどの問題は構造的に起きません。

--speculative-algorithm DSPARK \
--speculative-draft-model-path nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4-DSpark \
--speculative-dspark-block-size 3

同じ機体・同じ条件（最大長 65,536・8 スロット）で vLLM と並べました。

単独実行はほぼ互角です（差 1.6%）。DSpark の効き方は、スタックを替えても変わりませんでした。並列側は vLLM が 1 割ほど上回ります。日本語課題のスポット確認でも、思考の長い 1 問が 4,096 の予算を食い切った以外は vLLM と同じ判定でした。

差が出たのはメモリの設計です。同じ条件で KV キャッシュのプールを見ると、vLLM の約 1,845 万トークンに対して SGLang は約 544 万トークンと、3.4 倍の開きがあります。SGLang はドラフト用の KV キャッシュを bf16 で別枠に確保する設計で、そのぶん本体のプールが痩せます。レシピ既定の 1M コンテキスト設定でも約 505 万トークン・同時 48 リクエストでした。1M を活かしたい場合はここが効きます。

SGLang で測ってよかったのは受理長です。SGLang はログに受理長と受理率を毎バッチ出すので、vLLM では見えなかった「ドラフトがどれだけ当たっているか」を直接確認できます。日本語課題の生成中の 60 サンプルで、受理長は中央値 3.27（先読み 3 段の上限は 4.0）、受理率は中央値 0.76 でした。ドラフト自体は十分に当たっています。手元の倍率が公称より控えめに出る主因は、ドラフトの精度ではなく先ほどのスケジューリング制限側にある、という傍証になりました。

日本語

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

自由記述は機械で採点できないので合計から外しています。Nano の列は横並びのため予算 4,096 で測った値です（こちらは思考が短く、この予算で打ち切りは起きません）。

機械で採点できる 9 問のうち 8 問が正解でした。落としたのは固有名詞を保ったまま要約する課題で、20,678 字ぶん考えたうえで、6 つの固有名詞を 1 つも残せませんでした。予算はまだ余っている（12,112 トークン）ので、紙が足りないのではなく、この課題が苦手だということです。

ここは予算を変えて測ったことで見え方が変わりました。横並び用の 4,096 で測ると、同じ課題が「思考が予算を食い切って本文 0 文字」という落ち方をします。合計はどちらも 8/9 ですが、中身は別物です。狭い予算で測ると、苦手なのか紙が足りないのかを区別できません。

差がはっきり出たのは、答えにたどり着くまでの考え込みの量でした。同じ問題で Lightning は Nano の 3〜6 倍考えます。50 字で答える問題で Nano が 385 トークンなのに対し Lightning は 1,402 トークン、図表の書き起こしでは 854 対 5,286 です。

ただし Lightning は生成そのものが 1.3 倍速いので、体感の待ち時間はトークン数の比ほどには開きません。よく考えるぶんトークンは食うが、速いのでそれほど待たされない、というのがこのモデルの性格のようです。

コードを書かせる

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

仕様からゼロで書く

全問正解、テストも 49 個すべて通りました。前世代が 3/5 なので、ここは世代差がはっきり出たところです。

注目したいのは parse_duration（「1h30m」のような文字列を秒に直す問題）で、17,582 字ぶん考えて解いています。横並び用の 4,096 で測ったときは、この問題だけ思考が 13,091 字で予算に達し、コードを 1 行も出せずに終わっていました。1 万字を超える思考が必要な問題だったわけで、狭い予算では届かなかっただけです。

Nano のほうは 1,438 トークンで答えを出したものの、16 個のテストが全滅しました。片方は考える紙が足りず、もう片方は考える前に答えている、という対照的な落ち方です。

思考の長さの差も歴然としています。Nano が 331〜4,226 字で答えを出すのに対し、Lightning は 3,702〜17,582 字。同じ骨格でも、後継のほうがよく考える設計になっているのが数字に出ています。

既存のバグを直す

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

こちらは互角でした。どちらも 12 テスト全通過まで持っていきます。ツールを使って自分で直しに行く形の課題では、両世代とも危なげがありません。

ツールとして使えるか

エージェントの部品として使えるかを見ます。ツール呼び出しの形式は、チャットテンプレートを読むと JSON ではなく XML でした。

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

Qwen3-Coder と同じ形式で、vLLM 側も --tool-call-parser qwen3_coder を指定します。

基本的な呼び出しは 5 問すべて通りました。

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

required を指定すると止まらなくなる

ひとつ、はっきりした問題がありました。「必ずツールを呼べ」と指定する tool_choice: required を投げると、同じツール呼び出しを 159 回返してきます。

指示自体は守っています（ツールを呼んでいる）。ただ、1 回呼んで止まるべきところで止まらず、トークン予算が尽きるまで同じ呼び出しを吐き続けます。ほとんど考えずに（思考 474 字）出力し続けているので、生成が止まる条件を見失っている状態に見えます。

この挙動は他のモデルでも見てきました。Muse Glimmer と Gemma4-31B は required を投げてもエラーにならず 0 件が返ります。方向は逆ですが、どちらも「クライアントの契約が静かに壊れる」という点では同じです。required を使うクライアントを書くときは、モデルごとに実機で確かめるしかありません。

この暴走が Lightning 固有なのかを確かめるため、同じ骨格の前世代である Nemotron 3 Nano 30B-A3B を、同じ vLLM・同じパーサ・同じ課題で測ってみました。結果は 150 件・finish_reason: length で、同じように止まりませんでした。モデル固有ではなく、Nemotron 系と qwen3_coder パーサの組み合わせで起きる問題のようです。

複数のツールをどう呼ぶかが世代で変わった

もうひとつ、前世代との違いが出たところがあります。「東京と大阪の天気を教えて」のように 2 か所への問い合わせが要る質問で、呼び方が逆転していました。

どちらも最終的に両方の都市に到達するので、正しさの問題ではありません。ただ、ツールの呼び出しに時間がかかる環境では、まとめて呼べる前世代のほうが有利な場面もありそうです。以前 Muse Glimmer を測ったときも、場面によって 1 件ずつだったり 4 件まとめてだったりしたので、1 回の観測でモデルの性格と決めつけないほうがよさそうです。

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

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

ツール選択は、40 個のツール定義を積んだ状態で 6 つの依頼を出し、期待どおりのツールを選ぶかを見ます。両世代とも同じ 1 問を外しました。「毎朝 9 時に実行するよう設定して」に対して、cron を作るツールではなくディレクトリ一覧のツールを呼んでしまいます。骨格が同じだけあって、弱点も同じようです。

つまずいたのは定型フォーマットの再現です。日報のテンプレートを 5 回書かせて、毎回同じ構造になるかを見る課題なのですが、5 回とも 53.2 秒で本文 0 文字でした。ここでも思考が予算を使い切っています。

ここで条件を 2 つ振ってみました。思考が邪魔をしているなら切ればいいと考えて enable_thinking を切ったものと、逆に NVIDIA 自身のサンプルコードが使っている予算 16000 まで広げたものです。

予算を NVIDIA の想定まで広げたら、0/5 が 3〜4/5 まで改善しました。 やはり予算の問題だったわけです。ただしこれは「毎回同じ形で書ける」水準ではありません。5 回 1 セットを 3 セット回して 3/5・3/5・4/5、合計 10/15。どのセットでも 1〜2 回は構造が崩れます。所要時間も 34〜207 秒と 6 倍の幅がありました。

思考を切ったほうは 1〜2 秒で返ってくるものの、構造が揺れるうえに長い system prompt のルールも守らなくなりました。皮肉なことに、思考は指示を守るために使われていたようです。

無人で定型の書類を作り続ける用途なら、同じ条件で 5 回とも安定していた前世代 Nano のほうが、まだ安心して任せられます。

ここで冒頭の前提を思い出すと、見え方が変わります。NVIDIA が Lightning に任せる想定は、ツールを呼び、結果を検証し、次に渡すという実行の仕事でした。その物差しで見ると、ツール呼び出し 5/5、擬似ファイルシステムの探索、バグ修正 5/5 と、実行層としての仕事はきちんとこなしています。落としたのは「日報のテンプレートを毎回同じ構造で書き続ける」という、どちらかといえば書類仕事に近い課題です。

なお NVIDIA は「OpenClaw や Hermes Agent といったハーネス向けに訓練した」とも書いています。ここで測っているのは各ハーネスが必要とする能力のプローブであって、ハーネス本体を動かした結果ではないので、実際に載せたときの挙動は別途確かめる必要があります。そこは続編の宿題にします。

30B クラスの次の戦場は特化型エージェントになりそう

ここまでの話は、モデルを「特定の能力の調達先」として見る、という一点に集約できます。この見方を延長すると、並べるモデルは「賢い順」の縦一列だけではなくなりそうです。ちょうどこの記事を書いている時期に、Fastino が NVIDIA との協業で、Nemotron 3.5 Lightning を金融と医療それぞれに特化学習したモデルを Apache 2.0 で公開しました。ベースは 30B でアクティブ 3B の MoE（Mixture of Experts）という軽量モデルですが、Fastino の発表では金融ベンチマーク FinQA が 15.9% から 59.2% まで動いたとされています。ドメインを絞れば、軽いモデルがその領域では大型モデルに並ぶという実例です。重みが公開されているオープンモデルだからこそできる使い方で、プライバシーや規制の強い業界ほどこの路線は増えていくはずです。

https://fastino.ai/blog/fastino-nemotron-3-5-lightning-finance-and-healthcare

そうなると面白いのは、業務ドメインや企業そのものを 1 つの大きなモデルに見立てる発想です。特化学習された軽量モデルたちはその中のエキスパートに、振り分け役はどのエキスパートを呼ぶかを決めるゲーティングに相当します。MoE の構造が、1 つのモデルの内側からシステム全体のアーキテクチャへ外出しされていく形ですね。Nemotron 3.5 Lightning が「軽い実行担当」、Switchyard が「仕事を振り分ける監督役」という組み合わせを見ていると、NVIDIA はもう「最強モデルを 1 個選ぶ」競争ではなく、計画・実行・検証を別々のモデルへ分解するエージェント設計に踏み込んでいるのかもしれません。

先日 Meta Superintelligence Labs がオープンウェイトで公開した Muse Glimmer 30B もそうですが、このサイズのモデルが総合力の賢さ比べで最上位と張り合うのは難しくなっています。勝負どころは「どの領域のエキスパートになるか」に移っていて、30B クラスの次の戦場は特化型エージェントとしての場になりそうです。手元の DGX Spark にドメイン特化の Lightning が並ぶ日は、そう遠くない気がしています。

まとめ

Nemotron 3.5 Lightning は、DGX Spark に載せる 30B クラスとしては速度で明確に一歩抜けています。投機デコードなしで単独 79.59 tok/s、DSpark を載せて 115.75 tok/s、8 本同時なら合計 421.85 tok/s。最初の 1 トークンまで 0.071 秒という応答の速さも、対話で使うと効きます。KV キャッシュのプールが 1,800 万トークンあるので、看板の 1M コンテキストも容量の面では現実的でした。

扱いには癖があります。とにかくよく考えるモデルで、トークン予算を狭く取ると本文に届きません。 横並び用に 4,096 で測ったときは、3 つの課題で思考が予算を食い切りました。逆に NVIDIA の想定である 16,000 まで広げると打ち切りは消え、コード生成は 5 問すべて正解（テスト 49 個も全通過）、定型フォーマットも 0/5 から 10/15 まで改善します。予算さえ与えれば力は出る、というのが正しい理解でした。

それでも定型フォーマットは、5 回に 1〜2 回は構造が崩れます。かといって思考を切ると、今度は 50 字の制約や JSON の書式を守らなくなる。全開かゼロかの 2 択で、その中間を刻むノブがモデル側にない。ここは最初、弱点だと思いました。

ただ、これはモデル 1 つで完結させる前提が、そもそも違っていたのだと思います。NVIDIA の分担は、複雑な計画は Nemotron 3 Ultra のような上位モデル、手数の多い実行は Lightning。推論の強度をモデル内部で刻むのではなく、タスクごとにモデルを切り替えるという設計です。その切り替え役が NeMo Switchyard で、LangChain の検証では Lightning と Claude Opus 4.8 を振り分け、上位モデルに送るのは全体の 7% だけで 74% のコスト削減という数字が出ています。

この分担を前提にすると、手元の実測もきれいに収まりました。ツールを呼んで結果を確かめる類の仕事は取りこぼしがなく、コード生成は 5 問すべて正解、速度は前世代比で 27% 速い。「大量の定型作業を速く回す担当」としては、期待どおりのものが来たと思います。逆に、決まった書式の書類を無人で作り続けるような仕事なら、同じ骨格の前世代 Nano のほうが安定していました。用途で選び分ける、というのがこのモデルの正しい読み方でしょう。

NVIDIA が主張する「同クラス比で最大 4 倍の出力速度」も、手元では dense の 30B クラス相手に 6.8〜11.6 倍と、むしろ控えめな数字でした。エージェントのタスク完了時間で Qwen3.6 35B より 30% 速いという主張については、生成速度そのものはほぼ並んでいたので、差が出るとすればハーネス最適化の効きだろうと思います。そこは今回測れていません。

続きとしてやりたいのは、まさにその Switchyard との組み合わせです。以前 Switchyard は単体で試しているので、Lightning を実行層に据えて上位モデルと振り分ける構成を組めば、この記事で測った速度がそのまま効いてくるはずです。1M コンテキストを実際に埋めたときの性能も宿題にしておきます。

参考リンク

• NVIDIA Nemotron 3.5 Lightning 発表ブログ（2026-08-11）
• Nemotron 3.5 Lightning の開発者向け解説 — 実行層としての位置づけとハーネス最適化の説明はこちら
• NeMo Switchyard でエージェントの処理をモデル間に振り分ける — 上位モデルと使い分ける側の解説
• Fastino が Lightning をベースに公開した金融・医療の特化モデル — Apache 2.0。ドメイン特化でどこまで伸びるかの実例
• nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4 — 今回測った本体。DGX Spark 用の起動レシピもここ
• nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4-DSpark — DGX Spark 向けの投機デコード用ドラフト
• nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B-NVFP4 — 比較に使った前世代
• NVIDIA-NeMo/Nemotron の vLLM cookbook — 投機デコードの設定はモデルカードよりこちらが詳しいが、先読み段数の記述は実機と食い違っていた
• NVIDIA-NeMo/Nemotron の SGLang cookbook — SGLang 側の DSpark フラグはモデルカードにはなく、こちらに載っている
• MiaAI-Lab の DGX Spark 向け SGLang レシピ — 今回の SGLang 検証の起点。GB10 向けのメモリ設定つき
• vLLM v0.27.1 リリース（2026-08-11）— 量子化された DSpark head への対応が入っている
• OpenMDW-1.1 ライセンス
• Muse Glimmer 30B を DGX Spark で測った記事 — 比較表の Muse Glimmer / Gemma4-31B の数値はここで測ったもの
• Qwen3.6-35B-A3B-NVFP4 を DGX Spark で測った記事 — 同じ Active 3B の MoE との比較