手元のGPUでローカルLLMをファインチューニングできるか

ファインチューニングとは、学習済みモデルを自前データで追加学習する手法。

VRAM 16GBのGPUでローカルLLMを学習できるか。結論から言えば、QLoRAという手法を選べば7〜8B級のモデルは現実的に回せます。ただしフル微調整は標準的なやり方だと7Bでも100GB超〜130GB級を要し、16GBでは現実的に対象外。素のLoRAも24GB級からが快適圏。同じ「ファインチューニング」でも手法によって必要VRAMは10倍近く変わります。この記事では、手元のGPUで何ができて何ができないかを、必要VRAMの差から一意に判断できる状態まで整理していきます。

16GBのGPUで結論から言うと何ができるか（QLoRA・LoRA・フルの可否）

ローカルAI向けとしてよく選ばれるVRAM 16GB級のGPU（RTX 5080・5060 Ti・RTX 4080 など）を前提に考えます。この容量でファインチューニングに着手できるかは、選ぶ手法で答えが分かれます。フル微調整・LoRA・QLoRAの3つを、16GBという枠に当てはめて先に可否を示します。

フル微調整は、モデルの全パラメータを更新する最も重い手法。7Bクラスでも必要VRAMは概ね100GB超〜130GB級に達すると各種の実践報告が示しています。理由は後述しますが、学習中はモデル本体の何倍もの補助データをメモリに抱える必要があるためです。16GBはもちろん、コンシューマー単体GPUの範囲では届きません。

LoRA（Low-Rank Adaptation）は、元モデルの重みを凍結したまま小さな追加パラメータ（アダプタ）だけを学習する手法。Hugging Face PEFTライブラリが広く実装しています。学習対象は激減しますが、元モデル自体は16bit精度でメモリに載せ続けるため、7Bで28GB前後が目安。16GBには収まりきらず、24GB級のGPUで快適になります。

QLoRAは、その元モデルを4bitに量子化して凍結し、その上でアダプタを学習する手法。QLoRA論文（Dettmers et al., 2023）が提示した方式で、7Bなら概ね10〜13GBまで下がります。ここで初めて16GBが射程に入ります。つまり16GBの現実解は、4bit量子化を伴う省メモリ手法（QLoRA系）が事実上の第一選択になる、というのがこの記事の骨格です。

3手法と16GB VRAMの対応早見

3手法の位置づけを1行で押さえておきます。フル微調整は「品質は最上だが桁違いに重い」、LoRAは「軽いが元モデルは16bitのまま」、QLoRAは「元モデルも4bitに落として最小VRAM」。16GBという制約を軸に見ると、選べるのは事実上QLoRA系だけ、という関係が浮かびます。（なお、GaLoreやQ-GaLoreのように、勾配の低ランク化や量子化を組み合わせて学習メモリを削る研究系の手法もありますが、実装の手軽さと情報量では現状QLoRA＋Unslothが標準です。）

ここで一つ補助線を引いておきます。当サイトはローカルLLMの「推論」については、16GBに何が載るかをモデル別に実測した早見表を用意しています。ただし学習は推論とは別レジームで、必要メモリは推論より遥かに重い。推論で16GBに快適に載るモデルでも、学習となると同じ感覚では扱えません。この点は最初に区別しておいてください。

なぜQLoRA・LoRA・フルでVRAM消費が桁違いになるのか

同じモデルを学習するのに、なぜ手法で必要VRAMが10倍近くも変わるのか。ここを理解すると、早見表の数字が丸暗記ではなく「なぜそうなるか」で腑に落ちます。鍵は、学習時にメモリへ載るものが推論よりずっと多い点にあります。

そもそもPEFT（Parameter-Efficient Fine-Tuning＝パラメータ効率の良い微調整）という技術群が生まれた背景がここにあります。Hugging Face「Beyond LoRA」ブログによれば、ファインチューニングは本来メモリを大量に消費し、モデル全体を何度も載せられるだけの容量を要します。さらに量子化したモデルはそのままでは微調整できないという壁もありました。この2つを回避するために生まれた省メモリ手法の総称がPEFTで、LoRAやQLoRAはその代表格です。

フル微調整でVRAMが跳ね上がる理由

