vLLMコミュニティがLoRAの層ごとのスケーリング無視を報告、デプロイ後にファインチューニングの効果が弱まる可能性

10月2日、vLLMコミュニティからLoRAの互換性に関する報告がありました。Hugging Face PEFTで学習したアダプターで、rank_patternまたはalpha_patternを使って個別のモジュールを設定した場合、vLLM 0.30.0へのデプロイ後に誤ったスケーリングが使われる可能性があるというものです。報告によると、読み込み処理はグローバルなrとlora_alphaのみを読み取り、層ごとの設定は無視されますが、警告は出ません。確認時点で、このissueは未解決で、関連する修正も記載されていません。問題の報告

PEFTの公式ドキュメントでは、これら2つのフィールドをモジュール名または正規表現に応じて上書きできると説明されています。通常のLoRAでは、更新量はalpha/rでスケーリングされます。そのため、重みを正常に読み込めたとしても、スケーリングの意味が一致しなければ、モデルの計算結果が変わります。たとえば、グローバルなrankが16、alphaが32の場合、ある層でrankを4に変更すると、その層の倍率は8になるはずです。グローバルな倍率を使い続けると倍率は2にとどまります。つまり、フィールドが空でないことだけでは誤りと判断できず、層ごとの比率が変わるかどうかが重要です。PEFTドキュメント

報告者はOLMoE-1B-7Bをwikitext-2で200ステップ微調整してテストし、PEFTで困惑度10.06、vLLMで11.28という結果を得ました。困惑度は低いほど良い指標です。各モジュールのスケーリングをlora_Bに反映し、patternを取り除くと、vLLMの困惑度は10.06に戻りました。小規模なランダムモデルを使った別のケースでも、トークンの対数確率を比較するためのコードが添えられています。ただし、これらは報告者自身によるテスト結果であり、すべてのLoRAで品質が低下すると一般化することはできません。テストと再現コード

PEFTのドキュメントでは、アダプターのパラメーター予算を抑えるために専門家層のrankを下げる例が示され、vLLMによる高速推論も紹介されているため、この問題は特にMoEの微調整で注視する必要があります。エンジニアリング上は、学習側とサービング側の双方でファイル形式を確認するだけでなく、実際の更新量も比較すべきです。MoEの設定例

デプロイ担当者はまずアダプターの設定を確認し、同じトークン入力を使ってPEFTとサービング側の対数確率を比較したうえで、重み変換を検討できます。今後は、モジュールごとのスケーリングへの対応、patternに含まれる最大rankに対する容量チェック、上流での複数モデルにわたる検証に注目してください。現時点で公開情報から正式な修正版がリリースされたことは確認できません。修正の方向性