Skip to content
Published on

PyTorch 2.13のtorchcomms — c10dを置き換えにきた新しい分散通信バックエンド

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

はじめに — 2か月ごとに出るPyTorch、そして2.13

PyTorch 2.13.0が2026年7月8日にリリースされました。GitHubのリリース基準で今年のPyTorchは2.10(1月21日)、2.11(3月23日)、2.12(5月13日)、2.13(7月8日) — おおよそ2か月間隔で出ています。公式リリースブログによれば、2.13は2.12以降526人の貢献者による3,328件のコミットで構成されています。

ハイライトの一覧を見るだけでもリリースはかなり大きいです。FlexAttentionがApple Silicon(MPS)に載り(疎なパターンでSDPA比で最大およそ12倍 — 公式発表の数値)、InductorにTritonと並び立つCuTeDSLのコード生成経路が新しく付き、大語彙の言語モデル学習のピークメモリを最大4倍削減するというnn.LinearCrossEntropyLossが入りました。GPUカーネル生成レイヤーが多様化していく流れは、昨日扱ったTriton Gluonの話と同じ筋です。

ところが本稿で注目したいのは、その中で最も華やかでない項目です — torchcomms。リリースノートの表現では「PyTorch Distributedのための新しい通信バックエンドで、大規模クラスタ学習の耐障害性・拡張性・デバッグ可能性を改善する」ものです。単一の機能ではなく分散レイヤーの基盤の入れ替えが始まったという信号なので、いますぐ使わないとしても方向は知っておく価値があります。

c10d ProcessGroup — 何が問題だったのか

torch.distributedを使ったことがある人ならこのレイヤーを知っています。init_process_group()でグローバル状態を作り、dist.all_reduce()のようなグローバル関数を呼び、その下ではc10dのProcessGroup抽象がNCCL(あるいはGloo)を包む構造です。DDP、FSDP、パイプライン並列化まですべてこの上に立っています。

問題は、この抽象が設計された時点と、いまの要求との隔たりです。2.13リリースブログはこう要約します — ProcessGroupはそもそもNCCLを中心に設計されており、多次元並列化・弾力的(elastic)スケーリング・異機種インターコネクトによって分散学習が複雑になるにつれ、既存バックエンドのエラー処理と観測性の限界が運用チームのボトルネックになった、と。torchcommsの発表文はもっと直截です。既存のc10d APIは「相当な技術的負債(significant technical debt)」を抱えていて拡張も現代化も難しく、lazy initializationやP2P演算の限られた並行性のセマンティクスといった既存のアプローチが、NCCL系ライブラリの拡張性を制約していると明記します。

整理すると三つです。グローバル状態ベースのAPIなので通信レイヤーだけを切り離して実験しにくいこと、NCCL中心の設計なので他ベンダー・異機種ハードウェアが二等市民であること、そして数万GPU規模では初期化・障害処理・デバッグが手に負えなくなること。

torchcommsとは何か

torchcommsは、2025年10月22日にPyTorchブログで発表された、PyTorch Distributedと一緒に使うよう設計された実験的で軽量な通信APIです。リポジトリはmeta-pytorch/torchcommsで、BSD-3ライセンスです。発表文が挙げる目標は六つです。

  1. 通信プリミティブの高速プロトタイピング — 通信をPyTorchコアの数値プリミティブから分離し、既存機能を壊さずに新しいcollective・API・バックエンドを独立して実験できるように。out-of-treeバックエンドを一級で支援。
  2. 10万GPU以上へのスケーリング — lazy initの代わりにeager initialization(バックエンド資源をユーザーが明示的に管理)と、モデルごとのヒントでコミュニケータ・NVLinkバッファ・RoCE資源の割り当てを最適化。
  3. 異機種ハードウェア支援 — 一つの学習ジョブの中で複数のハードウェア世代・ベンダーを混ぜることを最初から設計目標に。
  4. 大規模での耐障害性 — torchftのような上位ライブラリを支えるfault-tolerantバックエンドの公開。発表文はfault-tolerant HSDPとStreaming DiLoCoを対象アルゴリズムとして言及。
  5. 片側(one-sided)通信 — RDMAスタイルのput/getを一級で支援。強化学習・チェックポインティング・非同期ワークフローが対象。
  6. デバイス中心のcollective — 通信メタデータとロジックをGPUに常駐させ、計算と通信を融合(IBGDAのようなGPU直接RDMAを含む)。