フル微調整で16GBに載らないのは、学習中に4種類のデータを同時に抱えるからです。モデルの重み本体、逆伝播で計算する勾配、そして最適化アルゴリズムが保持する「オプティマイザ状態」。広く使われるAdam系のオプティマイザは、各パラメータごとに移動平均を2種類（1次・2次モーメント）持ちます。

この結果、16bitでフル微調整する場合の所要メモリは、ざっくり重みの数倍規模。7Bモデルの重みが16bitで約14GBだとしても、勾配とオプティマイザ状態、さらに中間活性化を足すと100GBの桁に膨らみます。推論なら重みを載せるだけで済むのに対し、学習では重み以外が支配的になる。ここがフル微調整の壁です。

LoRAとQLoRAが軽い理由

LoRAはこの問題を「学習するのはアダプタだけ」という発想で回避します。元モデルの重みは凍結して更新しないので、その巨大な勾配とオプティマイザ状態が不要になります。オプティマイザ状態を持つのは、追加した小さなアダプタの分だけ。だからVRAMが劇的に下がる。ただし凍結した元モデル自体は16bitのままメモリに常駐するため、7Bなら28GB前後という下限が残ります。

QLoRAはこの残った元モデルにさらに手を入れます。凍結する元モデルを4bitに量子化してから載せる。学習中に更新しないなら精度を落としても差し支えない、という割り切りです。これで元モデルのメモリ占有が半分以下に縮み、7Bで10〜13GBまで到達します。「学習するのはアダプタだけ」「凍結する元モデルは4bitでいい」という2段構えが、16GBを成立させる仕組みです。

16GBで狙えるモデルサイズ早見（7-8B◎／12-14B△／13B+は要検討）

必要VRAMの理屈が分かったところで、16GBで狙えるモデルサイズを手法別に一覧化します。数字は2026年7月時点の公式ドキュメント・論文・実践報告・当サイト実測をもとにした、安全側の実務目安です。Unsloth公式が示す最小VRAM値はこれより低く出ますが、実環境ではモデル実装・シーケンス長・バッチサイズ・データ形式で大きく上下します。実際に手元で測った値は後半の「当サイトでの実測」にまとめました（概算より軽い結果でした）。

表を1行で読むなら、16GBで安心して回せるのは7〜8B級のQLoRAだけ。12〜14Bは条件次第の領域です（当サイト実測では14Bも約13GBで単一16GBに収まりました。後述）。13Bを超える素のLoRAやフル微調整は、そもそも別クラスのGPUの話になります。なおこの概算は安全側の見積もりで、Unslothやモデル実装・attention実装・シーケンス長・バッチサイズによっては、実測値が大きく下がることもあります（後半の実測を参照）。

7〜8B級が16GBの安全圏である理由

7〜8BのQLoRAが10〜13GBで収まるなら、16GBには余裕が生まれます。この2〜5GBのバッファが実務では効いてきます。学習ではシーケンス長（一度に扱うトークン数）やバッチサイズを上げるほど中間活性化のメモリが増える。バッファがあれば、シーケンス長を伸ばしたりバッチを増やしたりする余地が残ります。逆にVRAMを使い切るギリギリの構成だと、少し設定を上げただけでOOM（メモリ不足）で落ちます。7〜8B級は、この調整幅を持てるのが安全圏たる理由です。

12〜14Bを16GBで攻めるときの条件と限界

12〜14BのQLoRAは、素の設定では15〜20GBを要し16GBを超えがち。ここを16GBで成立させるには、後述するUnslothによる省メモリ化に加えて、シーケンス長を短めに固定する、バッチサイズを1に絞って勾配累積で補う、といった詰めが要ります。

条件を積めば届く一方で、余裕はほぼありません。学習データに長い例が混ざる、うっかりシーケンス長を上げる、といった小さなきっかけでOOMに転びます。12〜14Bを16GBで回すのは「動かせるが綱渡り」と正直に捉えるのが実態に近い。安定を優先するなら7〜8Bに落とすか、24GB級へ移るのが素直な判断です。

当サイトでの実測（RTX 5080／5060 Ti 16GB・Unsloth）

ここまでの必要VRAMは公式ドキュメントと実践報告にもとづく概算でした。実際に手元の16GBのGPU（表示に使っていない側のRTX 5060 Ti）でUnslothを使ってQLoRA学習を回し、ピークVRAMと挙動を測りました。構成は、当サイト検証時点で動作確認した PyTorch 2.10（CUDA 12.8対応wheel）＋Unsloth＋bitsandbytes の4bit、シーケンス長2048・バッチ1が基準です。なお、PyTorchの標準CUDA wheel構成はリリースごとに変わる（新しいリリースほどCUDA 13系が既定になる）ため、再現する際は各ライブラリの対応バージョンを必ず確認してください。

