Amazon Trainiumのトレーニング、ネイティブPyTorchでNvidiaに挑戦
Amazonは10月20日、研究者がすでに利用しているワークフローを通じてNvidiaのトレーニングソフトウェア上の優位性に挑むべく、Trainium向けのネイティブPyTorchサポートを開始した。Amazon Trainiumのトレーニングには現在、PyTorchのモデルコードをAmazonのアクセラレータに接続するソフトウェアコンポーネント「TorchNeuron」と呼ばれるパブリックベータ版バックエンドが用意されている。PyTorchは、開発者がモデルを定義、学習、実行するために用いるフレームワークだ。
この転換が重要なのは、トレーニング用ハードウェアの競争が計算性能だけで決まるものではないからである。研究者は、未知のデバイスに合わせてソフトウェアを作り直すことなく、モデルを変更し、障害を調査し、実験を繰り返す必要がある。高速コンピューティング向けのプログラミング環境であるNvidiaのCUDAプラットフォームは、依然としてその体験の基準点となっている。
10月23日のSemiAnalysisによる評価は、コンパイルの遅延や未完成の互換性とともに、有望な実地検証の証拠を示した。現在生まれつつある競争の焦点は、AmazonがTrainiumを日常的な研究で実用的にできるかどうかにある。これにより、AmazonがあらゆるトレーニングワークロードでNvidiaを追い越したと結論づけることはできない。
Amazon TrainiumのトレーニングにネイティブPyTorchへの経路が加わる
Amazonは研究者と自社チップの間にあるソフトウェア上の取り決めを変えようとしている。
AWSのTorchNeuronパブリックベータは、Trainium2およびTrainium3インスタンスをサポートする。同社によれば、開発者は標準的なPyTorchインターフェースを維持したまま、neuronデバイスを選択できる。また、デバイス固有の計算ルーチンを記述するためのAmazonのインターフェースであるNeuron Kernel Interfaceを通じ、カスタム演算子にも対応する。
この発表は、研究者が理解しているモデルと、適応しなければならないハードウェアスタックとの隔たりという実務上の障害に対処するものだ。実験の別バージョンを維持する必要があるなら、有望なアクセラレータであっても導入の魅力は下がる。
ネイティブ統合は、その適応がどこで行われるかを変える。理想的には、ハードウェアバックエンドがより多くのデバイス固有の作業を吸収し、研究者は既存のモデル定義に近い形で作業を続けられる。これによりAmazonは、専任のアクセラレータ専門家を持たないチームにも、より明確な導入経路を示せる。
ただし、この表現には注意が必要だ。ネイティブサポートは統合のアプローチを示すものであり、あらゆる演算、ライブラリ、ワークロードで同一の挙動を保証するものではない。パブリックベータであることも、開発者がサポート対象の範囲が変化していくと予想すべきことを意味する。
研究チームにとって有用な区別は、実験を開始することと、研究プログラムを継続することの間にある。開始には、モデルが読み込まれて実行できることが必要だ。継続には、アーキテクチャ変更、デバッグ、評価、ソフトウェア更新を管理可能な状態に保つことが求められる。
こうした後続の作業に特別な労力が不要になれば、Amazon Trainiumのトレーニングはより競争力を持つ。成功したデモンストレーションは入口を示せる。しかし、その入口が信頼できる作業環境となるかを決めるのは、繰り返される日常的な実験である。
たとえば、各予測にどの情報が影響するかを決めるコンポーネントである言語モデルのアテンション機構を変更するチームを考えてみよう。そのチームは、変更内容をベースラインと比較する必要がある。ハードウェアの選択そのものが、別個の研究プロジェクトになってはならない。
この例は、今回の発表がインフラ専門家にとどまらない理由を示している。研究者は、そのツールで試せる実験に基づいて、ある程度ツールを選択する。したがってハードウェア互換性は、チームが利用可能な時間内に検討できる問いに影響する。
企業の購入担当者にとっても、その意味は具体的だ。調達時の比較には、ワークロードを健全な状態で維持するために必要なエンジニアリング作業を含めるべきである。ソフトウェア面の負担によって実験が非現実的になるなら、デバイスの可用性はほとんど意味を持たない。
したがって当面の変化は、Trainiumを評価するよう促す対象が広がることにある。AWSはその評価のために、使い慣れたインターフェースを提供した。チームが利用を続けるかどうかは、そのインターフェースの下での挙動、特にコードが用意されたデモンストレーションから外れた場合の挙動にかかっている。
研究者が時間を費やす領域でNvidiaに圧力
競争上の突破口は、単独のハードウェアスコアではなく、研究を移行するために必要な労力にある。
AmazonがGPUトレーニングを取り巻くソフトウェア習慣に取り組んでいるため、Nvidiaはこの話における主な競合相手となる。GPUは並列計算向けに設計されたプロセッサだ。研究者は、デバッグ、ライブラリ、蓄積されたチームの知識を含め、その周囲にある作業環境全体を評価する。
こうした投資は、既存のプラットフォームにとどまる強い理由を生む。組織は、どの障害が日常的なものか、どの変更に慎重さが必要か、社内の専門知識がどこにあるかを把握している。ハードウェアの移行は、その理解を揺るがしかねない。
Amazonのアプローチは、この切り替え負担を直接狙うものだ。研究者が使い慣れたインターフェースを維持できれば、試す前から代替案を退ける理由は減る。購入者がどちらのプラットフォームの性能が高いかを決める前であっても、これは競争上の前進となる。
したがってNvidiaへの圧力は具体的である。AWSは、ハードウェア評価が研究プロセスを妨げにくくしようとしている。Nvidiaは、より利用しやすい代替手段を得たチームから引き続き選ばれる必要がある。
この圧力を、直ちに移行が進むという予測と混同すべきではない。研究室は既存のGPUインフラを維持しながらTrainiumを検討できる。評価によって選択肢は広がるが、最終的にどれだけの作業が移るかが決まるわけではない。
大規模トレーニングワークフローを組み立てるためのPyTorchフレームワークであるTorchTitanは、有用な参照点となる。そのプロジェクトは、モジュール型のモデル定義と、複数デバイスに計算を分散する構成可能な分散実行について説明している。このため、既存のトレーニング基盤を適応させる研究チームにとって関連性がある。
戦略的価値は、その基盤を維持できることにある。チームは、ハードウェアの実験ごとに科学的作業の恒久的な分岐を作りたくはない。実装が近い状態に保たれるほど、結果の比較は容易になる。
これは、推論での成功だけではトレーニングへの適性を自動的に証明できない理由でもある。推論は、学習済みモデルを使って出力を生成する。研究におけるトレーニングでは、開発者がアーキテクチャ、データ、最適化の選択肢を調べながらモデルのパラメータを変更する。
サービス提供用のワークロードでは、安定した経路を慎重に最適化することが有効になり得る。研究ワークロードでは、変化への耐性も重要になる。アクセラレータは、ベンダーが特別に準備していない実験もサポートしなければならない。
購入者にとって、これは競争の別の見方を示す。重要な問いは、チームが利用可能な人員とインフラで、どれだけ有用な研究を完了できるかだ。ハードウェアのスループットは、セットアップの労力や問題診断に要する時間とともに、その成果に寄与する。
Amazonがこうした追加負担を減らせるなら、信頼できる機会を得る。Nvidiaは、自社の作業環境がチームの生産性を高める領域で優位を維持する。この競争は、ワークロード、ソフトウェア依存関係、そしてそれらを運用する人々の専門性によって異なる。
このような違いがあるため、広範な勝者宣言は時期尚早だ。同時に、この発表は重要でもある。AWSは、ハードウェアへの選好が定着する研究者の日常業務をめぐって競争している。
ネイティブPyTorchが実験の反復サイクルを変える
Amazonの挑戦を支える仕組みは、モデルコードの変更からその挙動の評価までの経路を短縮することにある。
AWSのネイティブPyTorchバックエンドは、PyTorchの標準的な拡張機構を使い、Trainiumをデバイスとして登録する。そのドキュメントは、開発者が呼び出した時点で演算を実行するイーガー実行と、取得した計算を実行前にソフトウェアが最適化するコンパイル実行について説明している。
これらのモードは、実験の異なる局面に対応する。対話的な実行は、アイデアがまだ固まっていない間に開発者が挙動を調べる助けとなる。計算が安定し、繰り返しの実行にさらなる最適化の価値が生じると、コンパイルが有力になる。
実務上の利点は、研究コードを手放さずに、これらの局面を行き来できることにある。研究者は変更を調べ、機能するかを確認し、その後に性能を検証できる。その一連の流れをサポートするバックエンドは、実験作業の実際の進行に適合する。
AWSのドキュメントはまた、使い慣れた実行環境であってもコンパイルコストがなくならない理由を説明している。これまで見られなかった演算形状では、初回の利用時にコンパイルが必要になる場合がある。キャッシュされた結果は後続の実行を支援できるが、最初の待ち時間は依然として研究者の体験の一部となる。
この詳細は、統合の物語を残る摩擦と結び付ける。インターフェースは親しみやすく感じられても、その下で馴染みのない停止時間が生じる可能性がある。開発者は、どれだけ反復時間を節約できるかを見積もる前に、両方の層を理解する必要がある。
この観点でTorchNeuronを説明すると、それは責任の分担を変えるものだ。より多くの適応作業がバックエンドに移り、研究者はより馴染みのあるコードを保持する。対応範囲や性能が不足する場所では、デバイス固有のエンジニアリングが依然として必要になる。
同じドキュメントは、実行モードごとのフォールバック動作も区別している。イーガーモードでは、サポートされていない演算子を、警告とともにコンピュータの汎用プロセッサであるCPUで実行できる。コンパイル時には、バックエンドが変換できない演算がコンパイル失敗につながる場合がある。
この違いは、成功した実行を評価する際に重要となる。完了しただけでは、意図した計算がアクセラレータ上にとどまったことを示せない。実験が動作することと、効率的に高速化されていることは別の発見である。
例としての研究グループでは、評価は実際に行う作業に沿って進めるべきだ。標準モデルはベースラインを確立する。意味のあるアーキテクチャ変更は、互換性が準備された経路を越えて広がるかを明らかにする。
次にそのグループは、科学的成果と、それを得るために必要な労力を比較できる。変更後の実験が正しく動作しても、大幅な修正を必要とするなら、インターフェース改善は約束の一部しか果たしていない。
Amazonのソフトウェア戦略は、この評価を試みやすくする。その長期的な価値は、研究者が加える雑多な変更をバックエンドがどれほど一貫して処理できるかにかかっている。ここに、ネイティブ統合とより広範なトレーニング事業とのつながりがある。
より利用しやすい出発点は、潜在的な利用者層を広げる。信頼できる実験の反復サイクルは、そうした利用者に継続する理由を与える。
品質管理は正確性と待ち時間の両方を対象にすべきだ
トレーニングソフトウェアは、結果を維持しつつ実験を実用的に繰り返せるようにすることで信頼を得る。
SemiAnalysisのTrainiumトレーニングテストでは、16基のTrainium2チップ上で、Qwen3-32Bのスループットがイーガーモードで毎秒11,099トークン、コンパイルモードで毎秒14,156トークンと報告された。トークンは言語モデルが処理するテキスト単位である。これらはワークロード固有の測定値であり、Nvidiaとの一般的な比較ではない。
同誌はまた、gpt-ossのトレーニングレシピで27分17秒のコンパイル待機時間を報告した。Trainium3でのFlexAttention評価では96件中89件に合格し、残るケースはコンパイル時間の制限を超過した。FlexAttentionは、アテンションの変種を定義するためのPyTorchインターフェースである。
これらの調査結果は、慎重な解釈を支持している。このスタックは実質的なトレーニング実験を実行できる一方、研究における使いやすさの観点では待機時間が依然として重要である。繰り返し実行が高速化しても、そこに到達するまでに要する時間がなくなるわけではない。
この違いは、短い実験で特に重要になる。アイデアを検証する研究者にとっては、最初の結果を得るまでにかかる時間の方が重要かもしれない。より長時間の実行では、準備コストをより多くの有用な計算に分散できる。
つまり、性能報告では準備、実行、正常完了を分けて扱うべきだ。それらを都合のよい単一の数値にまとめると、研究者がそのプラットフォームを使い続けるかどうかを左右する体験の要素が隠れてしまう可能性がある。
正確性にも別の要件が加わる。高速に動作しても、学習の仕方が異なるモデルについては、その速度が有用になる前に検証が必要だ。数値的一致性とは、選択した精度とテスト条件の下で、計算が十分に一貫した結果を生むか確認することを意味する。
AWSは、TorchNeuron testing methodologyにおいて大規模な自動テストを説明している。同社によれば、モデルスイープは簡略化した構成で100,000件のHugging Faceモデルを対象とし、実行、コンパイル、フォールバックの挙動を記録している。これらはベンダーが報告したカバレッジに関する主張である。
同じ説明では、8月に約154,000件のアップストリームテスト結果があり、そのうち約69,000件がスキップされたと報告している。一部のスキップはPyTorchの適格性ルールに従ったものであり、その他はNeuronのカバレッジ方針を反映したものだった。列挙された初期の除外対象には、スパース演算と動的形状が含まれていた。
継続的インテグレーション、すなわちソフトウェア変更の自動テストは、ここで重要である。バックエンドの改善が別の箇所でリグレッションを生む可能性があるためだ。有用なテストシステムは、研究者が高コストな実験中に問題を発見する前に、そのリグレッションを特定する。
テスト量だけでは信頼性を確立できない。読者は、何が実行され、何がスキップされ、テスト構成が自らのワークロードにどの程度近いのかを知る必要がある。広範なカタログスイープは、掲載されたすべてのモデルに対する完全なトレーニング検証の代わりにはならない。
最も強力な証拠は、透明性のあるカバレッジ報告と再現可能な外部結果を組み合わせたものだろう。AWSの開示は、その検証に使える材料を提供している。SemiAnalysisの経験は、好意的な発表文では見えにくい問題も含め、外部の視点を提供している。
Amazon Trainiumのトレーニングは、両方の側面で評価に値する。実験が正しく完了するか、そしてチームが過度の遅延なくそれを繰り返せるかである。一方の進展が、他方の弱点を覆い隠してはならない。
プロファイラはAmazonに新たな競争手段をもたらす
遅い実行をよりよく可視化できれば、最初の結果が期待外れでもアクセラレータの改善は容易になる。
Neuron ExplorerはAmazonのプロファイリングツールであり、エンジニアが性能を調査できるよう実行を記録するソフトウェアだ。AWSのhardware profiling toolsは、システムレベルの活動とデバイスレベルの活動を区別している。タイムライン、ソースコードへのリンク、依存関係情報、メモリビューを提供する。
これらの機能が扱うのは、互換性とは別の問題である。モデルが動作した後、開発者はなぜそれが待機するのかを判断する必要がある。遅いステップは、計算、データ移動、通信、あるいはアクセラレータの外部で実行される処理を反映している可能性がある。
総実行時間は症状を示す。有用なトレースは原因の特定を助ける。この違いにより、エンジニアが狙いを定めた変更を加えられるか、それとも繰り返し推測しながら調査しなければならないかが決まる。
たとえば、説明用のトレーニングジョブでは、計算を進める前にデータ移動を待つ時間が生じる場合がある。演算処理だけを改善しても、その依存関係は残る。明確なタイムラインは、実際に進行を制限している作業へとエンジニアの焦点を移すことができる。
これが、プロファイラの品質が競争分析に含まれる理由である。ハードウェア仕様は利用可能な能力を示す。診断ツールは、開発者がその能力を特定のモデルにとって有用な実行へ変えるのを助ける。
ネイティブ統合とのつながりも実用的だ。使い慣れたモデルコードは、最初の実行までの距離を縮める。明確なプロファイリングは、その実行から挙動の説明に至るまでの距離を縮める。
これらの改善は合わせて、トレーニングを取り巻くエンジニアリング作業に対処する。性能上の優位性を保証するものではない。しかし、優位性が存在するかどうかをチームが見極めやすくすることはできる。
「GPUでは不可能」という表現には慎重さが必要だ。SemiAnalysisは、Trainiumのきめ細かなプロファイリング体験に対する期待を表すためにこの表現を使っている。この表現を、Nvidiaハードウェアには計算ルーチン内部の活動を観測する手段が一切ないという主張にしてはならない。
Nvidiaは、アクセラレータ上で実行されるルーチンであるカーネル内部のイベントを記録する仕組みとして、in-kernel event tracingを文書化している。その存在により、擁護可能な比較は、特定のタスクにおける統合、可視性、開発者の労力へと絞られる。
それでも、これは意味のある比較である。2つのプラットフォームが関連する情報を提供していても、それを収集し解釈するために必要な作業量は異なり得る。重要なのは、エンジニアが実施しなければならない調査である。
したがって購入者は、実際に未解決の性能上の疑問を使ってプロファイラを評価すべきだ。魅力的なスクリーンショットだけでは、ツールがチームの疑問にどれほど効果的に答えられるかを示せない。実行可能な診断につながるトレースの方が、より強い証拠となる。
分析では、診断と修復の境界も維持すべきだ。ワークロードが停止する理由を知っても、ソフトウェアやハードウェアがその停止を解消できるとは限らない。可視性の向上は、不適切なプラットフォームを却下する判断も含め、意思決定を改善する。
Amazonの機会は、こうした判断をより速く、より十分な情報に基づいて行えるようにすることだ。それにより、すべてのワークロードで好ましい結果を出すことを求めずとも、同社のトレーニング提案を強化できる。
持続的なトレーニング代替手段を確立するもの
次の証拠では、反復時間、維持される互換性、対応済みデモを超えた採用状況を追跡すべきだ。
今後数カ月で最初のシグナルとなるのは、初回コンパイル待機時間の再現可能な短縮である。リリース発表は、同じモデルと意味のあるアーキテクチャ変更によって裏付けられるべきだ。そうでなければ、高速化した結果が異なる実験を反映している可能性がある。
重要な成果は、信頼できる結果に至る経路が短くなることだ。正確性と繰り返し実行が同程度に維持されながら準備が改善すれば、Amazonの研究向け提案は強化される。通常の変更にわたって待機が続くなら、ネイティブインターフェースは大きな負担を未解決のまま残している。
この評価には、新規実行と繰り返し実行の両方を含めるべきだ。研究者は、キャッシュされたコンパイル結果による利点と、未知のワークロードに役立つ改善を区別する必要がある。どちらも重要だが、日常的な使いやすさについて異なる問いに答える。
2つ目のシグナルは、ソフトウェア更新後も維持される互換性である。ローンチ時点でのインターフェース対応は出発点を示す。チームには、研究が変化する中でもモデル、その依存関係、デバイスバックエンドが連携して動作し続けることが必要だ。
新たに対応した演算、残る除外対象、リグレッションについて透明性のある報告に注目すべきだ。例外リストが縮小すれば、Amazonがより多くの適応作業を引き受けているという見方が強まる。ユーザーコードでの修復が繰り返されるなら、その見方は弱まる。
ここで、TorchNeuronをローンチのスローガンではなく開発戦略として説明することがより有用になる。その価値は、ユーザーが時間の経過とともにどれだけハードウェア固有の保守を回避できるかにかかっている。インターフェースは、その約束の始まりにすぎない。
3つ目のシグナルは、多様なトレーニングワークロードを実行するチームからの詳細な報告である。有用な報告では、何を移行したのか、何に調整が必要だったのか、何が既存インフラに残ったのかを説明すべきだ。また、通常のベンダーサポートと例外的なエンジニアリング支援も区別すべきである。
このような報告は、その体験が用意されたレシピを超えて広がるかどうかを読者が判断する助けになる。独立した再現は、その証拠をさらに強化する。限定的なデモの集まりだけでは、実用的な採用の広がりは不確かなままだろう。
影響は読者によって異なる。開発者は、自らの実際の実験に照らして評価できる別の環境を得る。エンタープライズの購入者は、移行作業と保守についてより正確な質問をする理由を得る。
AI製品のユーザーは、間接的な影響を見込むべきだ。より良いインフラ選択は、製品チームがエンジニアリング時間をどう配分し、モデル改善をどう進めるかに影響し得る。この発表自体は、ユーザーが利用するアプリケーションにおける特定の改善を確立するものではない。
移行を追うチームは、好ましい結果とともに、ベンチマーク設定、ソフトウェアバージョン、障害の説明を保存すべきだ。searchable knowledge baseは、次のバックエンドリリースで比較が変わった際にも、その証拠を利用可能な状態に保てる。
チームが理解している研究ワークロードから始め、コード変更から検証済みの結果までの完全な経路を評価しよう。準備時間、実行挙動、デバッグ作業、保守ニーズを記録する。比較は、繰り返す予定の作業に結び付けておく。Amazon Trainiumのトレーニングは現在、この評価に入るためのより親しみやすい経路を提供しており、パブリックベータによって残る差がより広い読者に見えるようになった。互換性に関する開示を性能結果と併せて読み、ソフトウェアの発展に応じて判断を見直そう。有用な問いは、チームが手持ちのリソースでより信頼できる実験を完了できるかどうかである。自らのワークロードに対してその成果を示すプラットフォームを選ぶべきだ。
