推論のVRAM方程式は単純だった
RTX 4060の8GB VRAMで7Bモデルを動かす。推論のVRAM方程式は「モデル重み + KVキャッシュ」だけだ。Q4_K_M量子化で約4.68GB + KVキャッシュ0.5GB = 約5.2GB。8GBに対して3GB近い余裕がある。設定を変える自由度がある世界だ。
ファインチューニングは違う。
学習のVRAM方程式は推論の8倍重い
ファインチューニングのVRAMを分解すると、推論にはなかった3つの消費者が現れる。
学習のVRAM方程式:
モデル重み + 勾配 + オプティマイザ状態 + 活性化 = VRAM
Full Fine-Tuning (7B, FP16):
モデル重み: 14GB (7B × 2 bytes)
勾配: 14GB (パラメータと同精度)
オプティマイザ状態: 42GB (8-bit AdamW: FP32マスターコピー + 8-bit momentum + 8-bit variance)
活性化: 可変 (バッチサイズ × シーケンス長に依存)
──────────────────
合計: ~70GB (活性化除く)
推論が2GB/1Bパラメータなのに対し、Full Fine-Tuningは16GB/1Bパラメータ。8倍だ（Modal社のVRAM計算ガイドによる）。
7Bモデルをフルにファインチューニングするには67GB以上のVRAMが必要になる。RTX 4060の8GBでは桁が違う。
QLoRAが開いた道——5GBで7Bが学習可能に
QLoRA（Quantized Low-Rank Adaptation, arXiv:2305.14314）は、この桁違いのギャップを2つの手法で潰した。
1. 4-bit量子化でモデル重みを圧縮
7Bモデルの重みを4-bit NormalFloat（NF4）に量子化する。14GB → 約3.5GB。モデル重みは凍結されるため、勾配の計算対象にならない。
2. LoRAアダプタで学習パラメータを1%以下に
全パラメータを更新する代わりに、各層に低ランクの行列ペア（A, B）を挿入する。学習するのはこのアダプタだけだ。7Bモデルでrank=16の場合、学習パラメータは全体の0.1〜0.3%程度。勾配もオプティマイザ状態もアダプタ分しか発生しない。
QLoRA (7B, 4-bit) のVRAM方程式:
モデル重み (NF4): ~3.5GB
LoRAアダプタ (FP16): ~0.05GB (rank=16, 全体の0.2%)
勾配 (FP16): ~0.05GB (アダプタ分のみ)
オプティマイザ (8-bit): ~0.1GB (アダプタ分のみ)
活性化: ~1.0GB (BS=1, seq=512)
──────────────────
合計: ~5GB
→ 8GBに入る
公開されているVRAM要件の一覧を見ると、構造は明確だ。
| 手法 | 精度 | 7B | 13B | 70B |
|---|---|---|---|---|
| Full Fine-Tuning | FP16 | 67GB | 125GB | 672GB |
| LoRA | FP16 | 15GB | 28GB | 146GB |
| QLoRA | 8-bit | 9GB | 17GB | 88GB |
| QLoRA | 4-bit | 5GB | 9GB | 46GB |
（出典: Modal "How much VRAM do I need for LLM model fine-tuning?"）
QLoRA 4-bitなら7Bが5GB。RTX 4060の8GBに3GBの余裕を持って収まる——計算上は。
しかし推論と学習には、VRAMの「消費者の数」に根本的な差がある。推論はモデル重みとKVキャッシュの2つだけ。学習はそこに勾配、オプティマイザ状態、活性化、CUDAカーネルが加わり6つになる。中でも活性化が厄介だ。推論では各層の活性化を計算後に捨てられるが、学習では逆伝播のために全層分を保持しなければならない。これがバッチサイズとシーケンス長に比例して膨張し、「計算上の余裕」を食い潰す。
1.5Bモデルですら8GBの天井にぶつかる
arXiv:2509.12229 "Profiling LoRA/QLoRA Fine-Tuning Efficiency on Consumer GPUs: An RTX 4060 Case Study"は、まさにRTX 4060（8GB）でのファインチューニング効率をプロファイリングした論文だ。
対象モデルはQwen2.5-1.5B-Instruct。7Bの5分の1のサイズだ。しかしこの「小さな」モデルですら、設定によっては8GBの天井に到達する。
| Run | オプティマイザ | BS | 精度 | スループット | ピークVRAM |
|---|---|---|---|---|---|
| 1 | AdamW | 1 | fp16 | 500 tok/s | 6,234MB |
| 2 | PagedAdamW | 2 | fp16 | 628 tok/s | 8,062MB |
| 3 | PagedAdamW | 2 | bf16 | 360 tok/s | 7,949MB |
（arXiv:2509.12229, Table 1-2より）
Run 2のピークVRAM 8,062MBは、RTX 4060の物理メモリ（8,192MB）の98.4%だ。1.5Bモデルで、バッチサイズ2、シーケンス長2048にしただけで天井に張り付く。
この論文から読み取れるもう1つの重要な事実がある。bf16はfp16より43%遅い（628→360 tok/s）。Ada Lovelaceの第4世代Tensor CoreはBF16/FP16両方をサポートするが、ソフトウェアスタック（PyTorch/CUDA）の最適化状況やメモリ帯域の使い方に差があり、実測ではfp16が大幅に有利だ。ファインチューニングのチュートリアルで「bf16=True」がデフォルトになっていることが多いが、RTX 4060ではfp16を選ぶべきだ。
さらに、PagedAdamWはオプティマイザ状態をCPUメモリにページングすることで25%のスループット改善を達成している。これは8GB環境での必須設定だ。
7Bを8GBに押し込んだときの「監獄」
1.5Bで8GB天井に到達するなら、7Bではどうなるか。
Unsloth（GPU メモリ最適化に特化したファインチューニングフレームワーク）は、2026年時点でQLoRAの事実上の標準になっている。手書きTritonカーネルとメモリ効率化により、Llama 3（8B）で標準実装比63%のVRAM削減と2倍の速度向上を実現している（モデルによっては70%超の削減も報告されている）。
Unslothを使えば、Llama 3（8B）をバッチサイズ1、LoRA rank=32、コンテキスト長2Kで8GB GPUに収めることが可能だ。標準のHugging Face + FlashAttention 2ではOOMになる設定が、Unslothでは動く。
ただし、「動く」と「自由に設定を選べる」は違う。8GBで7B-8Bモデルをファインチューニングする場合の制約を整理する。
| パラメータ | 8GB制約 | 推奨値（16GB+） | 品質への影響 |
|---|---|---|---|
| バッチサイズ | 1（固定） | 4-8 | 勾配ノイズ増大、学習不安定化 |
| LoRA rank | 8-16（Unslothなら32も可） | 32-64 | 表現能力制限、困難タスクで劣化 |
| シーケンス長 | 512-1024 | 2048-4096 | 長文脈の学習不可 |
| gradient accumulation | 必須 (8-16) | 任意 | 実効バッチ拡大は可能だが遅い |
| gradient checkpointing | 必須 | 任意 | 学習時間+20-30% |
| 精度 | fp16一択 | fp16/bf16 | RTX 4060ではfp16優位 |
バッチサイズ1は、毎ステップ1サンプルしか見ない。勾配推定のノイズが大きくなり、学習が不安定になる。gradient accumulationで実効バッチサイズを擬似的に拡大できるが、ステップ数が増えるため時間がかかる。
rankは品質に直結する——だがVRAMが上限を決める
制約テーブルの中で最も影響が大きいのがLoRA rankだ。rankはアダプタ行列の「容量」を決めるハイパーパラメータで、rank=8なら8次元、rank=64なら64次元の低ランク空間で重み更新を近似する。rankを上げるとアダプタのパラメータ数が増え、勾配・オプティマイザ・活性化すべてが連動してVRAMを消費する。8GBではこのチェーンが天井にぶつかる。
arXiv:2512.15634 "How Much is Too Much? Exploring LoRA Rank Trade-offs"は、rank選択が下流タスクの品質と知識保持にどう影響するかを体系的に調査した。
主な知見:
- rank 32-64が最適バランス: 表現力と安定性のスイートスポット。2025年以降の研究でrank 8-16からのシフトが報告されている
- 単純な知識想起（MMLU等）はrank不感応: どのrankでもほぼ同等の性能
- 推論・数学タスクはrank感応: GSM8Kなどではrankによって性能差が出る。ただし興味深いことに、Full Fine-Tuningよりも低rankのLoRAが上回るケースもある
8GBの制約はrankを16以下に押し下げる。これはスタイル適応やシンプルな分類タスクなら十分だが、「モデルに新しい推論パターンを教える」ような高度なファインチューニングでは制約になる。
一方で、LoRA原論文（arXiv:2106.09685）のGPT-3 175B実験では、rank 4でもfull fine-tuningの性能をほぼ回復した。QLoRA原論文（arXiv:2305.14314）も、4-bit量子化下でfull fine-tuningと同等の性能を達成している。
矛盾するように見えるが、これはタスク依存だ。「既存知識の表層を調整する」タスクでは低rankで十分。「新しい知識パターンを獲得する」タスクでは高rankが必要。8GBではVRAMがrankの上限を物理的に決めてしまうため、前者に限定される。
8GBファインチューニングは「何を犠牲にするか」の選択
推論の8GBは「何を動かすか」を選ぶ世界だった。7Bか14Bか、コンテキスト長はどこまで伸ばすか。選択肢があり、組み合わせを探る楽しさがある。
学習の8GBは「何を犠牲にするか」を選ぶ世界だ。バッチサイズを犠牲にして安定性を失うか、rankを犠牲にして表現力を失うか、シーケンス長を犠牲にして長文脈の学習を諦めるか。
では8GBでのファインチューニングは無意味か。そうではない。
8GBで現実的にできること:
- スタイル適応: 出力のトーンや形式を調整する。rank 8-16で十分
- ドメイン特化の語彙強化: 専門用語や定型表現を教える。短いシーケンスで学習可能
- 分類タスクの微調整: センチメント分析、カテゴリ分類など。小バッチでも収束しやすい
8GBでは難しいこと:
- 推論パターンの変更: 数学的推論やコード生成能力の向上。高rankが必要
- 長文脈の学習: 要約、文書QAなど2K+トークンが必要なタスク。活性化メモリが爆発
- 大規模データセットでの学習: BS=1 × gradient accumulationで実効バッチを稼ぐと、学習時間が数十時間に
そして、もう1つの選択肢がある。クラウドGPUだ。RunPodやVast.aiでA100（40GB）を借りれば、7Bモデルのフルパラメータでのファインチューニングも可能になる。時間単価は0.7-1.5ドル/時程度。8GBの制約から解放されるコストとして、検討する価値はある。ローカルで推論し、クラウドで学習する——8GBユーザーにとっては合理的な使い分けだ。
参考
- "Profiling LoRA/QLoRA Fine-Tuning Efficiency on Consumer GPUs: An RTX 4060 Case Study" (MSR Avinash, arXiv:2509.12229)
- "QLoRA: Efficient Finetuning of Quantized LLMs" (Dettmers et al., arXiv:2305.14314, NeurIPS 2023)
- "LoRA: Low-Rank Adaptation of Large Language Models" (Hu et al., arXiv:2106.09685, ICLR 2022)
- "How Much is Too Much? Exploring LoRA Rank Trade-offs for Retaining Knowledge and Domain Robustness" (Rathore et al., arXiv:2512.15634)
- "How much VRAM do I need for LLM model fine-tuning?" (Modal)
- Unsloth Documentation — Benchmarks & Requirements (unsloth.ai)