生产环境微调对比：Claude vs GPT vs Llama 实操指南

TL;DR：大多数团队在本来应该优化检索架构时却选择了微调。Anthropic 目前没有为 Claude 提供通用微调能力——prompt caching、RAG 和上下文工程足以支撑。OpenAI 的微调适合窄范围的风格和格式控制，对领域知识注入帮助有限。开权重微调（Llama 3、Mistral、Qwen）能实现真正的领域适配，但基础设施成本被大多数团队低估了。拿不准的时候：先上 RAG，只有当 RAG 出现可衡量的天花板时，才考虑微调。

微调是当前生产级 LLM 工程中被滥用最多的词。半数需要微调的团队其实只需要一个更好的检索架构。四分之一需要更好的 prompt。剩下四分之一才有真正的微调需求，而且需要选对目标模型——但这个选择取决于大多数决策者未曾预料到的约束条件。

这是来自一线实战的经验。我们跨 Claude、OpenAI、Llama、Mistral 和 Gemini 栈交付生产级 ML 系统，其中大多数项目是因为团队遇到了 prompt 工程的瓶颈而找上门的。下面的比较是我们在 2026 年实际在scope电话中给出的建议。

何时微调 vs 何时 RAG vs 何时做 prompt 工程

决策树很简单，但很少被干净地执行。微调教会模型在风格、格式和语调上达到 prompt 工程无法持续匹配的层面。RAG 教会模型你的领域知识在微调无法经济地覆盖的层面。Prompt 工程是基准线，决定了另外两种方式是否值得尝试。

我们在生产环境中使用的经验法则：

想让模型在每次回复中都像你的品牌调性或遵循非常具体的输出格式 → 微调

想让模型在每次回复中都像你的品牌调性或遵循非常具体的输出格式 → 微调

想让模型使用你的产品文档、支持工单、合同或任何专有文本库来回答问题 → RAG

想让模型使用你的产品文档、支持工单、合同或任何专有文本库来回答问题 → RAG

想让模型基于特定的分析框架进行推理或使用你的评分标准做决策 → prompt 工程，可能需要结构化输出

想让模型基于特定的分析框架进行推理或使用你的评分标准做决策 → prompt 工程，可能需要结构化输出

想把模型压缩到适应你的基础设施或降低推理成本 → 用大模型的优质输出对较小的开权重模型做微调（蒸馏）

想把模型压缩到适应你的基础设施或降低推理成本 → 用大模型的优质输出对较小的开权重模型做微调（蒸馏）

模型在生产任务中答错事实 → 几乎总是 RAG 问题，不是微调问题

模型在生产任务中答错事实 → 几乎总是 RAG 问题，不是微调问题

我们反复看到的错误是团队试图通过微调注入领域知识。技术上可行，但经济上往往不划算。把知识截止日期微调到模型里，意味着每次知识更新都需要重新训练。RAG 在你更新源文件的那一刻就能同步。对于不断变化的知识，RAG 在总拥有成本上永远胜出。

Claude 和 Anthropic 技术栈

Anthropic 目前没有像 OpenAI 那样为 Claude 提供通用微调能力。这让首次规划 Claude 项目的团队感到意外。Anthropic 的理由是：在大多数微调用例中，prompt 工程加 RAG 的组合在 Claude 上效果更好——因为 Claude 处理超长上下文的能力很强，且遵循指令的方式减少了对微调的需求。

在实践中，对于我们运行的负载来说，这在很大程度上是正确的。Claude Opus 和 Sonnet 配合精心设计的 system prompt、对上下文不变部分做 prompt caching，再加上构建得当的检索架构，覆盖了大多数团队寻求微调来解决的需求。唯一例外是需要模型始终按照特定 schema 输出结构的强结构性输出约束场景——这种情况下用 tool use 和结构化输出模式就能搞定。

Prompt caching 是大多数团队使用不足的功能。如果你的 system prompt 加上检索上下文有 40k token，且在一个会话中基本稳定，prompt caching 就能让缓存部分将每次请求成本降低 90%。配合新版 Claude 模型的 extended thinking 模式，这往往是让一个项目从不可承受变为生产就绪的关键模式。

对于确实需要超越 prompt 工程的 Claude 特定适配的团队，Anthropic 的企业级产品包含 prompt 工程支持和评估框架。这在技术层面不是微调，但对于大多数生产用例来说，它以更低的成本产生了相同的效果。

OpenAI 和 GPT 微调

OpenAI 在 GPT-4o、GPT-4o-mini 和 GPT-3.5-turbo 系列上都提供微调。API 成熟，定价透明，过去两年微调成本已降至对窄范围风格和格式调优来说真正经济的水平。

OpenAI 微调的强项：跨数千次请求的输出一致性、超越 tool-use 覆盖范围的格式强制，以及用最少漂移匹配品牌特定的声音或语调。风格和格式任务通常一百到几百个标注良好的示例就够了。

OpenAI 微调被过度推销的地方：领域知识注入。用你的产品文档对 GPT-4o 做微调，感觉像是教会了模型你的业务。实际上，微调后的模型会对训练数据附近但不在其中的事实产生自信的错误答案。RAG 在同样任务上能产生可衡量的改进，还免费附赠来源追溯。如果客服 agent 需要引用它使用的具体文档，RAG 让这变得轻而易举，而微调则完全无法做到。

OpenAI 微调真正有用的一个模式：用 GPT-4o 的输出蒸馏一个 mini 或 Nano 模型，以一小部分成本运行高容量推理。这是微调经济性占主导的情况。蒸馏后的模型在困难任务上不如 GPT-4o，但在你蒸馏它的那套窄任务上又快又便宜。

开权重微调：Llama、Mistral、Qwen

