从提示词缓存到微调：何时该切换

当 AI API 成本开始攀升时，提示词缓存是大多数团队最先伸手去拿的优化手段。它确实管用：Anthropic 的提示词缓存对命中缓存的 token 最多可省下 90% 的成本，OpenAI 也提供类似的折扣。对很多工作负载来说，缓存在几个月甚至几年里都是正确答案。

但缓存有天花板。它压低的是每个 token 的单价，按 token 计费的经济结构本身原封不动。到了某个规模，或者遇上某类工作负载，你会撞上这层天花板，此时需要的是另一种架构选择：微调一个自己拥有、在本地运行的模型。

这份指南讲清楚三件事：缓存在什么条件下够用，在什么条件下已经到头，以及如何完成这次过渡。

提示词缓存的工作原理

Anthropic 和 OpenAI 现在都提供提示词缓存，对重复的上下文能显著降低成本。

机制很直接：如果你的提示词前 N 个 token 在每次请求中都相同，这些 token 就会被缓存在服务商的基础设施上。后续共享同一前缀的请求，只需支付正常输入 token 价格的一小部分。

Anthropic 提示词缓存：

• 命中缓存的输入 token：优惠 90%（只付正常输入价格的 10%）
• 可缓存前缀的最小长度：Claude Sonnet 为 1,024 个 token，Haiku 为 2,048 个
• 缓存有效期：5 分钟（每次命中后刷新）

OpenAI 提示词缓存：

• 命中缓存的输入 token：优惠 50%
• 超过 1,024 个 token 的提示词自动缓存
• 自 2025 年底起无需显式开启

对一个典型的 SaaS 场景来说，系统提示词有 2,000 个 token 且在各次请求之间保持不变，省下的开销相当可观：

仅仅是把系统提示词缓存起来，成本就降了 72%。不改代码，不换模型，质量不受影响。

提示词缓存是正确答案的场景

以下这些条件成立时，缓存就是最优解：

1. 你有一个又大又稳定的系统提示词。 系统提示词相对用户输入越大，省得越多。5,000 个 token 的系统提示词配 200 个 token 的用户输入，比 800 个 token 的系统提示词配 2,000 个 token 的用户输入省得多。

2. 你的请求量处于中等水平。 在每月 10,000 到 100,000 次请求的量级上，缓存也许已经能把账单压到可以接受的程度。微调有一笔前期的时间投入，需要靠持续的节省来抵消。

3. 你的用例变化频繁。 如果你每周都在迭代 AI 功能，改系统提示词、加新的任务类型、试各种输出格式，缓存让你无需重新训练就能继续迭代。微调会把行为固定下来，之后再改要花力气。

4. 你手上还没有训练数据。 缓存零数据起步，第一天就能用。微调需要 500 到 5,000 条高质量训练样本。如果 AI 功能还处在早期阶段，缓存为你争取到积累这批数据的时间。

5. 你需要前沿模型的能力。 缓存让你以更低的价格用上最好的模型；微调给你的是一个针对特定任务训练过的更小模型。如果你的任务确实需要 Claude Opus 或 GPT-4o 级别的推理能力，缓存能让你留在这些模型上，同时把开销降下来。

你已经超出缓存适用范围的五个信号

信号 1：缓存之后 API 账单依然太高

算一笔账。如果缓存之后每月 API 成本仍在 AU$5,000 以上，并且随使用量继续上升，那么缓存降低的只是这条曲线的斜率，线性的按 token 成本结构照旧。每次请求你仍然按 token 付费，只是单价低了一些。

举个例子：一个 SaaS 产品每月 500,000 次请求，系统提示词 3,000 个 token。

• 不使用缓存：约 AU$15,000/月
• 使用缓存（Anthropic，缓存 token 优惠 90%）：约 AU$5,200/月
• 使用微调后的本地模型：约 AU$1,200/月（固定的基础设施成本）

缓存把成本削减了 65%，本地模型削减了 92%。在这个量级上，每月多省下的 AU$4,000 足以支撑微调这笔投入。

信号 2：大部分 token 来自用户输入，而不是系统提示词

缓存只对重复的前缀起作用。如果你的请求是短系统提示词加上又长又各不相同的用户输入，比如文档处理、邮件分析、代码审查，那么可缓存的部分就很小。你可能在总共 8,000 个 token 里只缓存了 1,000 个，折扣只作用于 12.5% 的输入 token。

这类情况下，缓存带来的节省是 5-15%，而不是 60-90%。这个幅度不足以改变你的毛利结构。

信号 3：任务定义明确且高度重复

如果 80% 的 AI 请求遵循同一套模式，相同的输入格式、相同的输出格式、相同的任务类型，这就是一个微调信号。这类模式正是微调所要吸收的东西。微调模型完全不需要系统提示词就能给出同等质量的输出，因为行为已经内化进了模型权重。

缓存优化的是把指令送达通用模型的这条路径。微调让模型把任务学进去，指令这一步就省掉了。

