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_size5): # 只保留最近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, threshold10): 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, threshold0.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%简单分类提取小模型 低temperature80%-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模型成本优化方面积累的一些经验。核心思路其实很简单搞清楚钱花在哪里然后针对性地优化。上下文管理、缓存机制、使用习惯这三个方向每个都有很大的优化空间。你不需要一次性全部用上从最简单的开始逐步迭代成本自然就降下来了。 大模型API成本优化实战：上下文管理与缓存机制省钱指南
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_size5): # 只保留最近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, threshold10): 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, threshold0.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%简单分类提取小模型 低temperature80%-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模型成本优化方面积累的一些经验。核心思路其实很简单搞清楚钱花在哪里然后针对性地优化。上下文管理、缓存机制、使用习惯这三个方向每个都有很大的优化空间。你不需要一次性全部用上从最简单的开始逐步迭代成本自然就降下来了。