对 Llama 3 8B 或 70B 模型、Mistral Small 或 Large、或 Qwen 2.5 变体做微调，是给予最多控制权但也最多基础设施成本的选项。LoRA 和 QLoRA 让训练变得便宜——单卡 80GB A100 可以在几小时内对 Llama 3 8B 做微调——但推理基础设施才是总拥有成本的大头。

开权重微调胜出的场景：禁止使用美国云端 LLM 提供商的数据主权要求、受监管行业的本地部署、API 定价变得无法承受的超高容量推理，以及需要教模型预训练未包含的概念的专业领域（特定医疗、法律或科学专业）。

开权重微调不占优势的场景：没有 ML 工程资源来做部署的团队。训练是最简单的部分。推理栈——VLLM 或 SGLang 用于服务、请求批处理、监控、模型版本控制、漂移检测——才是总拥有成本所在，而且大多数团队低估了一个数量级。

我们的建议：大多数用例默认走 Claude 或 GPT 的 API 方式。只有当特定约束强制要求时才转向开权重微调——合规、规模或能力差距。不要因为感觉上拥有更多控制权就转向开权重。控制是有成本的。

正确的 RAG 胜过糟糕的微调

检索增强生成是大多数生产级 LLM 价值真正所在。团队犯错的方式是可以预测的。

最常见的错误：按固定字符数分块文档并对每个块做 embedding。这产生的检索返回的是乱序的上下文片段，常常只有半句话。然后模型就会幻觉出连接部分。好的分块应该尊重语义边界——段落、章节、完整的思想——而且通常使用重叠块，这样就没有边界会成为知识悬崖。

第二常见的：查询有强关键词信号时使用纯向量搜索。混合搜索——向量相似度加 BM25 关键词得分再加上融合步骤——在大多数真实负载上优于单独使用向量搜索。Cohere 的 Rerank 或 Voyage 的 rerank 模型以很小的边际成本又带来一次可观的提升。

第三：没有评估循环。一个在你的十个测试查询上表现良好却在第九十个生产查询上悄然失败的 RAG 系统，比毫无用处更糟糕。建立两百到一千个真实用户查询及其正确答案的评估数据集，并在每次检索架构变更时重新运行。没有这个，团队就在黑暗中优化。

多模型编排：何时路由

在我们的视频生成和内容管道中，我们运行多模型编排——将管道的每个阶段路由到主导该步骤的模型。将 brief 解析交给 Claude 做推理，故事板交给视觉模型，图像生成交给在当前主题上保真度最高的模型，产品保真度清理交给专业模型。每个阶段的总成本更低，每个阶段的品质比端到端跑一个模型更高。

这种模式不局限于视频。任何有明确步骤的管道都能从路由中受益。开销很小——只要有一个薄薄的编排层来追踪哪个模型处理了哪个步骤，并让你在新版本上线时可以按步骤切换模型。

生产环境中真正重要的成本计算

在 scope 电话中，成本讨论最终总是走到同一个地方。让我们用现实的数字把账算清楚。

2026 年每百万 token（输入）的成本——近似值：

Claude Haiku 4.5：最便宜层级，快速，适合高容量常规任务

Claude Haiku 4.5：最便宜层级，快速，适合高容量常规任务

Claude Sonnet：中端，大多数生产工作的主力

Claude Sonnet：中端，大多数生产工作的主力

Claude Opus：最高能力，昂贵，用于困难推理阶段

Claude Opus：最高能力，昂贵，用于困难推理阶段

GPT-4o-mini：与 Sonnet 相当，有时略便宜

GPT-4o-mini：与 Sonnet 相当，有时略便宜

GPT-4o：与 Opus 相当，定价也相当

GPT-4o：与 Opus 相当，定价也相当

Llama 3 70B 在 Together AI 或 Groq 上：在 API 层级比 Sonnet 便宜，低容量自托管则更贵

Llama 3 70B 在 Together AI 或 Groq 上：在 API 层级比 Sonnet 便宜，低容量自托管则更贵

Prompt caching 改变了 Claude 的成本计算。如果你的不变上下文是 30k token，每天服务 1000 次请求，缓存层级就能将那部分成本降低 90%。仅此一项就可能是一个项目从不可承受变成经济可行的分水岭。

微调有训练成本（一次性）和推理成本（每次请求，高于基础模型）。对于有高容量的窄范围风格任务，推理数学是有利的。对于中等容量的领域知识，RAG 在基础模型上永远在总拥有成本上胜出。

我们实际给出的建议

对于我们在 2026 年 scope 的大多数生产级 LLM 项目，建议是：通过 API 使用 Claude Sonnet 或 GPT-4o，在有不变量的地方使用 prompt caching，为领域知识搭建proper的 RAG 栈，并从第一天就建设评估基础设施。只有当明确遇到特定天花板且有明确证据表明微调能突破时，才会把微调摆上桌面。

对于受合规约束的负载：Llama 3 或 Mistral 配合 LoRA 微调，自托管，这是答案。工程成本是真实存在的，需要纳入项目 scope 的一部分。

对于窄范围大规模的风格和格式控制：OpenAI 微调是最紧密的选项。一百到五百个标注示例，一次训练运行，输出一致。

对于任何涉及评分、决策或触及单位经济的任务：LLM 保持在辅助角色——起草、总结、解释——决策层放在可审计的 ML 上。这根本不是 LLM 的故事，我们在上面链接的 iGaming 留存攻略中有详细讨论。

构建生产级 LLM 系统但不确定微调是否是正确的杠杆？预约一个电话。我们诚实做scope——如果 RAG 或 prompt 工程能以更低成本达到同样效果，我们在报价微调工作之前就会告诉你。参见 /services/ml 了解我们工作的完整技术栈。

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.