概算では7〜8Bが10〜13GB、12〜14Bが15〜20GBでしたが、実測はそれぞれ約8.6GB・約13.0GBと軽く、16GBで7〜14B級のQLoRAは現実に回ることを確認しました。8Bなら約7GBの余裕があり、シーケンス長やバッチを増やす調整幅も持てます。なお本節で測ったのはピークVRAMと収まり方であって、学習後の出力品質や収束はタスクごとに別途確認が必要です（本記事では未評価）。どのモデルから始めるかは後半の「実務判断」で扱います。

「綱渡り」の正体はヘッドルーム

難所は数字の大小ではなく空き容量でした。同じ8Bでもバッチを2にすると15.3GBまで上がり、16GBの上限際に張り付きます。学習専用に確保したGPUなら辛うじて収まりますが、GPUが1枚だけで画面表示にも使っている場合は、ブラウザなどが数GBを取っていて溢れやすく、Windowsは学習の一部をシステムRAMへ退避させます。この状態に入ると1ステップが数十倍に鈍化し、事実上学習が進みません。当サイトでも表示用のRTX 5080で回した際、1ステップ35秒が587秒まで落ち込むスラッシングを実際に踏みました。学習を回すGPUは他の用途に使わず、バッチとシーケンス長を欲張らないのが安全です。

16bitのLoRAは16GBに載らない

4bitのQLoRAではなく素の16bitでLoRAを試すと、8Bのベースを読み込むだけで14.8GBを占有し、学習に必要な勾配やオプティマイザの分が入りませんでした。単一の16GBでは16bit学習は成立せず、24GB級のGPUが要るという早見表の判定を、実測でも確認しています。ベースを4bitに落とすQLoRAが、16GBを成立させている核心だと数字で見えます。

RTX 50シリーズ（Blackwell）での環境構築

ひとつ環境依存の注意があります。RTX 50シリーズはBlackwell世代のため、PyTorch・bitsandbytes・Triton・xFormersなどを、いずれもBlackwell（CUDA 12.8以降）に対応したバージョンで揃える必要があります。当サイトの環境では、CUDA 12.8対応のPyTorchとUnsloth、bitsandbytesの4bitを組み合わせてQLoRA学習が動きました。UnslothはBlackwell対応を明記しており、対応バージョンを揃える手間を減らす現実的な選択肢です。

2枚目のGPUは思ったほど効かない

2枚目のGPUで大きいモデルを学習したくなりますが、Windowsでは壁が二つあります。第一に、複数GPUへ学習を分散させる定番のFSDPやDeepSpeedはGPU間通信にNCCLを使い、NCCLはWindowsに存在しません。当サイトの環境でも分散学習用のバックエンドは無効で、これらを使うにはWSLかLinuxが要ります。第二に、代替として層をGPUに分けて載せるモデル並列（device_map）は、単一プロセスでメモリ上限を手で詰めれば動きました。16bitの8Bを5080と5060 Tiに分けたところ、自動割り当てが偏って片方がメモリ不足で落ち、上限を手で調整してようやく学習できています（5080側10.5GB＋5060 Ti側13.6GB）。ただしこのdevice_mapによる分割はもともと推論向けの機能で、学習での利用は正式にサポートされたものではありません。しかも層の境界ごとにOculink経由でデータが往復します。14BまではQLoRAで単一の16GBに収まるので、2枚目を持ち出す手間に見合う場面は限られます。単一GPUのQLoRAが最も素直、という結論は実測でも変わりませんでした。

Unslothが16GBを成立させる鍵と、鵜呑みにできない落とし穴

12〜14Bを綱渡りとはいえ16GBに乗せられるのは、Unslothという学習高速化・省メモリ化ツールの存在が大きい。ただし公表される効果値をそのまま信じると足をすくわれる面もあります。効果と注意点をセットで見ていきます。

Unslothの効果（VRAM削減・高速化・checkpointing）

