1. 先算一笔账：为什么你的AI账单总比预期高
很多人第一次接触大模型API的时候，都会有一种错觉：按token计费，用多少付多少，应该很便宜才对。结果月底一看账单，傻眼了。我身边不止一个朋友跟我吐槽过，说本来预算一个月几十块，结果跑着跑着就上百了，关键是也没觉得自己问了什么复杂的问题。
问题出在哪？出在大多数人只关注了“单价”，没关注“消耗量”。大模型的计费逻辑是按输入token和输出token分别计价的，而且输出token通常比输入token贵好几倍。你每次提问，模型不仅要“读”你的问题（输入），还要“写”出回答（输出），这两部分都在烧钱。更隐蔽的是，很多人不知道，你每一轮对话的历史记录都会被重新当作输入发回去，也就是说，聊得越久，每一轮的输入token就越多，成本是滚雪球式增长的。
我拿一个真实场景举例。假设你用某主流模型做一个连续对话，每轮平均输入500 token、输出300 token。第一轮消耗800 token，第二轮因为要带上第一轮的历史，输入变成1000 token，消耗1300 token，第三轮输入1500 token……到第十轮的时候，单轮消耗已经超过3000 token了。如果你把十轮拆成十个独立的一次性提问，总消耗可能只有8000 token左右，但连续对话模式下可能轻松突破20000 token。这就是为什么很多人觉得“我也没问几个问题啊，怎么钱就没了”。
所以省钱的第一原则不是去找更便宜的模型，而是先搞清楚你的token到底花在了哪里。上下文管理、缓存机制、使用习惯，这三件事做好了，同样的任务成本砍掉一半甚至更多是完全可行的。接下来我会把这几个方向拆开讲，每个都配上我自己实测过的具体做法。
1.1 输入和输出的价格差，比你想的大
先把这个基础概念说清楚，因为后面所有的省钱策略都建立在这个认知上。目前主流大模型的定价策略里，输出token的价格通常是输入token的2到4倍。有些模型输入便宜到几乎可以忽略，但输出依然不便宜。这意味着什么呢？意味着你让模型“少说废话”本身就是在省钱。
我做过一个对比测试：同一个问题，我用两种方式提问。第一种是“请详细解释一下什么是向量数据库，包括它的原理、应用场景、优缺点、和传统数据库的区别，尽量全面”。第二种是“用三句话说明向量数据库是什么、干什么用的”。第一种输出大概800 token，第二种输出大概120 token。输入token差不多，但输出差了将近7倍。如果你的任务只是快速了解一个概念，第二种问法完全够用，成本却只有第一种的零头。
注意：不是让你所有问题都问得简短，而是要根据实际需求控制输出长度。需要详细方案的时候该长就长，但日常查询类的问题，明确告诉模型“简短回答”能省下大量输出token。
1.2 上下文累积：沉默的成本杀手
这是最容易被忽视的部分。大多数对话式API的设计是：你每次发请求，都需要把之前的对话历史一起带上，否则模型不知道你们聊了什么。这个“带上历史”的动作，就是把之前所有的输入和输出都重新计费一次。
我见过最夸张的案例是一个做客服机器人的朋友，他的系统把用户和机器人的全部对话历史都塞进每次请求里，一个用户聊了30轮之后，单次请求的输入token已经超过10000了。他一开始还纳闷为什么成本居高不下，后来把每轮的token消耗打出来一看，才发现问题所在。
解决办法有两个方向：一是控制对话轮数，超过一定轮数就做摘要压缩；二是对于不需要上下文的独立任务，坚决用单次请求而不是对话模式。后面我会详细讲具体怎么操作。
2. 上下文管理的四种实战策略
上下文管理是省钱的核心战场。你不可能完全不带上下文，否则多轮对话就没法用了。但你可以聪明地管理它。我总结了四种策略，从简单到复杂，你可以根据自己的场景选用。
2.1 滑动窗口：只保留最近N轮
这是最简单的策略。你设定一个窗口大小，比如只保留最近5轮对话，更早的直接丢掉。这样输入token就不会无限增长，而是稳定在一个可控范围内。
具体实现上，你需要在每次发请求之前，对历史消息列表做一次截取。伪代码大概是这样：
def build_messages(history, new_question, window_size=5): # 只保留最近window_size轮对话 recent = history[-window_size*2:] # 每轮包含用户和助手各一条 messages = recent + [{"role": "user", "content": new_question}] return messages这个策略的优点是实现简单，成本可控。缺点是如果用户突然提到很久之前说过的内容，模型就“失忆”了。适合那种话题比较独立、不需要长期记忆的场景，比如单次咨询、简单问答。
我实测下来，窗口大小设为5到8轮是个比较平衡的值。太小了体验差，太大了省不了多少钱。你可以根据自己业务的对话特点来调。
2.2 摘要压缩：把老对话浓缩成一段话
滑动窗口的问题是信息直接丢失。如果你希望模型还能“记得”早期对话的要点，但又不想带着全部原文，那就用摘要压缩。
做法是：当对话轮数超过阈值时，把最早的那部分对话交给模型，让它生成一段简短摘要，然后用这段摘要替换掉原始对话历史。这样既保留了关键信息，又大幅减少了token数量。
举个例子，原本10轮对话可能占3000 token，压缩成一段200 token的摘要之后，直接省了2800 token。而且这个摘要是可以逐层压缩的，每超过一定轮数就再压缩一次。
def compress_history(history, threshold=10): if len(history) <= threshold: return history # 把前半部分对话拿去生成摘要 old_part = history[:-threshold//2] summary_prompt = "请用200字以内总结以下对话的关键信息：\n" + str(old_part) summary = call_model(summary_prompt) # 用摘要替换原始历史 new_history = [{"role": "system", "content": f"之前的对话摘要：{summary}"}] new_history += history[-threshold//2:] return new_history这个策略的代价是你需要额外调用一次模型来生成摘要，但这次调用的成本远低于你后续每轮都带着全部历史所多花的钱。长期来看非常划算。
2.3 关键信息提取：只留有用的字段
有些场景下，对话历史里真正有用的信息其实很少。比如订票机器人，聊了20轮，核心信息可能就只有出发地、目的地、时间、人数这几个字段。这种情况下，你完全不需要保留对话原文，只需要把关键信息提取成结构化数据，每次请求时带上这几个字段就行了。
# 不保留对话历史，只保留提取出的关键信息 context = { "出发地": "某城市", "目的地": "另一城市", "日期": "某月某日", "人数": 2 } messages = [ {"role": "system", "content": f"当前已知信息：{context}"}, {"role": "user", "content": new_question} ]这种方式token消耗极低，而且信息不会丢失。缺点是需要针对具体业务设计提取逻辑，通用性不强。但如果你做的是垂直领域的应用，这是最省钱的做法。
2.4 向量检索替代全量上下文
如果你的应用需要模型“记住”大量知识，比如企业知识库问答，千万不要把所有知识都塞进上下文。正确做法是用向量检索，只把最相关的几条内容取出来放进上下文。
具体流程是：把知识库文档切块、向量化、存入向量数据库。用户提问时，先把问题向量化，检索出最相似的3到5个片段，只把这些片段作为上下文发给模型。这样无论知识库有多大，每次请求的输入token都是可控的。
我做过对比：一个包含500篇文档的知识库，如果全量塞进上下文，输入token轻松超过10万，成本极高且大部分模型根本放不下。用向量检索之后，每次只取最相关的3个片段，输入token控制在2000以内，成本降低了98%以上，而且回答质量反而更好，因为模型不会被无关信息干扰。
3. 缓存机制：同样的钱不要花两次
缓存是另一个省钱利器，但很多人没有充分利用。缓存的核心思想是：如果同一个请求之前已经发过了，而且结果没有变化，那就直接把之前的结果返回，不要再调用模型。
3.1 精确缓存：一模一样的请求直接复用
最简单的缓存是精确匹配。你把请求的内容做一次哈希，如果哈希值在缓存里存在，就直接返回缓存结果。这适用于那些重复率高的场景，比如FAQ问答、固定模板生成等。
import hashlib cache = {} def get_answer(question): key = hashlib.md5(question.encode()).hexdigest() if key in cache: return cache[key] answer = call_model(question) cache[key] = answer return answer这个方案实现成本极低，但命中率取决于你的请求重复率。如果是面向公众的客服系统，重复问题比例可能高达30%到50%，光这一项就能省下不少钱。
3.2 语义缓存：意思差不多就别重复问了
精确缓存的问题是，用户换个说法你就匹配不上了。“怎么退款”和“如何申请退款”在精确缓存看来是两个不同的请求，但实际上答案可以一样。
语义缓存的做法是：把请求向量化，然后在缓存里找相似度超过阈值的记录。如果找到了，直接返回缓存结果。这样即使用户表达方式不同，只要意思相近，就能命中缓存。
def semantic_cache_lookup(question, threshold=0.95): q_vector = embed(question) for cached_q, cached_a, cached_vector in cache_list: similarity = cosine_similarity(q_vector, cached_vector) if similarity > threshold: return cached_a return None阈值设多少需要根据你的业务调。设太高了命中率低，设太低了可能返回不准确的答案。我一般建议从0.95开始试，根据实际效果调整。
3.3 模型侧缓存：有些平台自动帮你省
现在一些模型平台提供了自动缓存功能。原理是：如果你的请求前缀和之前的某个请求完全一致，平台会自动复用之前计算过的部分，并对这部分token给你折扣。这个折扣有时候能到50%甚至更多。
要利用这个机制，你需要做一件事：把固定不变的内容放在请求的最前面。比如系统提示词、固定的知识背景、few-shot示例，这些每次都一样的内容放在前面，平台就能命中缓存。而用户的具体问题放在最后，这部分是变化的，不享受折扣。
# 好的做法：固定内容在前，变化内容在后 messages = [ {"role": "system", "content": "你是一个专业的客服助手，负责回答产品相关问题。以下是产品手册内容：..."}, # 固定，可缓存 {"role": "user", "content": user_question} # 变化，不缓存 ] # 不好的做法：把变化内容混在前面 messages = [ {"role": "system", "content": f"当前用户是{user_name}，问题是{user_question}。你是一个客服助手..."} # 每次都不同，无法缓存 ]这个细节很多人不知道，但只要调整一下消息顺序，就能白捡不少折扣。
4. 九个使用习惯，每个都在帮你省钱
前面讲的是系统层面的策略，这一部分讲的是日常使用中的习惯。别小看这些习惯，单个看起来省得不多，但日积月累下来差距很大。
4.1 明确输出格式，减少废话
大模型有个毛病，你如果不限制它，它喜欢在前面加一堆“好的，我来帮你分析一下”“这是一个很好的问题”之类的废话。这些废话也是要计费的。
我的做法是在系统提示词里明确写：“直接给出答案，不要寒暄，不要重复问题，不要总结。”这一句话就能让每次输出减少20%到30%的token。
另外，如果你需要结构化数据，直接告诉模型输出JSON格式，比让它自由发挥再自己解析要省token。因为JSON格式紧凑，没有多余的修饰词。
4.2 用系统提示词替代重复输入
如果你每次提问都需要带上一段背景说明，比如“你是一个法律助手，请根据以下法条回答问题”，那这段说明每次都作为输入计费。更好的做法是把它放在系统提示词里，虽然系统提示词也会计费，但很多平台对系统提示词有缓存优惠，而且你不需要每次手动输入。
更重要的是，系统提示词只需要写一次，后续所有请求自动带上，减少了你自己拼接文本的工作量，也减少了出错概率。
4.3 控制对话轮数，该断就断
很多人用对话式AI的时候，习惯在一个会话里聊到底。聊了50轮还在同一个窗口里。这时候每一轮的输入token已经非常大了。
我的习惯是：一个话题聊完就开新会话。如果确实需要跨话题记忆，手动把关键信息复制到新会话的开头。这样虽然麻烦一点，但成本差距非常大。
具体来说，如果你发现当前会话已经超过10轮，而且话题已经切换了，果断开新窗口。不要觉得“反正它还记得”就继续聊，你记得的每一轮都在花钱。
4.4 批量处理代替逐条调用
如果你有100条数据需要模型处理，不要写个循环一条一条调。把多条数据合并成一个请求，让模型批量处理。这样输入token可能差不多，但输出token会大幅减少，因为模型不需要对每条数据都单独生成一遍格式说明和结尾语。
比如你要给100个产品写描述，逐条调用的话，每条输出可能100 token，总共10000 token。批量处理的话，你给模型一个包含100个产品的列表，让它输出一个包含100条描述的JSON，总输出可能只有8000 token，而且请求次数从100次降到1次，网络延迟和调用开销也省了。
当然批量处理要注意单次请求的token上限，别一次塞太多导致请求失败。一般建议单次批量不超过20条，根据模型上下文窗口调整。
4.5 选择合适的模型，别用大炮打蚊子
不同模型的价格差距可能是几十倍。有些任务用便宜的小模型完全够用，没必要上最贵的大模型。
我的判断标准是这样的：如果是简单的分类、提取、格式转换，用最便宜的小模型就行。如果是需要推理、创作、复杂分析的，再用大模型。如果是介于两者之间的，可以先用小模型试，效果不行再换大的。
举个例子，从一段文本里提取人名和地名，这种任务小模型准确率已经很高了，成本只有大模型的十分之一。但如果你要让模型分析一段法律条款的潜在风险，那还是得用大模型，小模型容易漏掉关键点。
4.6 限制max_tokens，给输出封顶
大多数API都支持设置max_tokens参数，也就是限制模型最多输出多少token。这个参数非常有用，因为有时候模型会“刹不住车”，你问一个简单问题它给你写一篇论文。
设置max_tokens的好处是：即使模型想多写，也会被强制截断，不会产生额外费用。当然设置得太小可能导致回答不完整，需要根据任务类型调整。一般问答类设500到1000，创作类设2000到4000，具体看需求。
提示：max_tokens限制的是输出上限，不影响输入。所以这个参数是纯省钱用的，不会导致你多花钱。
4.7 温度参数调低，减少随机发挥
temperature参数控制模型的随机性。温度越高，输出越多样，但也越容易跑偏、说废话。温度越低，输出越确定、越简洁。
对于大多数实用任务，我建议把temperature设在0.3到0.7之间。太低了输出可能太死板，太高了容易浪费token在无关内容上。如果你需要模型严格按格式输出，直接设0。
4.8 预处理输入，别把垃圾喂给模型
很多人把原始数据直接丢给模型，里面包含大量无关内容。比如你要模型总结一篇文章，结果把网页的导航栏、广告、评论区全都复制进去了。这些内容都会计费，而且会干扰模型。
正确的做法是先做预处理：去掉HTML标签、去掉无关段落、只保留核心内容。这一步用简单的规则或者便宜的小模型就能做，成本远低于让大模型处理垃圾数据。
4.9 监控和告警，别等账单来了才知道
最后一个习惯是监控。你要知道自己每天花了多少钱、花在了哪里。大多数平台都提供了用量查询接口，你可以写个脚本每天拉一次数据，记录到表格里。如果发现某天用量异常增长，及时排查原因。
我自己的做法是设了一个简单的告警：如果单日消耗超过预算的80%，就发邮件提醒。这样不会等到月底才发现超支。
5. 一套可落地的成本优化组合方案
前面讲了这么多策略和习惯，你可能觉得有点散。这一部分我把它们串起来，给出一套可以直接用的组合方案。这套方案是我自己在多个项目中反复验证过的，适合大多数中小规模的AI应用场景。
5.1 第一步：梳理你的请求类型
先把你系统里的请求分个类。哪些是固定问答（FAQ），哪些是多轮对话，哪些是批量处理，哪些是知识库检索。不同类型的请求用不同的策略。
| 请求类型 | 推荐策略 | 预期节省 |
|---|---|---|
| 固定问答 | 精确缓存 + 小模型 | 60%-80% |
| 多轮对话 | 滑动窗口 + 摘要压缩 | 40%-60% |
| 批量处理 | 合并请求 + 限制输出 | 30%-50% |
| 知识库检索 | 向量检索 + 语义缓存 | 70%-90% |
| 简单分类提取 | 小模型 + 低temperature | 80%-95% |
5.2 第二步：从最容易的地方开始
不要一上来就搞复杂的语义缓存和摘要压缩。先从最简单的开始：加精确缓存、设置max_tokens、优化系统提示词。这三件事做完，成本通常就能降30%以上，而且实现成本极低。
等这些基础优化稳定了，再逐步引入滑动窗口、向量检索等更复杂的方案。每引入一个方案，观察一周数据，确认有效再继续。
5.3 第三步：建立成本基线，持续迭代
优化不是一次性的。你需要建立一个成本基线，比如“每1000次请求的平均成本”，然后持续监控这个指标。每次做优化之后，对比基线看效果。如果某个优化没有效果甚至负优化，及时回滚。
我自己的经验是，一个系统经过两到三轮优化之后，成本通常能降到最初的20%到30%。再往下压就比较困难了，需要针对具体业务做深度定制。
6. 几个容易踩的坑和我的实测心得
最后这部分讲几个我在实际操作中踩过的坑，以及一些不太容易从文档里学到的经验。
6.1 缓存不是万能的，过期策略很重要
缓存用不好反而会出问题。我遇到过一种情况：缓存了模型的回答，但后来知识库更新了，缓存里的旧答案还在返回，导致用户拿到过时信息。所以缓存一定要设过期时间，或者在有数据更新时主动清除相关缓存。
我的做法是给每个缓存条目加一个时间戳，超过24小时自动失效。对于知识库问答这种对时效性要求高的场景，过期时间缩短到1小时。
6.2 摘要压缩可能丢关键信息
摘要压缩虽然省钱，但摘要本身是有损的。如果摘要生成得不好，关键信息丢了，后续对话质量会下降。我的经验是：摘要提示词要明确要求保留“数字、日期、人名、地名、关键决策”这几类信息，这些是最容易在摘要中丢失但对后续对话最重要的。
另外，摘要不要压得太狠。我试过把10轮对话压成50字，结果模型完全接不上上下文。后来改成压成200字左右，效果就好多了。省token固然重要，但不能以牺牲可用性为代价。
6.3 小模型不是永远便宜
小模型的单价确实低，但有时候小模型需要更多轮对话才能完成任务，或者需要更长的提示词才能理解意图，综合下来不一定比大模型便宜。我的判断方法是：用同一个任务分别跑小模型和大模型，记录总token消耗和任务完成质量，算一下“每完成一个任务的平均成本”，而不是只看单价。
我实测过一个场景：一个信息提取任务，小模型单价是大模型的十分之一，但小模型需要三次尝试才能正确提取，大模型一次就搞定。算下来大模型的总成本反而更低。
6.4 别忘了网络延迟也是成本
省钱的同时也要考虑用户体验。如果你为了省钱把请求拆得太碎，用户等半天才拿到结果，那省下来的钱可能还不够弥补用户流失。我的建议是：在成本和延迟之间找一个平衡点，不要为了省几分钱让用户等好几秒。
一般来说，单次请求的响应时间控制在3秒以内是比较合理的。如果某个优化方案导致响应时间大幅增加，需要重新评估是否值得。
6.5 定期审查系统提示词
系统提示词是每次请求都会带的，所以它的长度直接影响成本。我见过一些项目，系统提示词写了2000多字，里面很多内容其实可以精简或者移到外部处理。定期审查一下你的系统提示词，把不必要的内容删掉，把可以动态拼接的内容改成按需加载。
我自己的习惯是每个季度审查一次系统提示词，看看有没有可以精简的地方。有一次我把一段500字的说明精简成了100字，效果没变，但每次请求省了400 token，按每天10000次请求算，一个月省了1.2亿token，折算下来是笔不小的数目。
6.6 用日志定位成本异常
如果你的成本突然上涨，一定要有日志能帮你定位原因。我建议在每次请求时记录以下信息：请求类型、输入token数、输出token数、使用的模型、是否命中缓存。这样当成本异常时，你可以快速找到是哪个环节出了问题。
我有一次发现成本突然涨了50%，查日志发现是某个功能的缓存失效了，导致所有请求都直接打到模型。修复缓存之后成本立刻恢复正常。如果没有日志，这种问题很难排查。
6.7 不要忽视输出token的优化
大多数人把注意力放在输入token上，但实际上输出token往往更贵。优化输出有几个立竿见影的方法：明确要求模型“不要重复问题”“不要总结”“直接输出结果”；对于结构化输出，指定JSON格式；对于列表类回答，限制条数。
我做过一个测试：同一个问题，不加任何限制让模型自由回答，输出800 token；加上“用三句话回答”的限制，输出120 token。质量上对于简单问题来说没有明显差异，但成本差了将近7倍。
6.8 考虑混合方案
没有一种策略是万能的。最省钱的做法往往是混合方案：简单请求走缓存，复杂请求走模型；短对话用滑动窗口，长对话用摘要压缩；高频问题用小模型，低频难题用大模型。
我自己的系统里就同时用了精确缓存、语义缓存、滑动窗口和向量检索四种策略，根据请求类型自动选择。虽然实现复杂一点，但成本比单一策略低了40%以上。
6.9 关注平台的计费规则变化
最后提醒一点：各大模型平台的计费规则和价格是经常变的。今天便宜的模型明天可能涨价，今天没有缓存优惠的平台明天可能推出缓存功能。定期关注平台的公告和文档更新，及时调整你的策略。
我有一次就是因为没注意到某个平台推出了新的缓存机制，白白多花了一个月的钱。后来设置了定期查看平台文档的习惯，再也没有错过这类优惠。
以上就是我在AI模型成本优化方面积累的一些经验。核心思路其实很简单：搞清楚钱花在哪里，然后针对性地优化。上下文管理、缓存机制、使用习惯这三个方向，每个都有很大的优化空间。你不需要一次性全部用上，从最简单的开始，逐步迭代，成本自然就降下来了。
