Red Hat と Hugging Face、ベンガルールで PyTorch の次世代 ML システム構築イベント開催

TL;DR

ベンガルールで開催された技術イベントには、170 名以上の学生、エンジニア、研究者、オープンソース貢献者が集まりました。Red Hat と Hugging Face が共催したこの夜は、PyTorch、大規模推論、強化学習環境、分散学習、そして次世代の通信プリミティブについて議論する場となりました。Hugging Face から 3 名、Red Hat の PyTorch エンジニアリングチームから 2 名のスピーカーが登壇し、これは単なる一般的な AI ミートアップではなく、オープンな ML スタックの未来を形作るインフラストラクチャ、抽象化、システム設計に焦点を当てた実践的なセッションでした。

最も印象的だったのは、発表内容の技術的多様性だけでなく、その背後にある共通の確信です。AI や ML システムを活用する人材はインドに不足していません。今こそ重要な機会が訪れています。つまり、より多くの学生や実務家が、これらのシステムの構築者や維持者へと成長できるよう支援することです。彼らは、プロファイラ、ランタイム、学習の抽象化、強化学習ツール、カーネル、そして分散通信層など、エコシステム全体を支える基盤を設計する人々です。

イベントのトーンを設定：AI ユーザーから AI インフラストラクチャ構築者へ

スディール・ダルラナイヤー氏がこの夜の基調講演で、会場全体に響くような課題提起を行いました。インドは単なる大規模な AI や ML テクノロジーの消費市場として留まるべきではない、と彼は訴えました。同国にはすでに優秀な人材がおり、研究への情熱もエンジニアリングの成熟度も備えています。今後は、コアとなるソフトウェアスタック自体に真摯に貢献できる存在へと成長する時なのです。

この視点の転換が重要でした。イベントは単なる製品デモから、システム全体の思考へとシフトしたのです。議論の焦点は、API を呼び出す方法やモデルを微調整する技術だけでなく、背後にある仕組みそのものにありました。推論を効率的にする要素とは何か、大規模な強化学習を訓練可能にする条件は何か、分散学習を壊れにくく組み合わせ可能なものにするにはどうすればよいか、そしてクラスターがより大規模で多様化する中で通信ライブラリに何が必要か——そうした問いが投げかけられました。

会場には学生やキャリア初期のエンジニア、スタートアップチームのメンバーもいました。彼らにとってこれは重要なシグナルです。AI における次のイノベーションは、モデルを消費する人々だけのものにはなりません。コンパイラーパスの改善、カーネルライブラリの強化、サービングエンジンの開発、報酬フレームワークの構築、そして現代の機械学習を実環境で運用可能にする分散システムの向上に取り組む人々こそが、その主導権を握るのです。

PyTorch でのプロファイリング：パフォーマンスの可視化

Hugging Face の Aritra Roy Gosthipaty 氏が、技術プログラムの基盤となる実践的なトークで「プロファイルできないものは最適化できない」というシンプルながら確固たる原則に基づいた PyTorch のプロファイリングについて解説しました。

パフォーマンスを曖昧な結果として扱うのではなく、このセッションではプロファイリングを反復可能なワークフローとして分解しました。Aritra氏は、torch.profiler.record_function を用いて関心のある領域に注釈をつけ、torch.profiler.profile で実行をラップし、スケジュールを使って待機、ウォームアップ、アクティブな収集の各フェーズを分離する方法を実演しました。その後、トレースのエクスポート方法や集計テーブルの生成、そして CPU オーバーヘッドと実際の GPU 処理を見分けるための読み解き方まで、順を追って解説されました。

特に有益だったのが「オーバーヘッドバウンド」という概念です。小規模なワークロードでは、GPU アクセラレーションが期待通りに機能していないように錯覚しがちですが、実際には CPU 側の起動やオーケストレーションのコストが実行時間を支配しているケースが多々あります。ワークロードをスケールアップし、実際に CUDA カーネルに費やされる時間の割合を比較することで、このセッションは実務者が苦労して学ぶ教訓を示しました。「すべての遅延がモデルの問題ではない」こと、「すべての最適化がモデルコードから始まるわけではない」という事実です。

実際のシステム構築やデバッグに取り組んでいる聴衆にとって、これは非常に強力な出発点となりました。プロファイリングの有無が、体系的な最適化と根拠のない試行錯誤を分ける鍵になるのです。

スライドは こちら で、さらに詳しい資料も こちら からご覧いただけます。

