NVIDIA Nemotron 3.5 Lightningとは？AIエージェントの実行レイヤーに特化した30Bモデル

NVIDIA Nemotron 3.5 Lightningは、万能なチャットボットというより、**自律型AIエージェントの「実行役」**として設計されたモデルだ。2026年8月11日に公開された、総パラメータ数30B（300億）のオープンなMixture-of-Experts（MoE）モデルで、1回の推論ステップで使うのは約3B（30億）パラメータ。大規模モデルの代替というより、長時間稼働するエージェントが大量に繰り返す細かな処理を、速く、効率よくこなすことを狙っている。

この位置づけを理解するには、AIエージェントの仕事を「計画」と「実行」に分けて考えると分かりやすい。目標を読み取り、複雑な手順を組み立てる場面では高性能な推論モデルが必要になる。一方、その後には、APIや外部ツールの呼び出し、文書からの項目抽出、ルール確認、データ変換、決められた形式への整形といった、比較的定型的な処理が何度も続く。Lightningは、この後半の実行レイヤーを担うモデルだ。

Nemotron 3.5 Lightningの特徴

NVIDIAはNemotronを、重みだけでなく、学習データや学習レシピも公開するオープンモデル群として位置づけている。開発者は、導入前にモデルを評価し、用途に合わせてカスタマイズや追加学習を行える。

LightningにはBF16版とNVFP4版が用意されている。モデルの構成は、Mamba系の状態空間モデル、Attention、ルーティングされた専門家（Experts）を組み合わせたハイブリッド設計と説明されている。MoEでは入力ごとにネットワーク全体を使うのではなく、一部の専門家だけを選択して処理するため、30Bという大きなパラメータ容量を持ちながら、各トークンの生成で動作する部分を抑えられる。

「30B」と「3B active」は、異なる数字を指す。

• 総パラメータ数30B：モデル全体が持つ学習済みパラメータの数
• アクティブパラメータ約3B：1トークンを生成する際に、おおよそ実際に計算へ使われる部分

この仕組みにより、生成トークンあたりの計算量を減らせる可能性がある。ただし、30B分の重みを保存・管理する必要までなくなるわけではない。アクティブパラメータが少ないことは、モデル全体の容量ではなく、主に推論時の計算効率に関わる特徴だ。

なぜ「推論モデル」ではなく「実行モデル」なのか

自律型エージェントは、1つの依頼に対して何度もモデルを呼び出すことがある。初期計画の後にも、次に使うツールの選択、結果の読み取り、形式の検証、例外処理、最終出力の整形などが発生するためだ。

これらすべてを最先端の大型モデルで処理すると、応答時間と運用費用が膨らみやすい。そこでLightningを、頻度が高く、ある程度パターン化できる処理に割り当てる。判断が難しい場面や不確実性が高いケースだけを、より能力の高いモデルへ戻すという考え方だ。

典型的な2層構成は、次のようになる。

1. 大型の推論モデルがユーザーの目的を解釈し、作業計画を作る。
2. Lightningがツール、文書、構造化データに対する定型処理を実行する。
3. 例外や曖昧な判断が発生した場合だけ、大型モデルを再度呼び出す。

NVIDIAは、Nemotron 3 Ultraを総パラメータ数550B、アクティブパラメータ55BのMoEモデルとして、エージェントシステムの高度な推論やオーケストレーション向けに位置づけている。Lightningとの役割分担はここでも明確だ。

NeMo Switchyardが担う「モデルの振り分け」

この構成を実際に動かすには、各処理をどのモデルへ送るかを決める仕組みが必要になる。すべてのリクエストを同じモデルへ送るのではなく、タスクの難易度や目的に応じて振り分けるためだ。

NVIDIAのNeMo Switchyardは、特定のプロバイダーに依存しないルーティングSDK。リクエストを表現し、利用可能なモデルのターゲットを定義し、選択したプロバイダーやモデルIDへの呼び出しを管理する。

そのため、Lightningを日常的な処理用の低コスト層に置き、難しい判断だけを大型モデルへ送るモデル階層を構築しやすくなる。Lightningの価値は、単体の会話モデルとしてよりも、複数モデルを組み合わせたエージェント基盤の一部として発揮されると考えられる。

