※本記事は、NVIDIA のセッション「Scaling Intelligence: NVIDIA NeMo and the Future of National AI」（AI Impact Summit 2026）の内容を基に作成されています。本セッションでは、NVIDIA のエンジニアリング・ディレクターである Bernard Wein 氏（NeMo フレームワークの開発を統括）が登壇し、大規模言語モデルの開発を、事前学習からファインチューニング、RL による事後学習までの各段階にわたって支える NeMo フレームワークについて解説しています。同フレームワークは NVIDIA のオープン AI 戦略の一環として、Hopper ノードから Blackwell ラックまでスケールしながら、ソブリン AI モデルの開発を比類のない効率で加速するものです。本記事では、セッションの内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。動画は https://www.youtube.com/watch?v=HXw4K-YkT3k でご覧いただけます。
1. はじめに：講演の射程とスケーリングの変遷
1.1 講演者紹介と本講演のテーマ
Bernard： おはようございます。少し遅れてしまって申し訳ありません。スライドを用意させてください。ノートパソコンを使ってもよろしいでしょうか。それでは、まず自己紹介をさせてください。私は Bernard Wein と申しまして、NVIDIA でエンジニアリング・ディレクターを務めております。私の担当は NeMo フレームワークの開発を統括することです。本日は、大規模言語モデル（LLM）の訓練をスケールさせていく取り組みについてお話ししたいと思っています。具体的には、モデルを事前学習（pre-training）から微調整（fine-tuning）、さらに事後学習（post-training）へと進めていくプロセスと、それを後押しするために NVIDIA が提供しているライブラリやオープンソース AI についてご紹介していきます。
Bernard： 本日の流れとしては、モデルがどのように作られ、賢くなっていくのか、その全体の道のりを追いながら、各段階で NVIDIA がどのような道具立てを用意しているのかをお見せしていきます。とりわけ後半では、モデルに「考える」能力を持たせる事後学習や推論時のスケーリングに時間を割いてお話ししたいと思っています。その前段として、NVIDIA がオープンソース AI に対してどのような姿勢で臨んでいるのかについても触れていくつもりです。本日の講演を通じて、皆さんが自前でモデルを訓練し、改良し、最終的に展開していくために必要な要素が一通りそろっていることを感じ取っていただければと考えています。
1.2 事前学習スケーリングから事後学習・テスト時スケーリングへ
Bernard： それでは始めさせてください。おそらく皆さんも一度はご覧になったことのあるスライドだと思いますが、本講演の文脈を整える上でちょうどよい題材です。LLM の訓練が始まった当初は、その多くが事前学習モデルをスケールさせることに焦点が当てられていました。そこで見えてきたのがスケーリング則であり、モデルを大きくすればするほど、それだけ知的になっていくという関係でした。
Bernard： ところが、この理屈をそのまま突き詰めていくとどうなるでしょうか。もし自分のモデルを極限まで賢くしたいのであれば、モデルをどんどん、どんどん大きくし続けなければならないということになります。しかし、これは現実的とは言えません。というのも、ある時点で必ずリソースが枯渇してしまいますし、こうしたモデルをエッジデバイス上に展開したいと思っても、超巨大なモデルはそうした環境には到底収まりきらないからです。
Bernard： そこで登場したのが事後学習によるスケーリングです。これは、すでに事前学習を終えた大きなモデルを取り出して、特定のドメインに適応させていく手法です。場合によっては、そのモデルを縮小して、限られた環境にも収まるようにすることさえできます。ただし、この段階のモデルはまだ、推論や思考を伴わないかたちで訓練されているという側面があります。皆さんの多くは ChatGPT のような AI アプリケーションをご存じだと思いますが、いまやそうしたモデルは実際に「考える」ことができるようになっています。つまり、思考のために時間をかけるのです。
Bernard： 質問やプロンプトに対して「もっとよく考えてほしい」と頼めば、モデルはより知的な答えを返してくれます。では、どうすればモデルに「考える」能力を持たせられるのでしょうか。まさにそこで起きているのが、事後学習からテスト時スケーリング、すなわち「長考（long thinking）」への移行です。本日は、この後半部分にしっかりと時間を割いてお話ししていきたいと思います。
2. NVIDIA のオープンソース AI 戦略と Nemotron
2.1 NVIDIA のオープンソース AI に対するスタンス
Bernard： 後半の本題に入る前に、少しだけ時間をいただいて、オープンソース AI と、それに対する NVIDIA の姿勢についてお話しさせてください。オープンソースのソフトウェア自体は、Linux の時代から数えても、もうずいぶん長い歴史があります。しかし AI については、そう長くオープンソースであったわけではありません。たとえば、私たちが日常的に使っているモデルやアプリケーション、ChatGPT などはオープンソースではありません。ところがここ最近になって、AI はだんだんとオープンソース化が進んできました。いま起きているのは、より多くのモデルが開発され、それが公開のかたちで世に出されていくという、ある種の爆発的な広がりです。
Bernard： ただ、モデルに関して「オープンソース」と言っても、その定義にはいくつかの幅があります。たとえば、重み（weights）にアクセスできるモデルがあります。重みをダウンロードし、モデルのアーキテクチャと重みを取り出して、それを動かすことができる、というものです。しかし、もしそのモデルをファインチューニングしたい、あるいは再訓練したい、そのモデルがどんなレシピで訓練されたのかを知りたいとなった場合、そうした情報はモデルの重みと一緒に必ずしも提供されているとは限りません。
Bernard： ですから、NVIDIA のオープンソース AI に対する姿勢という文脈で私が「オープンソース」と言うとき、それはモデルの訓練に必要なものをすべて提供したい、という意味です。つまり、モデルと重みだけでなく、データセットも、レシピも、そしてそのモデルの訓練に用いられたライブラリも提供する、ということです。何か漏れがあるかもしれませんが、私たちは NVIDIA から世に出てくるモデルを学び、再現するために必要なものを、できる限りすべて提供しようとしています。
Bernard： NVIDIA がソフトウェアをオープンソース化している領域はいくつもあります。ヘルス AI から物理（physics）、エージェント型 AI に至るまで多岐にわたります。本日はそのほとんどの時間を Nemotron についてお話しすることに充てますが、ほかにも物理 AI 向けの Cosmos、ロボティクス向けの Groot、そして自動運転（AV）といった領域があります。CES では今年1月に Jensen が Alpha Mayo についてかなりの時間を割いて語っていました。そして GitHub のリポジトリという観点で見ると、NVIDIA はリポジトリの総数で群を抜いてリードしている状況です。改めて整理しますと、私たちが提供しているのはデータ、モデル、ライブラリ、そしてそれらのライブラリを使ってモデルを訓練するレシピにあたる訓練スクリプト、さらにはモデルを組み合わせてソリューションへと仕立て上げるためのブループリント、これら一式なのです。
2.2 Nemotron モデルファミリー：効率・知性・オープン性
Bernard： さて、Nemotron です。私たちが Nemotron で取ろうとしているのは、効率的であること、知的であること、そしてオープンであること、この三つの絶妙なバランスです。これを裏づけるリーダーボードのチャートは後ほどお見せします。たとえば、ごく最近リリースした Nemotron 3 Nano というモデルがあります。Super と Ultra も近々登場する予定です。この Nano 3 は、その重量級、つまり 300 億パラメータ（30B）のモデルというクラスにあります。同じクラスでもっとも近い競合となるのは GPT-NeoX-20B や Qwen3 30B あたりになるでしょう。ご覧いただくと分かるとおり、NVIDIA の Nemotron 3 は、これらと同等か、それ以上に知的です。
Bernard： そして NVIDIA が本当に力を注いでいるのが効率の部分です。ここで効率と言うとき、私たちが問題にしているのはトークン、すなわち最小の計算量でモデルからどれだけ多くのトークンを引き出せるか、ということです。言い換えれば、ある一定の計算量を与えたときに、どのモデルがもっとも多くのトークンを出力してくれるか、ということになります。ここでご覧いただけるように、Nemotron 3 Nano は毎秒およそ350トークン超を出力しており、これは他のモデルと比べてはるかに高い水準です。これが何を意味するかというと、一定の時間内に、より少ないコストで、このモデルにより多くのプロンプトを投げかけられるということなのです。
Bernard： 先ほど申し上げたとおり、Nano 3 はすでに利用可能です。Super と Ultra は近々登場します。Super はごく間もなく、Ultra はそれに続いてすぐに出てくる予定です。これらは MoE（mixture of experts、混合エキスパート）アーキテクチャを採用しています。総パラメータ数は 30B、100B、500B というようにずっと大きくなっていきますが、私たちが効率を実現している仕組みは、推論時にその総パラメータのうちのごく一部だけが実際に活性化される、という点にあります。たとえば「A3B」という表記は、30B のうち 30 億パラメータ（3B）だけが活性化されているという意味です。これは MoE アーキテクチャを活用したものです。100B のモデルでも同様で、活性化されるのは 10B だけ、500B なら 50B だけ、という具合です。つまり、推論時に活性化されているのは、本質的にパラメータのおよそ10%にすぎないのです。
3. エージェント型 AI とその仕組み
3.1 エージェント型 AI の概念と Nemotron の対応
Bernard： ここからはエージェント型 AI（agentic AI）へと話を移し、なぜエージェント型 AI に事後学習や推論が必要になるのかを見ていきたいと思います。エージェント型 AI とは、本質的には、AI エージェントが人に代わって一連のタスクや目標を達成するために行動できる、というモデルのことです。この例では、ユーザーが音声を介してエージェントとやり取りをしています。つまり、私がこのエージェントに話しかけると、そのエージェントが特定のタスクや判断を、背後にいるさまざまな LLM へと振り分けていくわけです。
Bernard： 具体的には、言語モデル、視覚言語モデル、推論モデルといったものに振り分け、データにアクセスし、仕事を成し遂げ、そして最後にそれを音声へと、いえ失礼、テキストから音声（text-to-speech）へと戻していきます。Nemotron には、推論、視覚、情報検索、コンテンツの安全性、そして音声と、用途ごとに異なるモデルがそろっています。ここで私がお伝えしたいのは、皆さんがご自身のエージェント型 AI に使えるよう、Nemotron には幅広いモデルのポートフォリオが用意されているということです。ですから、こうしたモデルを数多く取り出して、エージェント型 AI のアーキテクチャの中に組み込んでいくことができるのです。
Bernard： データについてもう少し補足しますと、ここに挙げているものはいずれも、GitHub を通じてオープンソースで公開されている、それぞれ異なるデータセットです。先へ進めたいので次に移りますが、これらはブループリントの例です。一つは、ユーザーがエージェントとやり取りをしてレポートを生成するというものです。「〜についてレポートを作って」といった具合ですね。これはおそらく、すでに皆さんになじみのある機能でしょう。最近の AI チャットアプリケーションで「ディープ・リサーチ（deep research）」を使えば、自分で調べて取りまとめると何時間もかかるような主題について、数分で完成したレポートを返してくれます。そして、これをご自身で実装するためのブループリントが用意されているわけです。同様に、何時間にもおよぶ動画を検索して要約する、というのも別のエージェント型 AI のユースケースであり、そのためのブループリントもあります。
3.2 AI エージェントの動作・協調・専門特化
Bernard： それでは、AI エージェントそのものについてもう少し深く掘り下げてみましょう。出発点はプロンプトです。つまり、私は自分のエージェントに何をしてほしいのか、ということです。たとえば「一定の予算の範囲内で、数日間の旅程を組んでほしい」といった具合です。するとエージェントは、私のプロンプトを知覚し（perception）、それを理解し、筋道を立てて推論し（reasoning）、そして行動の方針を取る（action）、というサイクルを回していきます。その際、エージェントはツールを使うことができます。ウェブを検索するための検索ツール、物事を計算するための電卓、さらには Python インタプリタを通じてコードを実行することさえできます。
Bernard： 本質的には、プロトコルを介して利用可能にできるツールであれば、何であっても使えます。たとえば MCP のようなプロトコルがあり、これを使えばあらゆる種類のウェブサービスをエージェントからアクセスできるようにできます。エージェントはまた、皆さんのコンピュータを直接操作することさえできます。アクセス権を与えれば、ローカルのファイルシステムにアクセスし、皆さんのファイルや情報を検索して、それを計画の文脈の一部として取り込むことができるのです。
Bernard： メモリもエージェント型 AI における重要な側面です。というのも、多くのエージェントが協調しながら同時に動作することがあり得るからです。よりブルートフォース（力任せ）なやり方では、エージェントがすべてのデータをネットワーク越しに次から次へと受け渡していきます。これは非常にコストがかかり、しかも遅くなります。しかし、たとえばすべてのエージェントを Grace Blackwell のラックスケール構成のような環境に展開できれば、すべての GPU がメモリを共有できるようになります。つまり、一つの GPU ラックの中にエージェントのエコシステム全体を動かし、その文脈を高速な NVLink を介して共有させることができるのです。
Bernard： エージェントは他のエージェントとも対話できます。そして専門特化したエージェントを用意することも可能です。たとえば、旅行予約サービスのエージェントが、レンタカーの手配がとても得意なエージェントと会話する、といった具合です。ごく単純な例を挙げていますが、今後は専門特化したエージェントが数多く登場してくると想像できるでしょう。その専門特化エージェントに関連して言えば、これまで私たちは大きなモデルの話をしてきましたが、ここでは小さなモデルの話になります。より専門特化した小さなモデルを作ることができ、その小さなモデルを使ってこうした専門特化エージェントを動かすことができるのです。
Bernard： こうした小さなモデルは、はるかにドメイン特化的にできますし、適応もしやすく、そして非常にコスト効率に優れています。データや知的財産（IP）の統制という観点も重要です。これは、ご自身が信頼している、あるいはご自身で運用しているデータセンターか、もしくは同じく信頼できるクラウドサービスプロバイダの中でエージェントを動かす、という前提に立った話です。これは、本カンファレンスで議論されてきたソブリン AI（sovereign AI）というテーマにも通じる部分です。ここに挙げているのは、さまざまな専門特化エージェントの例です。
4. 事後学習（Post-training）の進化とロングホライズン
4.1 事後学習の意義と進化の流れ
Bernard： それでは、事後学習（post-training）についてもう少し踏み込んでいきましょう。事後学習とは、本質的には、すでに存在しているモデル、つまりご自身でゼロから事前学習したモデルか、あるいはオープンソースからダウンロードしてきたモデルを取り出して、それに追加の能力を与え、整合（alignment）させていく作業です。これによって、モデルをより役に立つもの（helpful）にし、より害の少ないもの（less harmful）にすることができます。
Bernard： 事後学習の最近の進化の流れを少し振り返ってみましょう。最初の段階では、本質的には、モデルを取り出して次のトークンを予測できるようにするだけのものでした。これは単なるテキスト補完です。その後、ChatGPT の登場とともに、皆さんもご覧になったように、これが一つの大きな転機となり、モデルと会話ができるようになりました。これは本質的には、そのモデルを取り出して、複数ターンにわたる会話の仕方を教え込む、ということでした。
Bernard： 次の波は、「複数ターンの会話はできるようになった、では今度は応答する前にきちんと考えてほしい」というものでした。こうして、思考（thinking）と推論（reasoning）が言語モデルに加えられていったのです。そして、エージェント型 AI とともに私たちが今いる地点では、その推論が複数のステップへとつながっていくようになりました。つまり、複数の行動方針が取り得るようになり、エージェントは先ほど議論したようにツールを使えるようになったのです。
4.2 ロングホライズンへの方向性と課題
Bernard： では、私たちはこの先どこへ向かっていくのでしょうか。私見を述べるなら、今後1年ほどのうちに、私たちはより長い「ホライズン（horizon、見通せる時間幅）」へとたどり着きたいと考えています。それがどういう意味なのか、次のスライドに進んでもう少しお話ししましょう。実を言うと、このスライドは少し古くなっています。GPT は今、2月初旬の時点で GPT 5.2 まで来ていますし、たしか Claude Sonnet 4.6 が昨日リリースされたばかりだったと思います。ええ、4.6 ですね。そう、それくらい AI の分野は速く動いているのです。
Bernard： とはいえ、このスライドが伝えようとしている要点はこういうことです。ここで言う「コンテキスト」、いえ「ホライズン」ですが、これは30分のホライズンを示しています。1〜2年ほど前のモデルは、人間がやれば30分かかるようなタスクを与えれば、それをこなすことができました。そして今、私たちは、人間がやれば数時間かかるようなタスクを、50%の確率で正しくこなせる、という地点にまで来ています。それはそれで結構なことです。しかし、私たちがロングホライズンと言うとき、念頭に置いているのは、皆さんや私がやれば数日、数週間、あるいは数か月かかるようなタスクです。長くなればなるほど、それがロングホライズンということになります。
Bernard： なぜロングホライズンが難しいのかと言いますと、たとえば100ステップから成るタスクを考えてみてください。仮にどの一つのステップを取っても、モデルがそのステップで成功する確率が99%だったとします。そうすると、100ステップが連なったとき、99%を100回掛け合わせていくわけですから、計算は今していませんが、おそらく最終的には20〜30%くらいになってしまいます。つまり、100ステップを終えた時点で、全体が成功している確率はおよそ20%程度しかない、ということです。これはかなり低い成功率です。
Bernard： ですから私たちは、どの一つのステップを取っても、9がいくつも並ぶような、ほぼ確実に近い成功率でモデルが成功できるところまで持っていく必要があります。さらにモデルは、自分があるステップを選んだ結果、道を外れてしまったことを検知できるだけの賢さも備え、軌道を修正してもう一度やり直せるようでなければなりません。ロングホライズンという、私たちがたどり着きたい地平には、まだまだやるべき仕事が残っているのです。
5. 推論訓練：報酬モデルと GRPO
5.1 推論の実際と RL による探索学習
Bernard： それでは、事後学習における推論で何が起きているのか、もう少し深く掘り下げてみましょう。ここにお見せしているのは、ある思考トレース（thinking trace）です。「この数式を解いてください」というプロンプトに対して、右側のこのボックスの中でモデルが考えを巡らせている様子が映し出されています。そして最後に最終的な答えを返します。ここで目指しているのは、その答えが高品質であると同時に、有用（helpful）で、安全（safe）で、敬意のあるもの（respectful）であることです。
Bernard： もともと事後学習は、教師あり学習、すなわちモデルを教師ありでファインチューニング（SFT）するというやり方で行われていました。これは、ある特定のプロンプトに対して「これが答えです」という形式のデータセットを用いるものです。別のプロンプトについても「これが答えです」と与えていく。つまり、プロンプトと正しい答え・誤った答えの例を数多く示すことで、あるプロンプトに対して何が正しい答えなのかを、モデルに半ば強制的に覚え込ませるわけです。しかし、これは本当の意味で「考えている」わけではありません。単なる模倣にすぎないのです。
Bernard： これに対して RL（強化学習）では、モデルに実際にいくつもの異なる推論の生成、いくつもの異なるステップを試させ、その中から他よりもより正しい生成を選んだときにモデルへ報酬を与える、という形で訓練します。この単純な例で言えば、ロールアウト（rollout）とは、本質的にはモデルがその問いに応答する機会のことです。一つ目の応答はより正しく見えるので、報酬として1を与えました。100%、よくやった、というわけです。二つ目の応答はまったく役に立っていません。ですから報酬は0としました。そしてこちらの応答はチケットを作成してしまいました。これは非常にまずい応答です。私はこのモデルにチケットを作ってくれとは頼んでいません。ただ情報がほしいと尋ねただけなのに、です。ですから報酬は、こんな応答はまったく望んでいない、という意味で、完全に否定する評価を与えます。これが、探索を通じた学習（learning through exploration）というものです。
5.2 報酬モデルと GRPO アルゴリズム
Bernard： では、報酬を実際にどうやって決めるのでしょうか。そのために報酬モデル（reward model）を作る必要があります。これは報酬モデルを訓練する単純な例ですが、プロンプトと応答候補が与えられると、報酬モデルがそれに対して特定の報酬を出力します。この例でお見せしているのは、報酬が単一の数値ではなく、ベクトルになっているケースです。すなわち、この応答がどれだけ有用か（helpful）、正確か（correct）、一貫しているか（coherent）、複雑か（complex）、冗長か（verbose）といった複数の観点で評価しているわけです。
Bernard： 今日の報酬モデルには、大きく分けて二つの主要なカテゴリがあります。一つ目は検証可能報酬（verifiable rewards）です。これはかなり直感的なもので、ルールベースの報酬であり、それが真か偽かを完全に検証できます。たとえば数学であれば、その応答が正しいかどうかを検証できます。コードであれば、そのコードを実行し、ユニットテストを走らせて、コードが正しいかどうかを確かめられます。指示追従であれば、指示にきちんと従ったかどうかを検証できます。これらは非常に検証しやすく、どれだけ検証可能かに基づいて報酬を割り当てるのがとても簡単です。もう一つは、モデルベースの報酬（model-based rewards）というクラスで、こちらは検証しにくいものです。より主観的なものであり、ここでは、たとえば LLM に判定役を担わせる、いわゆる「LLM as a judge（判定役としての LLM）」を使うことができます。LLM を使って、ある応答がどれだけ正しかったかを実際に判定させるわけです。
Bernard： さて、今日の RL ではさまざまなアルゴリズムが使われていますが、その中でも今もっとも一般的なものの一つが GRPO と呼ばれるアルゴリズムです。これは本質的にはグループベースのポリシーアルゴリズムです。ここで言うポリシー（policy）とは、私たちが訓練しようとしているモデルのことであり、このモデルに思考する能力を与えようとしているわけです。具体的には、モデルにプロンプトを与えます。先ほどの例で言えば「この数学の問題を解いてください」といったものですね。そのプロンプトに対して、モデルに、たとえば16回の試行、すなわち生成1から16までを行わせます。この16回の試行が出そろったら、それを先ほど議論した別個の報酬モデルに通して、16回それぞれの試行について報酬を採点します。
Bernard： この例では、16回のうち正解はおそらく1回だけだったとしましょう。そうしたら、私たちはそのグループの平均を取り、その平均をもってモデルを更新し、より正しい生成のほうへとモデルをそっと押しやっていきます。なお、この参照モデル（reference model）というのは、本質的には、元のモデルが特定の RL ループから離れすぎてしまわないように歯止めをかけている存在です。これは反復的なプロセスです。ここでの重要なポイントは、この GRPO ループは何度も何度も、本当に何度も回すことができ、しかもそれほど多くのプロンプトを必要としないということです。それほど多くのデータは要りません。きちんとした報酬モデル、あるいは複数の報酬モデルさえあれば、モデルはどんどん賢くなっていきます。賢くなり続けるのです。もちろん、収穫が逓減して飽和する地点はやってきますが、これこそが、冒頭でお見せしたあのスライド、事後学習スケーリング則とテスト時ループのスケーリング則が効いてくる場面です。ここでは、スケーリング則の主役が、モデルをどれだけ大きくするかではなく、モデルをどれだけ洗練させるか、すなわち何回ループを回すかという反復の回数のほうへと移っていくのです。
5.3 推論訓練の定量的観察とトレードオフ
Bernard： こうした効果は、ベンチマークによって定量的に確かめることができます。たとえば、このスライドの左上にある数学の報酬を見ると、GRPO というアルゴリズムをわずか100回ほどループさせただけで、モデルがずっと賢くなったことが見て取れます。そしてその後も、およそ600から800ループあたりまでは賢くなり続け、そこで頭打ちになりました。
Bernard： ここでもう一つ見ていただきたいのが生成長（generation length）です。これは、モデルがその生成の中でどれだけ多く考えているか、つまり思考のためのトークンをどれだけ多く使っているか、を表しています。ループを重ねれば重ねるほど、思考の出力もまた伸びていくのが分かります。ただし、これは実はバランスを取る必要がある要素です。モデルにあまりに長く考えさせすぎると、「考えるのはいいけれど、ちょっと長すぎる」という状態になってしまいます。賢くあってほしいけれど、こちらも仕事を片付けなければならないので、そこまで長くは考えてほしくない、というわけです。
Bernard： そしてこれは、先ほど私が触れていたことの例です。ある一定のトークン予算（token budget）を超えると、知性、ここではベンチマークをどれだけ正確にクリアできるかという精度（accuracy）ですが、それが頭打ちになります。ですから、必要以上にトークンを費やす必要はありません。モデルが思考に費やすトークン数に上限を設けても、そのモデルが到達し得る最高水準の知性には達することができるのです。そして、それで構わないわけです。
6. NeMo RL と NeMo Gym
6.1 ツール群の概要と提供環境
Bernard： それでは、ここまで議論してきたことを実現するために NVIDIA が提供しているツール、すなわち NeMo RL と NeMo Gym をご紹介しましょう。このスライドは、いままさに議論してきた GRPO の高レベルな全体像を描いたものです。NeMo RL は生成などに使えるライブラリで、この後さらに詳しくお話しします。そして NeMo Gym は、その RL プロセスの一部として、さまざまな検証器（verifiers）や環境（environments）を提供するものです。検証器については先ほども少し触れましたが、ここはルールベースのものや、判定役としての LLM（LLM as a judge）を据えるところです。これらは本質的には、あるモデルのプロンプト生成に対して報酬スコアを与えるための、それぞれ異なる手段なのです。
Bernard： ここで、NVIDIA から何を提供してもらえるのか、という観点に立ち返りましょう。「LLM の材料（ingredients）」とでも言うべきものです。NVIDIA は NeMo モデルを提供しています。もちろん、ご自身でモデルを事前学習することも、オープンソースから別のモデルを持ってきてそこから始めることもできます。さらに、私たちはさまざまなデータセットも提供しています。オープンな環境についても議論しましたが、NeMo Gym には、数学推論、科学推論、コーディング、指示追従、エンジニアリング、検索チャット、エージェントによるツール利用、そして長文脈（long context）といった、さまざまな環境が用意されています。
Bernard： これは、推論がモデルの知性をどれだけ向上させたかを示す一例です。Nemotron V2 は2025年の早い時期にリリースされ、小規模モデル向けの Artificial Analysis Intelligence Index で15というスコアを得ていました。これに対して Nemotron バージョン3を見ていただくと、V2 と V3 の間にはアーキテクチャ上の違いはそれほどありません。違いはむしろ、この GRPO による事後学習ループを加えたという点にあります。それによって、知性が67%向上したのです。また、これは一つの GRPO ループの中で複数の環境、すなわち本質的には複数の報酬モデルを用いる例です。ある一つのループの中で、モデルにプロンプトに対する複数の生成を試させ、それが複数の異なる環境に対してどう採点されるかを見ていくわけです。
6.2 NeMo RL の機能詳細
Bernard： それでは、この NeMo RL という GitHub プロジェクトが、いままで議論してきた訓練の中にどう収まるのかを少しお話ししましょう。これは NeMo RL というプロジェクトが提供する機能を、ハイレベルにまとめたものです。私たちは主にアルゴリズムとして GRPO を取り上げてきましたが、RL のアルゴリズムは GRPO 以外にもたくさんあり、その多くが NeMo RL でサポートされています。そして新しいアルゴリズムが絶えず登場し続けています。実はこのスライドには PPO が抜けているのですが、PPO、DPO といったものですね。SFT は、2年ほど前にはおそらく主役のアルゴリズムでした。1年ほど前には PPO や DPO が主役でした。そして今は GRPO、GSPO、DAPO という時代に入っています。ですから、RL 領域のアルゴリズムは非常に速いペースで進化していくものだと考えていただいてよいでしょう。昨日まで最先端と見なされていたものが、その後あっという間に時代遅れになってしまうのです。ですから私たちが抱える課題の一つは、もっとも新しく、意味のあるアルゴリズムが RL できちんとサポートされ、使える状態になっているようにする、ということです。
Bernard： 訓練バックエンド（training backends）についてもお話ししましょう。これはどういうことかというと、まず AutoModel という選択肢があります。これは本質的に、純粋なネイティブ PyTorch と互換性のあるバックエンドで、ネイティブ PyTorch の並列化を用います。その利点は、非常に多くのモデルにアクセスできることです。本質的には、Hugging Face 上のあらゆるモデルを NeMo RL 上で使えますし、AutoModel バックエンドを使ってそれを RL で事後学習できます。もう一つの Megatron は、より最適化されたバックエンドです。先ほどお見せした数値は、この Megatron バックエンドを使ったものでした。ただし Megatron バックエンドは、対応しているモデルの範囲が AutoModel よりも狭い、一部に限られるという点があります。
Bernard： 生成バックエンド（generation backends）についても触れておきましょう。これは、先ほどの GRPO アルゴリズムで、事後学習しているモデルに対して出力、すなわち生成を促していた、あの部分にあたります。ここでは異なる推論バックエンドをサポートしており、vLLM、Megatron inference、そして近々登場予定の SGLang もその一つです。そして最終的には、オーケストレーションに Ray を用いています。性能面では、さまざまなモデルアーキテクチャがサポートされています。あらゆる種類の並列化を伴う大規模 MoE にも対応していますし、精度を一致させたまま FP8 をエンドツーエンドでサポートしています。先ほどのスライドでお見せしたとおり、FP8 を使うと BF16 に対して20%の高速化が得られます。つまり、事前学習から RL による事後学習に至るまで、FP8 をエンドツーエンドで使えるということです。NVFP4 も近々登場します。非同期 RL（async RL）についてはあまり時間を割きませんが、これは本質的には NeMo RL の機能で、オフポリシー（off-policy）の事後学習と呼ばれることを行えるものです。より多くのインフラを使ってスケールアウトでき、RL ループ全体としてより最適なエンドツーエンドの性能が得られます。
6.3 NeMo Gym：オーケストレーション層
Bernard： それでは、なぜ NeMo Gym というプロジェクトを使うのか、その動機についてお話しします。事後学習を行うとき、これまで議論してきたさまざまなツール、すなわちモデルが使えるツール呼び出しや、あらゆる環境を取りまとめてオーケストレーションする何かが必要になります。それらは、RL ループの一部として管理しなければならない、別々のサーバーやリソースになり得るのです。ポリシーモデルとさまざまな環境をまたいで、データとロールアウトを効率よくさばくオーケストレーターがあると望ましいわけです。これに対する私たちの答えが NeMo Gym です。NeMo Gym は NeMo RL とともに使えるオーケストレーション層です。
Bernard： NeMo Gym は他の RL フレームワークとも互換性がありますが、NeMo RL に対して高度に最適化されています。そして実戦で鍛え抜かれており、NeMo RL と NeMo Gym は Nemotron 3 の事後学習に用いられました。さらに現在は、その Super と Ultra のバリアントにも使用しています。では NeMo Gym はどこで登場するのでしょうか。訓練環境を準備する例で見てみましょう。まずベンチマークモデルから出発します。そして、このベンチマークモデルにどんな能力を追加したいのかを考えます。NeMo Gym が提供する既存の環境を使うこともできますし、独自の新しい環境を開発して NeMo Gym に追加することもできます。こうして Gym 環境が整います。Gym 環境が用意できたら、モデルの訓練を始められます。モデルの訓練を開始し、訓練したモデルをベンチマークに照らして検証し、能力が向上したことを確かめるわけです。
Bernard： そろそろ時間が尽きてきましたが、続けましょう。これは NeMo の間で何が起きているのかを、より絵的・図的に表したものです。左側にあるのが訓練フレームワークである RL、右側にあるのが Gym 環境です。ここで起きているのは、ポリシーモデルそのものが RL フレームワークの内部でホストされ、訓練されている、ということです。ある一回の GRPO ループを回すとき、プロンプトを NeMo Gym 内のエージェントコーディネーター（agent coordinator）へと送ります。すると、それがモデル、あるいは複数のモデルを呼び出して生成を行わせます。先ほどの1から16までの試行ですね。そして、それらの生成を検証器、すなわち環境へと渡し、各生成について報酬スコアを得ます。その出力を取り出して RL の訓練ループへと戻し、元のモデルの重みを更新します。この一回のループこそが、概念レベルにあった GRPO を、実際に NVIDIA の NeMo RL と Gym のプロジェクトでどんな部品が関わって動いているのか、というところまで落とし込んだものなのです。繰り返しになりますが、NeMo Gym は拡張できます。独自の検証器を持ち込むことも、独自の訓練データを持ち込むことも、リソースサーバーとして振る舞う異なる HTTP エンドポイントを持ち込むこともできます。ここに挙げているのは、NeMo Gym が標準で提供しているものです。これらについてはすでに少し触れたとおりです。
7. NeMo フレームワークと Megatron Bridge
7.1 NeMo フレームワーク全体構成
Bernard： ここからは NeMo フレームワークについて少しお話ししていきます。これは少し情報量が多くて圧倒されるようなスライドですが、この GitHub の URL アドレスにアクセスしていただければ、NVIDIA NeMo のさまざまなリポジトリをすべてご覧いただけます。これらはすべてオープンソースで利用可能です。私たちが提供しているのは、自分自身のモデルを訓練するために必要となるもの一式、すなわち事前学習、事後学習、そして推論のための展開までを、エンドツーエンドでカバーするものです。
Bernard： 具体的には、データ生成・前処理のためのライブラリ群、事前学習のためのライブラリ、Megatron Bridge や AutoModel、事後学習のための RL と Gym、そして推論に関連するさまざまなライブラリがそろっています。これらはすべて公開の場で開発されています。そして、もしこれらが役に立つと感じていただけたなら、皆さんご自身でプルリクエストを送っていただき、これらのリポジトリの改善に力を貸していただいても構いません。私たちはオープンソースへの貢献をいつでも歓迎しています。
7.2 Megatron Bridge：ハードウェア最適化レシピ
Bernard： ここで Megatron Bridge について少しご紹介させてください。これは最適化されたレシピを提供するプロジェクトです。私が「最適化された」と言うとき、それはモデルを訓練するためのレシピが、NVIDIA 固有のハードウェアに合わせて最適化されている、という意味です。その一例として、Megatron Bridge には非常に多くのモデルに対応したレシピが用意されています。たとえば、お望みであれば DeepSeek V3 や Qwen3 を Megatron Bridge で事前学習することもできます。対象となるハードウェアも、H100 から Grace Blackwell まで幅広く、もっとも新しい Grace Blackwell は GB300 です。
Bernard： ここでお見せしているのは、さまざまなデータ型、すなわち BF16 や MXFP8 です。「NVFP4 はどこにあるのか」と思われた方もいるかもしれませんが、その数値については、いままさにレシピを最適化している最中です。ですから、このスライド向けには用意できていなかったのですが、近いうちにそろえる予定です。本質的には、NVFP4 のテラフロップス（teraflops）の値はさらに高くなると想像していただいて構いません。テラフロップスが何なのかよく分からないという方は、GPU からどれだけ効率を引き出せているか、と捉えていただければと思います。
Bernard： FP8 と BF16 を比べてみましょう。本質的に、MXFP8 はビット数が半分で済んでおり、ご想像のとおり BF16 よりも効率的です。NVFP4 はさらに効率的になりますが、低精度（low precision）と正確性（accuracy）の間には常にトレードオフが存在します。そして、もう一方のこのグラフが示しているのは、あるデータ型の内部で見たときの性能向上です。BF16 の場合、H100 から Grace Blackwell へ移ると、本質的におよそ3倍の向上が得られます。FP8 では、H100 から GB へ移ると、実に4倍の向上が得られます。NVFP4 については、おそらくさらに高く、5倍超の向上になるだろうと見ています。これは意味のある話です。というのも、もしモデルの訓練に5日かかっているとしても、より上位クラスの GPU に切り替えるだけで、それを1日にまで短縮できる、ということだからです。
8. 事例：Nemotron 3 の全工程とまとめ
8.1 事前学習から事後学習までの全工程
Bernard： 締めくくりとして、いままでの1時間ほどで議論してきたことすべてを踏まえながら、Nemotron 3 を事前学習から事後学習へとどのように進め、いま Hugging Face 上で利用可能になっている最終的なモデルをどうやって作り上げたのか、その全工程を数枚のスライドでお話ししたいと思います。
Bernard： まず事前学習データから始めました。事前学習データには15のカテゴリがあります。そこで事前学習を行い、コンテキストを拡張しました。ここが、コンテキストを100万トークンまで拡張できるようにした部分です。こうして事前学習済みのベースモデルが得られます。次に、その事前学習済みベースモデルに対して SFT を実行しました。ここでモデルに推論の制御（reasoning control）を与えています。これでファインチューニング済みのチェックポイントが得られます。
Bernard： そのファインチューニング済みチェックポイントを、続いて RL に通しました。これは RL を用いた GRPO ループで、検証可能報酬モデル（verifiable reward models）を使うものです。つまり RLVR（RL with verifiable rewards）を GRPO 経由で行うわけで、これで RLVR チェックポイントが得られます。さらに、それを報酬モデルを用いた RLHF に通しました。これは、先ほど私が触れていた、安全性・有用性・正確性といった複数のカテゴリを持つデータセットでモデルを誘導していくものです。これもまた一つのループです。そしてもう一度、RLVR を GRPO 経由で実行し、最終的な BF16 チェックポイントを得ます。最後に、事後学習量子化（post-training quantization）を行い、モデルを BF16 から FP8 のデータ型へと縮小しました。これで実際にサイズが半分になります。サイズは半分でありながら、賢さは変わりません。こうして最終的な FP8 チェックポイントが得られるのです。
Bernard： 事前学習についてもう少し触れますと、Data Designer というプロジェクトがあり、これを使えば合成的にデータを生成できます。データを追加したいときに、この Data Designer を使えるわけです。ベースモデルのアーキテクチャについてですが、これはハイブリッドの Mamba 2 と MoE を組み合わせたアーキテクチャです。ここでのユニークな点はこういうことです。かつて LLM はすべて attention、attention、attention と、attention だらけで、非常にコストが高いものでした。それが今では、私たちは MoE を伴う Mamba 2 を使い、全体のアーキテクチャの中に attention ブロックはごくわずかしか置いていません。これこそが、長文脈と効率の両方を実現できた理由なのです。
Bernard： これが SFT のループです。ここでの主眼は、思考のオン・オフを切り替えられるようにした点です。ごく一部のサンプルに、この「思考（thinking）」および「思考の終わり（end of thinking）」を表すトークンを入れて訓練しました。これによってモデルは、思考をオンにする・オフにするとはどういうことなのかを認識するようになったのです。そして最後が RLVR のループです。
8.2 まとめと謝辞
Bernard： そして、これは NeMo RL について改めて触れているスライドで、先ほどお見せしたあの一つの URL です。そこからこれらすべてにアクセスできます。ですので、写真を撮っていただいてもいいですし、戻って……どこでしたか、ええ、これですね。ここにアクセスしていただければ、すべてそこにそろっています。本日はお時間をいただき、誠にありがとうございました。少しでもお役に立てたなら幸いです。感謝申し上げます。
司会： ［拍手］ありがとうございました。