Hugging FaceはTransformers、Diffusers、KernelsからTPUを標準デバイスとして扱う構成を紹介しました。専用のOptimum TPUを介さない利用を案内しています。 PyTorchのコードを複数の計算基盤へ広げる選択肢です。対応モデル、コンパイル、分散処理の条件を実際の環境で確認することが焦点です。 TPUをPyTorchの通常のデバイスとして使う Hugging Faceは10月20日、TorchTPUに対応する主要ライブラリーの利用方法を公開しました。TPU向けにPyTorch/XLAへコードを移したり、JAXを学んだりする負担を減らす狙いです。TorchTPUはPyTorchのネイティブなバックエンドとして動き、標準的なコードからTPUを扱います。Transformers、Diffusers、Kernelsで利用する構成を紹介しています。これまでTPU上の実行を支えたOptimum TPUを必要としない経路です。今回の記事は、ライブラリーの統合と具体的な起動方法を示すもので、任意のモデルが同じ性能で動くことを保証する発表ではありません。 テキストと画像のモデルを同じ方法で配置 Transformersではdevice_mapにtpuを指定してモデルを読み込みます。DiffusersもTPUへ配置し、試作や確認にはeager実行、配備にはコンパイルを組み合わせる構成です。Pallasによるカーネルや分散学習の対応も説明しています。Google CloudのTPUを使う開発者や、複数の計算基盤を比較するチームが対象です。モデル定義を共通に保ちながら実行先を選べれば、移植用コードの負担を減らせる可能性があります。原文はTPU用の環境でCPU版のPyTorchを入れる方法を案内し、不要なCUDA版の取得を避ける点も示しています。実行先の変更はモデル本体だけでなく、環境構築や依存関係にも及びます。標準のインターフェースを使えることを入口に、実際の演算や精度を確かめる必要があります。公開Hubのモデルを試す場合も対応状況の確認が前提です。 移植の容易さと運用時の費用を分けて測る 実務では、コードが起動することと、期待した速度や費用で動くことを分けて確認することが論点です。最初のコンパイル、入力サイズが変わる場合の動き、分散時の通信などが全体へ影響する可能性があります。同じモデルと入力で出力を照合し、定常実行と初回準備を別々に測る進め方が考えられます。既存のXLA構成から移る場合は、独自の最適化や監視がそのまま使えるかも確認する対象です。新しいバックエンドへ移す利点は、独自コードの減少と保守の簡素化にもあります。ただし、更新するライブラリーと実行環境の版を揃えなければ再現しにくくなります。代表的なモデルで試験し、計算資源の利用料金だけでなく準備と障害対応の負担も比べることが重要です。共通のモデル定義を保つ範囲と、基盤固有の設定を残す範囲を決めることが判断点になります。