Transformersコミュニティが8基のB200でストレージをベンチマーク、モデル重みの集約書き込みがボトルネックと判明

Transformersコミュニティは10月30日、NVIDIA B200を8基搭載したベンチマークを提出し、現行のモデル重みの読み込み、集約ストレージ、分散チェックポイント（DCP）の各経路を比較した。今回新たに公開されたのは測定結果と再現用スクリプトであり、指定されたmainコミットを使用し、ライブラリの実装には変更を加えていない。テストレポート

Qwen2.5-72Bを8-way Fully Sharded Data Parallel（FSDP）構成で実行した場合、集約ストレージには158秒かかったのに対し、DCPでは52秒だった。Qwen3-235B-A22Bでは、それぞれ772秒と219秒だった。著者によると、集約経路ではメインプロセスがすべての重みを集め、形式を変換してファイルに書き込む間、ほかのプロセスは待機する。235Bのケースでは、メインプロセスのメモリ使用量のピークが775 GBに達した。測定結果とボトルネック分析

DCPでは、各ワーカープロセスが自身のシャードを並列に保存できる。読み込み時には、異なるクラスタートポロジーに応じてシャードを再構成することもできる。PyTorchのドキュメントによると、この種のチェックポイントは通常複数のファイルで構成され、モデルに事前割り当てされたストレージ領域を使って読み込まれる。この仕組みは分散環境での復旧に適している理由を示すとともに、ファイル配置と読み込み方法をデプロイ設計に含める必要があることも示している。PyTorch DCPドキュメント

シャードをより速く書き出せても、モデルの提供プロセスが完了するわけではない。レポートでは、72BモデルのDCP重みを単一のsafetensorsファイルに統合するのに、なお202秒かかることも測定された。モデルをエクスポートするチームは、定期保存、障害復旧、最終エクスポートのコストをそれぞれ測定すべきであり、いずれか一つの所要時間だけで全体の効果を見積もるべきではない。統合テスト

これらの数値は単一マシンでのコミュニティによる結果であり、ほとんどのケースは1回のみ実行され、対象も重みに限られている。オプティマイザー状態や複数ノード間の通信は含まれていない。今後は、独立した再現検証、学習状態全体を含むチェックポイントのテスト、異なるストレージデバイスでの性能が注目点となる。また、PyTorchはDCPのstate_dictについて、バージョンをまたいだ互換性を保証していないと明記しているため、異なるバージョン間での復旧も検証が必要だ。テスト範囲、互換性に関する説明