我们直接把话挑明大模型API的账单是每个做AI应用的人迟早要面对的一道坎。模型越强token越贵哪怕你只是调个接口做点小功能一个月下来账单也可能让人肉疼。我自己在好几个项目里摸爬滚打踩过不少坑之后慢慢摸索出一套能实打实把token消耗压下来的方法。这套东西不复杂核心就三招先把没用的回答砍掉再管好上下文最后优化重试逻辑。听起来简单但每一步都有讲究。这篇文章不跟你聊那些虚头巴脑的理论全是实操。我尽量把每一步的原理、计算方式、代码层面的写法都摊开讲方便你直接照着调整自己项目里的调用逻辑。1. 整体思路token消耗的两条线得分开算很多人一上来就纠结“为什么我的token用量这么大”却很少去算这笔账具体花在了哪里。其实大模型的token消耗就两条线输入token和输出token。不管是什么模型的计费体系基本都围绕这两个维度展开只是权重不同。输入token包含你发给模型的全部内容系统提示词、历史对话、工具返回的结果、用户当前输入。输出token则只有模型生成出来的文字。在大多数主流模型的定价表里输出token的单价通常是输入token的3到5倍。也就是说你省下10个输出token比省下10个输入token更划算。但很多人的优化重点却恰好搞反了。我见过有人疯狂压缩system prompt省了几百个输入token却忽略了模型每次都在生成长篇大论形式的废话一次回答多输出几百个token。这等于捡了芝麻丢了西瓜。所以我的建议是优化顺序永远是先输出、后输入、再重试。标题里说的“先缩短无用回答”就是这个意思。先让模型别再说废话再考虑怎么减少发给它的内容最后才是通过控制重试次数来避免重复计费。这三者的优先级是递进的千万别跳步。1.1 为什么输出token才是“大头”我做个简单的测算。假设你的模型输出单价是输入单价的4倍你每次请求的输入是800 token输出是600 token。那一次请求的综合成本换算成“输入token等价单位”就是800 600x4 3200。如果你能把输出从600砍到350总成本降到800 350x4 2200降幅超过30%。但如果只是把输入从800压到500输出不变总成本是500 600x4 2900降幅不到10%。这个账算下来结论就非常明确动输出的收益远大于动输入。所以在整个优化链条里第一步永远是先审视模型到底输出了多少没用的东西。1.2 从源头建立“token预算”意识要想系统性地降低消耗光靠零散的省法不行你得有预算意识。我习惯在项目的初期就给每个功能模块定一个“token预算”就像给代码定性能指标一样。比如一个文本分类场景我允许它在单次调用中最多消耗800 token一个客服机器人会话单轮不超过1500 token。预算一旦设死后续所有优化动作都围着这个数字转。这个做法最大的好处是能逼着你去量化每次调用的实际消耗。别光看计费平台上的估算值因为很多平台算的是“按字符粗估”不精确。如果你做的是普通文本应用可以自己写个简单的tokenizer统计函数大多数模型都提供了对应的编码库比如开源社区的tiktoken类工具把每次请求的输入输出都打日志记录下来。坚持一段时间你就能看清哪些场景超支哪些场景还有压缩空间。2. 缩短无用回答先让模型学会闭嘴“让模型少说话”这件事听起来很无脑做起来却有很多门道。我踩过的坑告诉我改prompt只是最浅的一层真正能让输出大幅缩短的是你对任务本身的拆解。2.1 用“任务类型”决定输出结构大模型不是人它没有“自觉删减废话”的能力你给它的指令是什么它就按什么模式输出。如果你只丢给它一句“请回答下面的问题”那它大概率会按训练数据里的习惯给你一段有开头、有展开、有结尾的“小作文”。你需要在prompt里明确告诉它这是一个什么类型的任务目标输出是什么。我测试过几种任务类型下的输出长度差异。同样的一个问题如果让模型“直接给答案”并限制“不要解释”输出往往能减少40%到60%。如果你让它“先给出结论再补充最多2条理由”那输出结构也会紧凑很多。这里有个小技巧不要用“请简要回答”这种模糊表述。“简要”在不同模型眼里有不同的定义有的模型觉得写200字就算简要了。你得给硬性约束比如“全部回答不超过80字”“只输出一个JSON不要任何额外文字”。数字化的约束比形容词约束可靠得多。2.2 错误回答的“缩句”后处理不管prompt写得再清楚模型总有没有发挥好的时候尤其是那些复杂推理任务输出的内容经常绕来绕去。这时候除了修改prompt我还会再加一层“缩句后处理”——就是用一次低成本的模型调用去压缩前一次的高成本输出。举个例子我先让一个强模型做了一次详细分析产出了1000字的回答。如果我直接把这段回答展示给用户当然没问题但消耗已经产生了。可如果这个分析过程比较长而且嵌在一个多次调用的链路里前面生成的内容可能只是给后面做基础的那我就可以在中间插一次压缩用一个小模型把前面的结果浓缩成两三句话。我做一个内容摘要功能时就是这么干的先用一个大模型阅读全文并生成详细要点再调用另一个价格更低的模型把这堆要点压缩成50字以内的摘要。这一步额外消耗的token不多但因为摘要被反复用在后续的流程里节省下来的输入费用反而很明显。当然这里要算清楚压缩成本如果压缩本身要消耗1000 token而你只省了500 token的后续输入那就是亏本买卖。2.3 系统提示词里的“输出最小化”设计系统提示词是约束模型行为的第一个关口。我建议把“输出最小化”作为一个专门的模块写进system prompt里而不是简单地混在对话规则中。它应该包括三块输出格式、输出长度、禁止项。输出格式很好理解比如“只输出JSON”“每条要点不超过20字”。输出长度就是我上面提到的数字约束。禁止项则是明确告诉模型什么不能做比如“不要寒暄”“不要复述问题”“不要给出多条备选答案只选一个最优解”。我还见过一个比较极端的做法直接把“每次回答能节省XX成本”这种话写进prompt里说“你的回答每多一个无关词就会浪费团队资源”。从结果上看这个提示模型理不理解不重要它确实会让输出变得收敛。当然这种情感绑架式写法不是什么场景都合适但它背后反映的一个原则是对的prompt里要有关于成本的明确信号模型才能朝那个方向优化。2.4 多轮对话里的“输出历史抑制”如果你做的是多轮对话应用会遇到一个特别烦人的现象模型在回答新问题时总喜欢把之前已经说过的结论再重复一遍。这种重复性输出非常消耗token而且毫无意义。解决办法是在每轮生成之前明确告诉模型“以下是本轮讨论的历史结论新回答中不要重复它们只补充增量信息。”我在客服机器人项目里用上了这个思路效果非常明显。原来每轮对话平均要输出800 token做了历史抑制后直接降到350 token左右。不过这里有个难点你怎么知道模型哪句话算重复我目前的方案是在把历史上下文组装好之后额外加一句“本轮回答仅针对用户最新问题历史中已回复过的信息不要再提及”。配合上上下文截断策略下面会讲到大部分情况下模型都能克制住自己。3. 上下文管理输入token的“精装修”工程说完输出再来对付输入。输入token优化最大的误区是一味追求“短”恨不得每句话都精简到不能再精简。但问题是上下文太少的话模型可能理解不了任务生成质量就会下降反而导致重试变多、输出变长。所以上下文管理的正确姿势应该是不追求最短而追求最有效。3.1 组装上下文的五级结构我习惯把一个完整的请求上下文拆成五层系统指令层模型的人设、技能、任务说明。数据层需要被处理的核心数据比如你要分析的文档内容、要转换的表格。对话历史层过去几轮用户的提问和模型的回答。工具结果层调用外部API或数据库返回的结果。当前输入层用户此刻发来的问题。这五层里面最容易膨胀的是对话历史层和工具结果层。对话历史越攒越多工具结果越积越长最后请求的输入token直接爆表。我一般给每层单独设一个“token上限”组装请求前对每一层做截断判断而不是等到整个请求快超限了再来一刀切。3.2 上下文滑动窗口怎么切才不伤效果所谓滑动窗口就是只保留最近N轮的对话。很多教程会说“保留最近5轮”或“保留最近10轮”但我觉得这种固定轮数的方式太粗糙了。不同的对话场景对历史长度的需求完全不同。一个技术排障助手可能需要参考最近5轮里用户描述过的错误信息一个闲聊机器人保留最近3轮就够。我自己的做法是按token预算反向计算轮数。比如我设定对话历史层最多占1500 token那我从最近的对话开始往前数直到累计token数接近1500就截断。这样即使某一轮用户发了一段超长的代码也不会挤掉后面更有用的对话信息。还有一个要点是截断的时候不要直接从中间一刀切尽量在“完整的对话轮次”边界上切。因为从中间切掉的内容往往会让上下文语义不完整模型需要费力去猜那些残缺的引用反而会影响生成质量。3.3 相关性与上下文压缩只做截断还不够因为有些历史内容虽然最近但跟当前问题八竿子打不着。你可以给每一轮对话做个相关性打分用一个轻量模型或者简单的关键词匹配来判断它跟当前问题的关联度。相关性低的哪怕发生在上一轮也可以不塞进上下文。我在做一个信息抽取项目时用户会连续问很多个不同维度的问题比如先问“有哪些异常订单”再问“这个月营收趋势”历史和当前问题的关联度其实很低。一开始我把所有历史都保留下来输入token居高不下。后来改成每轮对话算相关性只保留和当前问题相关的2到3轮输入的体积一下子降了一半还多。上下文压缩则是另一个思路不丢弃信息而是改变信息的表示方式。比如把一大段对话历史先用模型总结成摘要再把摘要放进上下文。这个方法适合长对话场景但要注意压缩本身会消耗一部分token如果对话轮数不多压缩得到的收益可能还没压缩消耗的token多需要实测去衡量。3.4 工具结果层的“减脂”技巧工具结果是个和普通聊天不太一样的地方。很多应用会接入数据库查询、API调用、文档检索如果直接把原始结果塞给模型那输入token很快就会爆掉。原因很简单数据库返回的原始记录往往有大量无关字段API返回的数据也可能带着各种冗余信息。我给工具结果层做了一道预处理管线先过滤字段把与当前任务无关的列去掉再截断长文本太长的字段只取前N个字符最后聚合归纳如果结果行数太多先用一个低成本模型做聚合只保留汇总后的统计值。印象很深的一个案例是从数据库里捞出了8000多行交易记录如果不处理直接塞进去光这一层就得大几千token。后来做了字段过滤和聚合只保留每天的交易总额、笔数和异常标记结果压缩到不到200 token。对下游的判断任务来说这些汇总信息完全够用。4. 重试逻辑用工程手段堵住浪费前面聊的都是单次请求怎么省钱接下来是重试层面的优化。重试会成倍放大token开销这是很多团队容易忽视的地方。一次请求失败了重试三次等于消耗变成了原来的4倍。所以对重试的控制本质上是在给整个系统的成本做“熔断”。4.1 指数退避的真正用途不只是“等”指数退避是重试策略的标配它的核心思路是每次重试之间的等待时间按倍数增长比如第一次失败后等1秒第二次等2秒第三次等4秒。很多教程会把这件事简单归结为“防止把服务打爆”但如果你仔细计较token消耗指数退避还有一个隐藏作用它给了服务端恢复的时间而不是让你在同一批错误里反复烧钱。我自己见过一些项目失败后立即重试重试又失败又立即重试一分钟内同一个请求重试了五六次。如果服务端已经出现稳定性问题这种无间隔重试不但大概率继续失败还会让token消耗瞬间飙升。正确的做法是把退避的上限卡死比如最长等待不超过30秒重试次数不超过2次。也就是说宁愿让这次请求失败也不要在不稳定的窗口里反复砸钱。4.2 分错误类型来决定重试而不是一刀切重试之前一定要看清楚报错到底属于哪一类。大模型的API错误大体上能分成两类一类是“上下文长度超限”或者“输入格式错误”这类问题你再重试10次也没用因为问题出在请求本身另一类是“服务暂时不可用”或者“限流”这类才是重试能解决的。我的策略是对输入类报错直接查请求组装逻辑不重试对限流和服务端错误按指数退避重试但重试上限卡在2次。另外还有一类“内容安全拦截”的报错这类错误基本和prompt有关盲目重试不但没用还可能在日志里留下风险记录直接进人工排查。4.3 用“乐观请求”和“保守请求”降低试错成本当你对自己的prompt质量不太有把握的时候可以先发一个低成本的试探请求只让模型输出非常短的内容比如让它根据输入数据给出一个“是/否”的判断。试探成功了再放心调用完整的高成本请求。这种“乐观请求”的好处在于能及早发现那些会导致生成异常、格式错乱的问题又不会因为一次失败就把完整的token消耗掉。反过来如果任务的实时性要求高比如用户在线等答案那就用“保守请求”逻辑直接调用模型不再做额外的验证步骤但要把单次请求的token上限压到最小。这要求你对这个任务的上下文结构非常熟悉能准确判断哪些信息可以省略。4.4 从服务端协议上减少重试成本重试不仅是客户端单方面的事和服务端的反馈机制也有关。在调用大模型的时候尽量通过API参数和服务端协商更细粒度的反馈。比如请求设置较低的max_tokens上限宁可一轮生成不完整也不要一次生成长篇大论再因为结果不理想而推倒重来。因为“重试”和“生成之后不满意”本质上是一样的浪费。另外有些模型的API支持流式输出这让我能够在生成过程中提前判断内容方向是否正确。如果发现模型在前几十个token里就跑偏了我可以主动终止这次生成然后修改输入的约束条件重新请求。这比等它把400个token全输出完再废弃要省得多。代价是客户端代码要写得细致一些但在高成本任务里非常值得。5. 常见问题与排查技巧实录和优化方法搭配的是一套日常排查的手段。没有这些手段你可能都发现不了自己的token到底消耗在哪里。下面是我整理的一些高频问题和排查思路。5.1 排查“为什么token比我预估的高”我接到过几次类似的问题代码明明没写几行每次调用的token却比预想中高出一大截。第一件事就是去抓取实际的请求日志把每次调用的输入和输出token记录下来。光靠控制台面板的粗略统计是查不出来的。排查顺序我建议先看输出token检查模型是不是生成了大量多余文字再看输入token检查是不是历史上下文没截断最后看工具结果层检查是不是有很多无关字段被塞了进去。90%的异常都能在这三步里找到原因。某个项目里我发现每轮对话的输入token稳定多出3000多。翻查日志后发现是对话历史的保存逻辑写错了——它把之前所有用户输入连同系统内部调试信息一起存了进去这些调试信息根本不是对话内容但被模型当成了上下文的一部分。找到原因后把存储逻辑一改token直接掉了大半。5.2 常见错误类型速查表遇到错误别急着改代码先对照下面的表看看属于哪种情况不同情况处理的方式完全不同。错误表现可能原因处理方向输出内容重复上下文里有历史结论未抑制加“不要重复历史结论”指令切断旧信息输入token超限对话历史层或工具结果层太长检查分层预算做滑动窗口截断或聚合过滤回答格式不稳定prompt里缺少数值化约束设定输出长度上限、JSON结构示例重试后仍失败token大量消耗错误类型未区分盲目重试按错误类型分流限制重试次数和退避上限单次输出很长但信息量少任务类型未明确用“直接给答案不解释”“只输出结论”等指令压缩输出5.3 避坑笔记三个我踩过的坑第一个坑是“优化了输出却砸了效果”。我曾经做一个复杂推理任务强行把模型输出压缩到只剩一个结论结果发现结论的准确率明显下降了。后来才想明白这个任务的推理过程里中间步骤本身有逻辑价值完全砍掉会让模型的思维链断裂。之后我改成保留一段极简的推理链只在最终答案展示时做压缩。输出量大概降了30%但准确率保住了。第二个坑是“为了省输入而丢了记忆”。在长对话里压上下文压得太过导致模型忘了用户几分钟前刚说过的关键信息。后来我引入了“关键信息快照”不保留全部历史而是每一轮结束时把本轮核心信息提取成结构化的键值对在下一次请求时把键值对放进上下文。这样既省了token又保住了必要的记忆。第三个坑是“重试次数设为0”。有一次我为了省token把所有失败情况都设置成不重试结果当天因为服务短暂抖动很多请求直接失败了用户体验很糟糕。这个问题的教训是省token不能靠牺牲可用性来换重试成本要在“不重试带来的损失”和“重试带来的额外消耗”之间做权衡。5.4 如何建立一套可持续的token监控机制优化不是一次性的随着业务迭代很多历史优化点可能会失效。所以一定要有监控机制。我自己会在每个项目里埋点记录每次请求的输入token、输出token、响应耗时、重试次数。这些数据每天汇总一次按功能模块看趋势。如果某一天某个模块的token消耗突然飘了我就能立刻定位到是哪个改动引起的。另外我还会设置一条“token消耗异常告警线”超过阈值就发通知。这样即便某些优化失效了也能在第一时间发现而不是等到月底账单出来才傻眼。6. 直接可以落地的优化清单最后把前面讲的这些整理成可以直接对着做的一页纸清单。你可以把它打印出来贴在工位旁边每次准备调用大模型之前都对照检查一遍。输出侧在prompt中明确任务类型用数字化约束限制输出长度禁止无意义寒暄和重复历史结论。输入侧按五级结构拆分上下文每层设独立token预算对话历史用滑动窗口按token反推轮数不保留无关联历史工具结果先过滤字段再做压缩。重试侧按错误类型决定是否重试输入类报错不重试限流类报错使用带指数退避的重试但限制次数在流式输出时用提前终止来避免生成垃圾内容。监控侧记录每次调用的输入输出token按天观测趋势设定异常告警线。测试侧在改动优化策略前先跑一组基准样本对比效果和消耗别凭感觉调整。我自己在实际操作中最大的体会是token优化不是一个“一次性大招”而是一个持续迭代的过程。每次改动都要拿数据说话看看消耗降了没有效果有没有受影响。如果两者之间平衡得好成本自然就下来了。最后再分享一个小技巧当你实在不知道怎么优化的时候把模型当成一个刚入职的实习生你的prompt就是工作手册。工作手册里写着“不要废话只给结果”实习生就会照着办工作手册里写得模棱两可那就是在允许它自由发挥。管好这本手册token就管好了。
