微调通常是错误的选择：大语言模型定制决策框架

大多数构建 LLM 产品的工程团队都遵循相同的路径：提示基础模型，遇到性能瓶颈，然后立即将微调作为解决方案。这种本能反应往往是错误的。

微调是一个强大的工具。它可以释放真实的性能提升，在大规模应用中降低推理成本，并让你对模型行为进行精确控制。但它也带来了隐性成本——在数据、时间、基础设施和持续维护方面——团队通常会系统性地低估这些成本。在许多情况下，提示工程或检索增强（RAG）本可以让他们更快、更便宜地达成目标。

本文为你提供了一个具体的框架，告诉你每种方法在何时胜出，其依据是最近的基准测试和生产经验。

“80% 原则”及其重要性

首先需要内化的是从业者所谓的 80% 原则：在大多数任务中，良好的提示工程（Prompt Engineering）可以让你达到峰值性能的 80% 左右。问题在于，弥补剩下的差距是否值得付出相应的代价。

这个差距因任务而异。对于网络钓鱼检测，微调后的模型性能可以比提示工程高出 10 个 F1 分数——这在安全背景下是一个显著的差异。而在 2024 年的一项临床分类研究中，单样本提示（One-shot Prompting）与精心设计的提示相比，没有提供任何增量收益；基础模型在良好的指令下已经达到了性能天花板。代码生成的情况则比较复杂：微调模型在 MBPP 基准测试上比 GPT-4 提示工程高出 28 个百分点，但在许多实际的代码任务中，这一差距要小得多。

这意味着：如果不进行衡量，你无法知道你的任务属于哪一类。跳过这一步直接进行微调的团队，是在支付训练成本来解决一个他们可能并不存在的问题。

发生了什么变化：Many-Shot ICL 与提示缓存

2024 年的两项进展显著改变了天平，使其向提示工程倾斜。

第一项是多样本上下文学习（Many-shot In-context Learning）。DeepMind 的 NeurIPS 2024 研究表明，将数百到数千个示例填充到长上下文模型的提示中，在摘要任务上可以匹配微调后的性能，甚至在低资源机器翻译上创下了新的纪录——而且无需任何训练。这很重要，因为支持微调的一个常见论点是，它可以让你通过示例教导模型，而少样本提示（Few-shot Prompting）则做不到。随着上下文窗口现在超过 20 万个 Token，对于许多任务来说，这一论点已经显著削弱。

第二项是提示缓存（Prompt Caching）。Anthropic 的前缀缓存（Prefix Caching）可将重复提示内容的输入 Token 成本降低 90%，延迟降低 85%。OpenAI 和 AWS Bedrock 也提供类似的折扣。如果你的少样本示例涉及一组稳定的演示示例，缓存会使多样本提示的推理成本比维护微调模型的成本更具竞争力。“按调用付费与按训练付费”的经济账现在比两年前看起来要接近得多。

微调的真实成本

在决定微调之前，坦诚面对你所承担的投入会很有帮助：

训练成本由于 LoRA 和 QLoRA 的出现而大幅下降。以前每次运行需要花费 30,000 美元以上的 A100 集群，现在可以在单个 RTX 4090 上花 50 到 500 美元完成。全量微调一个 7B 模型仍需要 100–120 GB 显存；QLoRA 可以在 24 GB 的消费级硬件上达到 80–90% 的质量。但即使在这种民主化的趋势下，70B+ 的模型即使使用 QLoRA 也需要 4–8 张 H100，成本会再次攀升。

数据准备是大多数团队感到意外的地方。它通常占微调总成本的 20–40%。来自 Meta 的 LIMA 论文给出的好消息是，1,000 个高质量示例通常就足够了——模型已经通过预训练了解了该领域，微调教授的是格式和行为，而不是事实。坏消息是，“高质量”意味着精心筛选、一致且具有代表性——无论数据集大小，这都是劳动力密集型的工作。

持续维护是没人会写进项目计划的隐性成本。微调模型会过时。当基础模型提供商发布新版本时，你需要重新开始整个过程。你的微调模型可能无法从基础模型推理能力的提升中受益。与此同时，一个设计良好的提示通常可以在几小时内完成更新。

对于小团队来说，MLOps 开销通常超过硬件成本。聘请具有微调基础设施经验的工程师年薪在 17 万至 21.5 万美元之间，而管理模型版本控制、评估流水线和推理基础设施的工具集，其搭建和维护也绝非易事。

微调在何时胜出

尽管如此，在某些明确的场景下，微调仍然是正确的选择：

延迟敏感、高并发的应用。 一个微调后的 7B 模型在特定任务上的表现可以超过 70B 模型，同时运行速度快 10 倍，且每个 Token 的成本仅为一小部分。如果你每月在狭窄、稳定的任务上处理数百万次查询，经济效益会强烈支持定制化的小模型。训练成本的盈亏平衡点通常出现在使用量达到 500 万个 Token 左右时。

