微调解决什么
"效果不够好，要不要微调一下"——这个问题在大多数团队里会被过早提出。因为微调听起来是最"正统"的 AI 工程手段，而实际上它通常是最后一个该试的。
原因很简单：提示词、检索、微调改的是三样不同的东西。搞不清这点，就会用最贵的手段去解决一个它解决不了的问题。
1. 三样东西分别改什么
1.1 提示词：改行为约束
语气、格式、什么该做什么不该做、输出多长。成本最低，改一次几分钟。
它改不了模型不知道的东西。你可以要求"用我们公司的术语回答"，但如果模型不知道那些术语是什么，它只会编。
1.2 检索：改输入
给模型它本来没有的事实、时效内容、可引用的来源。这是改输入，不改模型本身（见《RAG 链路与失败模式》）。
它改不了输出风格。检索做得再好，模型的语气和格式倾向还是原样。
1.3 微调：改模型本身
把行为模式写进权重。适合的是稳定的、反复出现的模式：固定的输出格式、特定领域的术语使用、窄任务的判断标准。
它不适合用来注入新知识。这一点值得反复强调，因为它是最常见的误用：拿一堆产品文档去微调，希望模型"学会"这些内容。结果是模型学会了文档的语气，但里面的具体事实仍然会记错、会编。
事实性内容走检索，行为模式走微调。这条分界是这套技术里最重要的一个判断。
2. 微调真正划算的三种情况
第一种：稳定格式。 你需要模型每次都输出一种很特定的结构，而提示词约束不稳定（偶尔跑偏）。微调之后格式合规率会显著提升，且可以省掉提示词里那一大段格式说明（顺带省 token）。
第二种：窄任务上的小模型。 用大模型做分类、抽取、打标这类窄任务，贵且慢。用小模型 + 微调，在这些任务上经常能达到接近的准确率，而成本和延迟降一个量级。
这是最常被证明划算的一种，而且它天然可被评测验证——见《模型选型看哪几项》，用你的评测集测小模型微调前后。
第三种：延迟与数据约束。 自托管小模型可以做到不出网、延迟可控。这时候微调是私有化部署的配套手段，不是效果手段。
3. 先做这三件事
在考虑微调之前，按顺序确认：
提示词是否已经调到位。 很多"效果不够好"其实是提示词写得含糊。这一步的成本几乎为零。
检索是否真的做对了。 如果问题出在召回，微调永远修不好——它只会让模型更自信地基于错误的上下文作答。
有没有评测集。 这一条是硬门槛。没有评测集就不要微调，因为你无法判断微调之后是变好还是变差了，只能靠"感觉好一点了"。而感觉在 AI 项目里是最不可靠的东西（见《评测集怎么变成门禁》）。
三条都过了，才谈微调。
4. 成本结构：数据才是大头
很多人以为微调的主要成本是 GPU。实际上：
数据准备占大头。 收集、清洗、标注、构造输入输出对。几百到几千条高质量样本通常比几万条噪声样本有用。
评测占第二。 要有一个能反映真实分布的留出集，还要有人看结果。
训练本身反而最便宜。 QLoRA 这类方法让单卡微调成为常态（配合 Unsloth 这类优化实现，单卡上微调 7B–8B 级模型是常规操作）。真正烧钱的是反复迭代——而反复迭代的次数取决于前两步做得好不好。
所以一个反直觉的结论：微调项目的主要工作量在数据工程，不在训练。
5. 部署：选什么
5.1 自托管推理
vLLM 是目前最常用的高吞吐推理服务器：PagedAttention 管理显存、连续批处理提升吞吐、对外提供 OpenAI 兼容接口。最后一点很实用——换成 vLLM 之后业务代码只改 baseURL。
Ollama 更适合原型验证和本地开发，部署简单，但吞吐和并发能力不如 vLLM。
其他选择（TGI、SGLang 等）各有侧重，选型时看：是否支持你要的模型结构、连续批处理的实现、是否有 OpenAI 兼容层、并发下的 P99 延迟。
5.2 什么时候值得自托管
三个理由，按说服力排序：
合规。 数据不能出境、不能交给第三方。这个理由最硬，没有替代方案。
成本。 量大到边际成本显著时，自托管的单位成本可能低于 API。但要把 GPU 闲置、运维人力、模型升级都算进去——只算 GPU 单价会得出错误结论。
可控性。 不被供应商的模型更新、限流、下线影响。见《多模型接入与降级链》，自托管还可以作为降级链的最后一环。
如果只是"想试试"，那不值得。自托管带来的是一整套运维责任：驱动、显存、扩缩容、模型版本升级、故障排查。
5.3 自托管的三个硬参数
真要把自托管扛到线上，决定成败的不是"选 vLLM 还是 SGLang"，而是下面三组数字。它们互相牵制，改一个必然影响另外两个。
量化：质量、显存、吞吐的三角。 FP16 是基准；FP8 在多数新卡上几乎不掉质量、显存减半；INT4（AWQ / GPTQ）能再压一半，但长尾任务（代码、数学、结构化抽取）掉点更明显；GGUF 那一套主要面向 CPU / 端侧。经验做法是先量化到 FP8，只有在显存确实不够时才下探 INT4，并且必须用你的评测集复测——不然省下的显存会以"偶发答错"的形式还回来。
KV cache：并发上限的真正瓶颈。 权重之外，每个在途请求都要占一份 KV cache，长度按"上下文 + 生成长度"算。这就是为什么同一张卡，batch 1 能跑 32K，batch 32 可能只跑得动 4K。PagedAttention 解决的是碎片浪费，不解决总量不足。上线前要算清楚：目标并发 × 平均上下文长度 × 每 token 的 KV 占用，和显存余量对一下。
连续批处理：吞吐与单请求延迟的取舍。 连续批处理（continuous batching）把新请求插进正在跑的批次，吞吐能翻几倍，但单个请求的 TPOT 会变差——它在和别人共享算力。所以"吞吐优先"和"P99 优先"要分开部署，或者用不同的并发上限。prefix caching 则是反过来白拿的收益：相同系统提示的请求共享前缀计算，命中率高的场景能直接省掉一大截 prefill。
另外两个值得知道的：投机解码（小模型先猜、大模型校验，延迟敏感场景有效，吞吐敏感场景未必）、multi-LoRA 热插拔（一份基座挂多个适配器，按请求切换，适合"一个基座服务多个租户"）。Embedding 与重排模型同样需要自托管规划，它们的显存需求小得多，但 QPS 通常高一个量级。
6. 微调模型的版本管理
微调产物不是"训完就完了"，它是需要管理的资产：
- 记录训练数据版本。哪批数据训出了这个版本，出问题时能追溯
- 基础模型要固定。基础模型悄悄升级，你的微调产物就和它对不上了
- 适配器单独存。LoRA 适配器体积小，可以和基础模型分开管理，方便回滚
- 评测结果一起存。每个微调版本在评测集上的分数应该和产物放在一起
最后一点最重要：没有分数记录的微调产物，等于没有经过验证的产物。三个月后没人记得它为什么比上一版好。
7. 私有化的真实代价
列一份不太讨喜的清单：
- GPU 成本是持续的，不管有没有流量
- 模型升级要重做一遍：新基础模型 → 重新微调 → 重新评测 → 重新部署
- 容量规划：峰值流量下要不要排队？排队多久？
- 观测与告警：显存占用、队列长度、P99 延迟、错误率
- 人员：得有人能在凌晨处理 GPU 节点故障
这些不是劝退，而是让决策基于完整的账。云端 API 的单价里包含了所有这些，自托管是把它们拿回来自己承担——只有在规模足够大或有硬合规要求时，这个交换才划算。
8. 清单
- 确认问题不是提示词或检索能解决的
- 有评测集，且能测出当前版本的基线分数
- 明确这次微调改的是行为模式，不是事实
- 数据准备好（质量优先于数量）
- 基础模型版本固定并记录
- 训练产物附带评测分数
- 部署方案选好了（高吞吐用 vLLM 这类，原型用 Ollama）
- 算过总成本，包含运维与升级
- 有回滚到上一版本或云端 API 的路径
最后一条容易被漏，但它是唯一一条能让你在微调效果不理想时全身而退的东西。
9. 一句话总结
微调是把稳定的行为模式固化进权重，让小模型在窄任务上更稳、更便宜、更可控。它不是"让模型知道更多"的手段——那是检索的活。
带着这个认识去做，微调通常值得；带着"喂文档让它学会"的期待去做，几乎总会失望。
还有一点是顺序问题：线上攒到样本之后，微调通常不是第一个该试的手段。先在知识侧和提示词侧解决，微调留到格式稳定性与成本成为瓶颈时——排序和理由见《数据闭环怎么接上》。