SGLang、Transformers、カーネル：推論の新たな形

バングロールで開催された Hugging Face のトークでは、Adarsh 氏が SGLang を軸に、Transformers バックエンドと新興のカーネルエコシステムを介した現代の LLM インフラについて解説しました。核心となるメッセージはシンプルかつタイムリーなものでした。「単一ユーザー向けのデモは容易ですが、数千もの同時リクエストを効率的に捌くことが、本格的なシステム設計の始まりです」。

このトークでは、大規模言語モデルにおける推論が構造的に困難である理由を解き明かしました。プリフィル（Prefill）は計算集約的で並列処理が可能ですが、デコード（Decode）は逐次的であり、メモリ制約が強く、KV キャッシュとの繰り返しやり取りによるコストが支配的となります。こうした現実を踏まえ、セッションでは SGLang を高性能な推論サービングフレームワークとして紹介しました。その設計思想の根幹には、まさにこの推論特性への対応があります。

発表で特に注目された概念の一つに「RadixAttention」があります。SGLang はリクエスト完了後に KV キャッシュ状態を破棄するのではなく、LRU（Least Recently Used）動作を持つラジックスツリーベースのキャッシュに、過去に見たプレフィックスを保持し続けます。この設計は、共有プロンプトや繰り返し出現するプレフィックス、あるいは高頻度の同時リクエストが発生するワークロードにおいて特に有効です。ユーザートラフィック内の構造的な重複を、システム上の明確な優位性へと転換できるからです。

この講演では、Hugging Face Transformers と SGLang などの推論エンジン間の生産的な役割分担も強調されました。Transformers はモデル定義、設定の解析、トークナイザー、テンプレート、重みフォーマットの「真実の源」として機能します。一方、SGLang はその基盤の上にスケジューリング、連続バッチ処理、アテンションバックエンド、そしてスケーラブルな推論動作といった高速化経路を構築します。実務的には、これにより Hub にある多数のモデルを手動で個別のランタイムへ移植する必要なく、それらを推論サービスとして提供できるハードルが下がります。

最後のセクションでは Hugging Face Kernels について議論が広げられました。カスタム演算子やアクセラレータ固有のカーネルが ML パフォーマンスにおいてより中心的な役割を果たすようになる中、ビルドの断片化が現実的な課題となっています。異なるツールチェーン、バックエンドの組み合わせ、互換性の制約などが原因で、カーネル開発の共有が本来あるべきほど容易ではない状況が生じています。Kernels 取り組みは、再現性のあるビルド、クリーンなパッケージング、PyTorch とのより良い互換性、そしてコミュニティによる簡単な配布を実現する道筋を示しました。

これらのアイデアを合わせると、推論が単一の巨大なスタックとしてではなく、モデル定義、推論ランタイム、コンパイラに優しい実行経路、再利用可能なカーネルインフラストラクチャという層ごとの協働によって進化している様子が浮かび上がります。スライドはここから確認できます。

RL Environments 101: Why the Next Scaling Axis Is the Environment

Adithya S Kolavi 氏の RL エンバイロメントに関するセッションは、ポストトレーニングのストーリーに焦点を当てました。講演では、事前学習から教師あり微調整、RLHF を経て、現在ではプログラムによる検証可能な報酬が最先端モデルの改善において中心的な役割を果たすに至るまでの、よく知られた流れを追跡しました。

この講演の重要な洞察は、「タスクがプログラムによって採点可能であれば、それはモデルが学習できる環境となり得る」という点です。この転換は一見抽象的に聞こえますが、プレゼンテーションを通じて具体的なイメージとして提示されました。RL エンバイロメントとはブラックボックスではなく、タスク、状態、ツール、観測、報酬ロジック、実行バックエンド、エピソード制御といった構造化された組み合わせとして説明されました。つまり、環境とはモデルが何を試せるか、何を観察できるか、そして成功をどう測定するかを決定するトレーニングの基盤なのです。

この枠組みは、LLM における強化学習がなぜ強力であると同時に困難なのかを理解する助けとなります。古典的な RL エンバイロメントは、制御問題のための相互作用を何年も前に標準化しましたが、エージェント型 LLM のトレーニングではさらに多くの要素が絡み合います。モデルにはツール、サンドボックス、データセット、プロンプト、検証器、そして多段階の状態が必要になる可能性があります。この複雑さを標準化できるかが、単発の実験とスケーラブルなトレーニングインフラを分ける鍵となります。

