大模型的提示词每轮都要重新计费吗？Token 消耗原理与省钱方案

不少开发者把大模型当成一个「配置一次、长期复用」的工具：把角色设定、输出格式、业务规则写进一段很长的提示词，之后每次只提一个新问题，希望账单上只出现「新问题 + 回答」这两部分。真实的疑问是——后面每一轮，那段固定提示词和此前所有对话历史，还要不要重复付费？

结论不算乐观，但也不是没有优化空间。下面把原因和可落地的做法拆开讲。

先明确：主流大模型 API 是无状态的

服务端不保存你的会话。每一次 HTTP 请求都是独立的一次推理，模型能「看到」的全部内容，只有这次请求体里带的 messages（或 input）。它没有跨请求的持久记忆。

由此可以推出三件事：

• 那段固定提示词，必须在每次请求里重新发送、重新计入输入 token；
• 若想让模型「记得」历史，历史同样要每次拼进请求；
• 所谓「让它记住」，只是客户端帮你把它写进每次请求，而不是服务端替你存着。

网页版聊天界面看起来能记住上下文，本质也一样：前端把历史消息攒起来一起发。上下文窗口不等于长期记忆，它只是单次请求能容纳的长度上限。

所以「只发新问题、只付新问题的钱」在通用 API 上无法实现，区别只在于这段重复内容按什么价格计费。

提示词缓存：省的是钱，不是传输

缓存功能常被误解为「存住提示词，以后不用再发」。实际是：请求仍要完整发送，只是计费时对命中的相同前缀给折扣。

原理大致是：请求开头的一段内容（system 提示词、工具定义、长文档、few-shot 示例）如果与之前某次请求逐字一致，服务端可以复用已算好的中间状态，这部分按更低价格计费，有的还单独收一次缓存写入费用；未命中的部分照常计价。Anthropic、OpenAI、Google 以及国内的 DeepSeek 等都提供类似能力，但折扣比例、最小可缓存长度、缓存有效期差异很大，请以各家官方文档的最新说明为准。

使用要点：

1. 提示词放在最前面，且逐字不变，才能命中；
2. 别在 system 内容里插入时间戳、随机 ID、用户名等每次都变的东西，前缀一断，缓存全部失效；
3. 注意有效期，间隔太久会过期并重新写入；
4. 缓存降低的是费用和首字延迟，不改变「上下文必须整段发送」这个事实。

工程上真正能省 token 的几种做法

缩短并稳住前缀

先审查那段提示词：有没有可以删掉的客套话、重复约束、示例堆砌？把稳定不变的内容（角色、规则、格式约定）放前面，把每次变化的内容（用户问题、检索到的资料）放后面。这既利于缓存命中，也减少每轮的固定开销。

限制携带的历史轮次

多数客户端（如常见的第三方聊天客户端）支持设置「保留对话轮次」。把系统提示词设为 role: system，历史保留轮次设为 1，就等于每轮只带提示词 + 上一问一答。代价是模型会忘掉更早的上下文，适合独立问答型任务，不适合连续推理或多步调试。

摘要式记忆

让模型定期把已发生的对话压缩成一段简短摘要，下一轮用「摘要 + 最近一两轮原文」代替完整历史。注意摘要本身也要花 token 生成，且会丢失细节，字段名、报错信息这类必须精确的内容不要放进摘要。

微调或蒸馏

如果提示词非常长且内容固定（例如固定的输出规范、固定的分类体系），可以考虑把这套规则通过微调固化进模型权重，之后调用时不再发送长提示词。微调有训练成本和维护成本，规则一改就要重训，只适合长期稳定、调用量大的场景。

把规则写成代码

输出格式校验、字段拼装、是否重试这类确定性逻辑，交给程序做比交给模型做更便宜也更可靠。模型只负责必须由它判断的那部分。

一个最小请求示例

下面这种结构每轮都会被完整发送，system 部分就是重复成本所在：

{
  "model": "<你的模型名>",
  "messages": [
    {"role": "system", "content": "固定的角色设定与输出规则……"},
    {"role": "user", "content": "这次的具体问题"}
  ]
}

如果服务商支持缓存，通常只需要保持这段 system 内容（及工具定义等前缀）在多轮请求中完全一致，无需额外改动请求结构；是否生效可查看响应里的缓存命中字段（字段名各家不同）。

检查清单

• 在响应的 usage 字段里核对输入、输出、缓存命中三类 token 各是多少，别凭感觉估算；
• 确认提示词里没有混入动态内容，破坏前缀一致性；
• 评估历史轮次上限，找到成本与效果的平衡点；
• 长文档类任务考虑把文档做成可缓存前缀，而不是每轮重新粘贴；
• 不要把「省 token」做到损害答案质量的程度，返工重问往往更贵。

小结

大模型 API 没有跨请求的记忆，固定提示词和历史上下文每轮都要重新发送、重新计入输入 token，这一点无法绕过。能优化的只有价格和体积：用提示词缓存拿到折扣，用精简前缀、限制历史轮次、摘要记忆压缩每轮内容，用微调在超高频固定规则场景下彻底去掉长提示词。选哪种，取决于你的提示词有多长、规则有多稳定、调用量有多大，以及能否接受模型忘掉更早的对话。