Unsloth公式ドキュメントは、同一条件でVRAMを約30〜70%削減しつつ、学習速度を約2倍に高めると説明しています。カスタムのカーネル実装で計算とメモリの無駄を削るのが要点。加えて、勾配チェックポイント（gradient checkpointing）を活用すると、中間活性化を都度保持せず再計算に切り替えることで、同じVRAMでも扱える実効コンテキスト長を伸ばせます。

導入も難しくありません。HugのTransformersやPEFTと整合するAPIで、元モデルを4bitで読み込む書き方は次のように簡潔です。

from unsloth import FastLanguageModel

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/llama-3-8b-bnb-4bit",
    max_seq_length=2048,
    load_in_4bit=True,
)
model = FastLanguageModel.get_peft_model(model, r=16)

この「4bitで読み込む＋アダプタを足す」という流れが、まさにQLoRAをそのまま実装した形になっています。

広告値とのギャップとOOM報告

一方で、公表される削減率をそのままご自身の環境に当てはめると危険です。実際、データセットの形式（たとえばChatML形式）によっては公表値より多くのVRAMを要してOOMになる、という報告も上がっています（Unsloth GitHub issue #4504）。削減率はモデル・シーケンス長・バッチ構成・データ形式に依存し、条件が違えば結果も動く。カタログ値は「うまくいった場合の上限」に近いと捉えるのが安全です。

12〜14Bを16GBで狙うほど、この余裕の有無が成否を分けます。広告値を鵜呑みにせず、まず小さく確実に動く設定から検証を積み上げる。この姿勢が、綱渡りの領域を渡り切るための前提になります。

学習にかかる時間とデータ規模の現実

VRAMのやりくりが片付いても、次に立ちはだかるのが時間とデータの問題。ここを見誤ると「動くけれど終わらない」「回したのに変化がない」という結果に陥りやすい。手法選びと同じくらい、学習規模の見積もりが実務では効いてきます。

ファインチューニングは、GPUを何十時間も占有する重い作業だと身構える人が多いはず。ところがQLoRAで数B級モデルをタスク特化させる程度なら、想像より短時間で終わります。QLoRA論文（Dettmers 2023）では、65Bモデルを単一48GB GPUで24時間ほど学習させた事例が示されました。7〜8B級を16GBで回す規模なら、桁がひとつ小さくなると考えて差し支えありません。

学習時間を左右するのは、モデルサイズ・シーケンス長・バッチサイズ・エポック数・データ件数の掛け算です。目安として、RTX 4090級のGPUで1000件のデータを3エポック回す場合、概ね2〜4時間の範囲に収まります。ここに含まれる変数のうち、シーケンス長とバッチサイズはVRAMと直結するため、16GBでは長い文脈や大きなバッチを諦める代わりに、学習時間そのものは伸びにくい傾向。トレードオフの構図です。

ひとつ注意しておきたいのが、QLoRAはLoRAより学習が遅い点。4bit量子化されたベースを扱う分、計算の途中で復元処理が挟まるためです。ただし遅くなる度合いはモデル・カーネル・バッチサイズ・実装に依存します。VRAMを節約する代償として時間を払う、という関係になっています。16GBという制約下ではQLoRA以外の選択肢がないので、この遅さは受け入れる前提で計画を立てるのが現実的でしょう。

学習時間の目安と、データは質が量に勝る理由

データ件数を増やせば増やすほど賢くなる、という直感は、ファインチューニングでは裏切られます。むしろ効くのはデータの質。OASST1のような公開対話データセットは全体では大規模ですが、実務の初回学習では、目的に合う高品質な数百〜数千件のサブセットから始めるほうが検証しやすいものです。数万件を雑に集めるより、目的に沿った良質な数千件を用意するほうが結果は安定します。件数を積み増しても、ある地点から改善は頭打ちになります。

つまり16GBのGPUでファインチューニングを回すうえで、データ規模は制約になりにくい要素です。ボトルネックはあくまでVRAMとシーケンス長。手元に良質な教師データが数千件あれば、週末の空き時間で1サイクル回せる、という感覚で捉えて問題ありません。

ファインチューニングは何に効いて、何に効かないか

ここを取り違えると、時間もVRAMも無駄になります。ファインチューニングは万能の「モデルを賢くする魔法」ではありません。効く領域と効かない領域がはっきり分かれる技術です。

