NVIDIA Nemotron 3.5 Lightningとは？エージェント業務を4倍速くする軽量MoEの正体

この記事のまとめ

NVIDIAのNemotron 3.5 Lightningは、常時動き続けるAIエージェントの反復作業を軽く速くさばくために設計された軽量モデルです。総パラメータは30Bで、実際に使うのは約3Bだけの疎なMoE構成となっており、同クラス比で最大4倍の出力速度をうたいます。ここでは仕様、思想、実力、活用場面までを整理します。

総30B・アクティブ3Bのハイブリッド構成で、コンテキストは最大1Mトークンに対応します。
Mamba-2＋MoE＋Attentionと投機的デコード、NVFP4量子化で最大4倍の出力速度を狙います。
NeMo Switchyardで計画は大型、実行はLightningという役割分担ができます。
CrowdStrikeやHarvey、CodeRabbitなどが事後訓練前提で採用しています。

Nemotron 3.5 Lightningの正体

モデルの基本スペック

Nemotron 3.5 Lightningの公開仕様を確認しておきます。

Nemotron 3.5 Lightningは総パラメータ30Bのうち、1回の推論で動くのは約3Bだけの、専門家を切り替えて使う疎な構成（MoE）のモデルです。構造はMamba-2とMoE、Attention層を織り交ぜたハイブリッドで、コンテキスト長は最大1Mトークン、単一のH100 80GBやA100 80GBでも動く設計です（参照*1）。

ライセンスはOpenMDW License Agreement version 1.1で、公開日は2026年8月11日です（参照*1）。

30Bの規模感を保ちつつ、動くときの計算は3B相当という燃費のよさが基本設計の軸です。私がこれを最初に見たとき、「軽量モデル」という言葉のイメージを更新する必要があると感じました。GPU1枚から始められる点は、ローカルやエッジで動かしたい開発者にとって、導入ハードルを大きく下げます。

Nemotronファミリーでの位置づけ

Lightningは、Nemotronファミリーの中で長時間動くエージェントの高ボリュームな実行を担う位置づけです。

NemotronはNano、Lightning、Super、Ultraの4階層で、Nanoはエッジ端末やPC、Lightningは長時間動くエージェントの高ボリュームな実行、Superは単一GPUでの高スループット、Ultraは複数GPUのデータセンター向けと役割が分かれています（参照*2）。

またLightningはNemotron 3 Ultraから蒸留して作られたモデルで、大型モデルが持つエージェント能力を受け継ぎつつ、効率と高スループット、素早いトークン生成に振り切っています（参照*3）。

この階層を意識すると、Lightningを単体で万能モデルとして評価するのは的外れだとわかります。大型モデルと組み合わせて実行層を担う駒として見る視点が、導入検討の出発点になるはずです。

エージェント実行層という設計思想

常時稼働エージェントの課題

実行専用の軽量モデルは、エージェントの反復作業を担うために想定されています。

自律エージェントの現場では、ツール呼び出しや結果チェック、コマンド実行、タスクの委譲といった反復作業が延々と発生します。ここで毎回大型の推論モデルを呼ぶのではなく、Lightningのような軽量モデルに定型作業を任せ、計画や難しい判断だけを大型モデルに残す使い分けが提案されています（参照*4）。

タスクの種類ごとに異なるモデルが担当する構図が想定されています。計画や難しい意思決定は大きな推論モデルが担い、繰り返しのツール呼び出しや検証、フォーマット処理などは高速な専用モデルが担う形です（参照*5）。

毎ステップで最上位モデルを呼ぶ設計は、コスト面でも遅延面でも重くなりがちです。私がコンサルティングの現場でAI導入を支援してきた経験でも、「とりあえず高性能モデルを全工程に使う」という設計が、思わぬコスト超過につながるケースを何度も見てきました。反復タスクの割合を洗い出し、そこだけ軽量モデルに置き換えられるかを検討する余地は、多くのプロジェクトに存在します。

システム・オブ・モデルズの発想

複数モデルの役割分担は、NVIDIAが掲げる将来像とも重なります。

NVIDIAのシニアディレクターであるJoey Conway氏は、複数モデルを組み合わせる「システム・オブ・モデルズ」こそがAIの将来像だと語っています（参照*6）。

エージェント型AIは、検索役、計画役、ツール実行役、検証役といった役割の異なるエージェントが、広いコンテキストと長い時間軸の中で協調して働く形へと進んでいます（参照*7）。

