何が発表されたか
Nvidiaが公開したのは2つです。ひとつは大量・専門特化のエージェント処理向けに設計された300億パラメータのオープンなMixture-of-Expertsモデル「Nemotron 3.5 Lightning」。同クラスの比較対象に対して最大4倍の出力速度、Qwen3.6-35Bと同等精度で約30%速いエージェントタスク完了を主張しています。もうひとつがオープンソースのルーティングライブラリ「NeMo Switchyard」で、ワークフローの各ステップを最も適したモデルに振り分けます。
Nvidiaの生成AI担当バイスプレジデントであるKari Briski氏は「ワークフローの各ステップに最適なモデルを当てる、それが『モデルのシステム』の力だ」と述べています。
単体スコアではなく「組み合わせ」で勝つという主張
重要なのは、Lightning単体が最強を主張していない点です。9つの評価からなるArtificial Analysis Intelligence IndexでLightningのスコアは24。gpt-oss-120bと同点で、いずれも30のNemotron 3 Super、Gemma 4 31B、Claude 4.5 Haiku、Mistral Medium 3.5には届いていません。一方、実タスク型のPinchBench(コーディング・リサーチ・ファイル操作)ではQwen3.6-35Bと同等精度を約30%速く、Gemma 4 26Bは同程度の完了時間で精度が上回るとされます。
つまりLightningは、ルーティング構成の「速く安い側」に置かれる駒として設計されています(ルーターなしでも単体で動作します)。Nvidiaの論点は、モデル層とルーティング層の両方にオープンソースを効かせて初めてエージェントAIのコストが動く、というものです。競争軸が「最良のモデル」から「最良のシステム」へ移りつつあることの、ベンダー側からの宣言と読めます。
ルーティング自体は新しくない。新しいのは「動的」であること
モデルルーティングは既存カテゴリです。OpenRouter、LiteLLM、独立系のルーティングスタートアップがすでにプロバイダ横断でトラフィックを振り分けています。名指しの競合はOpenRouterのAutoモードを支えるNot Diamondと、UC BerkeleyとLMSYS発のオープンソースフレームワークRouteLLMですが、いずれも自前のモデルは持ちません。Switchyardは既存ルーターを置き換えるのではなく、それらに差し込む形を取ります。
差別化点は、エージェントが処理を進める過程で「最適なモデルが変わる」ことに対処する設計です。ツールが結果を返した、エラーが出た、あるいはそのステップが想定より単純だった——という状態変化に応じて振り先を変えます。ランダムルーター、エージェント状態ルート、分類器ルートといった複数戦略を持ち、さらにモデルの冗長性(そのタスクでどれだけトークンを吐きやすいか)を予測し、呼び出す前に安い側へ寄せることもできます。
9社の実測値が示す削減幅
Nvidiaは9社のテスト結果を公開しました。LangChainは145件のマルチターンDeep Agentsタスクで、フロンティアモデルへの振り分けをわずか7%に絞り、精度6%の低下と引き換えに74%のコスト削減。Rampは自社のRamp SWE-Benchでフロンティアモデル同等の性能を保ちつつコスト58%・実行時間33%減。CognitionはDevin Desktopに段階的ルーターを社内導入し、FrontierCode Mainでほぼフロンティア級の性能を維持しながら平均コストを28%削減しています。
パートナーは、Switchyardを直接呼ぶエージェントフレームワーク(Cognition、LangChain、Nous Research)と、自社製品に組み込んだLLMゲートウェイ(Kong、LiteLLM、OpenRouter)に分かれます。KongはKong AI Gateway内にネイティブ実装しました。Briski氏は「私たちはエコシステム好きで、既に使っているツールのままアルゴリズムを拾えるようにした」と説明しています。
地味だが効く数字:$85のルーター
見落とされがちなのがポストトレーニング側です。NeMo Autoの標準レシピを1エポック回すだけで、CodeRabbitの実働ルーターエージェントが85ドル・約2時間で構築できたとNvidiaは述べています。CrowdStrike(悪性コンテンツの再現率)、Harvey・Trajectory(法務タスク完了率)、Lila Sciences(エネルギーシミュレーション)など4社の早期アクセス事例でも、ベースライン比の改善値が示されました。
背景には、春以降Alibaba、Moonshot、Zhipu、DeepSeekが競争力あるオープンモデルを投入し、Metaも同じ300億パラメータのオープンエージェントモデルMuse Glimmerを出したという密集状況があります。中国勢との直接比較を問われたBriski氏はヘッドトゥヘッドのベンチマークを示さず、オープン性とカスタマイズ性を挙げるにとどめました。
💼 事業会社視点:これは自社にどう効くか
日本企業にとっての読みどころは「モデル選定の意思決定を、いつまで固定で持つか」です。多くの社内AI導入は稟議の都合上「フロンティアモデル1本を全社標準に」という静的な決め方をしていますが、LangChainが示した数字——フロンティアへの振り分けを7%に絞って74%削減、精度低下は6%——は、その前提が経済的に不利になったことを意味します。
特に効くのは3層です。第一にSaaS。原価の相当部分がLLM API費用になっている国内SaaSは、粗利率がモデル選定に直結します。Rampの58%削減・実行時間33%減は、そのまま売上総利益率と応答速度の改善余地と読めます。第二に受託開発・SIer。Cognitionが平均コスト28%減を出したように、「どのモデルを使うか」ではなく「振り分け設計」を提案商材にできます。CodeRabbitのルーターが85ドル・約2時間で作れたという数字は、PoC見積もりの桁を変えます。第三にEC。商品説明生成やCS一次対応のように大量・定型の処理は、Lightning側に寄せるだけで単価が動きます。
経営判断としては、(1) 自社ワークフローのステップ別にコストと精度要件を棚卸しし、フロンティア必須の比率を実測する、(2) すでにLiteLLMやOpenRouter、Kong AI Gatewayを使っているならSwitchyardは差し込みで試せるため、既存ゲートウェイ経由でA/Bを回す、(3) 精度6%の低下を許容できる業務と許容できない業務(与信・法務・医療など)を先に線引きする——の3点です。ベンダーロックインの議論より、まず「振り分けたら何%落ちるか」を自社データで測ることが先決です。