1. 这套方案到底在省什么从“token焦虑”说起但凡跟大模型API打过交道的兄弟应该都有过这种体验月底一看账单心里咯噔一下。明明感觉自己没问几个问题怎么token就烧了这么多尤其是做长文档处理、多轮对话、代码仓库分析这类场景token消耗简直像开了闸的水龙头哗哗地流。“终极token节省方案兄弟们站起来蹬”这个标题我第一次看到的时候会心一笑。“站起来蹬”这个说法很形象它来自骑自行车上坡时站起来使劲踩踏板的动作放到这里的意思就是别再躺着被动烧token了主动出击把每一分token都花在刀刃上。这套方案的核心目标就一个——在保证输出质量不明显下降的前提下把token消耗压到最低。它解决的是什么问题说白了就是三个痛点第一输入token浪费太多大量无关内容被塞进上下文第二输出token控制不住模型啰里啰嗦说一堆废话第三多轮对话中历史信息不断累积越聊越贵。适合谁来参考我觉得只要你在用大模型API做产品、做自动化流程、做数据分析或者单纯自己写脚本调用接口这套思路都用得上。哪怕你只是偶尔用用了解一下token的运作机制也没坏处至少能让你知道钱花在哪了。我自己的经历是之前做一个文档摘要的批量处理任务一开始没注意优化跑了一千多份文档账单出来的时候我盯着屏幕沉默了大概十秒钟。后来花了两天时间把整套流程重新梳理了一遍同样的任务量token消耗直接降到了原来的三分之一左右。这篇文章就把我踩过的坑、试过的方案、以及最终沉淀下来的做法完整地分享出来。2. 先搞懂token的计费逻辑不然省个寂寞2.1 token到底怎么算的很多人省token省了半天其实连计费规则都没搞清楚。大模型的token计费分两块输入token和输出token。输入就是你发给模型的内容包括系统提示词、用户消息、历史对话、你塞进去的文档等等。输出就是模型生成的内容。这两块的价格通常不一样输出一般比输入贵有些模型输出价格是输入的三到五倍。关键点在于输入token是按你实际发送的内容计算的不是按字符数也不是按字数。英文大概一个单词对应1到1.5个token中文一个字大概对应1到2个token具体取决于分词器的实现。代码的token密度又不一样因为代码里有大量符号和缩进。我见过有人为了省token把中文改成英文结果发现token没降多少因为英文的分词效率也没高到哪里去。真正有效的做法是减少冗余内容而不是换语言。2.2 哪些地方在偷偷吃你的token根据我的实测经验token浪费主要发生在以下几个地方系统提示词过长很多人写系统提示词像写论文恨不得把产品说明书全塞进去。实际上模型只需要关键约束多余的描述不仅浪费token还可能干扰模型判断。历史对话全量携带多轮对话中每一轮都把之前所有对话原封不动带上这是最大的浪费源。聊了二十轮之后光历史记录就可能占掉几千token。文档内容不做筛选做文档问答时把整篇文档塞进上下文但实际用到的可能只有其中两三段。输出格式不做约束不告诉模型输出多长、什么格式模型就会自由发挥生成大量无关内容。重复调用不做缓存同样的输入反复请求每次都重新计费。注意不同模型平台的计费细节有差异有些平台对缓存命中、批量调用有折扣具体要看你用的平台文档。但上面这些浪费点是通用的跟平台无关。2.3 省token的核心原则我把省token的策略归纳成四条核心原则后面所有的具体方案都是围绕这四条展开的能不发的就不发精简输入去掉一切非必要内容。能少发的就少发压缩表达用更少的token传递同样的信息。能复用的就复用缓存机制、模板化处理避免重复计算。能控制的就控制约束输出长度和格式防止模型自由发挥。这四条听起来简单但真正落地的时候每一条都有很多细节可以抠。下面我逐个展开。3. 输入侧瘦身把每一颗子弹都用在刀刃上3.1 系统提示词的极限压缩系统提示词是每次请求都会携带的固定开销。假设你的系统提示词有500个token你一天调用1000次那就是50万token白白花出去了。所以系统提示词的压缩优先级最高。我的做法是先写一版完整的系统提示词把所有要求都列清楚然后逐条问自己——“这条不写模型会做错吗”如果答案是“大概率不会”就删掉。删完之后再跑一轮测试看输出质量有没有明显下降。通常来说系统提示词可以压缩到原来的三分之一甚至更少。举个例子我原来写的是“你是一个专业的文档摘要助手请仔细阅读用户提供的文档内容然后用简洁的语言总结出文档的核心要点注意保持客观中立不要添加个人观点输出格式为分点列表每点不超过50字。”压缩后变成“总结以下文档要点分点列出每点不超过50字保持客观。”信息量基本没丢但token从原来的80多个降到了30个左右。省下来的虽然看起来不多但乘以调用次数就很可观了。3.2 历史对话的滚动窗口策略多轮对话是token消耗的大头。我的建议是不要全量携带历史而是采用滚动窗口加摘要的方式。具体做法是保留最近N轮对话的完整内容更早的对话压缩成一段简短摘要。N的取值取决于你的场景一般3到5轮就够了。摘要可以由模型生成也可以自己写规则提取关键信息。比如一个客服场景用户前面聊了十轮你不需要把十轮都带上只需要保留最近三轮再加上一句“用户之前咨询了退货政策已告知七天无理由退货”。这样既保留了上下文连贯性又大幅减少了token。实操心得滚动窗口的N值不要设太小否则模型会“失忆”用户体验很差。我一般设5轮超过5轮的部分做摘要。摘要本身也会消耗token但相比携带完整历史还是划算的。3.3 文档内容的精准切片做文档问答或者文档摘要的时候最忌讳的就是把整篇文档一股脑塞进去。正确的做法是先做检索只把最相关的片段送给模型。如果你的文档不大比如几千字可以全部塞进去。但如果文档上万字甚至几十万字就必须做切片和检索。常见的做法是用向量检索或者关键词检索找出与问题最相关的几个段落只把这些段落送给模型。切片的粒度也有讲究。切太细可能丢失上下文切太粗又会带入无关内容。我的经验是每片500到1000字比较合适重叠部分留100到200字保证边界信息不丢失。3.4 用结构化格式替代自然语言同样的信息用JSON或者表格格式表达通常比自然语言更省token。因为自然语言有大量连接词、修饰词、重复表达而结构化格式直接给关键字段。比如你要告诉模型用户的订单信息自然语言写法是“这位用户名叫张三他在2024年1月15日下了一个订单订单号是12345商品是一件蓝色T恤价格是99元。”结构化写法是{name:张三,date:2024-01-15,order_id:12345,item:蓝色T恤,price:99}后者token更少而且模型理解起来更准确。当然不是所有场景都适合结构化但凡是涉及参数传递、信息提取的场景结构化都是更优选择。4. 输出侧管控让模型闭嘴也是一种艺术4.1 明确指定输出长度如果你不告诉模型输出多长它就会按照自己的“心情”来生成。有时候你只想要一句话它给你写一段你只想要一个列表它给你写一篇小作文。解决办法很简单在提示词里明确写清楚输出长度。比如“用一句话回答”、“不超过50字”、“分三点每点不超过20字”。模型对长度指令的遵循度还是比较高的只要你写清楚。我实测下来加了长度约束之后输出token平均能降40%到60%。这个数字一点都不夸张因为模型在没有约束时的“默认输出长度”往往远超实际需要。4.2 用停止符截断无用输出有些模型支持停止符stop sequence你可以指定一个字符串当模型生成到这个字符串时就停止。这在格式化输出场景特别有用。比如你让模型输出JSON可以在末尾加一个特殊标记模型生成完JSON后遇到这个标记就停不会再多说废话。或者你让模型做分类输出类别标签后就停不需要它再解释原因。停止符的设置要注意一点选的字符串不能出现在正常输出内容中否则会提前截断。一般用一些特殊组合比如###END###这种基本不会跟正常内容冲突。4.3 少样本示例的精简技巧少样本示例few-shot是提升输出质量的有效手段但示例本身也占token。我的做法是示例只给最关键的不给全量。比如你要做情感分类不需要给十个例子给两三个典型例子就够了。而且示例的输入部分可以简化不需要把完整的长文本放进去用短文本代替就行。模型看的是模式不是具体内容。另外示例的格式要统一且紧凑。不要每个示例都写一大段解释直接给输入和输出就行。解释性内容放在示例之前统一说一次不要在示例里重复。4.4 输出格式的强约束让模型输出JSON、XML、CSV这类结构化格式比让它自由发挥要省token。因为结构化格式有明确的边界模型不会加额外的修饰和解释。但要注意有些模型在输出JSON时会在前后加markdown代码块标记比如json和这些也是token。你可以在提示词里明确说“直接输出JSON不要加代码块标记”通常模型会遵守。如果模型不遵守可以在后处理阶段用代码把标记去掉这不影响token计费但能让你的下游处理更顺畅。5. 缓存与复用同样的钱不花第二遍5.1 精确缓存相同输入直接返回最简单的缓存策略把输入做哈希如果之前请求过相同的输入直接把缓存的结果返回不再调用模型。这在FAQ场景、固定模板生成场景特别有效。实现方式也很简单用一个字典或者数据库存起来就行。key是输入的哈希值value是模型的输出。下次请求先查缓存命中就直接返回。注意缓存要考虑时效性。有些场景下同样的输入在不同时间可能需要不同的输出比如涉及实时数据的场景。这种情况下可以给缓存加过期时间或者只在特定场景使用缓存。5.2 语义缓存相似输入也能复用精确缓存只能命中完全相同的输入但实际场景中很多输入是相似的但不完全一样。这时候可以用语义缓存把输入做向量化如果跟缓存中的某个输入向量相似度超过阈值就认为可以复用结果。语义缓存适合问答场景。比如用户问“怎么退货”和“退货流程是什么”语义上是同一个问题可以复用同一个答案。但语义缓存的阈值设置要谨慎设太高会命中不相关的缓存设太低又起不到缓存效果。我一般设0.92左右具体要根据实际数据调。5.3 提示词前缀缓存有些模型平台支持提示词前缀缓存prompt caching如果你的请求开头部分跟之前某个请求相同平台会自动复用那部分的计算结果只对新增部分计费。这对系统提示词固定、只有用户消息变化的场景特别有用。要利用这个机制关键是把固定不变的内容放在前面变化的内容放在后面。这样前缀缓存才能命中。如果你把变化的内容放在前面固定内容放在后面缓存就失效了。5.4 批量请求合并如果你有大量独立的请求要处理不要一个一个发而是合并成批量请求。很多平台对批量请求有折扣而且合并之后可以减少网络开销和重复的系统提示词开销。合并的方式取决于具体任务。比如做文本分类可以把多条文本放在一个请求里让模型一次性输出所有分类结果。但要注意合并后的请求不能太长超过模型上下文限制就适得其反了。6. 模型选型与参数调优杀鸡不用牛刀6.1 不是所有任务都需要最强模型这是最容易被忽视的省token策略用合适的模型而不是最强的模型。很多人习惯性地用最贵的模型处理所有任务但实际上很多任务用轻量级模型就能做好。我的做法是把任务分级简单任务分类、提取、格式化用轻量模型中等任务摘要、改写、简单问答用中档模型复杂任务推理、创作、代码生成才用最强模型。这样分级之后整体成本能降一半以上。因为大部分请求其实都是简单任务用轻量模型完全够用。6.2 温度参数的调节温度参数temperature影响输出的随机性。温度越高输出越多样但也越容易啰嗦温度越低输出越确定通常也更简洁。对于需要精确输出的任务比如信息提取、分类、格式化温度设0或者接近0就行。这样模型不会“自由发挥”输出更可控token也更省。对于创意类任务温度可以适当调高但也不要太高否则输出质量下降反而需要更多token来修正。6.3 最大输出token的限制很多平台支持设置最大输出token数max_tokens。这个参数一定要设而且要设得合理。设太大模型可能会生成超长内容设太小又可能截断有用信息。我的经验是先跑一批测试看正常输出的token分布然后取95分位数作为max_tokens的值。这样既能覆盖绝大多数正常输出又能防止极端情况下的token爆炸。6.4 流式输出的取舍流式输出streaming本身不省token但它能让你更早看到输出内容如果发现方向不对可以提前中断避免继续生成无用内容。从这个角度说流式输出间接帮你省了token。但流式输出也有代价实现复杂度更高而且有些平台对流式请求的计费方式不同。具体要不要用看你的场景和对成本的敏感度。7. 常见问题与排查技巧实录7.1 token消耗突然暴涨怎么排查这是最常见的问题平时用得好好的突然某天token消耗翻了好几倍。排查思路如下排查项可能原因解决方法输入长度用户输入变长或文档切片变大检查输入日志看是否有异常长的请求历史累积多轮对话轮次增加历史未压缩检查对话轮次启用滚动窗口输出长度模型输出变长或max_tokens设置过大检查输出日志调整max_tokens调用次数缓存失效或重复请求增加检查缓存命中率排查重复调用模型切换不小心切到了更贵的模型检查模型配置我遇到过一次是因为缓存key的计算方式变了导致缓存全部失效所有请求都打到了模型上。后来把缓存key的生成逻辑固定下来问题就解决了。7.2 压缩后输出质量下降怎么办省token和保质量是一对矛盾。压缩太狠输出质量肯定下降。我的做法是找到一个平衡点先压缩然后跑评测集看质量下降是否在可接受范围内。如果质量下降明显就逐步放宽压缩策略直到质量恢复到可接受水平。这个过程需要反复迭代没有一劳永逸的方案。另外有些压缩策略对质量影响小有些影响大。一般来说精简系统提示词和约束输出格式对质量影响较小而减少历史对话和文档切片对质量影响较大。所以压缩的时候要优先动那些影响小的部分。7.3 缓存命中率低怎么优化缓存命中率低说明你的缓存策略有问题。常见原因和优化方法输入变化太频繁如果每次输入都有细微差别精确缓存很难命中。这时候要考虑语义缓存或者把变化的部分剥离出来只缓存不变的部分。缓存粒度太细如果缓存key包含太多字段命中率自然低。可以适当放宽缓存key的粒度比如忽略一些不影响输出的字段。缓存过期太快如果缓存TTL设得太短还没来得及命中就过期了。可以适当延长TTL或者根据数据更新频率动态调整。7.4 不同平台的token计算差异不同模型平台的分词器不一样同样的文本在不同平台上的token数可能不同。这会导致你在A平台优化好的方案搬到B平台效果打折扣。解决办法是针对你主要使用的平台做优化不要指望一套方案通吃所有平台。如果确实要跨平台使用可以在每个平台上分别测试和调优。实操心得我一般会在项目里加一个token计数模块每次请求前先估算token数超过阈值就触发压缩逻辑。这样能实时监控token消耗及时发现异常。8. 一套可落地的完整方案8.1 整体架构设计把前面所有的策略串起来形成一套完整的token节省方案。整体架构分四层第一层是输入预处理层负责精简系统提示词、压缩历史对话、切片文档内容、结构化输入数据。这一层的目标是把输入token降到最低。第二层是缓存层负责精确缓存和语义缓存命中缓存的请求直接返回不调用模型。这一层的目标是减少实际调用次数。第三层是模型调用层负责模型选型、参数调优、输出约束。这一层的目标是用最合适的模型和参数完成任务。第四层是输出后处理层负责截断无用输出、格式化结果、更新缓存。这一层的目标是保证输出质量的同时控制输出token。8.2 关键配置参数参考以下是我在实际项目中使用的参数配置供参考# 系统提示词压缩后的模板 SYSTEM_PROMPT 总结以下内容分点列出每点不超过50字保持客观。 # 历史对话滚动窗口大小 HISTORY_WINDOW_SIZE 5 # 文档切片参数 CHUNK_SIZE 800 CHUNK_OVERLAP 150 # 缓存配置 CACHE_TTL 3600 # 秒 SEMANTIC_CACHE_THRESHOLD 0.92 # 模型调用参数 MAX_TOKENS 500 TEMPERATURE 0.1 STOP_SEQUENCE ###END###这些参数不是固定的要根据你的具体场景调整。比如文档切片大小如果你的文档段落比较短可以设小一点如果段落比较长可以设大一点。8.3 效果验证与持续优化方案上线之后要持续监控效果。我一般关注三个指标token消耗总量、缓存命中率、输出质量评分。token消耗总量看趋势如果突然上升就要排查原因。缓存命中率看是否稳定如果下降就要优化缓存策略。输出质量评分可以通过人工抽检或者自动评测来获取如果下降就要调整压缩策略。优化是一个持续的过程没有终点。随着你的业务变化和模型更新最优策略也会变化。所以要保持监控和迭代的习惯。9. 一些踩过的坑和真实体会最后分享几个我在实操中踩过的坑希望能帮你少走弯路。第一个坑是过度压缩导致模型理解错误。有一次我把系统提示词压得太狠结果模型完全理解错了任务输出了一堆无关内容。后来我学乖了压缩之后一定要跑回归测试确认模型还能正确理解任务。第二个坑是缓存key设计不合理。我一开始把时间戳也放进了缓存key结果每次请求的key都不一样缓存永远命中不了。后来把时间戳去掉缓存命中率立刻上来了。第三个坑是忽略输出token的管控。我一开始只关注输入压缩没管输出结果输入省下来的token又被输出浪费回去了。后来加了输出长度约束和停止符整体消耗才真正降下来。第四个坑是不同模型混用导致效果不稳定。我试过在同一个流程里混用多个模型结果因为不同模型的输出格式和风格不一致后处理逻辑经常出错。后来统一用一个模型只在特定环节切换问题就少了。这些坑说到底都是一个道理省token不是单一维度的优化而是系统工程。输入、输出、缓存、模型选型每个环节都要考虑到而且要反复测试和调优。没有一劳永逸的方案只有持续迭代的过程。我现在做新项目的时候会在一开始就把token监控和优化逻辑加进去而不是等到账单爆炸了才想起来优化。这个习惯帮我省了不少钱也省了不少心。希望这套思路对你有用兄弟们站起来蹬吧。