低VRAM環境でのLoRA学習において、bitsandbytesに代わりGGUFが採用

新しいオープンソースのレシピは、従来考えられていたよりも大幅に少ないビデオメモリで大規模言語モデルに対するLow-Rank Adaptation（LoRA）学習を行う方法を実証しています。従来の量子化ライブラリの代わりにGGUFファイル形式を活用することで、開発者は遅いCPUオフロードに依存することなく、わずか16 GiBのVRAMでQwen3.6-35Bなどのモデルをファインチューニングできるようになりました。この変化は、効率的なローカル学習における標準的なベースモデル形式として、GGUFがbitsandbytesを置き換える準備ができていることを示唆しています。

何が起きたか

リポジトリ woct0rdho/transformers5-qwen3.5-recipe の開発者が、Strix Haloハードウェアアーキテクチャ向けに調整された低VRAM学習手法に関する技術的な詳細解説を公開しました。この取り組みは、大規模モデルの学習には大規模なGPUクラスタや広範なメモリスワッピングが必要だという通説に挑戦するものです。その代わりに、適切な量子化ベースモデルと最適化されたカーネルの組み合わせにより、コンシューマーグレードまたは統合型高性能ハードウェアであっても、 substantial なファインチューニングタスクを処理できることを示しています。

核心的な成果は、以前には不十分だと考えられていたVRAM制限内で、最先端のオープンウェイトモデルを完全に学習させることにあります。例えば、Qwen3.6-35B-A3Bモデルはわずか16 GiBのVRAMで学習されました。著者によれば、この効率性は、より大きなバリアントであるQwen3.5-122B-A10Bが64 GiBで、そして巨大なQwen3.5-397B-A17Bが192 GiBで学習できる可能性を示唆しています。同様に、2840億パラメータを含むDeepSeek-V4-Flashモデルは90 GiBのVRAMで学習され、Qwen3.8-Flash-Nextモデルには40 GiBが必要でした。

この発展は、オープンウェイトAIをオープンソースソフトウェアと同様に扱う点で重要です。ユーザーは重みを実行するだけでなく、それを変更することもできます。 prohibitive なハードウェアコストなしにローカルで重みを修正できる能力は、基盤モデルのカスタマイズへの参入障壁を下げます。ただし、現在の実装はStrix Halo専用にチューニングされているため、これらの最適化を他のGPUアーキテクチャへ移植するには追加のエンジニアリング作業が必要です。

仕組み

この手法は、量子化重みの読み込みにおけるベースモデル形式として、bitsandbytesライブラリをGGUFに置き換えることに依存しています。もともとllama.cppによって推論用途で普及したGGUFは、Transformersライブラリの独自フォークを通じて、学習ワークフロー向けに適応されています。このアプローチでは、学習ループに直接統合されるGGUF量子化器を使用し、計算中に過度なメモリを消費する高精度形式へ完全に解凍するのではなく、モデルを圧縮状態のまま維持します。

いくつかの専門的なカーネルと最適化技術がこの実現を支えています。システムは、llama.cppで見られるような調整済みのGeneral Matrix Multiply（GEMM）演算とMixed Precision Quantization（MMQ）を採用しています。Mixture of Experts（MoE）レイヤーについては、非量子化LoRAアダプター向けの特定設定を持つAITER Tritonカーネルを使用しています。また、Unslothで使用されるものと同様のLoRA更新用の高速バックワードフォーミュラを実装し、線形レイヤーとMoEレイヤー両方の勾配計算を加速しています。

メモリ節約はさらに、自己回帰デコーディングキャッシュや負荷分散損失など、学習安定性にとって厳密には必要ない機能の無効化によって達成されます。システムはnon-reentrantなグラディエントチェックポインティングと、bitsandbytes由来の8-bit AdamWオプティマイザーを使用し、メモリフットプリントを最小限に抑えます。加えて、torch.compileがGGUF逆量子化関数に適用され、読み込みフェーズ中のVRAM使用量を削減し、圧縮重みの処理に伴うオーバーヘッドが管理可能な範囲内に留まるようにしています。

主要な詳細

• Qwen3.6-35B-A3Bは、APEX-I-Mini量子化を使用して16 GiBのVRAMで学習され、実際には13.3 GiBのみを占有します。
• DeepSeek-V4-Flash（284Bパラメータ）は、IQ2_XXS量子化を使用して90 GiBのVRAMで学習されます。
• Qwen3.8-Flash-Nextは、GSQ-RCO Q2_0量子化を使用し、40 GiBのVRAMに加え、エングラム用に27 GiBを必要とします。
• このソリューションは、Hugging Face issue #40070で追跡されている、GGUFサポート付きの独自Transformersフォークを使用しています。
• 最適化には、調整済みGEMM、MMQ、AITER Tritonカーネル、およびLiger KernelからのRMSNormが含まれます。
• 現在のカーネルとパラメータはStrix Haloハードウェア専用にチューニングされており、他のGPUでの利用には適応作業が必要です。

なぜ重要か

AIを組み込んだ製品を構築するエンジニアにとって、このシフトは大規模モデルのファインチューニングのコストと複雑さを軽減します。従来、学習には数百ギガバイトのVRAMを持つ高価なクラウドインスタンス、あるいは学習時間を劇的に遅くするCPUオフロードを含む複雑なセットアップが必要でした。効率的な量子化を用いて学習プロセス全体をVRAM内に保持することで、開発者はより迅速に反復でき、よりアクセスしやすいハードウェア上でより大きなモデルを試験できます。これにより、モデルカスタマイズへのアクセスが民主化され、小規模なチームでも大規模なインフラ投資なしに、自らのドメインに合わせて基盤モデルを調整することが可能になります。

学習におけるGGUFへの移行は、推論と学習ツールチェーン間の収束も示しています。以前は、開発者は推論用（多くの場合GGUFや類似形式を使用）と学習用（フル精度またはbitsandbytesを使用）のモデル変換のために別々のパイプラインを維持する必要がありました。これらの形式を統一することでワークフローが簡素化され、変換時のエラーリスクが低減し、学習中のモデル挙動がデプロイ時の挙動と密接に一致することが保証されます。この一貫性は、本番環境でのモデルパフォーマンスと信頼性を維持するために不可欠です。

できること

• Strix Haloハードウェア上で提供されたレシピを実験し、特定のユースケースにおける学習速度とメモリ使用量をベンチマークしてください。
• GGUF量子化サポートがメインライブラリにマージされる可能性を追跡するため、Hugging Face Transformers issue #40070を監視してください。
• ベースモデルに対してbitsandbytesからGGUFベースの量子化へ切り替えることで、現在のファインチューニングワークフローが利益を得られるかどうか評価してください。
• Strix Haloを使用していない場合、独自のTritonカーネルとMMQ実装を調査し、それらが特定のGPUアーキテクチャにどのように適応できるかを理解してください。
• 同様の大型モデル向けの学習ループ設計時に、自己回帰デコーディングキャッシュと負荷分散損失の無効化によるメモリ節約を検討してください。
• モデル読み込みと学習中のVRAM使用量をさらに最適化するために、逆量子化関数へのtorch.compileの使用を探求してください。