【要約】ローカルLLMって本当に開発に使える？（６）SFTしてGGUFに変換してOllamaで動かすまで：7つの罠 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がローカルLLMの微調整からデプロイを行う際、環境の不整合やモデル構造の誤解により、出力が崩壊する問題に直面した。具体的には以下の課題が挙げられる。
- ・ライブラリのバージョン競合：unslothの導入によりtorchのバージョンが書き換わり、GPUと非互換になる。
- ・リソース不足：70BモデルのGGUF変換時に、一時的に約285GBのディスク容量を消費し、容量不足で失敗する。
- ・Adapter Stackingのミス：Baseモデルにv3アダプタのみをマージし、中間層のv2アダプタを欠落させた。
- ・データ品質の欠如：評価データの欠損を無視したフィルタリングにより、不適切なデータが学習に含まれた。
- ・シーケンス長の不足：学習時の最大長が短く、データの半分が途中で切り捨てられていた。
// Approach
開発者は、失敗したv3のプロセスを分析し、データ品質の厳格化と正しいマージ手順の確立によって問題を解決した。採用した手法は以下の通りである。
- ・データ抽出の厳格化：評価者が揃っている「triplet-only」のデータのみを使用するように変更した。
- ・シーケンス長の拡張：MAX_SEQ_LENGTHを2048から8192へ引き上げ、情報の欠落を防いだ。
- ・手動マージの実施：Base、v2、v3のアダプタを順次PeftModelで適用し、merge_and_unloadを実行した。
- ・環境依存への対応：cudnnのライブラリパス問題をシンボリックリンクの作成によって解決した。
- ・評価戦略の導入：eval splitを導入し、最良のチェックポイントを自動選択する仕組みを構築した。
// Result
開発者は、学習設定とデータ品質を最適化したv4モデルを構築し、汎化性能の向上を確認した。成果は以下の通りである。
- ・データ品質の向上：不完全なデータを除外し、高品質な42件のデータセットを構築した。
- ・学習の最適化：シーケンス長を拡張し、情報の欠落がない状態で学習を完遂させた。
- ・汎化性能の確認：eval_lossの推移により、モデルが適切に汎化していることを定量的に示した。
- ・コスト効率：H100を使用することで、学習時間を短縮しつつ、効率的な学習を実現した。
Senior Engineer Insight
> LLMの微調整は、モデルの重み以上に周辺ライブラリの依存関係が極めてシビアである。特に、複数アダプタを扱う際の「マージの順序」を誤ると、モデルは即座にゴミを出力する。また、70Bクラスの変換には、VRAM以上に膨大な一時ディスク容量が必要となる。実戦では、環境の完全な固定と、ディスク容量の事前確保が不可欠だ。データ品質の定義も、単なる平均値ではなく、欠損値の扱いまで含めて厳格に設計すべきである。