最大100万トークンのコンテキストと展開先

Lightningは最大100万トークンのコンテキスト容量をうたっている。長期間にわたる会話履歴、大量の文書、エージェントが保持する大きなタスク状態を扱う用途では、重要な仕様になり得る。ただし、実際に利用できるコンテキスト長や性能は、サービング環境や設定によって変わる。

NVFP4チェックポイントは推論向けに設計され、対応するNVIDIA GPU世代向けの専用カーネルを利用する。NVIDIAは、ローカル環境、ワークステーション、データセンター、クラウドでの展開を案内しており、Hugging Faceやホスティングサービスからも利用できる。

AWSでは、Nemotron 3.5 LightningがAmazon SageMaker JumpStartで利用可能。SageMakerのコンソール、またはPython SDKから展開できる。 また、NVIDIA NIMでは、コンテナ化された別の展開手段が提供されているが、Ubuntu、CUDA、GPUドライバー、Dockerなどの要件を満たす必要がある。

もっとも、「単一GPUで動く」という説明は、環境を問わず成立するものではない。量子化済みチェックポイントによってサービングが現実的になる場合でも、必要なGPUメモリは、GPUの種類、コンテキスト長、量子化方式、バッチサイズ、同時実行数、サービングソフトウェアによって変わる。ノートPCやデスクトップでの動作可否は、使用するモデルカードと展開レシピで確認すべきだ。

「最大4倍高速」「30％短縮」はどう読むべきか

NVIDIAとAWSは、対象となるエージェントワークロードについて、最大4倍のスループットと、タスク完了時間の最大30％短縮を示している。 ただし、これはモデルの知能全般を測る普遍的な指標でも、あらゆる本番環境で保証される数字でもない。

実際の結果は、次の条件で大きく変わる。

• 比較対象にしたモデル
• GPUの世代とメモリ構成
• バッチサイズと同時実行数
• プロンプトおよびコンテキストの長さ
• ツール呼び出しやネットワークの遅延
• デコード設定
• 許容できる誤りの割合

導入を検討する場合は、トークン生成速度だけでなく、実際のエージェントで重要な指標を測る必要がある。たとえば、情報抽出の正確さ、ツール呼び出しの信頼性、構造化出力への準拠率、リトライを含めたエンドツーエンドの完了時間などだ。

料金は安価でも、プロバイダーごとに異なる

ホスティングサービスを使う場合、Lightningは大量推論向けの料金面でも注目される。DeepInfraは、入力100万トークンあたり0.05ドル、出力100万トークンあたり0.20ドルと案内している。サーバーレスの従量課金で、GPUインフラを自前で管理する必要はない。

ただし、この金額はモデルそのものに固定された価格ではない。プロバイダー、精度、キャッシュ、ルートによって料金は変わり、他のサービスでは異なる価格が掲載されている。

大型モデルとの比較では、単価だけで判断するのは危険だ。リトライ、ツール呼び出し、ルーティング処理、そして最終的に大型モデルへ送られるリクエストまで含めて、ワークフロー全体の費用を計算する必要がある。

結論：Lightningは「大型モデルの代役」ではなく「現場担当」

Nemotron 3.5 Lightningは、AIエージェント向けの高速でカスタマイズしやすいワーカーモデルと見るのが適切だ。大量の類似リクエストが発生し、タスクを専門化・制約化できるアプリケーションほど、その設計上のメリットを活かしやすい。

一方で、複雑な計画、不確実な判断、失敗時のコストが大きい処理まで、Lightningだけで置き換えられるとは限らない。そのような場面では、Nemotron 3 Ultraなどの大型モデルや、別の最先端推論モデルが必要になる可能性がある。

要するに、Lightningが最も生きるのは、複数モデルをルーティングするエージェント構成の低遅延な実行層だ。30Bの総容量と約3Bのアクティブパラメータ、公開されたモデル資産、NVFP4による推論向け選択肢、ローカルからクラウドまでの展開経路は、日常的なエージェント処理を安く速くするために設計されている。NVIDIAが示す性能向上は有望だが、本番導入の判断には、自社のワークフローを使った検証が欠かせない。