NVIDIA MegatronによるLLM学習高速化へ向けた新世代オプティマイザの高度化
NVIDIAはMegatron-LMフレームワークにShampooなどの高次最適化アルゴリズムを組み込み、大規模言語モデルの学習速度と効率を大幅に向上させる技術実装を発表した。
キーポイント
高次最適化アルゴリズムの公式統合
Megatron-LMにShampooなどの既存の高次最適化手法をネイティブサポートとして実装し、学習の安定性と収束速度を改善。
トレーニング効率の大幅な向上
最適化アルゴリズムの変更により、大規模モデルにおける学習ステップ数を削減し、計算リソースの効率的な活用を実現。
実装ガイドラインとベンチマーク
開発者向けに具体的な設定手順、ハイパーパラメータ調整の指針、および既存オプティマイザーとの性能比較データを公開。
影響分析・編集コメントを表示
影響分析
NVIDIAがMegatron-LMに高次最適化アルゴリズムを公式統合したことは、大規模モデル学習のハードルを下げ、研究開発サイクルの加速に寄与する。特に計算リソースが限られる環境でも高度な最適化手法を活用できるため、業界全体の学習効率標準が引き上げられると予想される。
編集コメント
技術ブログ形式のため具体的な数値データは限られるが、Megatron-LMユーザーにとっては学習効率を改善する実装ガイドとして即座に活用できる価値がある。今後は他の高次オプティマイザーとの組み合わせベンチマークも期待される。
シュリンプ(Shampoo)などの高次最適化アルゴリズム(higher-order optimization algorithms)は、少なくとも過去10年にわたりニューラルネットワークの学習に効果的に適用されてきました。これらの手法は、近年では主要な大規模言語モデル(LLM: Large Language Model)に適用されることで顕著な成功を収めています。特に、ニュートン-シュルツ法による直交化モーメント(Muon: MomentUm Orthogonalized by Newton-Schulz)は、Kimi K2やGLM-5など、現在公開されている最高水準のオープンソースモデルの一部の学習に使用されています。
本記事では、NVIDIAがMuonやその他の最先端の新興オプティマイザ(optimizer)に対して包括的なサポートを提供する方法、および大規模モデルの学習を可能にする技術について解説します。
NVIDIA GB300 NVL72におけるMuonの学習パフォーマンス
表1は、NVIDIA GB300 NVL72システム上でMuonおよびAdamWオプティマイザ(optimizer)を用いたKimi K2モデルとQwen3 30Bモデルの学習スループット(throughput)をまとめたものです。次のセクションで紹介する技術を用いることで、AdamWと比較してMuonオプティマイザ使用時の学習パフォーマンスの低下は極めて小さいことが示されています。ニュートン-シュルツ反復(Newton-Schulz iteration)における行列乗算のFLOPsをカウントした場合、Muonの方がモデルFLOPs利用率(MFU: Model FLOps Utilization)が高くなります。
これらの計測は、NeMo Framework内のPyTorchネイティブライブラリであるNVIDIA NeMo Megatron Bridge 26.02を使用して達成されました。このライブラリは、主要なLLMおよびVLMモデルに対して事前学習(pretraining)、SFT(Supervised Fine-Tuning)、LoRAを提供します。NVIDIAチームは、Kimi K2の学習にPP4DP64EP64構成で256個のNVIDIA GB300 GPUを、Qwen3 30B-A3Bの学習にDP8EP8構成で8個のNVIDIA GB300 GPUを使用しました。
NVIDIA GB300 MXFP8(TFLOPs/s/GPU)
モデル AdamW Muon
Kimi K2 1,051 1,080(モデル1,029 + Muon 51)
Qwen3 30B-A3B 713 721(モデル686 + Muon 35)
表1. NVIDIA Megatron-Bridge 26.02で計測された学習スループット
詳細な実験設定および計測の再現手順については、以下のクイックスタート(Quickstart)セクションを参照してください。
大規模なMuon学習を可能にする技術
Muonなどの高次オプティマイザはLLMの学習効率向上が期待されますが、大規模な実装にはいくつかの課題があります。ニュートン-シュルツ反復や固有値分解を用いた前処理(preconditioning)ステップは、計算コストとメモリ消費を大幅に増加させます。さらに、混合精度学習(mixed-precision training)や勾配蓄積(gradient accumulation)の過程で数値不安定性が発生する可能性があります。同期化された直交化更新を数千個のGPUに効率的に分散配置することは、通信ボトルネックを引き起こし、全体的な効率向上のメリットを損なう可能性があります。
このセクションでは、これらの課題を克服し数千個のGPUにスケールするための技術を紹介しています。選択された技術は、汎用性、スループット、実装の複雑さの間でバランスが取れています。単純なMuonに特化した最適化を優先するのではなく、Muon、SOAP(ShampoO with Adam in the Preconditioner’s eigenbasis)、その他の複雑なオプティマイザに一般化可能な技術を優先しています。
レイヤーごとの分散オプティマイザ(layer-wise distributed optimizer)
従来の要素ごとの分散オプティマイザ(element-wise distributed optimizer)(AdamWなどの要素ごとのオプティマイザに大規模適用されるもの)は、以下の機能を提供します:
パーティショニング状態(Partitioning states):すべてのGPUが全データを保持するのではなく、オプティマイザの状態(optimizer states)は利用可能なすべてのGPUに均等に分割されます。
リデュース・スキャッター勾配(Reduce-scatter gradient):すべての勾配に対してリデュース・スキャッター演算が行われ、各GPUは自身が「所有する」パラメータに対応する勾配の一部を受け取ります。
ローカル更新(Local updates):各GPUは自身が「所有する」モデルパラメータの特定の部分のみを更新します。
アールギャザーパラメータ(AllGather parameters):更新後、GPUは通信を行い、次の順伝播(forward pass)のために全デバイスがモデル全体の更新された重みを持つことを確認します。
より高度なバージョンでは、演算を細分化し、通信と計算処理をオーバーラップ(重畳)させます。
要素ごとの分散オプティマイザ(Element-wise distributed optimizers)はAdamオプティマイザとよく機能してきました。しかし、Muonを含む多くの新興オプティマイザは、その層の重み更新を計算するために層全体の勾配を必要とします。重みとオプティマイザの状態がデータ並列(data parallel, DP)ランク間で均等に分散されている場合、各GPUで利用可能なデータに基づいて更新を計算することはできません。完全な更新を計算するためのデータを収集するために、追加の通信が必要になります。
このタイプのオプティマイザをサポートするために、層ごとの分散オプティマイザ(layer-wise distributed optimizer)が導入されました。異なる層のパラメータは、異なるDPランクに分散されます。各GPUにはプリコンディショナ(preconditioner)を計算できるだけの完全な層分のパラメータが用意されています。
図1. DPランク間における要素ごとのパラメータ分散と層ごとのパラメータ分散の比較。層ごとの分散では、各ランクに完全な層が割り当てられ、全層のプリコンディショニングを可能にします。
層ごとの分散に伴う変更の一つは、可変サイズ通信(variable-size communication)です。完全な層のサイズが異なるため、各GPUはall_gathervを通じて、異なるGPUから異なるサイズの重み更新を収集する必要があります。
この層ごとの分散オプティマイザは、高度な並列処理、混合精度(mixed precision)、最適化されたGPUカーネルを用いて大規模モデルの構築とトレーニングを行うためのオープンソースライブラリであるNVIDIA Megatron Coreに完全に統合されています。実装はlayer_wise_optimizer.pyで確認できます。
分散ニュートン・シュルツ(Distributed Newton-Schulz)
大規模なLLMトレーニングでは、他の並列処理手法と組み合わせてテンソル並列(tensor parallelism, TP)がよく使用されますが、これにより独自の課題が生じます。TPは特定の次元に沿って複数のGPUに個別の重み行列を分割するため、単一のデバイスが完全なパラメータテンソルを保持することはありません。Muonオプティマイザの重要な直交化ステップでは、計算のためにモーメンタムバッファ行列全体へのアクセスが必要です。このモーメンタムバッファがデバイス間でシャードされている場合、シャードされたモーメンタムと重みを処理するために追加の通信が必要になります。
TensorParallelMuonでは、このようなシナリオを処理するために2つの手法が提供されています:複製モード(duplicated mode)と分散モード(distributed mode)です。
複製モード(Duplicated mode)
まず、TP(テンソル並列)ドメイン内でモーメンタムが all-gather(全結合)され、各 GPU がニュートン-シュルツ反復(Newton-Schulz iteration)に必要な全データを持つようにします。その後、各 GPU は完全なニュートン-シュルツ反復を実行し、対応する直交化されたモーメンタムによって自身が管理する重みを更新します。このモードは、各 GPU が同じ NS 反復(NS interactions)を実行する代償として、ネットワークレイテンシを最適化します。各更新において、NS 反復の回数(通常は5回)に関わらず、事前に必要となる通信は all-gather が1回だけです。
分散モード
名が示す通り、NS 反復の計算は TP ドメイン内の GPU に分散されます。各 NS 反復では3回の行列乗算(matrix multiplication)が行われ、各反復の最初の行列乗算後に all-reduce(全縮小)が必要です。このモードは、より頻繁な通信を行う代償として、計算効率を最適化します。
さらに、ブロックワイズモード(blockwise mode)もサポートされており、これは各 GPU が所有するモーメンタムと重みのみを用いて直交化(orthogonalization)と更新を行います。他の2つのモードと比較して計算コストが低く、通信も不要です。ただし、これは全モーメンタム行列をまとめて直交化することとは等価ではありません。数学的には概念的にブロック直交化(block orthogonalization)であり、したがってこの名前が付けられており、『Scalable Second Order Optimization for Deep Learning』で最初に紹介されたブロッキング手法に類似しています。
追加の最適化
その他の最適化手法により、トレーニングスループット(training throughput)をさらに向上させることができます。このセクションでは重要なものいくつかを簡潔に解説し、これらは NVIDIA Emerging Optimizers 研究プロジェクトを通じて段階的に導入されていきます。
通信の非同期化(Communication hiding)
現在の NVIDIA Emerging Optimizers プロジェクトのリリースでは、パラメータはオプティマイザステップ(optimizer step)直後に収集され完全に公開されますが、これは特定の状況下でボトルネックとなる可能性があります。要素ごとの分散オプティマイザ(element-wise distributed optimizers)で用いられるのと同じ手法を適用でき、パラメータの収集を次のバッチのフォワードステップ(forward step)に遅延させ、計算と重畳させることができます。
負荷分散(Load balancing)
アテンションおよび MLP 重み行列(attention and MLP weight matrices)のサイズが様々であるため、プリコンディショニング(preconditioning)に起因するオプティマイザの計算コストも層によって異なります。理論上でも完全な負荷分散は達成できません。現在、層は同じ DP ドメイン(DP domain)内の GPU にラウンドロビン方式で分散されています。計算コストと通信コストをある程度見積もることで、より良い負荷分散を実現する方法もあります。
SYRK と融合された all-reduce
NS 反復の3回の行列乗算のうち最初の2回を SYRK(対称ランクK更新)にマッピングできるため、浮動小数点演算(floating point operations)の約半分を節約できます。対角に沿ったタイルを完全に計算する必要があるため、節約幅は半分よりわずかに少なくなります。現在のリリースでは Triton カーネル(Triton kernels)が提供されています。
SYRKは圧縮形式の上位(または下位)三角行列ではなく、完全な行列を出力します。分散モードでは、all-reduce(全結合)依然として半分ではなく完全な行列を通信する必要があります。より高度なバージョンでは、通信をSYRKカーネルに融合でき、帯域幅の節約だけでなく、より細かな粒度(つまりタイルレベル)で通信を隠蔽することも可能です。CuTe DSLの実装は将来のリリースで予定されています。
研究のためにNVIDIAがサポートする他のオプティマイザは何ですか?
Muonに加え、NVIDIAは研究コミュニティが探索できる多くの他のオプティマイザもサポートしています。以下を含む:
直交化オプティマイザの究極形態であるMOP(偏微分解由による... -> 極分解によるモーメンタム直交化)
REKLSにおける、固有値分解とKL補正を用いてステップごとに固有基底を更新する高度なSOAPバリアント
Muonの学習結果の再現
このセクションでは、表1のスループット結果を再現する方法と、MuonがNVIDIAソフトウェアスタックにどのように統合されているかを説明します。
クイックスタート
NVIDIA-NeMo/Megatron-Bridge GitHubリポジトリのパフォーマンスレシピに記載の手順に従ってください。
例として、256個のNVIDIA GB300 GPUでKimiを実行する場合、Megatron Bridgeリポジトリのルートから開始します:
CONTAINER="nvcr.io/nvidia/nemo:26.04"python scripts/performance/setup_experiment.py --account
-i ${CONTAINER}
--partition
-m kimi
-mr kimi_k2
--log_dir
--num_gpus 256
--gpus_per_node 4
-t "00:15:00"
-g gb300
-c fp8_mx
-hf
統合
MuonはMegatron Coreに統合されており、Muonクラスとレイヤーごとの分散ラッパーが含まれています。
Muonの場合、use_distributed_optimizerは要素ごとの対応物ではなく、レイヤーごとの分散オプティマイザに自動的にディスパッチすることに注意してください。
LLM学習のための新興オプティマイザの開始
Muonのような高次オプティマイザは、LLM学習効率の限界を押し広げる上で不可欠であることが証明されています。レイヤーごとの分散最適化、カスタマイズされた分散ニュートン-シュルツ反復(Newton-Schulz iterations)、そして通信隠蔽(communication hiding)および融合SYRK/all-reduceカーネルに関する継続的な作業を通じて、これらの強力な手法を大規模に効果的にデプロイできるようになりました。Megatron Coreを使用すれば、今すぐこれらの手法の使用を開始できます。
Muonおよびその他の新興オプティマイザはMegatron Coreに統合されています。
MOPやREKLSなどの研究用オプティマイザは、NVIDIA-NeMo/Emerging-Optimizers GitHubリポジトリで実験用に利用可能です。
設定を選択する際は、以下の考慮事項を念頭に置いてください:
分散NS(ニュートン-シュルツ)モード:ネットワークレイテンシが支配的な場合は重複モードを使用します。計算がボトルネックとなる場合は分散モードを使用します。ブロックごとのモードは通信を完全に回避しますが、完全な直交化を近似します。
スケーラビリティ:レイヤーごとの分散オプティマイザは、最小限のオーバーヘッドで大きなDP(データ並列)スケールにおいてMuonを可能にします。表1は、NVIDIA GB300におけるAdamWのスループットとほぼ同等であることを示しています。
今後の改善課題:通信の隠蔽(Communication hiding)、より高度な負荷分散(Load balancing)、そしてSYRK/All-reduceの融合カーネルにより、今後のリリース版で残るスループット(Throughput)の差をさらに縮小していきます。
早速始めたい方は、Megatron Bridgeのパフォーマンスレシピをご覧ください。
原文を表示
Higher-order optimization algorithms such as Shampoo have been effectively applied in neural network training for at least a decade. These methods have achieved significant success more recently when applied to leading LLMs. In particular, Muon (MomentUm Orthogonalized by Newton-Schulz) was used to train some of today’s best open source models, including Kimi K2 and GLM-5.
This post explains how NVIDIA provides comprehensive support for Muon and other cutting-edge emerging optimizers and the technologies enabling them to train large-scale models.
Muon training performance on NVIDIA GB300 NVL72
Table 1 summarizes training throughput of the Kimi K2 and Qwen3 30B models with Muon and the AdamW optimizer on the NVIDIA GB300 NVL72 system. With the technologies that will be introduced in the next section, the results show that there is a very small training performance loss using the Muon optimizer compared to AdamW. Model FLOPs utilization (MFU) is higher with Muon when counting the FLOPs of the matrix multiplication in Newton-Schulz iterations.
These measurements were achieved using NVIDIA NeMo Megatron Bridge 26.02, a PyTorch-native library within the NeMo Framework that provides pretraining, SFT, and LoRA for popular LLM and VLM models. The NVIDIA team used 256 NVIDIA GB300 GPUs with PP4DP64EP64 for Kimi K2 training and eight NVIDIA GB300 GPUs with DP8EP8 for Qwen3 30B-A3B training.
NVIDIA GB300 MXFP8 (TFLOPs/s/GPU)ModelAdamW MuonKimi K21,0511,080(1,029 model plus 51 Muon)Qwen3 30B-A3B713721(686 model plus 35 Muon)Table 1. Training throughput measured with NVIDIA Megatron-Bridge 26.02
For more detailed experimental settings and steps to reproduce the measurement, see the Quickstart section below.
Enabling technologies for large-scale Muon training
While higher-order optimizers like Muon promise to improve LLM training efficiency, their practical deployment at scale faces several hurdles. The preconditioning step, using Newton-Schulz iteration or eigen decomposition, significantly increases computational cost and memory consumption. In addition, numerical instability can arise during mixed-precision training and gradient accumulation. Efficiently distributing the synchronized, orthogonalized updates across thousands of GPUs may introduce communication bottlenecks that can diminish the overall efficiency benefits.
This section introduces technologies to overcome these hurdles and scale to thousands of GPUs. The selected technologies are balanced among generality, throughput, and implementation complexity. We favor technologies that can be generalized to Muon, SOAP (ShampoO with Adam in the Preconditioner’s eigenbasis), and other complex optimizers instead of solely focusing on Muon, for which more optimizations would apply because of its simplicity.
Layer-wise distributed optimizer
A traditional element-wise distributed optimizer (commonly applied to element-wise optimizers like AdamW at scale) provides the following:
Partitioning states: Instead of every GPU storing everything, the optimizer states are evenly sliced up across all available GPUs.
Reduce-scatter gradient: A reduce-scatter is performed over all gradients and each GPU gets a portion of gradients corresponding to the parameters it “owns.”
Local updates: Each GPU updates only the specific portion of the model parameters it “owns.”
AllGather parameters: After the update, GPUs communicate to ensure all devices have the updated weights of the full model for the next forward pass.
A more advanced version breaks down operations and overlaps communication with computations.
Element-wise distributed optimizers have been working well with Adam optimizers. However, many emerging optimizers, including Muon, require gradients of the entire layer to calculate updates to the weights of that layer. If weights and optimizer states are evenly distributed among data parallel (DP) ranks, updates can’t be calculated based on the data available on each GPU. Additional communication will be needed to collect data for calculating the full update.
A layer-wise distributed optimizer is introduced to support this type of optimizer. Parameters of different layers are distributed to different DP ranks. Each GPU has full layers worth of parameters so that the preconditioner can be calculated.
Figure 1. Element-wise versus layer-wise parameter distribution across DP ranks. Layer-wise distribution assigns whole layers to each rank, enabling full-layer preconditioning
One change that comes with layer-wise distribution is variable-size communication. Because whole layers vary in size, each GPU needs to collect differently sized parameter updates from different GPUs through all_gatherv.
This layer-wise distributed optimizer is fully integrated into NVIDIA Megatron Core, an open source library for building and training large-scale models with advanced parallelism, mixed precision, and optimized GPU kernels. The implementation can be found in layer_wise_optimizer.py.
Distributed Newton-Schulz
LLM training at scale often uses tensor parallelism (TP) together with other parallelisms, which introduces unique challenges. TP splits individual weight matrices across multiple GPUs along specific dimensions, meaning no single device holds the full parameter tensor. The Muon optimizer critical orthogonalization step requires access to the entire momentum buffer matrix to compute. When this momentum buffer is sharded across devices, additional communication is necessary to handle the sharded momentum and weights.
Two methods are provided to handle such scenarios in TensorParallelMuon: duplicated mode and distributed mode.
Duplicated mode
Momentums are first all-gathered among TP the domain so that each GPU has all the data for the Newton-Schulz iteration. Then each GPU performs full Newton-Schulz iterations and updates the weights it owns by the corresponding orthogonalized momentum. This mode is network latency optimized at the cost of each GPU performing the same NS iterations. For each update, regardless of how many NS interactions are used (commonly five), only one all-gather communication is needed upfront.
Distributed mode
As the name suggests, computation of NS iterations is distributed among GPUs in the TP domain. Each NS interaction does three matrix multiplication, an all-reduce is needed after the first matrix multiplication of each iteration. This mode is computation optimized at the cost of more frequent communication.
In addition, a blockwise mode is also supported, which does orthogonalization and updates only with momentum and weights owned by each GPU. It is more cost effective to compute and doesn’t require any communication compared to the other two modes. However, it is not equivalent to orthogonalizing the entire momentum matrix together. Mathematically, it is conceptually a block orthogonalization (hence the name blockwise), similar to the blocking approach first introduced in Scalable Second Order Optimization for Deep Learning.
Additional optimizations
Other optimizations can further boost training throughput. Some important ones are briefly discussed in this section and will be gradually introduced through the NVIDIA Emerging Optimizers research project.
Communication hiding
In the current release of the NVIDIA Emerging Optimizers project, parameters are gathered immediately after the optimizer step and fully exposed, which could become bottleneck under certain circumstances. The same technique used in element-wise distributed optimizers can also apply, parameters gathering can be delayed to the forward step of the next batch and overlap with computation.
Load balancing
Because of various sizes of attention and MLP weight matrices, the computational cost of the optimizer because of the preconditioning also varies among layers. A perfect load balancing can’t be achieved even in theory. Currently, layers are distributed among GPUs in the same DP domain in round robin fashion. There are methods that can achieve better load balancing based on some estimation of computational and communication cost.
SYRK and fused all-reduce
The first two out of three matrix multiplications of an NS interaction can be mapped to SYRK (SYmmetric Rank-K update), so that close to half of the floating point operations can be saved. Saving is slightly less than half because tiles along the diagonal need to be fully computed. Triton kernels are provided in the current release.
SYRK outputs a full matrix instead of upper (or lower) triangle in compacted format. In the distributed mode, all-reduce still needs to communicate the entire matrix instead of half. A more advanced version can fuse communication into the SYRK kernel, which not only saves bandwidth but can also hide communication at finer granularity (that is, at the tile level). A CuTe DSL implementation is planned for a future release.
What other optimizers does NVIDIA support for research?
In addition to Muon, NVIDIA also supports many other optimizers for the research community to explore, including:
The ultimate form of orthogonalized optimizer MOP (Momentum Orthogonalized by Polar decomposition)
An advanced SOAP variant that updates eigen basis per step with eigen decomposition plus KL correction in REKLS
Reproducing Muon training results
This section explains how to reproduce the throughput results from Table 1 and how Muon is integrated into the NVIDIA software stack.
Quickstart
Follow the instructions in the performance recipes in the NVIDIA-NeMo/Megatron-Bridge GitHub repo.
As an example, to run Kimi on 256 NVIDIA GB300 GPUs, start from the Megatron Bridge repo root:
CONTAINER="nvcr.io/nvidia/nemo:26.04"python scripts/performance/setup_experiment.py --account <slurm_account> \ -i ${CONTAINER} \ --partition <slurm_partition> \ -m kimi \ -mr kimi_k2\ --log_dir <result_dir> \ --num_gpus 256 \ --gpus_per_node 4 \ -t "00:15:00" \ -g gb300 \ -c fp8_mx \ -hf <HF_TOKEN>
Integrations
Muon is integrated in the Megatron Core, including a Muon class and layer-wise distributed wrapper.
Note that for Muon, use_distributed_optimizer will automatically dispatch it to the layer-wise distributed optimizer instead of the element-wise counterpart.
Get started with emerging optimizers for LLM training
Higher-order optimizers like Muon are proving essential for pushing the boundaries of LLM training efficiency. Through layerwise distributed optimization, tailored distributed Newton-Schulz iterations, and ongoing work on communication hiding and fused SYRK/all-reduce kernels, these powerful methods can now be deployed effectively at massive scale. With Megatron Core, you can start using them now.
Muon and other emerging optimizers have been integrated into Megatron Core.
Research optimizers like MOP and REKLS are available for experimentation in the NVIDIA-NeMo/Emerging-Optimizers GitHub repo.
When choosing a configuration, keep these considerations in mind:
Distributed NS mode: Use duplicated mode when network latency dominates. Use distributed mode when computation is the bottleneck. Blockwise mode avoids communication entirely but approximates the full orthogonalization.
Scale: The layer-wise distributed optimizer enables Muon at large DP scales with minimal overhead. Table 1 shows near-parity with AdamW throughput on NVIDIA GB300.
Future improvements: Communication hiding, better load balancing, and fused SYRK/all-reduce kernels will further close any remaining throughput gap in upcoming releases.
Ready to get started? Check out the Megatron Bridge performance recipes.
関連記事
Nvidiaに挑戦するAIチップ新興企業MatXが5億ドルを調達
元Google TPUエンジニアが設立したAIチップ新興企業MatXが5億ドルを調達。Nvidiaへの競争激化を示す動き。
NVIDIA Nemotron 3 Ultra が長時間実行型エージェントの推論を高速化・効率化
NVIDIA は、長時間実行型エージェントが推論を行い、文脈を維持し、ツールを活用して効率的に動作するための新モデル「Nemotron 3 Ultra」を発表した。これにより、単発チャットボットから複雑なタスクをこなすエージェントへの進化が加速する。
マイクロソフトと NVIDIA の新ツールを用いて Windows PC でパーソナル AI エージェントを構築する
マイクロソフトと NVIDIA は、Windows PC 上でパーソナル AI エージェントを構築するための新ツールを提供した。これにより開発者はローカル環境で効率的にエージェントを設計・実装できる。