PyTorch 2.12 リリースのハイライト（7 分読了）

** ## Featured projects - PyTorch® 2.12 のリリースを発表できることを嬉しく思います ([release notes](https://github.com/pytorch/pytorch/releases/tag/v2.12.0))！ PyTorch 2.12 リリースには、以下の主要な変更が含まれています： - CUDA におけるバッチ処理された linalg.eigh が、更新された cuSolver バックエンドの選択により最大で 100 倍高速化されました - 新しい torch.accelerator.Graph API は、CUDA、XPU、およびアウトオブツリーバックエンド間でグラフキャプチャとリプレイを統一しました - torch.export.save は now Microscaling (MX) 量子化フォーマットをサポートし、積極的な圧縮モデルの完全なエクスポートを可能にしました - Adagrad が now fused=True をサポートし、Adam、AdamW、SGD とともに単一カーネル最適化実装に参加しました - torch.cond コントロールフローは、CUDA Graphs 内でキャプチャおよびリプレイできるようになりました - ROCm ユーザーは、拡張可能なメモリセグメント、rocSHMEM 対称メモリ集合体、FlexAttention パイプラインングの恩恵を受けます 今回のリリースには、PyTorch 2.11 から 457 名の貢献者による 2,926 のコミットが含まれています。私たちの献身的なコミュニティの皆様に心から感謝申し上げます。いつも通り、これらの新機能をお試しいただき、2.12 の改善に向けて問題点を報告していただくことをお勧めします。PyTorch 2 シリーズの始め方に関する詳細は、[Getting Started](https://pytorch.org/get-started/pytorch-2-x/) ページをご覧ください。 ご質問はありますか？5 月 20 日（水）午前 10 時（太平洋標準時）に、パネルディスカッショナーの Joe Spisak 氏、Andrey Talman 氏、Alban Desmaison 氏と司会者の Chris Gottbrath 氏によるライブ Q&A にご参加ください。リリースの概要を簡単に説明し、皆様のご質問にお答えします。[今すぐ登録する](https://pytorch.org/event/pytorch-2-12-release-live-qa/) 2.x シリーズを通じて、PyTorch は研究ファーストのフレームワークから、大規模な生産環境でのトレーニングと推論のための統一されたハードウェア非依存プラットフォームへと進化を遂げてきました。[PyTorch 2.10](https://pytorch.org/blog/pytorch-2-10-release-blog/) では、クロスバックエンドのパフォーマンスプリミティブと TorchScript の正式な非推奨化により基盤を整えました。[PyTorch 2.11](https://pytorch.org/blog/pytorch-2-11-release-blog/) では、分散トレーニングのための微分可能なコレクティブ（collectives）、次世代 GPU 向けの FlashAttention-4、そしてより広範なエクスポート対応により、その基盤を拡張しました。 PyTorch 2.12 はこの方向性を継続します：新しいデバイス非依存の torch.accelerator.Graph API が、CUDA、XPU、およびアウトオブツリーバックエンド間でグラフキャプチャとリプレイを統一し、バッチ処理された固有値分解（eigendecomposition）は最大で 100 倍高速化され、torch.export では、 aggressively compressed models を展開するためのマイクロスケーリング量子化形式（Microscaling quantization formats）がサポートされます。これらのリリースを通じて、PyTorch はバックエンド間でより高速になり、AI イノベーションを可能にし続ける中で、利用可能なプラットフォームの幅も広がっています。 ## パフォーマンス機能 CUDA におけるバッチ処理された固有値分解（linalg.eigh）が最大で 100 倍高速化** CUDA における linalg.eigh のバックエンド選択が大幅に改修されました。従来の MAGMA バックエンドは廃止され、cuSolver に置き換えられました（Grayson Derossi による PR #174619）。また、Johannes Z による PR #175403 で、cuSolver のディスパッチヒューリスティックが更新され、syevj_batched が無条件で使用されるようになりました。バッチ化された対称/エルミート固有値問題において、これは前バージョンと比較して最大 100 倍の高速化を実現し、CuPy との間で長年存在していた性能格差を解消しました。** 以前は PyTorch が各行列求解を非効率的に個別にディスパッチしていたため数分かかっていたワークロードも、cuSolver の syevj_batched カーネル（多数の小型・中型行列を単一の GPU 操作として処理するように設計されたもの）を使用することで、秒単位で実行可能になりました。これらの性能向上は、バッチ化された行列の固有値分解に依存する科学計算や機械学習のワークロードにおいて特に重要です。（ドキュメント内の使用例：[example usage in the doc](https://docs.pytorch.org/docs/2.11/generated/torch.linalg.eigh.html)） 融合型 Adagrad オプティマイザ ** Adagrad オプティマイザは now fused=True をサポートするようになりました。これにより、各操作ごとに別々のカーネルを起動するのではなく、オプティマイザのステップ全体が単一の CUDA カーネル内で実行されます。これによってカーネル起動のオーバーヘッドとメモリアクセス量が削減されました。Adagrad は、Adam、AdamW、SGD に続き、融合型バリアントを提供するようになりました。基盤となる CUDA カーネルは @MeetThePatel 氏により 2.11 サイクル中に貢献され（PR #159008）、Python フロントエンドがユーザーに公開される形での実装は Jane Xu 氏によって 2.12 で完成されました（PR #177672）。 ## ハードウェア間でのコンパイルとエクスポート **torch.accelerator.Graph: デバイス非依存アクセラレーターグラフキャプチャおよびストリーム API** `torch.accelerator.Graph` は、`torch.xpu.XPUGraph` などのバックエンド固有の実装に対する統一された抽象化を提供する、グラフキャプチャとリプレイのための新しいデバイス非依存 API です。各バックエンドは、軽量な GraphImplInterface を通じて独自の実装を登録することができ、バックエンドの自律性を維持しつつ、一貫したユーザー向け API を実現します。 これに伴い、`c10::Stream` および `torch.Stream` は now `is_capturing()` メソッドを公開するようになり、デバイス固有の `is_current_stream_capturing` に代わり、バックエンド非依存な代替手段を提供しています。ストリームコンテキストマネージャーの再入問題も修正されました。これらの変更により、ストリームおよびグラフ管理におけるクロスバックエンド間の整合性が実現され、XPU バックエンドに対する初期サポートが提供されるとともに、`PrivateUse1` を介してアウトオブツリー（外部）バックエンドへの拡張性も確保されています。 Guangye Yu 氏 (Intel) によって 6 つの PR にわたって貢献され、C++ インターフェース (PR #171269) と Python フロントエンド (PR #171285) を基盤としています。([ドキュストリング内の使用例](https://github.com/pytorch/pytorch/blob/1d803512199040e98738e95d0dc074acbde9fb5c/torch/accelerator/graphs.py#L11-L48)) **torch.export がマイクロスケーリング (MX) 量子化フォーマットをサポートするようになりました** モデルが研究から本番環境へ移行する際、torch.export は PyTorch モデルをデプロイ用にシリアライズするための標準的なパスです。しかし、Microscaling (MX) 量子化を使用するモデルは、これまでエクスポートできませんでした。これは、MX フォーマット（MXFP4, MXFP6, MXFP8）で共有ブロックスケール指数として使用される float8_e8m0fnu データ型を torch.export.save が処理していなかったためです。 PyTorch 2.12 では、torch.export.save と torch.export.load がこのデータ型を持つテンソルのシリアライズとデシリアライズを正しく行うようになり、Microscaling 量子化を活用するモデルの完全なエクスポートからデプロイまでのワークフローが阻害されなくなりました。これは、大規模言語モデルをコスト制約のある環境やエッジ環境にデプロイするチームにとって特に重要です。そこでは積極的な量子化が不可欠です。ARM の Chizkiyahu Raful 氏による寄稿 (PR #176270)。 **CUDA Graph 内での torch.cond を用いた制御フローのキャプチャ** torch.cond を使用した制御フロー領域を、CUDA Graphs の一部としてキャプチャして再生できるようになりました。以前はデータ依存型の制御フローにより分岐が CPU で評価されるため、CUDA グラフツリーへのフォールバックを余儀なくされていました。CUDA 12.4 の条件付き IF ノードを活用することで、torch.cond の分岐は単一のグラフキャプチャ内で完全に GPU 上で評価されるようになりました。** これは、Daniel Galvez と Ting-Yang Kuei（NVIDIA）によって貢献されたものであり（PR #168912）、Paul Zhang（Meta）によって Inductor の順序付けサポートが追加されました（PR #179457）。現在、この機能は eager および cudagraphs バックエンドで動作しますが、Inductor への対応は今後のリリースを予定しています。 XPU 向けの FMA ベースの addcdiv 低減化 Inductor は now、addcdiv 演算に対して融合乗算加算（FMA: fused multiply-add）命令を使用し、Triton カーネル融合の利点を維持しながら、eager CUDA 実行とビット単位の数値整合性を達成しています。 addcdiv は、Adam、AdamW、RMSprop など多くのオプティマイザ更新ルールの核心に位置する融合演算（結果 = input + value × (tensor1 / tensor2)）です。以前は、Inductor の低減化が個別の乗算および除算命令を使用していたため、eager モードと比較して小さな浮動小数点丸め誤差が生じていました。これらの違いは数千回のトレーニングステップにわたって蓄積し、コンパイルされたモデルが数値的に同一の結果を生成していることを検証することが困難になっていました。 これはまず Michael Lazos（Meta）によって CUDA 向けに実装され（PR #174912）、その後 Guangye Yu（Intel）によって XPU へ拡張されました（PR #176163）。これにより、Intel GPU 上のいくつかの数値的正しさの問題が修正されました。オプティマイザを多用するトレーニングループで torch.compile を使用するユーザーは、NVIDIA および Intel のハードウェアの両方で、数値的な再現性を犠牲にすることなくコンパイルされたパフォーマンスを得ることができます。 ## 分散トレーニング **カスタム演算における ProcessGroup サポート** カスタム演算子は、呼び出し側がグローバルレジストリで文字列グループ名に変換して検索する必要がある代わりに、ProcessGroup オブジェクトを直接引数として受け取れるようになりました。すべての c10d 機能的集合演算 (all_reduce, reduce_scatter など) は、ProcessGroup オブジェクトを直接受け取ることも、文字列名を受け取ることもできるよう更新されました。Aaron Orenstein (Meta) による寄稿 (PR #172795)。 **マルチ GPU/マルチノードプロファイリングの改善** PyTorch Profiler Events API は now、フロー ID、フロータイプ、アクティビティタイプ、未完了イベント、Python 関数イベントを公開するようになりました。これにより events() が Chrome trace JSON 出力と同等になり、より豊富なプログラムによる事後分析が可能になります。さらに、新しい seq_num フィールドを使用して、ランク間の NCCL 集合トレースを相関させることが可能になりました。同じ集合に参加するすべてのランクは、プロセスグループ内で同じシーケンス番号を共有します。これらの変更により、複数の GPU およびノードにわたる分散トレーニングのパフォーマンスデバッグのためのツールが大幅に改善されました。API の拡張は Ryan Zhang (Meta) によるもの (PR #177888)、NCCL seq_num の追加は Marvin Dsouza (Meta) によるものです (PR #177148)。 **FlightRecorder: ncclx + gloo バックエンド** FlightRecorder のトレース解析機能は、既存の nccl および xccl バックエンドに加え、ncclx と gloo バックエンドもサポートするようになりました。これにより、より広範な集合通信バックエンドにわたる分散通信のトレーシングが可能になります。さらに、FlightRecorder は以前は追跡されていなかった torchcomms 操作（例：all_gather_single, reduce_scatter_v, barrier）も認識できるようになりました。また、複数のプロセスグループが同時に FlightRecorder のシングルトンにアクセスした際に無限ループを引き起こす可能性があった競合状態の問題も、今回のサイクルで修正されました。バックエンドの許可リスト追加は Lily Janjigian (Meta) 氏によるもの（PR #180268）、torchcomms 操作サポートは Tushar Jain 氏によるものです（PR #178359）。 ## プラットフォーム関連アップデート ## CUDA **CUDA Graph カーネル注釈** torch.cuda.graph は now、enable_annotations という kwarg を受け付けるようになりました。これにより、キャプチャされた CUDA グラフ内の個々のカーネルに注釈メタデータ（例：集合演算の名前、プロセスグループ、メッセージサイズなど）が注入されます。コンパニオンポストプロセッシングスクリプト（python -m torch.cuda._annotate_cuda_graph_trace）でトレーサーを後処理した後、これらの注釈はトレースにマージされます。これらの注釈は Perfetto/Chrome プロファイラーのトレースに表示され、再生されたグラフ内の各カーネルが何を行っているかを理解することが大幅に容易になります。Shangdi Yu (Meta) 氏による寄稿（PR #179768）。 **CUDA Green コンテキストワークキュー制限** CUDA Green Contexts で、ワークキューの制限を指定できるようになり、GPU リソースの分割に対するより細かな制御が可能になりました。この実験的機能により、ユーザーはグリーンコンテキスト内の並行する作業提出数を制限でき、複数の同時実行ワークロード間でのリソース共有をより予測可能にできます。Matthias Jouanneaux (NVIDIA) による寄稿 (PR #177242)。 ## ROCm **ROCm: 拡張可能なセグメント** AMD GPU (ROCm >= 7.02) では、PyTorch のキャッシュアロケータにおいて拡張可能なメモリセグメントがサポートされるようになりました。これは、仮想メモリ API を介して動的に割り当てを拡大することでメモリの断片化を削減する CUDA の機能と同等です。Prachi Gupta (AMD) による追加 (PR #173330)。 **ROCm: rocSHMEM サポート** rocSHMEM サポートにより、対称メモリ集合演算 (torch.ops.symm_mem.*) が AMD GPU で利用可能になりました。これは、NVSHMEM ベースのオンGPU 通信プリミティブ — ポイントツーポイント、ブロードキャスト、オール・トゥー・オール、および MoE 指向の 2D AllToAllv を含む — を ROCm に移植したものです。rocSHMEM の実装では、NVSHMEM と rocSHMEM の間の API およびワープサイズの差異を処理するために、専用のコンパイルユニットが使用されています。Prachi Gupta による寄稿 (PR #173518)。 **ROCm: hipSPARSELt および FP8 半構造化スパース性** hipSPARSELt は、ROCm >= 7.12 における PyTorch ビルドでデフォルトで有効化され、AMD GPU に対して半構造化（2:4）スパース性サポートをもたらしました。FP8 (float8_e4m3fn) 入力も、MI350X (gfx950) 上で hipSPARSELt を介して FP32 出力とともにサポートされるようになりました。これにより、以前は CUDA のみに限定されていた torch._cslt_sparse_mm スパース性加速パスが利用可能になります。hipSPARSELt の有効化は rraminen (AMD) によって行われました（PR #170852）、FP8 半構造化スパース性の追加は Benji Beck (Meta) によって行われました（PR #179310）。 **ROCm: Inductor FlexAttention パイプライン処理** AMD GPU 上の FlexAttention は、Triton バックエンドで二段階パイプライン処理を使用するようになり、MI350X 上で因果関係（causal）、アルバイブ（alibi）、スライディングウィンドウなど、さまざまなアテンションパターンと形状において 5-26% の速度向上を実現しました。これは、より効率的なメモリー・計算のオーバーラップを解放する単一の設定変更（num_stages=1 から 2）によるものです。nithinsubbiah によって貢献されました（PR #176676）。 ## Apple MPS **MPS: Metal-4 オフラインシェーダーコンパイル** Apple Silicon のバイナリホイールは、macOS 26 で metal-4 標準に基づいて事前コンパイルされた Metal-4 シェーダーを同梱するようになりました。これにより、初回実行時のランタイムシェーダーコンパイルのオーバーヘッドが排除され、MPS ワークロードの起動レイテンシが削減されます。また、事前にコンパイルされた .metallib バイナリを直接読み込むための補完 API (torch._C._mps_loadMetalllib) も追加され、Triton Apple MPS バックエンドのコンパイル時 metallib ワークフローをサポートしています。Isalia20 (Irakli Salia) によって貢献されました（PR #179378）。 ## 非推奨および破壊的変更 ## Distributed: Planned Breaking Changes for torchcomms torchcomms を PyTorch Distributed に直接統合し、誰もがすぐにその恩恵を受けられるように取り組んできました。今後のリリース（2.13 以降）では、torchcomms をデフォルトで使用する予定であり、これには ProcessGroup の動作に関するいくつかの破壊的変更が含まれます。これらの変更がほとんどのモデルで自動的に機能し、エコシステム内の互換性問題を修正することを目指していますが、それでも一部のモデルには影響が生じます。 torchcomms はまだ改良中ですが、現在すぐに使用可能であり、新しい API、フォールトトレランス（耐障害性）、ウィンドウ機能、スケーラビリティ、デバッグ機能へのアクセスを得ることができます。始めるには、pip install torchcomms を実行し、TORCH_DISTRIBUTED_USE_TORCHCOMMS=1 を設定してください。 詳細については [https://github.com/meta-pytorch/torchcomms](https://github.com/meta-pytorch/torchcomms) をご覧ください。 主な変更点: - 即時初期化：dist.init_process_group 内ですべての ProcessGroup/通信子を即時に初期化するよう要求し、単一のバックエンドデバイスのみをサポートします。つまり、初期化時にデバイスを指定する必要があります。 - P2P 操作：各 ProcessGroup/通信子が基盤となる通信子と 1:1 で対応するように目指しています。これにより、同じグループまたはストリームで発行された P2P 操作が並行して実行されることは保証されなくなります。並行して実行する P2P 操作には、バッチ API または別のグループ/通信子の使用が必要です。 - torchcomms の依存関係：PyTorch Distributed に対して torchcomms を必須パッケージ化し、既存の c10d::Backends を非推奨として、より現代的な単一の通信定義に置き換える計画です。 torchcomms の統合は PyTorch Distributed チームが主導しており、2.12 では基盤整備が行われています。これには Yifan Mao 氏によるバックエンドラッパーのリファクタリング（PR #177157）と、Tushar Jain 氏による FlightRecorder の統合（PR #175270）が含まれます。 **Torchscript は非推奨となりました** Torchscript は 2.10 で非推奨となり、jit trace および script API を置き換えるには [torch.export](https://docs.pytorch.org/docs/stable/user_guide/torch_compiler/export.html) を使用し、組み込みランタイムを置き換えるには [Executorch](https://docs.pytorch.org/executorch/stable/index.html) を使用する必要があります。詳細については、PTC からの[この講演](https://youtu.be/X2YbbDmCsOI?si=8s6Ue3BKIa_FYUne&t=903)をご覧ください。 **CUDA 12.8 Wheel の非推奨** PyTorch 2.12 から、CUDA 12.8 のバイナリ Wheel は非推奨となり、標準リリースマトリクスの一部として公開されなくなります。デフォルトの Wheel は CUDA 13.0（PyPI から pip install torch で入手可能）のままです。また、CUDA 13.2 が実験的ビルドとして追加されました。 Pascal や Volta などの古いアーキテクチャで動作しているユーザーは、このリリースでもサポートされている CUDA 12.6 Wheel に切り替えるべきです。Blackwell などの新しい GPU で動作しているユーザーは、CUDA 13.0 以上の Wheel を使用する必要があります。なお、これには NVIDIA ドライバーのアップグレード（Linux では 580.65.06、Windows では 580.88）が必要です。

PyTorch 2.12 リリースのハイライト（7 分読了）

背景や根拠まで確認しますか？

調べる

選ぶ

サイト