ここで OpenEnv が議論の中心となりました。LLM の環境に対する共通の形状として提示された OpenEnv は、Gym スタイルの API の精神をポストトレーニング時代へと拡張するものです。この発表では、環境が MCP を通じてツールを公開し、タスクを提供し、報酬評価基準を直接埋め込み、さらに TRL などのトレーニングライブラリに比較的少ない結合コードで接続できる仕組みについて解説されました。これは重要であり、環境構築という場当たり的なエンジニアリング作業を、コンポーザブルで共有可能なものへと変えるからです。

発表の後半では、エコシステムへの影響についても言及されました。より良い環境がより優れたモデルにつながるのであれば、高品質な環境を多数生成することが戦略的優位性となるのです。特にコーディングタスクは、検証可能かつ決定論的であり、経済的価値も高いことから非常に魅力的です。これにより、リポジトリ、テスト、イシュー、実行サンドボックスなどがトレーニング用の問題の豊富な源泉となります。Repo2RLEnv の導入はまさにこの方向性を捉えたものであり、公開リポジトリをスケーラブルで検証可能な RL 環境へと変換するものです。

これは夜中最も活気ある発表の一つでした。学生や実務家にとって、貢献できる具体的なフロンティアが示されたからです。誰もが基盤モデルを構築するわけではありませんが、多くの人がモデル改善を実世界に根ざしたものとするための環境、検証器、ツール、ベンチマークの作成に携わることができます。スライドはここから確認できます。

次元ごとにスケールアップする

Red Hat の PyTorch エンジニアリングチームに所属する Mansi Agarwal 氏は、DeviceMesh、DTensor、FSDP2 に関する講演を通じて、現代の分散トレーニングの核心へと聴衆を導きました。

この講演では、大規模な学習ジョブに取り組んだ経験がある人なら誰もが共感できる課題が最初に指摘されました。異なる並列化形式を組み合わせた際、これまで手動での配管作業（plumbing）が多すぎたという点です。データ並列化、テンソル並列化、パイプライン並列化はそれぞれ個別の API やグループ管理、そして独自の障害モードを伴うことが多くありました。トレーニングスタックを 1 つの次元から 2 つや 3 つの次元へ拡張しようとすると、システムを単純にスケールするのではなく、周囲のロジックを書き換える必要が生じるのが常でした。

Mansi が主張した新しい PyTorch の抽象化が持つ最大の約束は「組み合わせやすさ（composability）」です。DeviceMesh を使えば、エンジニアはクラスターを n 次元トポロジーとして記述できます。DTensor は、そのトポロジー上でテンソルがどのように分散されているかを認識可能にします。そして FSDP2 は、これらの基本要素の上にシャードされたデータ並列化を再構築し、シャディングをモデルの使いやすさを損なう特別なラッパーではなく、インプレース変換として実現します。

これは、開発者体験とランタイムの挙動の両方に大きな影響を与える出来事です。プロセスグループを手作業で構築し、モデルコードにカスタム通信を注入する代わりに、エンジニアはメッシュ次元や配置ルールという視点で考えられるようになります。テンソル並列化、パイプライン並列化、コンテキスト並列化を追加することは、訓練スタックをゼロから書き直すことではなく、グリッドを拡張するような感覚になります。

セッションではトレードオフについても隠し立てしていませんでした。DTensor のイーグルモードにおけるオーバーヘッド、不完全なオペレータカバレッジ、そして貪欲なシャードリング伝播の限界は、確かに存在する制約です。しかし、こうした率直な指摘が全体のメッセージを強めています。分散学習におけるコンポーザビリティ（組み合わせ可能性）はもはや研究上の夢やフレームワークのマーケティング用語ではありません。それは PyTorch において実用的な設計方向性へと変わりつつあり、モデルサイズとハードウェアトポロジーがさらに拡大するにつれて、その重要性は増していくでしょう。

多くの参加者にとって、この講演は日常のモデル利用では遭遇しないレベルのシステム設計を垣間見る機会となりました。しかし、コアスタックへの貢献を選ぶのであれば、必ず直面することになる内容です。スライドはこちらで見られます。

ゼロコピー GPU から GPU への通信を PyTorch で実現する

アーカディップ・マイトラが、大規模学習を支える通信基盤にまで議論を下げて、PyTorch におけるゼロコピー GPU から GPU への通信について深掘りするトークで夕べを締めくくりました。