APIの設計はc10dと対比すると理解が速いです。グローバルなdist.*関数がなく、すべての演算がオブジェクト指向です。TorchCommオブジェクト一つがデバイス一つ・コミュニケータ一つに対応し、生成時点でデバイスを受け取って即座に(eagerly)初期化し、rankもグローバルなrankではなくコミュニケータ基準です。演算は発行順に実行され、同時実行が必要ならバッチAPIを使います。現在のREADMEの例を要約するとこんな形です。

import torch
from torchcomms import new_comm, ReduceOp

# torchrunが与える環境変数で即座に初期化。コミュニケータは単一デバイスにバインド。
comm = new_comm("ncclx", torch.device("cuda"), name="main_comm")

rank = comm.get_rank()          # グローバルなrankではなく、このコミュニケータのrank
world_size = comm.get_size()

tensor = torch.full((1024,), float(rank + 1), device="cuda")

# 同期all-reduce
comm.all_reduce(tensor, ReduceOp.SUM, async_op=False)

# 非同期all-reduce
work = comm.all_reduce(tensor, ReduceOp.SUM, async_op=True)
work.wait()

comm.finalize()

既存の並列化ライブラリとの接点はDeviceMeshです。torchcommsは自前のinit_device_meshでDeviceMeshを作ることができ、そのmeshをFSDP2のfully_shard(model, device_mesh=mesh)にそのまま渡せます。発表文はtorchtitanに統合してFSDP2・テンソル並列化との互換性と整合性を検証したと述べています(統合コードはtorchtitanのexperimentsの経路)。torchtitan自体が気になるなら、Torch-Titan完全ガイドで扱いました。

バックエンドはREADME基準でNCCL・NCCLX・Glooが既定で有効、AMD向けのRCCL・RCCLXとIntel XPU向けのXCCLはビルドオプションで有効化します。要件はPython 3.10以上、PyTorch 2.8以上で、安定チャネルのpipインストールはPyTorch 2.11以上とともにdownload.pytorch.orgのインデックスで案内されます。

NCCLXとCTran — 一緒に公開されたもの

発表においてtorchcommsと同じくらい重要なのがNCCLXのオープンソース化です。NCCLXはNCCLに対するMetaの拡張で、発表文の自己記述をそのまま移すと「10万GPU以上にスケールするために開発」し、「Llama 3やLlama 4のようなLLMの大規模な学習・推論に使われ、今日Metaのすべての生成AIサービスがNCCLXの上で動いている」といいます。列挙された機能は、拡張可能な初期化、zero-copyおよびSM-free通信、カスタムcollectiveアルゴリズム、ネットワークトラフィックのロードバランシング、片側通信、GPU常駐の低遅延collective、障害分析・位置特定(fault analyzer and localization)です。

その下にはCTran(Custom Transport)という転送スタックがあります。NVLink、IB/RoCE、TCPの転送を担い、collective・P2P・RMAのような通信セマンティクスをその上に構成する層です。NCCLXとCTranはどちらもtorchcommsと一緒に公開されました。

ここで正直に押さえておく部分 — 上の数値と使用履歴はすべてMeta自身の記述です。発表文には、NCCL比でのNCCLXのスループット・遅延を比較した公開ベンチマーク数値がありません。「10万GPU以上」は再現可能な測定ではなく内部の運用規模についての言明であり、どのワークロード・トポロジー条件なのかも公開されていません。Glooに新しいlazy initモードで「10万ワーカー以上にスケール」と述べる箇所も、同じく自己記述です。採用の判断に使える独立したベンチマークはまだない、と見るのが妥当です。

2.13で実際に入ったもの

