模型訓練工具
Soup 0.74、凍結モデルのfp32読み込みパスを修正、単一LoRAテストのピークGPUメモリ使用量が18.7 GiBに低下
Soupのテキスト、ビジョン、オーディオ用ローダーではdtypeが指定されておらず、最適化対象ではないベースモデルもfp32のままGPUメモリに常駐していた。修正後、公式のH100テストでは48,241 MiBから18,658 MiBに減少したが、2.59倍という改善をすべてのモデルやハードウェアに一般化することはできない。

オープンソースのモデルファインチューニングツールSoupは0.74.0をリリースし、ハードウェア容量計画を大きく歪めかねないデフォルト動作を修正した。従来、テキスト、ビジョン、オーディオの3つの`from_pretrained`パスはいずれもdtypeを明示的に渡していなかったため、教師ありファインチューニングで凍結されたベースモデルがfp32として実体化されていた。LoRAが少数のアダプターパラメータしか更新しない場合でも、ベースモデル全体がチェックポイントの2倍のビット幅でGPUメモリを占有していた。
新バージョンでは、凍結された重みをチェックポイント本来の精度に従って読み込む一方、フルファインチューニング時には意図的にfp32を維持する。また、トレーナーとGPUメモリ事前チェックがそれぞれ個別に管理していた「フルファインチューニングかどうか」の判定を、単一の`is_full_finetune()`に統合した。これにより、容量見積もりではモデルが凍結済みと判断されているのに、実際の読み込みパスでは逆の判断が行われる事態を防ぐ。
メンテナーは単一のH100上でLlama 3.1 8BとLoRAを使用してテストし、ピークGPUメモリ使用量が48,241 MiBから18,658 MiBに低下したと報告した。差は約28.9 GBで、2.59倍の削減に相当し、3回の実行結果はバイト単位で一致した。この差は、ワークロードが特定のGPUに収まるかどうかや、チームがParameter-Efficient Fine-Tuningの経済性を誤って低く評価するかどうかを左右し得る。ただし、この数値はプロジェクト自身によるもので、対象は1種類のモデルとハードウェア構成に限られており、独立した再現検証はまだない。
0.74.0では、実行環境とネットワーク境界に関する複数の問題も修正された。テレメトリ、Webhook、OTLPのバリデーターは、`127.1`、10進数、16進数、8進数などの代替IPv4表記を検出し、アドレス検査の回避を防ぐようになった。再び有効化された`/v1/tools/bash`はOSレベルで隔離され、サービスが非loopbackアドレスにbindされているにもかかわらず`--tool-auth-token`が指定されていない場合、警告を表示するだけではなく、ステータスコード2で直ちに終了する。SGLangバックエンドでも、remote model codeがデフォルトで有効化されることはなくなった。
アップグレードには依存関係上の落とし穴が残る。パッケージが宣言する最小要件`torch>=2.5.0`は、実際には`trl>=0.29`と互換性がない。既知の問題として、Torch 2.5.1には必要な`FSDPModule`が存在せず、DPO、KTO、GRPO、BCOを読み込めない。導入者は、ベースモデルの実際のdtype、凍結状態、ピーク時の割り当て済みGPUメモリと予約済みGPUメモリを記録し、自身のモデル、シーケンス長、GPUを使って容量テストを再実行すべきだ。パッケージリゾルバーで正常にインストールできることは、そのバージョン構成がテスト済みであることを意味しない。