模型訓練與開源工具
Fizgig 5.0、ローテーション式トレーニングウィンドウにより33B動画モデルを16GB GPUでフルパラメータ・ファインチューニング
Fizgig 5.0は、現在のスライスの勾配とオプティマイザ状態だけを保持しながら、MiniMax H3とKrea 2の全重みを区間ごとに更新する。開発者の実測ではピークVRAM使用量を最低13GB未満に抑えたが、システムメモリ、学習速度、独立した品質検証が依然として主な制約となる。

Fizgig 5.0は、従来のLoRAワークベンチをフルパラメータ・ファインチューナーへと拡張し、単一のNVIDIAコンシューマー向けGPUで、33BパラメータのMiniMax H3動画モデルと12.9BパラメータのKrea 2を学習できるようにした。ここでいう「フルパラメータ」とは、モデル全体の勾配を同時に確保するという意味ではない。システムは各epochで重みの一部だけを有効化し、トレーニングウィンドウをローテーションさせる。残りのブロックは4-bit NF4でGPU上に凍結され、勾配とオプティマイザ状態も現在のスライスについてのみ保持される。通常、モデル全体が1回の更新サイクルを完了するには4 epochを要する。
出力される重みが量子化誤差の影響を恒久的に受けるのを避けるため、Fizgigはbf16のmaster copyをメインメモリに保存し、学習後はこのコピーから直接checkpointを書き出す。メンテナーが16GB GPUで測定したH3のピークVRAM使用量は8.8~12.3GB、Krea 2は8.4~11.0GBだった。H3では、長さ2.3秒、56フレームの動画を使った学習が各VRAM構成で実際に実行されている。内蔵ツールでは、ファインチューニング前後のcheckpointを比較し、ComfyUIで読み込める通常のLoRAを抽出することもできる。
このスライス方式は、VRAM要件を「モデル、勾配、オプティマイザを同時に収容すること」から「単一のアクティブウィンドウを収容すること」へと変える。ただし、総計算量、PCIe転送、ストレージ要件がなくなるわけではない。Krea 2では、実用上少なくとも48GBのシステムメモリが推奨される。H3ではメモリが不足するとmaster copyがディスクへスピルされ、学習速度が大幅に低下する可能性がある。AMD/ROCmはまだテストされておらず、長尺動画に関する一部の数値も推定値にとどまる。また、rank 64 LoRAと完全なcheckpointに「知覚上の差がない」という主張も、作者によるテストだけに基づいている。今後は、コミュニティが収束品質を再現できるか、完全な更新サイクルごとの所要時間を測定できるか、さらにQLoRAや分散フルパラメータ・ファインチューニングと比べた実際のコストがどうなるかを見極める必要がある。