結論から書きます。LLMの追加学習では手法の98.4%がLoRA一択という実態がある一方、画像生成ではOFTがLoRAより高精度（0.708対0.697）かつメモリが約1GB少ないという実測が出ました。ただし推論基盤がLoRA形式しか読めない制約があり、ベンチマークの勝者がそのまま使えるとは限りません。
LoRAはどれくらい「一択」になっているのか（一次資料の実測）
Hugging Faceが公開した記事「Beyond LoRA: Can you beat the most popular fine-tuning technique?」に、追加学習（ファインチューニング）手法の利用実態と性能比較の実測が載っています。
まず、どれだけLoRAに偏っているかの数字です。
| 調べた対象 | 条件 | LoRAの割合 |
|---|---|---|
| Hugging Face Hub上のモデルカード | サンプル20,834件。PEFT手法を「ちょうど1つ」記載したものに限定 | 98.4%（20,834件中20,509件） |
| 画像生成用チェックポイント | サンプル10,000チェックポイント。画像生成モデル対象 | 95.0%（10,000件中7,111件） |
| GitHubコード検索の結果 | GitHubコード検索によるサンプリング。検索クエリ・総件数は記載なし | 71.3%（2位LoHa 3.7%、3位AdaLoRA 3.5%） |
モデルカードでは98.4%、画像生成のチェックポイントでは95.0%、GitHubのコード検索でも71.3%。3つの角度から見て、LoRAが事実上の標準になっていることが確認できます。2位のLoHaが3.7%、3位のAdaLoRAが3.5%ですから、差は一桁違います。
なお、GitHubの71.3%については検索クエリと総件数が記載されておらず、他の2つと同じ精度で扱える数字ではありません。傾向を裏づける補助的な数字として読むのが妥当です。
（出典：Hugging Face（著者：Benjamin Bossan、Sayak Paul、Marian Tietz、Kashif Rasul。ほか70名以上のコントリビューター記載）、2026-06-18、https://huggingface.co/blog/peft-beyond-lora）
この記事は誰が書いたのか（利害関係の明示）
数字を読む前に、押さえておくべき前提があります。この記事はHugging Face自身による発表であり、同社は比較に用いられたPEFTライブラリの提供者です。
つまり「LoRA以外にも有力な手法がある」という結論が出ることは、多様な手法を扱える自社ライブラリの価値を示すことにつながります。発信元に利害があるという意味です。数字が捏造だと言いたいのではなく、比較の設計や取り上げる手法の選び方に、提供者側の関心が反映されうるという話です。
この構造は珍しいものではありません。ベンダーが自社の測定結果を出すこと自体は普通で、判断材料としては有用です。読む側が「誰が測ったか」を把握したうえで、自社の条件で確かめられるかを考えればよい話です。同じ論点は単価の安いモデルを選べば安くなるのかでも扱っています。
数学タスクと画像生成で、結果が違った
実際の比較結果を見ます。まず数学タスク。ベースモデルはLlama-3.2-3B、ベンチマークはGSM8Kです。
| 手法 | テスト精度 | メモリ使用量 | 条件 |
|---|---|---|---|
| LoRA | 53.2% | VRAM 22.6GB | Llama-3.2-3B／GSM8K |
| BEFT | 32.9% | 20.2GB | 同上 |
| Lily | 54.9% | 25.6GB | 同上 |
BEFTはLoRAより約2.4GB省メモリですが、精度は約20ポイント低くなりました。省メモリと引き換えに失うものが大きすぎます。逆にLilyはLoRAより高精度（54.9%対53.2%）ですが、メモリは約3GB多い。数学タスクの範囲では、LoRAは「精度とメモリのバランスが取れた無難な選択」という位置づけのままです。
次に画像生成。ベースモデルはFLUX.2-klein-base-4B、評価指標はDINO類似度です。
| 手法 | DINO類似度 | メモリ使用量 | 条件 |
|---|---|---|---|
| LoRA | 0.697 | 9.97GB | FLUX.2-klein-base-4B／DINO類似度 |
| OFT | 0.708 | 9.01GB | 同上 |
こちらは様子が違います。OFTは精度でLoRAを上回り（0.708対0.697）、同時にメモリも約1GB少ない。トレードオフではなく、両方で勝っています。
ただし、いずれのベンチマークも「ハイパーパラメータを網羅的にスイープしていない条件下」の結果である点は明記されています。著者自身が、ハイパーパラメータの選択が特定の手法に有利に働きうると認めており、多数の手法にわたる網羅的なスイープは困難だったと書いています。数字の差が手法そのものの差なのか、設定の当たり外れなのかは、この記事だけでは切り分けられません。
中小企業にとって、この数字はどこに効くのか
正直に書くと、この話が意味を持つ企業は限られます。
- まだ自社データでの追加学習をしていない企業：示唆は弱いです。市販のAPIやクラウドサービスで足りている段階なら、手法選定の議論は先の話です。まずは中小企業がAIを導入する最初の一歩の段階を固めるほうが順序として妥当です。
- すでにLLMや画像生成モデルを微調整している企業：手法選定がGPUメモリの実消費に効きます。クラウドGPUは搭載メモリ帯でインスタンス単価が変わるため、約1GBの差が下の価格帯に収まるかどうかの分かれ目になることがあります。
- 画像生成モデルを社内用途で調整している企業：この記事のなかで最も具体的な示唆があるのはここです。9.97GBが9.01GBになる差は、10GB前後を境にした構成では実際の請求額に効いてきます。
金額そのものは記事に記載がないため、ここでは書きません。自社が使っているGPUインスタンスの価格表に照らして、メモリ帯の境目がどこにあるかを確認するのが実務の手順になります。
ベンチマークで勝つ手法と、本番で動かせる手法は違う
情シスの実務判断として、この記事でいちばん重要なのはここだと考えます。記事には、性能以外の制約が正直に列挙されています。
- 下流ツールの制約：vLLMなどの推論基盤では、LoRA形式のチェックポイントしか読み込めません。ベンチマークで優れた手法でも、本番の推論基盤に載らなければ採用できません。推論基盤側の事情はvLLMとTransformersの実装まわりの議論とも直結します。
- 機能面のパリティが揃っていない：量子化されたベースモデルに対応していない手法があり、変更できる層の種類も手法によって制限があります。同じ土俵で比べているように見えて、できることの範囲がそもそも違います。
- ベンチマークが手法の能力を完全には測れない：著者はこれも明示しています。例としてCartridgesはプロンプト圧縮向けの手法であり、今回の測定対象では本来の価値が現れないとしています。数字が低いことが「その手法が劣る」ことを意味しない場合がある、ということです。
- 結論自体が控えめ：著者は「LoRAは決して悪い選択ではないが、より良い選択肢がありうる」という表現にとどめており、LoRAからの乗り換えを断定的に推奨してはいません。
つまり、この記事は「LoRAをやめろ」という記事ではありません。「LoRA一択で検討を打ち切るのはもったいない場面がある」という程度の主張です。そして、その検討の結果が本番で使えるかどうかは、推論基盤の対応状況という別の軸で決まります。
TOEの読み筋
先に断っておきます。TOEでは、ここで挙げた手法の比較検証は未実施です。以下は実測に基づく主張ではなく、記事を読んだうえでの見立てです。
見立てとしては、手法の選定より先に、推論基盤の制約を確認するほうが順番として正しいと考えています。vLLMのようにLoRA形式しか読めない基盤を使う予定があるなら、OFTがどれだけ良い数字を出していても検討対象から外れます。逆に自前の推論コードで回すなら選択肢は広がります。この順番を逆にすると、比較検証に工数をかけたあとで「載らない」と気づくことになります。
もう一点、画像生成でOFTが両面で勝ったのに対し、数学タスクではLoRAが依然としてバランス良く残った、という結果の非対称性は示唆的です。タスクの種類によって最適解が変わるなら、「うちの用途で測る」以外に答えを出す方法はありません。他社の比較表を自社の結論として持ち込む危うさは、自社の評価基準を持つことで書いた話と同じ構図です。
社内で追加学習に着手している企業であれば、まず現行のLoRA構成で「精度」と「GPUメモリのピーク値」を記録しておくことを勧めます。比較対象がなければ、どの手法に乗り換えても良くなったかどうかを判断できません。記録が先、比較は後です。
まとめ
- Hugging Face Hub上のモデルカード（サンプル20,834件、PEFT手法を1つだけ記載したものに限定）のうち98.4%がLoRAに言及しており、追加学習手法は事実上LoRA一択の状態にある。
- 画像生成（FLUX.2-klein-base-4B、DINO類似度）ではOFTが0.708／9.01GB、LoRAが0.697／9.97GBで、OFTが精度・メモリの両方で上回った。
- 数学タスク（Llama-3.2-3B、GSM8K）ではLoRAが53.2%／22.6GB、BEFTが32.9%／20.2GB、Lilyが54.9%／25.6GBで、LoRAのバランスの良さが残った。
- この記事はHugging Face自身による発表であり、同社は比較に用いたPEFTライブラリの提供者である。加えてハイパーパラメータの網羅的スイープは行われていないと著者が明記している。
- vLLM等の推論基盤はLoRA形式のチェックポイントしか読み込めないため、ベンチマークで優れた手法が本番で採用できるとは限らない。手法選定より先に推論基盤の制約を確認する順番が実務では重要になる（この点についてTOEでは検証未実施）。