三种范式的本质区别
面对"如何让模型在我的业务场景中表现更好"这个问题，有三种主流方案，它们针对的是不同类型的"不足"：
Prompt Engineering（提示词工程）
通过精心设计的 System Prompt、Few-shot 示例引导模型输出。零成本，但依赖模型已具备相关能力，对格式和风格的控制有上限。
RAG（检索增强生成）
将外部知识注入上下文，让模型基于检索到的文档回答问题。适合知识更新频繁或私有文档问答的场景，不修改模型权重。
Fine-tuning（微调）
通过有标注数据更新模型权重，将特定行为"烧录"进模型。适合需要改变模型输出风格、格式规范、专业能力的场景。
决策树：我该用哪种方案？
你的问题是什么？
│
├─► 模型不知道某些最新/私有知识
│ └─► 知识会频繁更新？
│ ├─ 是 → RAG（实时检索，无需重新训练）
│ └─ 否 → 数据量 < 1000 条？
│ ├─ 是 → RAG 或 Few-shot
│ └─ 否 → Fine-tuning（将知识烧入权重）
│
├─► 模型输出风格/格式不符合要求
│ └─► Fine-tuning（SFT 最有效）
│
├─► 模型在特定任务（代码/法律/医疗）表现差
│ └─► Fine-tuning（专业能力提升）
│
└─► 模型回答不够"安全"或偏好不对
└─► RLHF / DPO（偏好对齐）
微调真正能解决什么
微调不是万能药，理解它的边界非常重要：
✅ 微调能解决
- 输出格式规范化（JSON、Markdown、特定结构）
- 专业领域语言风格（医疗、法律、客服）
- 减少 Prompt 长度（将 Few-shot 烧入权重）
- 提升特定任务准确率（分类、提取、翻译）
- 注入较为稳定的领域知识
❌ 微调无法解决
- 模型基础能力不足（换更大的基座模型）
- 实时知识更新（用 RAG）
- 超出训练数据分布的新任务
- 数学 / 推理能力的根本提升（需要大量数据）
- 幻觉问题（可减轻但不能消除）
显存需求估算
在决定微调之前，先估算你的硬件是否够用。这是最常被忽略的"入门门槛"：
显存估算公式（近似值）：
全参数微调（Full Fine-tuning, FP16）：
显存 ≈ 参数量(B) × 16 GB
7B 模型 ≈ 112 GB → 需要 A100 80G × 2
13B 模型 ≈ 208 GB → 需要 A100 80G × 3+
LoRA 微调（FP16 基座 + LoRA）：
显存 ≈ 参数量(B) × 2.5 GB（近似）
7B 模型 ≈ 17.5 GB → RTX 3090 / 4090 可以跑
13B 模型 ≈ 32 GB → A100 40G 可以跑
QLoRA 微调（4-bit 量化 + LoRA）：
显存 ≈ 参数量(B) × 0.7 GB（近似）
7B 模型 ≈ 4.9 GB → RTX 3060 12G 可以跑！
70B 模型 ≈ 49 GB → A100 80G 可以跑
注意：以上为单机批量大小=1时的最小显存，实际训练需要更多。
Google Colab 免费版限制
免费 T4 GPU 只有 16GB 显存。使用 QLoRA 可以在 T4 上微调 7B 模型，但批量大小需要设为 1，配合梯度累积。
微调的成本结构
按云计算价格估算（以 A100 40GB 为基准）：
| 方案 | 7B 模型 | 13B 模型 | 适用场景 |
|---|---|---|---|
| QLoRA (A100 40G) | ~$3–10 | ~$8–25 | 个人/小团队验证 |
| LoRA (A100 40G) | ~$10–40 | ~$25–80 | 生产级微调 |
| 全参数 (8×A100) | ~$80–300 | ~$200–800 | 企业级训练 |
| OpenAI Fine-tune | ~$0.008/1K tokens | 快速上线，无硬件 | |
微调前的数据规模指导
50–200 条
可以看到轻微格式/风格效果，但不稳定。适合快速验证数据质量，不建议用于生产。
500–2000 条
大多数专业场景的甜点区。高质量数据 > 大量低质量数据。重点放在数据清洗而非堆量。
5000–50000 条
可以产生明显的能力提升，接近领域专家水平。这是大多数商业微调项目的目标规模。
100000+ 条
接近预训练数量级，通常只有大公司才会走这条路。此时考虑是否直接从头预训练更合算。
黄金法则
1000 条高质量、多样化、覆盖边界 case 的数据，往往比 10000 条低质量重复数据效果更好。微调是数据工程，不是数据堆积。
微调的三种主要方法对比
全参数微调（Full Fine-tuning）
更新模型所有参数，效果最好但资源消耗极大。7B 模型需要约 80-100GB 显存（Adam 优化器状态占大头），通常需要多张 A100。适合：大型企业有充足 GPU 资源；需要从根本改变模型知识体系；数据量 >10 万条且资源充足。大多数业务场景不推荐，成本收益比差。
LoRA / QLoRA（低秩适配）
LoRA 在原始权重矩阵旁边插入低秩矩阵（A 和 B 两个小矩阵），只训练这两个矩阵（参数量约为原模型的 0.1%-1%），大幅降低显存需求。QLoRA 在 LoRA 基础上加 4-bit 量化，7B 模型只需约 5-10GB 显存，消费级 GPU 可以运行。适合：绝大多数企业和个人微调场景的首选方案。
Adapter Tuning（适配器微调）
在 Transformer 层之间插入小型 Adapter 模块，只训练这些新插入的模块。参数效率好，但比 LoRA 稍慢（推理时有额外前向传播开销）。现在已被 LoRA 大部分取代，但在某些需要热插拔（同一基座模型运行多个不同任务的 Adapter）的场景仍有优势。
Prefix Tuning / Prompt Tuning
不修改模型参数，只在输入序列前面添加可训练的"软提示词"向量（连续向量，不是真实 token）。参数量极少（约 0.1% 的 LoRA 的 1/10），但效果相对有限，在小数据集上不稳定。适合：只有少量参数预算；模型权重不允许修改（如 API 服务）。实际部署中较少用。
选择基座模型
微调效果上限由基座模型决定。当前（2025-2026）主流开源选择：
| 模型系列 | 推荐规格 | 特点 | 适用场景 |
|---|---|---|---|
| Llama 3.x | 8B / 70B | 综合能力强，社区生态好 | 通用任务首选 |
| Qwen 2.5 | 7B / 14B / 72B | 中文能力强，指令跟随好 | 中文场景首选 |
| Mistral / Mixtral | 7B / 8×7B | 高效率，推理速度快 | 资源受限场景 |
| DeepSeek V3/R1 | 7B / 67B | 代码和数学能力突出 | 技术类任务 |
| Gemma 3 | 4B / 12B | Google 出品，多模态版本 | 轻量部署 |
选择基座模型
微调效果上限由基座模型决定。当前（2025-2026）主流开源选择：
| 模型系列 | 推荐规格 | 特点 | 适用场景 |
|---|---|---|---|
| Llama 3.x | 8B / 70B | 综合能力强，社区生态好 | 通用任务首选 |
| Qwen 2.5 | 7B / 14B / 72B | 中文能力强，指令跟随好 | 中文场景首选 |
| Mistral / Mixtral | 7B / 8×7B | 高效率，推理速度快 | 资源受限场景 |
| DeepSeek V3/R1 | 7B / 67B | 代码和数学能力突出 | 技术类任务 |
| Gemma 3 | 4B / 12B | Google 出品，多模态版本 | 轻量部署 |
基座模型选择的关键考量
Base vs Instruct 版本
Base 模型（如 Llama-3.1-8B）是纯预训练模型，只会续写文本，不会遵循指令。Instruct 模型（如 Llama-3.1-8B-Instruct）经过 SFT + RLHF，能理解和执行指令。微调时的选择：如果你的任务是对话/问答/指令跟随，必须用 Instruct 版本作为基座；如果是文本生成/续写/补全任务，Base 版本更合适（Instruct 版本会拒绝某些续写请求）。常见错误：用 Base 模型微调对话任务——效果会很差，因为需要从零学习指令格式。
许可证陷阱
开源模型的许可证差异巨大，直接影响商业使用。Apache 2.0（Llama 3.1、Qwen2.5、Mistral）：完全商业友好，可自由部署、修改、销售。CC-BY-NC（某些研究模型）：禁止商业使用，只能用于研究。自定义限制（Llama 2 早期版本）：月活用户 >7 亿需要特殊许可。生产环境务必选 Apache 2.0 或 MIT 许可证的模型，避免法律风险。
上下文长度（Context Length）
模型的最大输入长度限制。Llama 3.1：128K tokens（适合长文档分析）；Qwen2.5：32K tokens（足够大多数场景）；Mistral 7B：8K tokens（短对话场景）。微调时可以通过 RoPE scaling 扩展上下文长度，但效果有限且需要更多显存。如果你的业务场景需要处理长文档（如法律合同、研究论文），优先选择原生支持长上下文的模型。
多语言能力评估
不要只看英文 benchmark。Llama 3.1 的中文能力明显弱于 Qwen2.5（因为预训练中文数据比例低）。如果你的业务主要是中文，用 Llama 微调需要更多中文数据才能达到 Qwen 的效果。测试方法：在你的目标语言上跑 few-shot 测试（不微调），看基座模型的零样本表现——这是微调效果的下限。
微调的隐藏成本
除了 GPU 成本，还有这些
- 数据标注成本：高质量标注 1000 条数据，外包成本约 $500-2000（取决于任务复杂度）。自己标注的时间成本更高。
- 实验迭代成本：第一次微调很少成功。通常需要 3-5 轮实验（调整超参数、数据清洗、格式修正），每轮 $10-50 GPU 成本。
- 模型存储成本：7B FP16 模型约 14GB，每个 checkpoint 都要保存。云存储成本约 $0.02/GB/月，10 个实验版本 = $2.8/月。
- 推理部署成本：微调后的模型仍需 GPU 推理（除非量化）。A100 云实例约 $1-3/小时，24/7 运行 = $720-2160/月。
本章核心要点
- 微调的适用场景：当 Prompt 优化已达极限、需要稳定专业风格/格式、需要注入大量领域知识或大幅降低推理成本时，才考虑微调。盲目微调不如认真设计 Prompt。
- 微调 vs RAG 的选择：知识频繁更新 → RAG；需要改变输出格式/风格 → 微调；需要灌入静态知识 → 两者都可以，但 RAG 更灵活。企业级应用通常两者结合。
- 基座模型选择：从 7B 参数、有 Instruct 版本、持续维护的开源模型开始（如 Llama 3.1 8B、Qwen2.5 7B）；生产级首选 Apache 2.0 许可证；需要中文能力选 Qwen/Yi 系列。
- 硬件门槛：QLoRA（4-bit + LoRA）让消费级 GPU 可微调 7-13B 模型；A100 80G 可微调最大 70B 模型；云端实例（RunPod、Lambda Labs）是自有硬件不足时的首选。