この視点に立つと、Lightningは1個で全部こなす選手ではなく、実行担当として繰り返し呼ばれる中継ぎのような役どころに位置づきます。「モデルを選ぶ」のではなく「モデルを組み合わせて設計する」という発想の転換が、エージェント型AIを実務に乗せるときの本質的な問いだと私は考えています。

高速化を支えるアーキテクチャ

ハイブリッドMoEとMTP

Lightningは、専門家を絞って動かし、複数トークンを予測することでスループットを高める設計です。

LightningはMamba-2層とMoE層を交互に配置し、そこにAttention層を組み合わせたハイブリッドMoEを採用しています。総パラメータ30Bのうち、1回の順伝播で動くのは3Bだけという疎な設計です（参照*1）。

より細かい構成としては、層数は52、隠れ次元は2688、エキスパートは128（top-6でルーティング）に加えて共有エキスパートが1つあり、1度に複数トークンを予測する仕組み（Multi-Token Prediction、以下MTP）が組み込まれています（参照*8）。

つまり同時に働く専門家を絞りつつ、1ステップで複数トークンを予測してスループットを稼ぐ二段構えです。

投機的デコードとNVFP4量子化

Lightningの速度は、投機的デコード、MTP、NVFP4量子化を組み合わせて高めています。

公表資料によれば、Lightningの速度は2つのドラフトモデルを使う投機的デコード、MTP、NVFP4量子化を積み重ねて達成しており、コンテキスト長は最大100万トークンまで扱えます（参照*9）。

NVFP4という4ビット系の量子化を事後に施し、Quantization-Aware Distillationで精度を戻したチェックポイントは、BF16の66GBから22GBまでサイズが縮み、スループットは最大4倍にまで伸びるとされています（参照*8）。

DSparkは、DGX Sparkのようなコンパクトなブラックウェル系システムでの投機的デコード用に用意され、ブロック単位で下書きしつつ受理長を伸ばすことを狙って設計されています（参照*10）。

4倍という数字はNVFP4量子化を含む条件での最大値であり、環境や設定によって伸びは変わります。発表数値をそのまま信じず、手元のタスクで確かめる姿勢が必要です。

ベンチマークで見る実力

Lightningは、エージェント寄りのタスクを速く多く処理する性質にチューニングされているモデルと読めます。

NVIDIAの統合評価では、Nemotron 3 Nano世代からの伸びが分かりやすく示されています。SWE-bench Verifiedは34.08から51.56、Terminal-Bench 2.1は8.29から24.58、PinchBenchは66.11から85.37へと上がり、同じサイズ帯のモデルとしては大きな伸びとなっています（参照*9）。

Hugging Faceのモデルカードでは、SWE-bench Verified 51.56、Terminal-Bench 2.1 24.58、PinchBench 85.37、τ³-bench（Banking）9.28、IFBench（loose）71.88、AA-LCR 52.00といったスコアが公開されています（参照*1）。

速度面ではNVIDIAが同クラス比で最大4倍の出力速度をうたい、PinchBenchでは86%の精度に達しつつ、Qwen3.6 35Bと同程度の精度のまま1万タスクの完了が30%高速だったと説明されています（参照*4）。

一方でArtificial AnalysisのIntelligence Indexではスコア24となり、Qwen3.6 35B A3BやMuse Glimmerといった小型モデルの後ろに位置しています。ただしプレリリース環境でNVFP4版を測ると、中央値でおよそ670トークン毎秒という出力速度を示しました（参照*5）。

難しい推論の総合力より、エージェント寄りのタスクを速くたくさん回す性質にチューニングされているモデルという読み方が自然です。Intelligence Indexでのスコアだけを見て判断するのは、このモデルの使いどころを見誤る原因になります。

ローカル／エッジ実行の実際

想定デプロイ環境

Lightningは、ローカルからデータセンターまで幅広い環境での実行を想定しています。

Lightningはローカル動作も想定しており、NVIDIAのDGX Spark、Jetsonシステム、GeForce RTX 5090で動かせるほか、データセンターにも展開できます（参照*4）。

対応ハードウェアはBlackwell（GB200、GeForce RTX 5090）、Hopper（H100、H200）、Ampere（A100）が明記されています（参照*1）。

デプロイターゲットはさらに幅広く、DGX Spark、DGX Station、RTX PRO、RTX、NVIDIA Jetson、H100、H200、A100、L40S、B200/GB200、B300/GB300が挙げられています（参照*11）。