严格的数据隐私要求。 HIPAA、PCI-DSS 和类似的合规框架通常禁止将敏感数据发送给第三方 API。对于医疗、法律和金融应用，自托管的微调模型有时是唯一的选择。

真正的知识注入。 为大型律师事务所构建 LLM 工具的 Harvey AI 不仅仅是进行了微调——他们从特拉华州判例开始，使用超过 100 亿个 Token 的美国判例法训练了定制模型。这是因为他们需要注入预训练数据中不存在的真实领域知识。如果你的领域确实非常新颖（专有流程、内部分类法、具有特定含义的专业术语）并且你有数据来教导它，微调就会变得非常有吸引力。

大规模的一致格式和风格。 当你需要每个输出都遵循严格的 Schema 时——如结构化 JSON 提取、特定的文档模板、受监管的披露语言——微调提供了提示工程在大规模生产中难以企及的确定性，特别是当输出需要通过下游自动化系统处理时。

何时坚持使用提示词工程

提示词工程在比大多数团队预期的更多情况下胜出：

• 你拥有的标注样本少于几百个。在数据不足的情况下进行训练会导致模型产生过拟合且泛化能力差。
• 你的任务领域频繁变化。当分布发生偏移时，微调后的模型需要重新训练；而提示词可以在当天完成更新。
• 你需要用一个模型服务于多个任务。为十个用例维护十个微调模型是运维噩梦；一个结构良好的提示词系统通过一个 API 即可处理。
• 你还没有穷尽提示词技术。思维链、结构化输出约束、少样本示例和工具调用在必要进行训练之前，可以释放巨大的性能提升。

在生产环境中行之有效的实际顺序是：从提示词工程开始建立基准线 → 为知识密集型任务添加检索增强生成 (RAG) → 只有当你穷尽了这两者且仍有明显的业务理由支持可衡量的差距时，才进行微调。

对齐税与灾难性遗忘

微调特有的两种失败模式值得关注，因为它们在供应商文档中鲜有提及。

对齐税 (Alignment tax) 是指为了安全性或领域对齐而进行微调，会导致在其他任务上性能下降。EMNLP 2024 的研究表明，在一个 3B 模型中，增加奖励对齐会导致 SQuAD F1 下降 16 点，WMT 翻译 BLEU 下降 5.7 点。2025 年的一篇论文将这一发现扩展到了大型推理模型，表明安全对齐会显著降低推理能力。这是一个活跃的研究课题，目前还没有完美的解决方案。

灾难性遗忘 (Catastrophic forgetting) 是指狭隘的微调覆盖了基础模型原有的通用能力。1B 到 7B 参数的模型特别容易受到影响。实际后果是：你的微调模型在特定评估集上的表现可能超过基础模型，但在相邻任务上却在悄然退化。MIT 的研究人员在 2025 年发布了一种名为“自蒸馏微调”的技术，通过在训练期间将微调前的模型作为正则项来部分缓解这一问题，但这增加了实现的复杂性。

这两种风险都指向同一个缓解方案：在微调之前建立全面的评估 (Evals)，并在整个任务覆盖面上衡量退化，而不仅仅是你优化的那个任务。

决策框架

以下是实践中的决策逻辑：

1. 你能通过提示词工程达到性能目标吗？ 如果可以，到此为止。
2. 失败模式是基础模型不具备的事实性知识吗？ 如果是，在考虑微调之前先添加 RAG。
3. 失败模式是格式、风格或行为吗？ 微调可能是合适的——但要量化你有多少数据。如果优质样本少于 500 个，请先考虑少样本提示或合成数据增强。
4. 任务是否稳定、高频且对延迟敏感？ 计算你的盈亏平衡点：训练成本 ÷ (每 token 成本差异 × 每月调用量)。如果盈亏平衡点在 6 个月以内，微调值得探索。
5. 你是否有禁止使用 API 的合规性要求？ 无论上述情况如何，可能都需要通过自托管进行微调。

如果这些条件都不满足，你可能是在试图通过微调来解决一个本可以通过更好的评估和提示词迭代解决的工程问题。

2026 年的基础设施现状

QLoRA 让微调变得触手可及，但“触手可及”并不意味着“免费”。生产级微调所需的堆栈——实验跟踪、评估流水线、模型服务、回滚机制和持续重训触发器——仍然需要真正的工程投入。训练的民主化并没有民主化运行微调模型的运维负担。

Duolingo 的方法很有启发性：他们对 Duolingo Max 功能使用重度提示词工程配合尖端 API 模型，通过提示词快速达到 95% 的目标性能，然后针对特定的边缘情况进行针对性的、数据稀疏的微调。结果是在没有建立内部微调团队的情况下，实现了 37% 的订阅用户同比增长。

大多数构建 LLM 产品的团队应该效仿这一顺序。在过去两年中，经过精心设计的提示词与微调模型之间的性能差距已大幅缩小。微调仍然很有价值，有时也是必要的——但默认的起点应该是满足要求的最简单方案，而不是最复杂的方案。