1. 从一场直播复盘说起Token 性价比为什么值得单独拎出来聊做 AI 应用这两年我越来越觉得Token 性价比这个词被严重低估了。大家平时聊模型张口就是参数规模、跑分、上下文长度但真到了要上线一个智能体、要跑一个批量任务、要控制月度账单的时候决定你能不能活下去的往往不是模型有多强而是每一块钱能换回多少有效 Token。这场直播回顾的主题就是如何获取最优 Token 性价比我把它拆成上下两篇来写。上篇主要解决一个核心问题Token 到底花在哪里了以及怎么在架构层面把浪费堵住。下篇再讲具体的模型选型、缓存策略和成本监控。之所以这么分是因为我发现很多人一上来就问哪个模型便宜但连自己的 Token 消耗结构都没搞清楚这种优化基本等于瞎猜。先说清楚这篇适合谁看。如果你只是偶尔用用聊天窗口那 Token 成本对你几乎无感但如果你在做智能体开发、多 AI 协作、批量内容生成、客服机器人接入或者任何需要长期跑量的 AI 应用那 Token 就是你的水电煤一个月烧掉几千上万块是常事。这时候性价比优化不是锦上添花而是生死线。我见过太多团队模型选得挺对架构也搭得漂亮结果一个月账单出来傻眼——钱全花在了重复的上下文、无意义的系统提示词、以及那些根本没被用上的长输出上。所以这篇不讲虚的就讲Token 消耗的解剖学以及怎么从根上把性价比拉起来。2. Token 消耗的解剖学你的钱到底被谁吃掉了2.1 输入 Token 和输出 Token 的定价差异比你想的大很多人算成本的时候习惯把输入和输出混在一起算这是第一个大坑。主流模型的定价里输出 Token 通常比输入 Token 贵 2 到 4 倍。这意味着什么意味着你让模型多说两句的代价远高于你多喂两句。我拿一个真实场景举例。假设你在做一个智能体客服用户问我的订单为什么还没发货你的系统提示词有 800 Token历史对话有 1200 Token用户问题 50 Token加起来输入是 2050 Token。模型回复一段 300 Token 的解释。按某主流模型输入 0.001 元/千 Token、输出 0.002 元/千 Token 算这一轮成本是 0.00205 0.0006 0.00265 元。看起来不多但如果你每天有 5000 轮对话一个月就是接近 400 块。而如果你把系统提示词精简到 400 Token历史对话做摘要压缩到 400 Token输入直接降到 850 Token成本立刻砍掉一半以上。提示优化 Token 性价比的第一步永远是先把输入和输出分开统计别混着算。混着算你永远找不到真正的浪费点。2.2 系统提示词是隐形的成本黑洞系统提示词这东西写的时候很爽觉得越详细模型越听话。但它是每一轮对话都要重新计费的。你写 1500 Token 的系统提示词用户聊 20 轮这 1500 Token 就被计费了 20 次也就是 30000 Token 的输入成本全花在重复描述同一件事上。我自己的做法是系统提示词只保留角色定义、核心约束、输出格式这三块其余能挪到用户消息里的就挪能做成模板变量的就做成变量。比如你是一个专业的客服助手语气要亲切遇到退款问题要引导用户提供订单号这种可以压缩成客服助手亲切退款需订单号。意思没丢Token 省了 70%。还有一个更狠的招把系统提示词做成可缓存的。现在不少模型平台支持提示词缓存第一次计费后后续相同前缀的输入按折扣价算。如果你的系统提示词是固定的一定要用上这个能力长期看能省下相当可观的一笔。2.3 历史对话的膨胀速度是线性还是指数历史对话的 Token 增长很多人以为是线性的其实在智能体场景里经常是超线性的。因为智能体每一轮可能不只是把用户的话加进去还会把工具调用结果、中间推理、检索到的文档片段全塞进上下文。聊到第 10 轮上下文可能已经膨胀到 8000 Token 以上。我实测过一个多 AI 协作的场景两个智能体互相讨论一个方案聊了 15 轮之后单次请求的输入 Token 突破了 12000。这时候如果不做任何压缩成本会像滚雪球一样涨。解决办法后面会细讲但核心思路就一句话历史对话不能无脑全带要有选择地保留。2.4 那些看不见的 Token工具调用与检索注入智能体开发里最容易被忽略的 Token 消耗是工具调用的返回结果和检索注入的文档。你调一次搜索 API返回 3000 字的网页内容这 3000 字如果全塞进上下文那就是实打实的输入 Token。你做一个 RAG 检索召回 5 个文档片段每个 500 字又是 2500 Token。这些 Token 的特点是它们不是你主动写的但它们是你在架构设计时决定要带进来的。所以优化 Token 性价比本质上是在优化你的上下文组装策略。带什么、不带什么、带多少直接决定成本。3. 上下文压缩把每一轮对话的水分挤出去3.1 滑动窗口不是万能药但它是第一道防线最简单的上下文压缩就是滑动窗口——只保留最近 N 轮对话。这个方案的好处是实现简单坏处是会丢信息。用户第 3 轮说的关键需求到第 12 轮可能就被滑出去了模型突然失忆体验直接崩。我的经验是滑动窗口适合短任务型对话比如单次问答、简单查询。对于需要长期记忆的场景滑动窗口只能作为兜底不能作为主力。而且窗口大小要按任务类型调不能一刀切。客服场景保留 6 到 8 轮通常够用复杂方案讨论可能得保留 15 轮以上。3.2 摘要压缩让模型自己记笔记比滑动窗口更聪明的做法是摘要压缩。当对话轮数超过阈值时让模型把之前的对话总结成一段简短摘要然后用摘要替代原始对话。这样既保留了关键信息又把 Token 量压下来了。具体操作上我会设一个触发条件当历史对话 Token 超过 2000 时触发摘要。摘要的提示词大概是请用 200 字以内总结以下对话的关键信息包括用户需求、已确认的事实、待解决的问题。实测下来2000 Token 的原始对话能压到 150 Token 左右压缩比超过 10 倍。注意摘要本身也要花 Token所以别太频繁触发。我一般设成每 5 轮触发一次或者 Token 超阈值时触发避免每轮都摘要导致成本反而上升。3.3 结构化记忆比摘要更可控的方案摘要的问题是不可控模型可能漏掉你认为重要的信息。所以我后来更倾向于结构化记忆把对话中的关键信息抽成结构化字段比如用户 ID、订单号、问题类型、已尝试的解决方案、当前状态。这些字段用 JSON 存着每轮只带必要的字段进上下文。这样做的好处是 Token 消耗可预测而且信息不会丢。坏处是需要额外设计抽取逻辑前期投入大一点。但对于长期跑的智能体这个投入绝对值得。我做过对比同样 20 轮对话结构化记忆方案的输入 Token 只有全量历史的 15% 左右。3.4 检索增强的 Token 控制召回多少才合适RAG 场景里召回文档的数量直接决定 Token 成本。很多人默认召回 top 5 或 top 10但其实召回数量和效果不是线性关系。我实测过top 3 和 top 10 在很多任务上效果差不多但 Token 差了 3 倍多。我的做法是先做小规模测试找到效果拐点。通常 top 3 到 top 5 是性价比最高的区间。另外召回后的文档要做截断和去重别把整个网页塞进去只保留最相关的段落。还有个小技巧如果多个召回片段内容重叠先去重再拼接能省不少 Token。4. 模型分层不是所有任务都值得用最贵的模型4.1 任务分级是性价比优化的核心杠杆Token 性价比优化里最有效的一招其实是模型分层。不是所有请求都需要最强的模型。用户问今天天气怎么样你用顶级模型是浪费用户让你写一份商业计划书你用最便宜的模型是找罪受。我一般把任务分成三档任务档位典型场景模型选择策略Token 成本占比轻量档意图识别、分类、简单问答、格式转换小模型或轻量模型约 10%标准档常规对话、信息抽取、摘要、客服回复中等模型约 50%重载档复杂推理、代码生成、长文写作、方案设计顶级模型约 40%关键是入口处就要做路由别等请求进了顶级模型再想办法。路由可以用规则也可以用一个小模型做意图分类。规则路由适合场景固定的业务小模型路由适合场景多变的业务。4.2 路由器的成本也要算进去这里有个容易被忽略的点路由器本身也要花 Token。如果你用一个小模型做路由每次请求都先过一遍小模型那也是一笔开销。所以路由逻辑要尽量轻能用关键词规则解决的就别上模型。我的经验是80% 的请求可以用规则路由搞定。比如包含写代码生成分析这类词的走重载档包含是什么怎么读这类词的走轻量档。剩下 20% 模糊的再用小模型兜底。这样路由成本能压到很低。4.3 降级与重试别让失败请求白花钱还有一个隐形成本失败的请求。模型超时、返回格式错误、被安全策略拦截这些请求的 Token 是照常计费的。如果你的重试策略是无脑重试三次那成本直接翻三倍。我的做法是区分可重试错误和不可重试错误。超时、限流可以重试但格式错误、内容被拦截这种重试大概率还是失败不如直接降级到备用方案。另外重试时可以把上下文精简一下别把完整历史再带一遍减少重复消耗。5. 输出控制让模型少说废话就是省钱5.1 输出长度限制是最直接的省钱手段输出 Token 比输入贵所以控制输出长度的性价比极高。很多模型支持 max_tokens 参数直接设一个上限防止模型滔滔不绝。但要注意设太小会导致回答被截断体验变差。我的做法是按任务类型设不同的上限。分类任务设 50摘要任务设 300对话回复设 500长文写作设 2000。这样既不会截断又不会让模型放飞自我。实测下来光这一项就能省 20% 到 30% 的输出成本。5.2 提示词里明确简洁要求除了硬性限制提示词里也要明确要求简洁。比如加一句请用不超过 100 字回答或者直接给出结论不要解释过程。模型对这类指令的遵从度还是挺高的。但要注意别在需要详细回答的场景里强行要求简洁那样会导致模型反复被追问反而多花 Token。简洁要求要用在合适的任务上比如信息查询、状态确认这类。5.3 结构化输出JSON 比自然语言更省 Token如果你的下游系统需要解析模型输出那让模型直接输出 JSON比输出自然语言再解析要省 Token。因为 JSON 没有客套话、没有过渡句信息密度高。而且结构化输出还能减少解析错误导致的重试。我一般会在提示词里给出 JSON schema让模型按格式填。比如请以 JSON 格式返回包含 intent、confidence、entities 三个字段。这样输出通常能控制在 100 Token 以内比自然语言回复省一半以上。5.4 停止序列让模型在该停的地方停有些模型支持 stop 参数遇到指定字符串就停止生成。这个在特定场景下很好用。比如你让模型生成一段代码可以在代码块结束后设停止序列防止模型继续写解释文字。不过 stop 参数要慎用设不好会导致输出被意外截断。我一般只在格式非常固定的场景用比如生成 SQL、生成特定标记包裹的内容。6. 缓存与复用同样的钱别花两次6.1 提示词缓存固定前缀的折扣红利前面提过提示词缓存这里展开说。现在不少平台对相同前缀的输入提供缓存折扣命中缓存的部分按更低价格计费。这对系统提示词固定、或者多轮对话场景特别友好。要用好这个能力关键是把固定内容放在前面变化内容放在后面。比如系统提示词、few-shot 示例、固定指令放最前面用户输入放最后。这样缓存命中率最高。我实测过一个客服场景开启提示词缓存后输入成本降了 40% 左右。6.2 语义缓存相似问题直接复用答案比提示词缓存更进一步的是语义缓存。用户问怎么退款和退款流程是什么语义上是一回事如果之前回答过直接复用答案就行不用再调模型。实现上可以用向量数据库做相似度匹配超过阈值就返回缓存答案。这个方案对 FAQ 类场景效果极好能省下大量重复请求。但要注意设置合理的相似度阈值太高会漏掉本可复用的太低会返回不相关的答案。我一般设在 0.92 到 0.95 之间。6.3 结果缓存确定性任务的必备如果你的任务输入相同、输出也应该相同比如格式转换、固定模板填充那直接做结果缓存就行。用输入内容的哈希做 key命中就直接返回。这个最简单也最有效但只适用于确定性任务。提示缓存一定要设过期时间别让过时答案一直返回。我一般设 24 小时到 7 天按业务变化频率定。7. 监控与度量没有数据就没有优化7.1 必须监控的几个核心指标优化 Token 性价比不能靠感觉要靠数据。我一般会监控这几个指标单请求平均输入 Token看上下文是否膨胀单请求平均输出 Token看输出是否失控缓存命中率看缓存策略是否有效模型分层比例看路由是否合理单次任务总成本看整体趋势这些指标按天看趋势按周做复盘。一旦发现某个指标异常上涨立刻排查原因。7.2 按业务维度拆分成本光看总量不够还要按业务维度拆。比如按用户、按功能模块、按任务类型分别统计 Token 消耗。这样你才能知道钱花在了哪里哪些功能是成本大户。我见过一个案例某团队发现 60% 的 Token 花在了一个使用率不到 5% 的功能上原因是那个功能的上下文组装有 bug每次都把全量历史带进去。修掉之后整体成本直接降了三分之一。7.3 设置预算告警最后一定要设预算告警。按天、按周、按月设阈值超了就报警。别等到月底账单出来才发现超支。告警可以发到群里也可以发邮件关键是让相关人第一时间知道。我自己的习惯是设两级告警达到预算 70% 时提醒达到 90% 时强提醒并触发降级策略。降级策略可以是切换到更便宜的模型或者限制某些非核心功能的调用。8. 一些踩过坑之后的实操心得聊了这么多方法论最后分享几个我自己踩坑之后总结的实操心得都是真金白银换来的。第一别迷信上下文越长越好。我早期做智能体的时候觉得上下文给得越全模型表现越好。结果发现上下文超过一定长度后模型反而会分心效果下降成本还飙升。后来我把上下文控制在 4000 Token 以内效果反而更稳。第二系统提示词的每一句话都要问这值不值。我现在的习惯是系统提示词写完后逐句问自己这句话删掉模型表现会差多少如果差得不多就删。这样能砍掉大量冗余描述。第三输出格式约束比输出内容约束更省钱。与其告诉模型回答要简洁不如直接给一个 JSON schema 让它填。格式约束是硬性的内容约束是软性的硬性的更省 Token。第四缓存策略要分层设计。提示词缓存、语义缓存、结果缓存三层配合用效果最好。别指望一层缓存解决所有问题。第五监控要趁早。别等账单爆炸了才想起来做监控。项目一上线就把 Token 统计埋点做好后面优化才有依据。第六模型分层要动态调整。业务在变模型能力也在变今天合适的路由策略三个月后可能就不合适了。定期复盘路由效果该调的调该换的换。第七别忽略小模型的进步。现在很多小模型在特定任务上已经够用了价格却便宜一个数量级。定期测试新出的小模型说不定能替换掉你现在用的贵模型。这篇上篇主要讲的是架构层面和策略层面的 Token 性价比优化核心就一句话把每一份 Token 都花在刀刃上。下篇我会接着讲具体的模型选型对比、缓存实现细节、以及成本监控的工程落地感兴趣的话可以接着看。