微调自托管 vs 用 API：怎么在两条路中做正确选择
“要不要微调一个自己的模型”是开发者在 API 调用验证业务后常问的问题。通常的触发场景是这样的：Prompt 调了两三周，输出格式还是时不时跑偏，客服同事在群里反馈”这条回答又答非所问了”，于是有人在评审会上抛出一句”要不要上微调”。这时候先别急着立项——直接用 API + 优化 Prompt 往往能解决 80% 的场景，微调的成本和复杂度远超预期，而且一旦决定微调，就意味着接下来几周你要认真面对数据标注、显卡排队、loss 曲线不收敛这些琐碎又费神的事。这篇文章把两条路的真实成本、常见踩坑和判断依据摊开讲清楚，帮你少走弯路。
两条路的本质区别
| 维度 | 直接调用 API | 微调 + 自托管 |
|---|---|---|
| 启动成本 | 几乎为零（一个 API Key） | 高（数据准备 + 训练 + 部署） |
| 迭代速度 | 快（改 Prompt 即可） | 慢（重新训练 + 测试 + 部署） |
| 效果上限 | 受限于基础模型的能力边界 | 可针对特定任务超越基础模型 |
| 数据隐私 | 数据发往第三方 | 数据留在本地 |
| 运维负担 | 零（无服务器） | 高（GPU 节点 + 框架 + 监控） |
| 模型迭代 | 自动（API 升级新模型版本） | 手动（需重新训练或更换基础模型） |
什么场景适合继续用 API？
满足以下条件，优先继续用 API：
- 业务逻辑可以通过 Prompt 表达清楚：System Prompt + Few-shot 示例已经能达到目标效果
- 需要频繁迭代：每周甚至每天都在调整任务定义，微调跟不上迭代节奏
- 调用量不稳定或还在验证阶段：流量波动大，自建闲置成本高
- 对最新模型能力有依赖：新版本 API 自动获益，自托管需要主动升级
关键原则：先做 Prompt Engineering，再考虑 RAG，最后才考虑微调。很多”微调需求”本质上是 Prompt 没写好。
什么场景值得微调？
微调真正发挥价值的条件比较苛刻：
| 场景 | 说明 |
|---|---|
| 特定格式/风格的稳定输出 | 如特定 JSON Schema、行业术语风格，Prompt 难以稳定控制 |
| 领域专业知识注入 | 大量行业特定知识，RAG 检索覆盖不了 |
| 推理效率优化 | 用小模型微调到大模型在特定任务上的效果，降低推理成本 |
| 合规数据隔离 | 数据不能发往外部，必须本地闭环 |
| 高频稳定任务 | 同类任务日均百万次以上，自建边际成本显著低于 API |
微调的隐性成本清单
选择微调前，确保你已经把这些成本算进去：
数据成本：
- 高质量训练数据准备（标注、清洗、格式化）：通常 数周人力
- 数据量要求：SFT（有监督微调）通常需要 500–5000 条高质量样本起步
训练成本：
- 7B 模型 LoRA 微调：通常需要 1–2 张 A100，跑几小时到几十小时
- 全量微调（Full Fine-tuning）：显存需求是推理的 3–5 倍，成本更高
部署与运维成本：
- 微调后的模型需要自己部署，完整推理服务的运维成本参考 自建推理成本测算
持续迭代成本：
- 基础模型升级时，需要重新微调（训练数据、调参、评测全套再来一遍）
微调技术选型
如果确定要微调，主流技术路线：
| 技术 | 方法 | 显存需求 | 适用场景 |
|---|---|---|---|
| LoRA / QLoRA | 低秩适配，只训练少量参数 | 低（1–2 张 24GB 卡） | 大多数场景的首选 |
| Full Fine-tuning | 全量参数微调 | 极高（训练显存 = 推理 × 3–5） | 需要深度定制，有充足 GPU |
| PEFT（Prefix Tuning / IA³） | 参数高效方法 | 极低 | 任务切换频繁，多任务共享一个基础模型 |
| DPO / RLHF | 偏好对齐 | 中高 | 调整模型风格、遵从性，需要偏好数据 |
LoRA + QLoRA 是 90% 场景的正确起点：显存友好，效果接近全量微调，可在消费级 GPU 上完成。
具体到怎么选：如果你只有 1 张 24GB 卡（比如 4090），QLoRA（在 LoRA 基础上把基础模型量化到 4bit 再训练）几乎是唯一现实的选项，7B 模型量化后显存占用能压到十几 GB，代价是训练速度会比 LoRA 慢一些、精度有极轻微损失，绝大多数任务感知不到差别。如果你手上是 A100/H100 这类 80GB 大卡，直接上 LoRA（不量化）训练更快、更稳。全量微调则建议只在两种情况下考虑：一是任务和预训练分布差异极大（比如把通用模型改造成专门的代码生成模型），LoRA 这种”打补丁”式的适配天花板不够高；二是你已经验证过 LoRA 效果不达标，且预算允许——全量微调对显存的要求是同规模推理的 3–5 倍，7B 模型全量微调基本要多卡（4×A100 起步）才跑得动，而且优化器状态（Adam 的一阶二阶动量）会再吃掉相当于参数量 2 倍的显存，这也是很多人第一次跑全量微调直接 OOM（显存溢出）的根源。
微调过程中真实会踩的坑
这几个坑不是理论上”可能发生”，是几乎每个第一次微调的团队都会撞上的：
1. CUDA out of memory（OOM）
现象：训练脚本跑到某个 step 突然报 CUDA error: out of memory 或者 RuntimeError: CUDA out of memory. Tried to allocate ...。根因通常是 batch size 设太大，或者序列长度（max_seq_length）超出了预期——比如你的训练样本里混进了几条超长文本，某个 batch 恰好凑齐了几条长样本，显存瞬间顶爆。修法：先把 batch size 降到 1，用梯度累积（gradient accumulation）凑够等效 batch size；同时对训练数据做长度分布统计，把超过 95 分位数的超长样本单独截断或剔除，别让极端值拖累整体训练稳定性。
2. Loss 不收敛或者震荡
现象：训练几十个 step 后 loss 曲线不降反升，或者上下剧烈跳动。常见根因有三个：学习率设太高（LoRA 场景常见的坑是照搬全量微调的学习率，通常需要调高一个数量级，比如从 2e-5 调到 1e-4 到 2e-4 区间，但具体值要结合你用的框架默认配置核对）；训练数据里有脏数据（格式错乱、标签打反）；或者数据量太少导致模型在几十条样本里反复过拟合又震荡。排查顺序建议是：先抽查 100 条训练样本人工核验格式和标签是否正确，再看学习率和 warmup 设置，最后才考虑加数据量。
3. 微调后效果反而变差（灾难性遗忘）
现象：微调前模型能正常回答的常识问题，微调后开始一本正经地胡说八道，或者只会输出训练集里见过的固定套路。这就是”灾难性遗忘”——模型在拟合你的小样本任务时，把预训练阶段学到的通用能力冲掉了一部分。修法：一是控制训练轮数（epoch），大多数 LoRA 微调 2–3 个 epoch 就够，跑 10 个 epoch 基本必现遗忘；二是在训练数据里混入一定比例（比如 10%–20%）的通用对话样本，让模型”记得”自己还是个通用助手；三是微调完必须跑一遍基础能力评测集，不能只看业务指标。
微调之后，推理部署怎么落地
很多人低估了”微调完成”和”能对外提供服务”之间的距离。微调产出的是一份权重文件（LoRA 场景下是几十到几百 MB 的适配器权重，需要和基础模型一起加载），要真正跑起来对外提供 API，还得解决这几件事：
- 推理框架：用 vLLM、TGI（Text Generation Inference）这类专门的推理服务框架，而不是直接用训练框架（如 transformers 的
generate方法）做线上推理——后者没有做 KV Cache 复用、连续批处理（continuous batching）这些优化，同样的卡吞吐能差 5–10 倍。 - LoRA 权重合并 vs 动态加载：可以选择把 LoRA 权重合并进基础模型（推理时和普通模型无异，但每个任务要存一份完整模型）；也可以用支持多 LoRA 动态挂载的框架（vLLM 较新版本支持），一个基础模型同时服务多个 LoRA 适配器，节省显存。业务线多、每条线数据量不大的场景，优先选动态加载。
- 并发与显存预算：推理时显存占用 = 模型权重 + KV Cache（随并发数和上下文长度线性增长）。7B 模型 FP16 权重约 14GB，剩余显存基本都被 KV Cache 吃掉，24GB 卡上大概能撑几十路中等长度的并发请求，具体数值要用你的真实上下文长度和框架实测，不要凭感觉估。
完整的自建推理部署细节（框架选型、显存测算、成本核算）参考 自建推理成本测算，这里不重复展开。
API Fine-tuning：兼顾两者的折中选项
OpenAI、阿里云等提供商支持 API 层面的微调（Hosted Fine-tuning）：
- 你提供训练数据（上传到平台）
- 平台负责训练和托管微调后的模型
- 调用时和普通 API 体验相同
优点：省去自建推理基础设施；缺点：数据发往第三方，微调成本按 token 计费，定制化程度低于完全自建。
决策树
业务需求
↓
Prompt Engineering 能否解决？ → 是 → 继续用 API，停止
↓ 否
数据能否发往外部？ → 否（合规要求）→ 必须自建（微调或直接推理）
↓ 是
调用量是否稳定且大？（日均亿 token+）→ 否 → 继续用 API
↓ 是
评估自建月总成本 vs API 月费用 → API 更低 → 继续用 API
↓ 自建更低
评估团队是否有 MLOps 能力 → 否 → 招人或用 Hosted Fine-tuning
↓ 是
→ 启动自建/微调
常见问题
RAG 和微调有什么区别，什么时候用哪个？
RAG（检索增强生成）是把外部知识检索后拼入上下文，适合知识库频繁更新的场景；微调是把知识”烧入”模型参数，适合固定的格式/风格/专业知识。优先尝试 RAG，它不需要训练，迭代成本极低。
微调后的模型效果一定比基础模型好吗？
不一定。微调数据质量差、数量不足或任务定义不清，反而会降低效果（“灾难性遗忘”）。微调前必须有清晰的评测指标，且准备好高质量的标注数据。
用 API Fine-tuning（如 OpenAI）和自建微调怎么选？
如果数据不敏感且对基础设施没有特殊要求，API Fine-tuning 是更低摩擦的起点，可以先验证微调是否真的有效，再决定是否值得自建。
延伸阅读：
- 算力决策全景：大模型算力基础：GPU 云、推理部署与 API 取舍
- 自建成本测算：自建推理成本测算指南
- 混合方案设计：API + 自托管混合推理方案
- 算力专题 Hub：算力专题