DGX Sparkでの実測値

DGX Sparkでの個人計測では、単一ストリームでのデコードは約72〜87トークン毎秒と報告されています。

ある個人ブログのDGX Spark上でOllamaを用いた計測では、単一ストリームでのデコードが約72〜87トークン毎秒、プレフィルが約2,600トークン毎秒で、コンテキストが8Kから16Kトークンあっても維持できたと報告されています。同じ環境でvLLMとDSparkを組み合わせた場合は、Ollama比でデコードがおよそ1.5倍、プレフィルはおよそ2倍まで伸び、21Kトークンのコンテキストを積んでも約90トークン毎秒を保ったとされています（参照*12）。

DSparkのSPEED-Benchでは、ドラフト長7での受理率がコーディング4.38、人文3.18、数学4.17、多言語4.55、QA3.36、RAG4.25、推論3.90、ロールプレイ3.06、STEM3.40、要約4.15、ライティング2.83、全体平均3.75と報告されています（参照*10）。

これらは単一ユーザ・単一ストリームの数値です。複数ユーザが同時にリクエストを投げる本番想定にそのまま当てはめるのは危険で、自社環境での検証は必須です。

NeMo Switchyardによるモデルルーティング

Switchyardの仕組み

NeMo Switchyardは、複数のモデルやプロバイダへのリクエストを送り分けるルーティング基盤です。

NeMo Switchyardは、Kong、OpenRouter、LiteLLMといった既存のルータやAIゲートウェイが取り込みつつある、新しいオープンソースのルーティングライブラリとして提供されています（参照*6）。

技術的にはLLMトラフィック向けのRust製プロキシ兼ライブラリで、複数プロバイダ間でリクエストをルーティングし、OpenAIとAnthropicのAPI形式を相互変換し、運用メトリクスを記録しつつ、型付きで組み合わせ可能なルーティングアルゴリズムを提供します（参照*13）。

既存のエージェントスタックの内側に置き、精度、遅延、コスト、あるいは自社データで学習させたルータといった基準で、ステップごとに最適なモデルへリクエストを送り分けます（参照*9）。

Nemotron専用ではなく複数のモデルとプロバイダを扱える汎用ルータなので、Lightningを実行層に据えつつ既存のフロンティアモデルを計画層として残す構成が取りやすくなります。生成AI導入で私がよく見る失敗は、ツールを入れた後の運用設計が抜けることです。Switchyardのようなルーティング基盤は、業務を分解して「どのステップに何のモデルを当てるか」を決める設計力があって初めて機能します。

パートナー導入の成果

パートナー事例では、ルーティングによるコストや実行時間の削減が報告されています。

LangChainはDeep Agentsの145件のマルチターンタスクで、フロンティアモデルへの呼び出しをわずか7%に絞りつつ、精度は6%落ちる一方でコストを74%削減したと報告されています。またRampは、社内のSWE-Benchでフロンティアモデル相当の性能を保ちつつ、コストを58%、実行時間を33%削減したとしています（参照*6）。

このほか、CognitionはDevin Desktopで平均コストを28%引き下げ、Classmethodは社内テストで品質を保ったまま27%のコスト削減、BoomiはドメインルーティングでLightningの5倍高速なモデルへ59%のトラフィックを流し後半ターンの遅延を21%削減、Cadenceはフォーマル検証で9.9%の効率改善という結果を出しています（参照*9）。

各社の測定条件やタスク分布はそれぞれ異なるため、これらの数値は自社環境にそのまま当てはまるとは限りません。私が生成AI導入支援で繰り返し伝えていることですが、他社事例の数値はあくまで仮説の出発点です。自社ワークロードで似た比率のオフロードが可能かどうかを、小さな検証から確かめる流れが現実的です。

活用ユースケースと事後訓練

事後訓練が生む差別化

Lightningは、事後訓練を通じて自社タスクに寄せる前提のモデルと読めます。

NVIDIA担当者は、一般的なエージェント向けベンチマークはあくまで出発点であり、本番で重要なのは自社タスクにおける精度であって、そこで事後訓練が最も大きな差を生むと語っています。Lightningを早期に触った顧客が専門ワークフロー向けにカスタマイズしたところ、精度が大きく伸び、パートナーが従来使っていた開放モデルや専有モデルを上回ったとされます（参照*6）。