向いているのは、語調・出力形式・分類・特定ドメインの言い回しといった、スタイルやタスクへの特化。たとえば「常に敬体で、指定のJSON形式で、社内用語を正しく使って答える」といった振る舞いの調整は、ファインチューニングの得意分野です。プロンプトで毎回長々と指示する代わりに、モデル自体にその癖を覚え込ませる。タスク特化の用途では、LoRA/QLoRAがフル微調整に近い性能を示す例は多いです。QLoRA論文でも、NF4を使った4bitのQLoRAが16bitのフル微調整やLoRAに近い結果を示しています。ただし差はタスク・評価指標・設定に依存します。手法を軽くしたことによる劣化は、タスク特化の用途では気にならないことが多い水準です。

向くタスク——スタイル・形式・分類

具体的に効果が出やすいのは、次のような場面。カスタマーサポートの定型応答を自社トーンに揃える、雑多な入力を決まったカテゴリに振り分ける、特定業界の専門用語を崩さず扱わせる、といったケースです。いずれも「正解の幅が狭く、望ましい出力の型が決まっている」タスク。少量の教師データでも、モデルは型を素早く学びます。

出力フォーマットの固定も相性がよい用途。マークダウンの見出し構造や、決まったフィールドを持つ構造化出力を安定して吐かせたいとき、プロンプトだけでは揺れが出ます。ファインチューニングで型を刷り込めば、この揺れが目に見えて減る。実務で効果を体感しやすいポイントです。

知識の注入がRAG向きな理由

一方で、最新の・更新されていく知識を覚えさせる用途には、あまり向いていません。「自社の最新マニュアルの内容を答えられるようにしたい」「昨日更新された仕様を反映したい」といった知識注入は、ファインチューニングの苦手領域です。理由は二つ。第一に、モデルは学習データを丸暗記するわけではなく、少量のデータから特定の事実を正確に引き出せる保証がない。第二に、知識が更新されるたびに再学習が必要になり、運用コストが跳ね上がります。

こうした知識ベースの用途では、RAG（検索拡張生成）のほうが適切です。外部の文書を検索して、その内容をプロンプトに差し込んで答えさせる方式なら、知識の更新はドキュメントを差し替えるだけで済む。ファインチューニングは一般に「振る舞いを変える」技術であり、「知識を足す」技術ではないと広く理解されています。両者を混同したままファインチューニングに手を出すと、時間をかけたのに事実を間違える、という結果になりがちです。

VRAM 16GB級GPUでの実務判断と最初の一歩

ここまでの整理を、実際のGPU構成に落とし込みます。VRAM 16GBのGPUを1枚持っているなら、着手すべきは7〜8B級モデルのQLoRA、これが最もシンプルで確実な選択です。

理由は明快です。QLoRAはベースを4bitで凍結するためVRAM消費が最小で、7B級なら16GBに余裕を持って収まります。単一GPUで完結するので、分散学習の複雑な設定も要りません。学習するのはアダプタだけなので、生成される成果物も数十MB〜数百MBと軽量。試行錯誤のサイクルを短く回せる点も、初手として理にかなっています。ローカルでLLMを動かす環境そのものの前提は、姉妹サイトのローカルLLM入門記事も参考になります。

なぜ16GB単体・7B QLoRAが最もシンプルか

当サイトの検証環境（推論）では、7〜8B級のモデルは16GBのGPU1枚に収まり、推論なら快適に動く水準にあります。ただし学習は推論とは別レジーム。同じ7Bでも、微調整では勾配やオプティマイザの状態を抱える分、必要VRAMは推論よりずっと大きくなります。だからこそ、ベースを4bitに圧縮して凍結するQLoRA系が16GBでは事実上の第一選択になる。推論で「載る」感覚のまま学習に臨むと足をすくわれる、という点は押さえておきたいところです。

最初の一歩として推奨できる構成は、7〜8B級のベースモデル＋良質な数千件の教師データ＋QLoRA（Unsloth併用）。シーケンス長は2048前後から始め、バッチサイズは1〜2、勾配累積で実効バッチを稼ぐ。この設定なら16GBでOOMを避けやすく、数時間で1サイクル回せます。出力を確認してデータを詰め直す、という反復に入れる状態を作ることが、遠回りに見えて最短ルートです。

2枚目のGPU・シャーディングを持ち出すべきでない場面