信号 4：你想拥有自己的模型和数据管道

缓存让你留在别人的基础设施上，受制于对方的价格调整、模型下线时间表和速率限制。微调给你的是一个完全由你控制的模型。你可以跑在自己的硬件上，部署到物理隔离的环境里，也无需担心 API 服务商改条款。

信号 5：延迟很关键，而缓存已经不够

命中缓存的提示词比未命中的快，但它们依然是云端 API 调用。典型延迟：命中缓存的请求要 500-2,000ms；同一个请求交给跑在像样硬件上的本地微调模型，只要 50-200ms。如果你的产品需要 200ms 以内的 AI 响应，比如实时建议、行内自动补全、交互式工作流，本地推理就是那条路。

决策框架

下面是这套框架的表格形式：

如果你在“切换到微调”这一列勾中 3 项以上，就该开始规划迁移了。

迁移路径：从缓存到微调

这次过渡是渐进的，可以分步推进。具体流程如下。

步骤 1：盘点你的缓存工作负载（1 周）

分析过去 30 到 60 天的 API 日志：

• 你一共有多少种不同的任务类型？
• 缓存 token 与独特 token 各占多大比例？
• 请求复杂度的分布是怎样的？
• 哪些任务的输入/输出模式最稳定？

步骤 2：构建训练数据集（1-2 周）

你现有的 API 响应就是训练数据。对每一种想要迁移的任务类型：

• 从 API 日志里导出 2,000 到 5,000 对请求-响应
• 筛出高质量的响应（用户没有重新生成、也没有编辑过的那些）
• 整理成指令-响应对的格式

这批数据你早就有了，它就躺在 API 日志里。每一次 API 调用你都已经为它付过钱。现在它变成了那项能消除未来 API 成本的资产。

步骤 3：微调并评估（1 周）

在你的数据集上微调一个 7B 或 14B 模型。用 QLoRA 的话，GPU 时间不到 2 小时。然后做评估：

• 在一个 200 到 500 条样本的测试集上运行微调模型
• 把输出与 API 给出的黄金标准做对比
• 按你自己的标准打分（准确率、格式合规、语气）
• 目标：在定义明确的任务上达到 90-95% 以上的质量对等

步骤 4：部署并做路由（1 周）

通过 Ollama 或 llama.cpp 部署微调模型，前面挂一个兼容 OpenAI 的 API 端点。更新路由，把已迁移的任务类型发给本地模型，云端 API 保留作兜底。

步骤 5：监控并迭代（持续进行）

在生产环境中跟踪质量指标。常见的监控做法：

• 对 5% 的本地模型响应做影子打分，与云端 API 的结果对比
• 跟踪用户反馈信号（重新生成率、编辑距离、满意度评分）
• 每月用模型处理得不好的新生产样本重新训练

哪些请求留在云端 API 上

微调之后，云端 API 仍有它的位置。以下这些继续走带缓存的云端 API 调用：

• 新的实验性功能，提示词和任务定义都还在迭代中
• 长尾边缘情况，微调模型见过的这类样本还不够多
• 需要广泛世界知识的任务，而这些知识会随时间变化（时事、最新数据）
• 复杂的多步推理，确实能从 200B 以上参数的模型中获益

多数 SaaS 产品的终态是一种混合模式：70-90% 的请求交给微调的本地模型，10-30% 走带缓存的云端 API 调用。大头流量拿到本地推理的成本结构，真正需要前沿能力的那部分任务拿到前沿模型的能力。

规模化之后的成本对比

下面是一个 SaaS 产品从每月 100,000 次请求增长到 500,000 次请求的 12 个月成本预测：

与直接调用 API 相比，缓存在 12 个月里省下 AU$70,200。微调混合方案在缓存的基础上再省 AU$19,500，相对仅用 API 的方案总共省下 AU$89,700。

规模越大，差距拉得越开。到每月 100 万次请求时，微调混合方案的成本与 50 万次请求时基本相同，因为基础设施是同一套；而纯 API 和带缓存的 API 这两种方案的账单都会翻倍。

这次过渡是可逆的

这条迁移路径有一个好处：它可以往回走。如果微调模型在某个任务类型上表现不佳，就把这个任务类型路由回云端 API，同时补充训练数据。你不会被锁死在某一边。

你的路由层给你的是一个旋钮，而不是一个开关。随着微调模型越来越好，逐步把它拧向本地推理，同时为确实需要的任务保留云端 API。

把这次过渡执行到位的团队，最后能兼得两边的好处：复杂任务上有前沿模型的质量，其余任务上有微调模型的效率，还有一套随业务一起扩张、而不是和业务对着干的成本结构。

---

延伸阅读

• 从提示词工程到微调：从提示词一路走到微调模型的完整旅程
• 如何微调 LLM：为你的第一个模型准备的分步微调指南
• 从 API 升级到微调：面向 SaaS 的迁移实战手册