具体例としてCodeRabbitはBaseten TrainingでLightningを2段階に事後訓練しました。1段階目はNVIDIA NeMo AutoModelを使ったマネージドH100上での教師ありファインチューニングで、凍結された1,000タスク評価での完全一致ルート合意が75.8%から80.4%に上昇しています。

2段階目はNVIDIA NeMo RLを介した検証可能な報酬による強化学習で、Cohenのカッパは0.461から0.544に伸び、ルート精度も維持されました（参照*3）。

素の状態で汎用チャットに使うより、SFTや強化学習を通して自社タスクに寄せる前提のモデルと読むのが自然です。「モデルを入れれば終わり」ではなく、事後訓練まで見越した計画を最初から持っておく必要があります。

領域別ユースケース

Lightningは、サイバーセキュリティ、法務、コードレビューなどの専門領域での活用が示されています。

NVIDIAは、CrowdStrike、Harvey、CodeRabbitといった企業が、サイバーセキュリティ、法務、コードレビューといった専門領域向けにカスタム版のLightningを使っていると説明しています（参照*5）。

ユースケースとしては、メールやカレンダー、予約を扱う個人エージェント、データ抽出やポリシー確認、リスク監視、レポート要約を担う金融サービス、アラート補強や事案分類、ログ照会、報告書作成を担うサイバーセキュリティ、ネットワークアラームの振り分けや設定最適化、請求問い合わせに応える通信、カタログ拡充や在庫例外の解決、商品発見の補助を担う小売が挙げられています（参照*3）。

またLightningはOpenClawやHermes Agentなど、代表的なエージェントハーネスを念頭に学習されており、ツール呼び出しの精度を上げ、繰り返し作業の遅延を下げるとNVIDIAは説明しています（参照*4）。

多くのツール呼び出しが定型化されている業務ほど、Lightningの得意分野に重なります。逆に言えば、自社の業務フローの中でどれだけ定型的な反復処理があるかを棚卸しすることが、導入検討の最初のステップです。

導入前に押さえたい注意点

Lightningは、単体で選ぶモデルではなく、役割分担の中で位置づけるモデルです。この前提を外すと、導入後に「思ったより賢くない」という的外れな評価につながります。

Lightningは唯一のモデルとして選ぶような存在ではありません。難しい推論や込み入ったソフトウェアエンジニアリング、長文コンテキストの分析を任せれば、より大きなモデルに負けます。

一方で、午後のうちに1万回のツール呼び出しを片付けるような仕事なら、代替モデルより早く終わり、コストも低く、既に持っている可能性のあるハードで動きます（参照*9）。

本番運用では、ルーティングそのもののオーバーヘッドがコスト削減分を食い潰さないかという問いが残されており、この点についてはまだ公表数値が出ていません（参照*9）。

またBF16版はフル精度の参照ウェイトであり、直接の本番推論よりも、カスタマイズと事後訓練を主目的とする位置づけになっています（参照*1）。

自社タスクの難易度分布、事後訓練のための評価データと学習コスト、ルータを含めた総遅延、精度と速度の妥協点を揃えて検討すると、判断がぶれにくくなります。生成AI導入で最初に詰まるのは、モデル選定よりも「何をさせるか」を業務レベルで定義するところです。Lightningについても同じ問いが先に来ます。

おわりに

Nemotron 3.5 Lightningは、ローカルやエッジでも動く軽量高速なMoEを軸に、常時稼働するエージェントの反復作業を安く速く回すための駒として設計されたモデルです。基本仕様、ハイブリッドMoEやNVFP4量子化、投機的デコードといった高速化、そしてSwitchyardによるルーティングまでを合わせて見ると、単体モデルの優劣を問う話ではなく、モデル群を組み合わせるシステム設計の話であることがはっきりします。私がAI導入支援で繰り返し感じるのも、「どのモデルを使うか」より「どう組み合わせて業務に定着させるか」のほうが、最終的な成果を左右するという点です。

計画は大型モデル、実行はLightningという役割分担を軸に、自社のエージェントで反復比率の高い工程を切り出し、事後訓練で自社タスクへ寄せる。この流れを小さく試すところから始めると、Lightningが持つ価値を自分の環境で確かめやすくなります。まず業務を分解し、反復タスクの割合を可視化することが先決です。そこから始めれば、導入判断の根拠も、検証の設計も、ずっと具体的になります。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、95万部（2026年6月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））