登壇では、PyTorch のデフォルト分散通信レイヤーである c10d と、なぜ長年にわたりエコシステムを支えてきたのかについて語られました。これは CPU と GPU のバックエンドにまたがる汎用的な抽象化を提供し、大半の分散ワークロードがバルク同期型で集合操作中心、かつ規模も比較的小さかった当時の時代背景に合致していました。

しかし、通信に関する前提条件は変わりつつあります。ネットワークインターフェースが進化し、GPUDirect RDMA が成熟し、NVLink の経路が強化され、トレーニング用ファブリックはトポロジをより意識した専用なものへと進化しています。クラスター規模や通信パターンが変化する中で、中間コピーのコストやスレッドオーバーヘッドが目に見えるようになってきました。

だからこそ、登壇で議論されたゼロコピーパスが重要なのです。不要なコピーステップを回避することで、PyTorch はスレッドブロックの使用量を減らし、実際のトレーニングやサービスシステムにおいて重要なメッセージサイズ領域において、意味のある通信速度向上を実現できます。発表で報告された成果、つまりコピーコストの削減や中規模メッセージ通信の高速化は、より大きなテーマを示唆しています。ML システムのスケーリングとは、もはやトレーニングループの下にある見えない層から非効率を削ぎ落とすこと increasingly 重要になっているのです。

これは、その夜の繰り返される教訓を再確認するにふさわしい締めくくりとなりました。つまり、高レベルなモデルの性能は、多くのユーザーが目にすることのない低レベルなエンジニアリングの選択に大きく依存しているという事実です。こうしたレイヤーについて実践家たちがより深く理解できるよう支援することは、エコシステムが成熟するための重要な一歩です。

なぜこの協力が重要なのか

今回のイベントの独自性は、Red Hat と Hugging Face の両社からスピーカーが登壇したことにだけあるわけではありません。重要なのは、両社の連携によって技術スタック全体の一貫した視点が浮き彫りになった点です。

Hugging Face は、プロファイリング、推論インフラストラクチャ、強化学習（RL）によるポストトレーニングのワークフローに関する知見を提供しました。一方、Red Hat の PyTorch エンジニアリングチームは、分散学習の内部構造や通信プリミティブについての洞察を共有しました。これらを組み合わせることで、一貫したストーリーが生まれました。システムを適切に測定し、モデルを効率的に提供し、堅牢な学習環境を構築し、構成要素ごとに学習を拡張し、そのすべてを支える通信基盤の改善を継続する——そんな流れです。

インドの学生や AI 実践家にとって、こうした生態系全体を捉える視点は極めて貴重です。それは「AI を使う」ことと「AI システムに貢献する」ことの間の距離を短縮します。オープンソースへの貢献は、モデルの公開やアプリケーションのデモに限られたものではないことを示しています。プロファイラー、カーネル、ランタイムバックエンド、報酬インフラストラクチャ、チェックポイント処理、シャーディングのセマンティクス、分散通信ライブラリなどにおいて、意味のある取り組みが可能です。まさにこうした活動こそが、実践者を単に熱意を持って関与させ、最先端を維持させるだけでなく、次世代を形作るために貢献するよう動機づけるのです。

インドがどのようにして AI の未来により深く参画できるかを問う声が高まる中、今回のイベントは確かな回答を示しました。コアとなるレイヤーを構築するコミュニティに参加し、技術的な協力を、学生の好奇心から本格的なオープンソースの管理へとつなぐパイプラインを広げる手段として捉えることこそが、その道筋です。

今後の展望

170 名以上の参加者を集めた今回のイベントで明らかになったのは、インドには技術的に厳密でシステム指向の ML コミュニティイベントに対する明確な需要があるということです。会場の雰囲気から感じられるエネルギーは、学生が単なる導入説明を求めているのではなく、実践者が表面的なベストプラクティス以上のものを望んでおり、モデルの挙動とそれを支えるインフラストラクチャをつなぐ対話が生態系全体で求められていることを示唆しています。

今回のイベントをきっかけに、Red Hat と Hugging Face、そして広範な PyTorch コミュニティとの連携が、単なる良好なミートアップの開催にとどまらないことが示されました。彼らは、オープンな ML スタックそのものを中心とした貢献文化を地域に根付かせる役割を果たします。そこでは、次世代のイノベーターたちが既存のツールをただ受け入れるだけでなく、誰もが利用できるよう設計・維持・改善する主体として参画していくのです。