大模型应用上线三个月账单从每月两千涨到两万八这是很多团队真实经历过的曲线。模型能力确实强但每一次对话、每一次文档解析、每一次 Agent 工具调用背后都是实打实的 Token 在燃烧。更麻烦的是钱花出去了却说不清花在哪儿——是哪个业务线在跑批量任务是哪个测试环境忘了关还是某个 Prompt 写得太啰嗦导致输入 Token 翻了三倍。没有计量就没有管理这句话在大模型成本治理上体现得淋漓尽致。API 网关在这里扮演的角色不是简单的请求转发而是整个成本治理体系的数据入口和控制阀门。它站在所有模型调用的必经之路上天然具备做用量采集、配额限制、路由降级、缓存复用的位置优势。这篇内容围绕用 API 网关做 Token 消耗管控展开把计量口径怎么定、配额怎么设计、缓存怎么省、降级怎么做这几件事讲透适合正在为大模型账单发愁的后端工程师、平台架构师和 AI 应用负责人参考。下面这些经验一部分来自实际项目踩过的坑一部分是基于常见工程实践做的合理推演你可以在自己的环境里对照验证。1. 先搞清楚 Token 到底花在了哪里1.1 大模型计费的基本单位与计量口径大模型的计费单位是 Token这个词在自然语言处理里指的是文本被切分后的最小片段。英文里一个单词可能对应一到两个 Token中文里一个汉字通常对应一到两个 Token具体取决于模型使用的分词器。计费时输入 Token 和输出 Token 是分开算的而且输出 Token 的单价普遍比输入贵通常是输入的三到四倍。这个价格结构决定了成本优化的重点方向控制输入长度能省钱但控制输出长度省得更多。很多团队一开始只盯着调用次数做统计结果发现调用次数没涨账单却翻倍了。原因就在于单次请求的 Token 量在膨胀。比如把整篇文档塞进上下文做问答一次请求可能就是几万 Token再比如让模型做长文摘要输出动辄几千 Token。所以计量口径必须落到 Token 维度而不是请求维度。API 网关在转发请求时需要把请求体和响应体都解析出来分别统计输入和输出 Token再按模型单价折算成金额。这里有个容易忽略的点不同模型的 Token 单价差异巨大。同一个网关可能同时对接了轻量模型和旗舰模型如果统计时不区分模型成本数据就是一笔糊涂账。网关的计量模块必须把模型标识作为统计维度之一否则后面做成本归因时根本没法拆。1.2 请求链路中 Token 消耗的分布特征把一次大模型调用拆开看Token 消耗分布在几个环节。系统提示词是固定开销每次请求都要带上如果系统提示写得很长这部分成本会持续累积。用户输入是变量开销取决于用户实际输入的内容长度。历史对话上下文是容易被低估的部分多轮对话场景下每一轮都要把之前的对话历史重新发一遍Token 量随轮次线性增长。检索增强生成场景下召回的文档片段会拼进提示词这部分可能比用户问题本身长几十倍。最后是模型输出包括正式回答和思维链内容。我见过一个客服机器人项目系统提示词写了三千多 Token包含各种业务规则和话术模板。单看一次请求不算多但这个机器人每天处理两万次对话光系统提示词一天就是六千万 Token 的输入。后来把系统提示词精简到八百 Token把详细规则改成按需检索一个月省下来的费用够买一台不错的服务器。这个案例说明Token 管控不能只看单次请求要乘以调用量来看总账。网关做计量时最好能把这几部分拆开统计。系统提示词、用户输入、检索内容、历史上下文、模型输出各自占多少比例。有了这个分布数据优化才有方向。如果系统提示词占比过高就去精简提示词如果检索内容占比过高就去优化召回策略如果历史上下文占比过高就去做对话摘要压缩。1.3 为什么请求次数统计会严重低估真实成本请求次数是个迷惑性很强的指标。一个批量处理任务可能只发一次请求但这次请求里塞了一百条待处理数据Token 量是普通请求的几十倍。反过来一个高频的轻量问答请求次数很多但每次 Token 很少总成本可能并不高。如果只按请求次数做配额就会出现两种失控批量任务用少量请求消耗大量 Token或者轻量问答被误伤限流。正确的做法是双维度管控请求次数和 Token 用量都要设限。请求次数限制防的是高频刷接口Token 用量限制防的是单次大请求。两者结合才能覆盖完整的成本风险。网关在做限流时可以给每个调用方分配两个配额桶一个按次数计一个按 Token 计任意一个触顶就触发限流。这样既能拦住恶意刷量也能拦住无意识的资源滥用。还有一个细节流式响应场景下Token 是逐步吐出来的网关需要边转发边累计输出 Token。如果等响应结束再统计遇到客户端提前断开的情况就会漏计。比较稳妥的做法是在流式转发的过程中对每个数据块做增量解析实时累加输出 Token 数同时在连接关闭时做一次最终结算。2. API 网关做 Token 管控的架构落点2.1 网关在模型调用链路中的位置选择API 网关放大模型调用链路上位置不同能做的事情差别很大。放在客户端和模型服务之间是最常见的选择所有请求必经此地计量和限流都能覆盖。放在模型服务和后端业务之间适合做服务间的统一治理。还有一种做法是在网关前面再加一层边车代理做更细粒度的流量镜像和采样。对于 Token 管控这个目标网关放在客户端和模型服务之间是最直接的。它能看到完整的请求和响应能拿到调用方身份能在转发前做配额检查能在响应后做用量结算。如果网关放在更靠后的位置可能会漏掉一些直连模型的调用计量就不完整了。实际部署时还要考虑网关本身的高可用。大模型调用往往是业务关键路径网关挂了业务就断了。所以网关需要多实例部署配额数据要放在共享存储里比如 Redis 或者分布式数据库保证多个网关实例看到的是同一份配额账本。如果配额数据只存在单个网关实例的内存里实例重启或者扩容时配额就会错乱。2.2 请求解析与 Token 预估的实现方式网关要统计 Token首先得把 Token 数算出来。最准确的方式是调用模型官方的分词器但分词器通常比较重在网关这种高并发场景下逐个请求调用分词器延迟和资源消耗都吃不消。实践中常用的是预估加校准的组合方案。预估阶段网关用轻量级的规则做 Token 数近似计算。比如按字符数除以一个经验系数英文大约四字符一 Token中文大约一点五字符一 Token。这个预估值用于转发前的配额预扣速度快能拦住明显超额的请求。校准阶段等模型响应返回后从响应体的 usage 字段里拿到真实的 Token 数用真实值替换预估值做最终结算。这样既保证了转发前的拦截效率又保证了结算的准确性。有些模型服务的响应里不带 usage 字段或者流式响应里 usage 在最后一个数据块才出现。这种情况下网关需要自己维护一个分词器做精确计算或者退而求其次用预估值做结算但要在账单里标注这是预估值避免和真实账单对不上。我个人的经验是如果模型服务支持返回 usage一定要用真实值结算预估值只用于转发前的快速拦截两者不要混用。2.3 配额模型按调用方、按模型、按时间窗配额模型的设计直接决定了管控的精细度。最粗的粒度是全局配额所有调用方共享一个总额度简单但容易互相影响。细一点的是按调用方配额每个业务线、每个应用、甚至每个用户有自己的额度。再细一点的是按调用方加模型配额同一个调用方调用不同模型有不同的额度。最细的是再加时间窗比如每小时、每天、每月的额度分别设置。实际项目中我建议至少做到按调用方加模型加时间窗的三维配额。按调用方是为了成本归因知道钱是谁花的。按模型是为了防止有人用旗舰模型跑本该用轻量模型的任务。按时间窗是为了平滑消耗避免月初就把整月额度用完。这三个维度组合起来基本能覆盖大部分管控需求。配额的数据结构可以设计成层级化的。顶层是租户或者业务线下一层是应用再下一层是模型每个层级都有自己的额度上限。检查配额时从最细的层级开始查任意一层触顶就拒绝。这种层级结构的好处是既能做精细管控又能在业务线层面做总量兜底。配额维度管控目标适用场景实现复杂度全局配额防止总成本失控初期快速上线低按调用方成本归因与分摊多业务线共用网关中按调用方模型防止模型滥用同时接入多档模型中高按调用方模型时间窗平滑消耗与预算控制有明确月度预算高2.4 计量数据的采集、聚合与落库计量数据是成本治理的基础采集要全聚合要快落库要稳。采集环节网关每处理一次请求就产生一条计量记录包含调用方、模型、输入 Token、输出 Token、时间戳、请求 ID 等字段。这条记录可以先写到本地日志或者消息队列异步落库避免阻塞主请求链路。聚合环节原始记录量可能很大直接查明细做报表会很慢。需要做预聚合按小时、按天、按调用方、按模型等维度提前算好汇总数据。预聚合可以用流处理做也可以用定时任务做。流处理实时性好但复杂度高定时任务简单但有延迟。如果对实时性要求不高定时任务就够了。落库环节原始明细和聚合汇总要分开存。明细用于问题排查和对账保留周期可以短一些比如三十天。汇总用于成本分析和报表保留周期长一些比如一年。存储选型上明细可以放对象存储或者日志系统汇总放关系型数据库或者分析型数据库。这样既控制了存储成本又保证了查询性能。3. 把 Token 花在刀刃上的缓存与路由策略3.1 语义缓存相同或相似请求的复用缓存是降低 Token 成本最直接的手段。如果两个请求的语义相同第二个请求就没必要再调模型直接返回缓存结果就行。这里的关键是语义相同的判断。最简单的做法是精确匹配请求内容完全一样才命中缓存。但实际场景中用户问法千变万化怎么退款和如何申请退款意思一样但字面不同精确匹配命中率很低。语义缓存的做法是把请求内容转成向量在向量库里做相似度检索超过阈值就认为语义相同返回缓存结果。这个方案命中率比精确匹配高很多但引入了向量化和检索的开销。向量化本身也要调模型如果用一个轻量模型做向量化成本可以接受。检索用向量数据库延迟通常在毫秒级。语义缓存适合什么场景适合那些问题重复度高、答案相对稳定的场景比如产品 FAQ、客服常见问题、文档问答。不适合什么场景不适合个性化强、答案依赖实时数据的场景比如我上个月的账单是多少这种问题缓存了反而会出错。所以语义缓存要配合场景白名单使用只对特定类型的请求开启。注意语义缓存的相似度阈值需要根据业务调优。阈值太高命中率低阈值太低容易返回错误答案。建议先用历史请求做离线测试找到命中率和准确率的平衡点再上线。3.2 提示词压缩与上下文裁剪提示词压缩是从源头减少 Token 消耗。系统提示词能精简就精简把不常用的规则挪到按需检索里。历史对话上下文可以做摘要压缩把早期对话用模型总结成一段短文本替代原始的多轮对话记录。检索增强生成场景下召回的文档片段要做去重和排序只保留最相关的几条而不是一股脑全塞进去。上下文裁剪有个原则保留最近几轮对话的原文更早的对话做摘要。因为最近几轮通常和当前问题最相关摘要会损失细节。摘要的粒度可以是每五轮做一次把五轮对话压缩成两三句话。这样既控制了上下文长度又保留了关键信息。还有一个技巧是动态上下文窗口。根据请求的复杂度决定带多少历史上下文。简单问题只带最近一轮复杂问题才带更多历史。这个判断可以在网关层做根据请求内容的关键词或者意图分类来决定。虽然增加了一点网关的逻辑复杂度但省下来的 Token 很可观。3.3 模型路由按任务复杂度选择合适档位不是所有任务都需要旗舰模型。简单的意图识别、文本分类、格式转换用轻量模型就够了成本可能只有旗舰模型的十分之一。模型路由的核心是根据任务复杂度把请求分发到不同档位的模型上。路由策略可以基于规则也可以基于模型判断。基于规则的做法是维护一个任务类型到模型档位的映射表比如意图识别走轻量模型内容生成走旗舰模型。基于模型判断的做法是用一个小模型先做难度评估再决定路由到哪个档位。规则方案简单可控模型判断方案更灵活但多了一次调用开销。实际落地时我建议先用规则方案跑起来把常见的任务类型和对应的模型档位梳理清楚。等积累了一定数据后再考虑用模型做动态路由。规则方案的好处是行为可预测出问题容易排查。动态路由虽然理论上更优但调试复杂度高不适合一开始就上。任务类型推荐模型档位成本对比路由依据意图识别轻量模型基准的10%规则匹配文本分类轻量模型基准的10%规则匹配简单问答中档模型基准的30%规则匹配内容生成旗舰模型基准的100%规则匹配复杂推理旗舰模型基准的100%规则匹配3.4 降级与熔断超额时的优雅处理配额用完或者模型服务异常时网关需要有降级策略而不是直接报错。降级的方式有几种切换到更便宜的模型、返回缓存结果、返回预设的兜底话术、排队等待配额恢复。选择哪种降级方式取决于业务场景。对于非实时场景比如批量文档处理排队等待是可行的。对于实时对话场景排队会让用户等太久切换到轻量模型或者返回缓存更合适。对于关键业务可能需要预留一部分紧急配额正常配额用完时还能继续服务。熔断是另一个维度的保护。当某个模型服务错误率飙升或者响应时间过长时网关应该自动熔断把请求路由到备用模型或者直接降级避免大量请求堆积导致雪崩。熔断的阈值要根据历史数据设定错误率超过百分之多少、响应时间超过多少毫秒触发熔断。熔断后要有恢复机制定期探测服务是否恢复恢复了就自动切回。4. 从账单到行动成本归因与持续优化4.1 成本归因把账单拆到业务线成本归因是让每个业务线知道自己花了多少钱。网关的计量数据里已经有调用方标识按调用方聚合就能得到各业务线的成本。但光有总数还不够还要能拆到具体功能、具体场景。这需要在调用时打上更细的标签比如功能模块、请求来源、用户分群等。标签的设计要提前规划不能等账单出来了才想拆。常见的标签维度包括业务线、应用、功能模块、环境生产/测试、用户等级。这些标签在请求头里带上网关采集时一并记录。有了这些维度成本报表就能按任意组合下钻定位到具体是谁在花钱。我见过一个团队测试环境的调用没有打标签和生产环境混在一起统计。结果发现测试环境竟然占了总成本的百分之四十因为自动化测试脚本每天跑大量用例。后来给测试环境单独打标签并设置低配额成本立刻降下来了。这个案例说明标签不全成本归因就是盲人摸象。4.2 异常检测识别突增与异常调用模式成本突增往往有原因要么是业务量涨了要么是有人在滥用。网关可以基于历史数据建立基线当某个调用方的 Token 消耗偏离基线超过一定比例时触发告警。告警要能定位到具体调用方和具体时间段方便快速排查。异常模式有几种典型形态。一种是单次请求 Token 量异常大可能是有人把整个文档库塞进了上下文。一种是请求频率异常高可能是脚本在刷接口。一种是调用时间异常比如凌晨三点突然大量调用可能是定时任务配置错了。网关的异常检测要能识别这些模式并给出对应的处理建议。告警之后要有处置手段。轻则通知调用方自查重则自动限流或者暂停配额。处置策略要分级不能一上来就停服务那样可能误伤正常业务。可以先降速再限流最后才暂停。每一步都给调用方留出反应时间。4.3 配额动态调整与预算周期管理配额不是定死的要根据实际使用情况动态调整。月初可以给宽松一点的配额月末根据剩余预算收紧。业务高峰期可以临时提额低谷期收回。这种动态调整需要网关支持配额的实时修改并且修改要能立即生效。预算周期管理是另一个要点。很多团队是按月做预算但配额是按天或者按小时设置的。需要有一个换算机制把月度预算拆解到每天每小时的额度。同时要监控消耗速度如果发现按当前速度会在月中就把预算用完要提前预警并采取措施。动态调整的决策可以基于历史数据做预测。比如根据过去三个月的消耗曲线预测本月每天的合理额度。实际消耗偏离预测时自动调整后续的额度。这种预测加调整的闭环能让配额管理从被动变主动。4.4 优化闭环从数据到策略的迭代成本治理不是一次性的项目而是持续迭代的过程。每一轮迭代都遵循采集数据、分析问题、制定策略、验证效果的循环。网关提供数据分析找到优化点策略在网关落地效果通过数据验证。迭代的频率取决于业务变化速度。业务稳定的团队每月做一次复盘就够了。业务快速变化的团队可能需要每周甚至每天看数据。复盘时要关注几个核心指标总成本、单位请求成本、缓存命中率、降级触发次数、配额触顶次数。这些指标的变化趋势能反映治理效果。优化策略要有优先级。通常先做缓存因为收益直接且风险低。再做提示词压缩和上下文裁剪需要业务配合但收益也明显。然后做模型路由需要梳理任务类型。最后做配额和降级这是兜底手段。按这个顺序推进每一步都能看到成本下降团队也有动力继续做下去。5. 落地过程中容易踩的几个坑5.1 计量不准导致的对账纠纷计量不准是成本治理中最常见的问题。网关统计的 Token 数和模型服务账单上的数字对不上业务方就会质疑数据的可信度。造成不准的原因有几个预估值和真实值的偏差、流式响应的漏计、异常请求的漏记、多网关实例的数据不一致。解决计量不准首先要统一口径。网关统计的 Token 数要和模型服务的计费口径一致输入输出分开算不同模型分别算。其次要保证采集完整所有经过网关的请求都要记录不能有遗漏。再次要保证数据一致多实例部署时配额和计量数据要共享存储。最后要定期对账把网关数据和模型账单做比对发现偏差及时排查。对账的粒度建议按天做每天比对一次总量。如果偏差超过阈值就下钻到调用方和模型维度定位偏差来源。偏差可能是技术问题也可能是业务问题比如有人绕过了网关直接调模型。对账机制能发现这些漏洞。5.2 限流误伤正常业务的处理限流是把双刃剑用好了控制成本用不好误伤业务。误伤通常发生在配额设置过紧、限流粒度太粗、突发流量没预留缓冲这几种情况。比如给某个业务线设了很低的配额结果它搞了一次促销活动流量涨了十倍直接被限流用户投诉就来了。避免误伤配额设置要留缓冲。根据历史峰值再上浮一定比例而不是按平均值设。限流粒度要细能精确到具体调用方和具体模型而不是一刀切。突发流量要有应对机制比如允许短时间超额但超额部分要记录并告警事后追认或者调整配额。限流触发后的处理也很重要。不能直接返回错误要有降级方案。降级可以是返回缓存、切换模型、排队等待。同时要通知调用方让他们知道被限流了以及为什么。透明的沟通能减少很多扯皮。5.3 缓存失效与数据一致性的平衡缓存用得好省钱用不好出事故。最大的风险是缓存了不该缓存的内容导致用户看到过时或者错误的信息。比如用户问我的订单状态缓存了上一个用户的答案这就严重了。所以缓存必须区分场景个性化查询不能缓存公共知识可以缓存。缓存的失效策略也要设计好。有些内容有时效性比如今天的天气缓存一小时就过期了。有些内容相对稳定比如产品退货政策可以缓存久一点。失效策略可以基于时间也可以基于事件比如产品政策更新时主动清除相关缓存。缓存命中率是衡量缓存效果的核心指标。命中率太低说明缓存策略有问题可能是阈值设太高或者缓存的内容太分散。命中率太高也要警惕可能是缓存了不该缓存的内容。定期审查缓存内容确保缓存的都是适合缓存的。5.4 多模型接入时的计费口径统一一个网关往往要接入多个模型服务每个模型的计费方式可能不同。有的按 Token 计费有的按请求计费有的按字符计费。计费口径不统一成本数据就没法横向对比也没法做统一管控。统一口径的做法是建立一个换算层把不同模型的计费方式都折算成 Token 成本。按请求计费的根据平均 Token 量折算成单 Token 成本。按字符计费的根据字符和 Token 的换算比例折算。折算系数要定期校准因为模型价格会调整。统一口径之后配额和限流就能跨模型生效。调用方看到的是一个统一的成本数字而不是每个模型一套账。这样业务方更容易理解自己的成本构成也更容易做优化决策。6. 一些实操层面的经验补充6.1 网关性能与计量开销的平衡在网关上做计量和限流必然会增加请求延迟。计量要解析请求体和响应体限流要查配额存储这些都是开销。如果开销太大网关就成了瓶颈。所以要在功能完整性和性能之间找平衡。优化的方向有几个。计量解析可以异步做不阻塞主请求链路。配额检查可以用本地缓存加定期同步减少对共享存储的查询。Token 预估用轻量规则精确计算放到异步环节。这些优化能把网关增加的延迟控制在毫秒级。压测是验证性能的必要环节。上线前要用真实流量做压测看网关在峰值流量下的延迟和吞吐。如果延迟增加超过可接受范围就要继续优化。压测时还要模拟各种异常场景比如配额存储不可用、模型服务超时看网关的降级行为是否符合预期。6.2 与现有监控告警体系的对接网关的计量数据要和现有的监控告警体系打通而不是另起一套。成本告警可以复用现有的告警通道成本报表可以集成到现有的数据看板。这样运维和业务方不用切换多个系统使用成本低推广阻力小。对接的方式可以是网关把计量数据推到现有的监控系统比如时序数据库或者日志平台。然后在监控系统里配置告警规则和报表。也可以网关提供 API监控系统定期拉取数据。选择哪种方式取决于现有系统的能力。告警规则的设计要避免噪音。成本告警太敏感会天天响大家就麻木了。太迟钝又会漏掉问题。建议分级告警轻微异常只记录不通知中度异常通知到负责人严重异常才升级。告警阈值根据历史数据动态调整而不是拍脑袋定。6.3 团队协作谁负责配额谁负责优化成本治理不是网关团队一个团队的事需要多方协作。网关团队负责提供计量和管控能力业务团队负责合理使用和优化财务团队负责预算和核算。角色不清会导致互相推诿。建议明确几个责任方。平台团队负责网关的建设和运维保证计量准确和管控有效。业务团队负责自己的配额使用对超支负责。成本治理小组负责制定策略和推动优化成员来自平台、业务和财务。这个小组定期开会看数据决定配额调整和优化方向。协作机制要落到流程上。配额申请有流程优化有跟踪超支有复盘。流程不用太复杂但要有记录可追溯。这样成本治理才能持续运转而不是一阵风。6.4 从零搭建的最小可行方案如果团队刚开始做成本治理不用一上来就搞大而全的方案。可以先做一个最小可行版本快速上线拿到数据后再迭代。最小版本包含三件事计量、看板、告警。计量就是网关记录每次请求的 Token 用量按调用方和模型聚合。看板就是把聚合数据可视化让业务方看到自己的消耗。告警就是设置一个简单的阈值超过就通知。这三件事做完成本治理的基本盘就有了。最小版本上线后观察一到两周的数据看看消耗分布和异常情况。然后根据数据决定下一步做什么。如果发现缓存能省很多就做缓存。如果发现某个业务线消耗异常就去做配额。这种数据驱动的迭代方式比一开始就规划大方案更务实。我在实际项目中的体会是成本治理最难的不是技术而是让业务方有成本意识。网关提供了数据和工具但如果业务方不关心成本治理效果就有限。所以除了技术手段还要做成本透明化让每个业务方看到自己的消耗和排名形成同侪压力。再配合一些激励措施比如省下来的成本可以折算成资源额度业务方就有动力主动优化了。