2枚目のGPUを増設している場合（たとえば当サイトではRTX 5060 TiをOculinkで接続しています）、これを学習に使いたくなるかもしれません。結論として、QLoRA単GPUの範囲では基本的に2枚目は使いません。複数GPUに学習を分散させるFSDPやDeepSpeedといった仕組みは、13B超の大型モデルをどうしても学習したいときには効きます。ただし設定は一気に複雑化し、Oculink接続の帯域が分散処理のボトルネックになりやすい。16GB単体で収まる7〜8B級を狙う限り、2枚目を持ち出す実益はほとんどありません。

複数GPUで推論を分散させたときの挙動と落とし穴については、当サイトのデュアルGPU検証でも「2枚目が遊ぶ」現象が確認されています。学習でシャーディングを組む前に、まず単GPUのQLoRAで目的が達成できないかを見極める。構成を複雑にするのは、単純な構成で限界に突き当たってからで十分です。

まとめ

VRAM 16GBのGPUでローカルLLMをファインチューニングできるか——答えは、手法を選べばできる、です。フル微調整は7Bですら100GB超〜130GB級を要し、標準的なやり方では16GBの対象外です。LoRAはベースを16bitで抱えるため7Bで28GB前後が目安となり、快適に回すなら24GB級が必要。16GBの現実解は、4bit量子化を伴うQLoRA系の手法が事実上の第一選択です。ベースを4bitで凍結してアダプタだけを学習するこの方式なら、7〜8B級のタスク特化は無理なく回せます。

12〜14Bに手を伸ばすなら、Unslothの省メモリ機能が鍵。ただし公表される削減率は上限に近く、鵜呑みにすればOOMに転びます。余裕を持った設定から積み上げるのが安全策です。データは質が量に勝り、良質な数千件で十分。そして忘れてはならないのが用途の切り分けで、口調・形式・分類の固定はファインチューニング、知識の参照はRAG。ここを取り違えなければ、手元の16GB GPUは十分に実用的な学習マシンになります。まず7〜8B級のQLoRAから、良質な数千件のデータで1サイクル回してみてください。

よくある質問

Q. 16GBのGPUでフル微調整は本当に無理ですか？

7Bモデルのフル微調整でも約100GB超〜130GB級のVRAMを要します。重みに加えて勾配とAdamオプティマイザの状態（モデルの数倍）を同時に保持するためで、16GBでは桁違いに足りません（オフロードや省メモリ化の研究例はありますが、標準的な手順では対象外です）。16GBで学習するなら、QLoRA（4bit量子化＋アダプタ学習）が現実的な第一選択です。

Q. QLoRAやLoRAは、フル微調整より品質が落ちますか？

タスク特化の用途では、LoRA/QLoRAがフル微調整に近い性能を示す例が多く、QLoRA論文でもNF4の4bit QLoRAが16bitのフル微調整に近い結果を示しています。ただし差はタスク・評価指標・設定に依存します。口調や出力形式の調整が目的なら、軽量手法で十分な品質が得られる場面が多いです。

Q. 学習データは何件くらい必要ですか？

質の高いデータなら数百〜数千件で成果が出ます。件数を増やすほど良いわけではありません。公開データセットも全体は大規模ですが、実務では目的に合う高品質な数百〜数千件から始めるほうが検証しやすく、件数より良質なデータを揃えることが結果を左右します。

Q. モデルに新しい知識を覚えさせたいときもファインチューニングですか？

更新される知識の注入には、あまり向いていません。特定の事実を正確に引き出せる保証がなく、更新のたびに再学習が要るためです。最新のマニュアルや仕様を参照させたい場合は、RAG（検索拡張生成）のほうが適切です。

Q. 2枚目のGPUを足せば大きいモデルを学習できますか？

FSDPやDeepSpeedで複数GPUに分散すれば大型モデルの学習は可能になりますが、設定が複雑で、Oculink接続では帯域がボトルネックになりやすい。16GB単体で収まる7〜8B級を狙う限り、2枚目を持ち出す実益は乏しく、単GPUのQLoRAが最もシンプルです。

参考資料

• Tim Dettmers ほか: QLoRA: Efficient Finetuning of Quantized LLMs (arXiv:2305.14314)
• Unsloth 公式ドキュメント: Fine-tuning LLMs Guide
• Hugging Face PEFT 公式ドキュメント
• Hugging Face TRL 公式ドキュメント
• Hugging Face Blog: Beyond LoRA — Can you beat the most popular fine-tuning technique?