発表は昨年10月でしたが、2.13はtorchcommsがPyTorch本体のリポジトリに物理的に反映され始めたリリースです。リリースノートで確認できる項目です。

  • 分散CIへの統合 — torchcommsがPyTorchのdistributed CIに追加されました(#181662)。コアが変わるときにtorchcommsの経路も一緒に検証されるという意味です。
  • c10dテストによるバックエンド検証 — TorchCommsバックエンドにc10dのテストスイートを回し、その過程で目的地でないrankのgatherのバグを修正(#178533)。リリースブログはこの統合を「既存のc10dバックエンドの現代的な代替でありつつAPI互換性を維持」と説明し、改善点として優雅なタイムアウトと部分グループの復旧、構造化ロギングとcollectiveのトレースを挙げます。
  • サブグループ生成経路の整理 — TorchCommsが有効なときnew_groupをsplit_groupにルーティングし、split_groupが支援できない引数は黙ってフォールバックする代わりに明示的にエラーを出します(#185416)。マルチバックエンドのプロセスグループでのsplit_groupの動作も修正されました(#182057)。
  • symmetric memoryのデカップリング — NCCLSymmetricMemoryのProcessGroupNCCLへの明示的な依存が取り除かれ、torchcommsのようなout-of-treeバックエンドでもsymmetric memoryを使えるようになりました(#184260)。
  • 公式ドキュメントへの編入 — torch.distributedのドキュメントにTorchCommsバックエンドのドキュメントが追加されました(#182711)。

そして個人的に最大の信号だと見る変更 — 公開collective APIの改名です。2.13でall_gather_into_tensorはall_gather_singleに、reduce_scatter_tensorはreduce_scatter_singleに名前が変わりました(#186123ほか)。リリースノートの理由説明が明示的です — torchcommsのTorchCommBackendが使うネーミングに公開のtorch.distributed APIを合わせるため。既存の名前は薄いラッパーとして動き続けますがFutureWarningを出します。torchcommsがc10dに合わせるのではなく、c10dがtorchcommsに合わせて動いているということ — 方向はこれ以上に明確になりようがありません。

同じリリースでFSDP2が、reduce-scatterに専用のNCCLコミュニケータを与えるオプトインAPI(set_separate_reduce_scatter_group、#186335)を得てall-gatherとの通信の重ね合わせが可能になったことも、通信レイヤーをより柔軟に切り分けるという同じ流れの上にあります。

正直なトレードオフ — いま乗り換える物ではない

ここでブレーキを踏む番です。

APIが不安定です。 リリースブログのtorchcomms項目にはAPI Unstableの表示が付いており、発表文自身が「APIはまだ初期であり、成熟する過程で破壊的変更を被る可能性がある」と釘を刺します。空言ではありません — 2025年10月の発表ブログのサンプルコードはcomm.allreduce(...)ですが、2026年7月現在のREADMEの例はcomm.all_reduce(...)です。9か月の間に公式サンプルのメソッド表記が変わったほどの段階だという意味です。いまこのAPIの上にプロダクションコードを積み上げれば、リリースのたびに追いかけて直す覚悟をしなければなりません。

大半のユーザーには当面の利得がありません。 単一ノードの数枚、あるいは数十〜数百GPUでDDP・FSDP2がうまく回っているなら、torchcommsで得られるものは現状ありません。eager initと資源ヒントが解こうとする問題(数万GPUの初期化、コミュニケータの資源管理)は、その規模でだけ痛みます。発表文の移行の約束も正確にその点を突きます — c10dバックエンドインターフェースの廃止は段階的に、最小限の中断で進められ、「大半のユーザーとモデルはいまのまま動き続ける」だろう、と。裏返して読めば、一般ユーザーは待つのが公式の推奨経路だという意味です。

独立した検証がありません。 上で押さえたとおりNCCLXのスケールの主張はMeta自身の記述であり、公開された比較ベンチマークがありません。性能を根拠に採用するには、根拠そのものがまだありません。

では誰がいま見るべきか。通信プリミティブを研究する人(新しいcollective・バックエンドをout-of-treeで実験)、自前の通信スタックを持つハードウェアベンダー、torchft系の耐障害性学習を大規模に回すチーム、片側通信が必要な非同期ワークロード(RL、チェックポインティング)を扱う人 — この程度が発表文の明示する対象であり、実際にそのとおりです。分散学習スタック全般の地形が気になるなら、分散学習フレームワークのディープダイブを参照してください。

で、今日やること

実務者の基準で整理するとこうです。

  1. 2.13に上げるならFutureWarningの整理から。 all_gather_into_tensor・reduce_scatter_tensorの呼び出し箇所が警告を出し始めます。動作はそのままですが(薄いラッパー)、新しく書くコードはall_gather_single・reduce_scatter_singleへ行くのが正しいです。どのみちその方向に収束します。
  2. マイグレーション計画はまだ立てないでください。 c10dの上のDDP/FSDP2のコードはそのままで構いません。移行はコアチームが下で入れ替える方式で進むというのが公式の立場です。
  3. 大規模クラスタを運用しているならリポジトリを注視してください。 meta-pytorch/torchcommsとtorchtitanのexperimentsの統合が観戦ポイントで、耐障害性・片側通信・デバイス中心のcollectiveがロードマップの次の段階です。

おわりに

torch.distributedの下回りは、2.xの時代を通じて事実上同じ構造でした。torchcommsはその下回りを丸ごと入れ替えるという宣言であり、PyTorch 2.13は、その宣言がコアのリポジトリにCI・テスト・ドキュメント・公開APIのネーミングという形で反映され始めた最初のリリースです。今日あなたがやることはマイグレーションではなく方向の認知です — そしてアップグレードしながら出会うFutureWarningの数行を直すこと。基盤の入れ替えは、こうして、警告の数行から始まります。

参考資料

Discuss on Twitter • View on GitHub