1. 问题现象Token 用量失控的典型表现先说结论Openlaw 网关的 Token 激增不是某一处代码写错了那么简单它通常是链路中多个环节共同作用的结果。最近我在排查一个实际项目时发现网关层单日 Token 消耗量从日常的 800 万左右直接飙到 5000 万以上账单数字看着都心疼。更麻烦的是这种激增不是一次性的而是每隔几天就来一轮完全摸不到规律。后来把日志、计费数据、调用链路全部拉出来对齐才发现问题远比“某个循环调用了太多次大模型”要复杂得多。你如果也遇到类似情况可以先对照一下有没有这几个典型症状账单显示 Token 消耗量级与业务调用次数不匹配比如调用次数只涨了 20%Token 消耗却翻了三倍。个别请求的 Token 消耗异常大单次请求甚至顶得上平时几十次的消耗。网关内置的限流、配额预警规则频繁触发但你并没有主动调整过阈值。下游大模型服务返回的 Token 使用量usage 字段与网关记录的对不上或者上游框架统计与下游模型计费端对不上。这些症状单独出现任何一个都还算是正常波动。但几个同时出现基本可以断定网关层已经失去了对 Token 消耗的可见性和控制力。换句话说你已经不知道每一笔 Token 花在哪儿了而这恰恰是成本失控的开始。这里要特别说明一下“网关”在 AI 应用架构里的角色。传统网关管的是流量、鉴权、路由、限流但在接入了大模型能力之后网关还多了一个身份Token 的“计量表”和“阀门”。每次对话请求进来网关负责把请求转发给大模型服务模型处理完后返回结果同时返回这次调用消耗了多少 Token。如果网关层不记录、不聚合、不控制这个数字那整个系统的成本就是一笔糊涂账。我在实际项目里遇到过一个更隐蔽的情况会话上下文管理器会自动把历史消息全部带上但某一轮对话里用户上传了一个超长文档前端做了切片处理后推送给了会话接口。结果这轮调用直接吃掉了将近 10 万 Token而网关完全不知情。后续所有对话都会带着这段文档的上下文继续累积一直到上下文窗口溢出或账单爆炸才被注意到。这就是典型的“Token 激增”场景。2. 为什么 Token 消耗会突然激增把问题拆开看Token 激增从来都不是某一刻突然发生的它一定有一个积累的过程。区别只在于你是否及时发现了它。以我排查过的项目为例Token 激增的原因基本可以归为四大类上下文无限膨胀、工具调用结果回流、系统提示词被重复注入、以及重试机制把成本放大。2.1 上下文无限膨胀是最大的隐性杀手大多数 AI 网关在设计时都会内置一个会话上下文管理器它负责把多轮对话的历史消息拼装起来一并发送给大模型。这个机制本身没问题问题出在“全量累积”的策略上。很多团队的初版实现都是用户每问一句就把从第一条到当前这一条的所有消息全部打包然后加上系统提示词一起发给模型。假设每轮对话平均消耗 800 Token聊到第 10 轮时单次请求携带的历史上下文就接近 8000 Token。聊到第 50 轮时单次请求要携带 4 万 Token 左右。这里还没算上用户偶尔粘贴的长文本、文件内容摘要、工具返回的查询结果。一旦这些内容混入上下文Token 基数是直线上升的。我见过一个比较极端的情况某同事在调试接口时直接用测试脚本连续发了 200 轮相同的请求每轮都携带全量历史。结果等到发现的时候单次请求的上下文已经超过 20 万 Token而下游模型当时的上下文窗口上限也就是 32K。后续所有请求都因为超出窗口限制而报错但 Token 账单依然在累积。2.2 工具调用结果回流导致的“连锁膨胀”Openlaw 这类网关通常还承担着工具/插件调用的编排职责。比如用户问一个法律条文问题网关先调用检索服务把相关法条拉回来然后把这些法条塞进上下文再发给大模型做生成。工具返回的结果往往是很“胖”的。一次数据库查询可能返回上百条记录每条记录几百个字一次网页抓取可能返回好几万字符的正文。网关在把这些内容塞进上下文时如果没有做截断、摘要或结构化压缩那这部分 Token 消耗会非常惊人。而且它还会随着多轮对话继续累积——第一轮拉回来的法条第二轮聊到别的话题时依然在上下文里占着位置。更要命的是循环调用。某些逻辑设计里大模型为了回答问题会连续触发多次工具调用每次调用返回的结果都追加到上下文模型基于新结果再决定下一次调用。这个过程如果缺乏熔断机制模型可能陷入“调用—看结果—再调用—再看结果”的循环一次用户提问能引出几十次工具调用Token 消耗自然爆炸。2.3 系统提示词被反复注入看似不起眼实则积少成多系统提示词是很多团队容易忽略的隐形消耗点。初版可能只有几百 Token但随着功能迭代提示词里逐渐加入了角色设定、输出格式要求、few-shot 示例、安全约束、动态规则……最终轻松超过 2000 Token。问题在于这 2000 Token 是每轮请求都要带着的。如果日均调用量是 10 万次光是系统提示词一天就要消耗 2 亿 Token。这就是为什么有些团队明明感觉调用次数没怎么涨Token 账单却居高不下。更隐蔽的是动态提示词注入。有些网关会在请求处理链路中根据用户画像、会话状态、业务类型动态拼接额外的指令片段而这些片段也会进入每次请求。如果没有统一的提示词版本管理和增量统计这部分消耗基本处于“失控”状态。2.4 请求重试机制把成本放大数倍网关层通常都会配置重试策略当下游服务返回超时、限流或 5xx 错误时自动重试同一请求。这个机制本身没有错但很多团队在配置重试时忽略了一个事实大模型调用是计费的重试意味着同一笔逻辑消耗要重新付一次钱。如果你配置的重试次数是 3 次而下游服务因为瞬时过载连续超时那一次用户请求的实际 Token 消耗就是正常情况的 3 倍甚至更多。在某些极端场景下重试风暴甚至会把系统拖进雪崩状态重试越多下游压力越大超时越多重试就更多。所以网关层的重试策略必须与成本控制联动。重试前要确认上游请求是幂等的重试次数要控制到最低必要值重试退避策略要设置合理的递增间隔同时还要对单请求最多消耗 Token 设置硬性上限。3. 网关层 Token 成本治理的四个优化方向搞清楚了原因接下来就是怎么治理。我整理了几个经过验证的优化方向均已在生产环境跑通过。这些方向的核心思路其实就一句话让 Token 消耗变得可视、可控、可优化。3.1 方向一建立精细化的 Token 计量与用量统计如果连用量数据都没有优化就无从谈起。所以第一步一定是在网关层建立完整的 Token 计量体系。具体来说网关需要从下游模型服务的返回结果中提取 usage 字段——它通常包含 prompt_tokens、completion_tokens、total_tokens——并且按维度做聚合统计。至少要覆盖以下维度用户维度、会话维度、请求路径/接口维度、模型维度、时间维度。这样当你看到 Token 账单异常时能第一时间定位到是哪个用户、哪个会话、哪个接口、哪个模型产生的。我实际项目中用到的统计方案是在网关的响应拦截器里读取 usage 数据然后异步写入时序数据库配合一个简单的聚合任务按小时粒度更新各维度用量。这套方案不需要复杂的实时计算引擎也足够支撑到千万级日调用量的分析需求。除了统计还要做超额预警。设定分级阈值日用量达到总额度的 60% 时告警到负责人达到 80% 时通知整个研发群达到 100% 时自动触发限流或降级策略。阈值最好做成可配置的不同业务线可以参考不同的告警水位。3.2 方向二采取直接有效的 Token 削减技术统计和告警只是前提真正把成本降下来还是要靠技术手段。这里分享几种在网关层可直接落地的削减方案。上下文窗口滑动与消息裁剪不再把全量历史发给模型而是按时间或轮次做滑动窗口。比如只保留最近 10 轮对话或者按 Token 数裁剪到最多保留 6000 Token 的历史上下文。结合消息重要性做取舍——系统消息和最近几轮用户消息优先保留中间过程性消息可以合并或丢弃。历史消息摘要当会话轮次很多、上下文快接近上限时先调用一次小模型把早期对话压缩成摘要后续请求只携带摘要加最近几轮完整消息。这种做法会牺牲一些信息密度但能大幅降低 Token 消耗。我测试过一个典型的客服场景用摘要方案后上下文 Token 直接削减了 70% 以上回答质量几乎没有明显变化。工具返回结果截断与压缩对工具返回的内容做 Token 预算控制。比如设置单次工具调用结果最多占用 800 Token超出部分按“开头保持 结尾保持 中间截断”的策略裁剪或者直接让大模型对原始结果做摘要后再进入上下文。对结构化数据JSON、表格可以压缩成 key-value 的紧凑格式——省去的空格、缩进、引号加起来的 Token 总量非常可观。系统提示词瘦身定期审计系统提示词删除冗余表述和无用的 few-shot 示例。把动态拼接的指令改为静态模板少量占位符避免每个请求都带着大段重复文本。这一步虽然“技术含量”不高但通常是性价比最高的优化手段。3.3 方向三在协议层做请求级别控制削减小技巧是治标协议层的控制才是治本。网关需要在请求进站时和出站前做两道检查。进站时检查根据会话历史 Token 消耗和当前请求的预估 Token 消耗判断是否超出配额。如果超出直接返回 429 或自定义错误码让客户端降级处理。预估 Token 的方法不要求精确粗估即可——中文字符按 1 个汉字约等于 1.5 到 2 个 Token 估算英文字符按 1 个单词约等于 1.3 个 Token 估算。误差在 20% 以内都不会影响配额控制效果。出站前检查在请求发给下游模型前对拼装好的完整请求体做 Token 计数。如果超出模型上下文窗口或超出该用户/会话的剩余配额则拒绝发送或做自动降级——比如改用更小的模型、切到更便宜的模型版本、或者直接返回缓存结果。这套双检查机制能兜住大多数异常场景。比如前文提到的那位连续发 200 轮请求的同事如果是先经过进站检查在第 N 轮超出会话配额时就会被拦下根本走不到下游。3.4 方向四架构层面做多级缓存与请求合并最后是架构层面的优化思路是减少对大模型的真实调用次数。多级缓存包括结果缓存、语义缓存、部分推理缓存。结果缓存最简单KV 形式直接存用户问题与模型回答的映射命中即直接返回语义缓存稍微复杂些需要把用户问题做向量化后与历史问题做相似度匹配相似度超过阈值的直接复用历史回答可以搭配“这个问题的答案由缓存提供”的提示标识。请求合并则适用于对实时性要求不高的场景。比如多个用户在同一时段问了极其相似的问题网关可以把它们合并为一次模型调用拿到结果后分别返回给所有用户。这个方案实现复杂度较高但效果非常显著尤其适合高频问答类的业务场景。另外还有一条思路是模型分级。把简单的意图识别、文本分类、格式转换放到小参数模型上只有复杂推理、长文本生成才调用大模型。小模型的单 Token 成本通常只有大模型的几十分之一。通过网关按请求复杂度自动路由模型整体成本能下降一个数量级。这条路线值得深入研究。4. 实操落地从排查到优化的完整路径理论和方向都有了具体怎么落地才是关键。下面我把实际项目里从发现异常到完成优化的完整操作流程拆开讲。4.1 第一步锁定激增发生的精确时刻排查问题之前先把“激增”的定义量化。不是单看某一天的总额高了而是要看小时级别的数据曲线。方法很简单从网关日志里把每日请求量和每日 Token 消耗按小时拉出来做对比找出两者的背离点。我遇到的那个项目请求量曲线一直是平稳的但 Token 消耗曲线在凌晨 2 点到 4 点之间出现了陡峭的尖峰。后来查日志发现是某个离线任务在批量调用网关接口且没有做任何限速。单线程跑还好但这个任务开了 50 个并发每个请求都携带完整的对话历史结果 2 小时就烧掉了平时 5 天的 Token 量成本自然就爆了。4.2 第二步确定最大消耗来源锁定了时间段接着要看具体是哪类请求在消耗 Token。我用的是“抽出 Top 100 高消耗请求”的办法在网关日志里记录每个请求的 total_tokens按降序排列查看前 100 条请求的特点。结果发现高消耗请求集中在两类场景一类是携带了超长上下文的会话续接请求另一类是工具调用繁多的复合请求。前者单次请求普遍在 2 万 Token 以上后者虽然没有那么夸张但调用频次很高累计消耗也非常可观。据此我就能确定优化优先级——先解决“超长上下文”这个大头。4.3 第三步实施上下文优化组合方案优先级排定后我落地了两个核心优化第一个是给会话上下文管理器加上了 Token 预算机制。每个会话预设 8000 Token 的上下文预算超出后触发“摘要裁剪”逻辑。具体实现是把前几轮对话发给一个小模型让它生成一段不超过 300 Token 的总结之后的所有请求都携带这段总结代替早期原始消息。第二个是给工具调用结果加上了截断逻辑。在工具返回进入上下文之前做一个预算检查超过 1500 Token 的结果截断到 500 Token 并补一句提示“以下内容因长度限制做了截断如需完整数据请联系技术支持。”这一步对回答质量的影响很小因为大模型即使看到全量数据真正用到的也只是关键字段。4.4 第四步设置配额与告警联动优化做完之后还要防止下一次激增。我在网关里追加了两个配置项用户级日配额与会话级单请求配额。默认值是日配额 100 万 Token单请求配额 3 万 Token超出拒绝并返回明确错误码。同时接入了内部告警平台用量达到阈值的 70% 和 90% 时分别发出预警。这里给一个实测数据作为参考优化前日均消耗约 1200 万 Token优化后稳定在日均 350 万 Token 左右降幅超过 70%。整个优化周期只花了两周一次上线完成。4.5 第五步建立成本运营常态机制优化上线不是终点Token 成本治理应该是一个持续运营的过程。我的建议是每两周固定做一次 Token 消耗复盘拉出本周 Top 消耗来源、环比变化、异常波动时间点逐项审视是否有优化空间。同时把 Token 成本纳入网关的版本发布评审。任何修改了提示词、会话策略、工具调用逻辑的变更都要附带 Token 影响评估避免优化上线后又因为一个小改动把成本打回原形。5. 常见问题与避坑实录这节集中回答我收到的共性问题以及我在实际踩坑后总结的经验。5.1 为什么 OpenAI 的 usage 数据和网关统计的数据对不上这是最容易让人困惑的问题。如果你发现网关记录的总 Token 数和模型服务账单对不上大概率是统计口径不一致。比如有些推理框架把输入输出分开计费有些把历史上下文单独计费还有些缓存命中的 Token 不体现在 usage 中。建议统一以模型服务返回的 usage 字段为准并在网关层做一次手工校验对比网关统计总量和平台账单总量误差控制在一定范围内可接受。5.2 重试机制导致 Token 代码双倍扣费怎么办重试导致的双倍扣费可以从两个层面解决。第一把重试开关默认设为关闭只在幂等接口上显式开启第二在重试请求中打上“重试”标记网关记录消耗时单独归类月末账单核对时可以直接看到重试产生的额外消耗。5.3 提示词瘦身会不会影响模型回答质量会有影响但通常是可以接受的。关键是要做 A/B 测试同一批测试集分别用原提示词和瘦身后的提示词跑一遍对比回答的准确率和用户满意度。只要指标稳定在一个可接受区间瘦身就可以上线。个人经验是提示词的语气词、重复强调、过度冗余的格式说明是最值得删的部分影响最小收益最大。5.4 网关只做简单透传Token 统计能放到业务侧吗可以但不推荐。真实环境里业务侧会很多很杂你很难保证每个服务都统一实现了 Token 统计逻辑。放在网关层的好处是只做一遍所有流量都经过它统计维度自然统一。前期投入不算大但后期的运维收益非常明显。5.5 一些容易被忽略的隐性消耗最后提醒几个大家容易忽略的消耗点心跳检测请求有些客户端实现每隔几秒发一个空请求保活如果网关把这些请求也转发给大模型了成本就白白流失了。建议对这类请求直接返回空响应不进入模型调用链路。联调环境与生产环境共用网关联调时打印日志、重复请求、模拟数据都会真实消耗 Token。建议用独立的沙箱网关或者给联调请求打上特殊标记并限制用量。日志打印完整请求和响应体如果在日志中打印完整的大模型请求/响应报文日志存储成本先不说单是日志系统对字符串的处理开销就能让网关吞吐量明显下降。建议只打印 usage 元数据和请求摘要。以上方案都是我在实际生产中验证过的项目不同、业务不同具体的参数阈值和裁剪策略需要你根据实际情况调整。但核心思路是通用的让 Token 消耗变得可视化、可控制再通过持续优化把它降下来。