一、项目背景

我们接了网关计费之后，本以为成本可控了，结果某业务方一夜之间刷了平时十倍的费用。查下来是循环调用加上超长上下文，token 像水一样流，谁都没设上限。月底账单出来，财务直接找过来，钱已经花出去，预算形同虚设。我们事后翻日志，那个脚本其实跑了六个小时，前三个小时还算正常，后三个小时进入死循环，单价乘上超长上下文，单小时花掉平时一天的量。更隐蔽的是，因为走的是部门共用账号，这笔钱混在整体账单里，财务月初才察觉，追都追不回来。

我们当时意识到，网关计费如果不接熔断，就等于给调用方开了一个没有上限的敞口，花的是真金白银，而且出事时往往是半夜，等第二天发现已经晚了，事后追责也补不回成本。后来我们给财务也开了只读面板，他们能实时看到各部门当日消耗和异常标记，不用等月底账单再吓一跳，财务说这下终于不用当惊弓之鸟了。

二、落地场景

方案分五块。一是调用成本实时计量：每次调用按 token 乘单价流式累加，不再等月底结算才发现。二是成本异常检测：对部门、应用、调用方做环比和同环比，突增即告警。三是按部门配额：每个部门在网关侧有日级和月级预算上限。四是超额熔断：预算耗尽立刻拒绝新调用，返回明确错误而不是继续烧钱。五是成本告警与归因：超阈值时标记具体调用方和场景，方便定位。

三、关键技术挑战与解决思路

最磨人的是成本实时计量。大模型调用是流式的，token 边生成边计费，不能在请求结束才算，否则熔断永远慢半拍。我们把计量做成流式累加，网关在请求进行中就更新配额余量，超了马上断，不等请求跑完。

另一个坎是异常检测的误报。业务高峰本来就会涨，单纯看绝对值会误伤正常活动。我们改成相对阈值加时间窗，只有偏离自身基线数倍且持续才触发，避免大促被误熔断，误报率从一开始就压住了，业务方才愿意配合。

还有超额熔断的姿势。第一版只做了告警不熔断，财务还是被吓到，告警拦不住真金白银。后来改成超预算硬拒绝，并给调用方返回结构化错误码，让它自己降级，而不是无限重试把账烧穿，业务方也据错误码做了退避。

还有一处细节，是配额和异常检测的配合。光有配额熔断，遇到的是硬上限，但很多事故是温水煮青蛙式地涨，单日没超配额但速率异常。所以我们把异常检测放在配额之前做预警，配额做最后兜底，两层叠加才稳。异常检测那块，我们用的是调用方自身的七日基线，而不是全平台平均值，因为不同业务部门用量天差地别，用全局平均会天天误报。这个小改动让误报率直接下来，业务方才愿意把检测开起来，不然天天告警他们就当狼来了。现在财务和我们都盯那块面板，月初对账前就能先看到异常苗头。我们也给配额做了分级，日级熔断加月级预警，月级不硬拦但提醒，避免一个脚本把整月预算一天造完，后面二十多天全停摆。

案例片段（已脱敏）： 成本配额与熔断（配置节选）：metering:  mode: streaming  price_per_1k_tokens: {input: 0.012, output: 0.036} quota:  scope: department  daily_limit: 2000   # 元  on_exceed: reject anomaly:    baseline: self_7d    multiplier: 3x    window: 10m某部门脚本死循环，十分钟花了约 1800 元，熔断在日限额 2000 处拦截，而此前无熔断版本同款事故单晚账单达 1.2 万元，且钱已结算无法追回。

案例片段（已脱敏）： 某次大促，一个部门调用量较平日涨了两倍，绝对值看着吓人。异常检测按自身基线比对，发现仍在三倍阈值内且持续平稳，判定为正常活动，没有误熔断，大促顺利跑完。同周另一个部门出现十倍突增且只集中在单一脚本，系统在十分钟内告警并标记调用方，业务方自己停了脚本，没等到熔断就止了损。

四、效果数据

超额拦截率约 100%，成本异常发现时延从原来的次日缩短到十分钟内。预算执行率从混乱状态提升到可预期，超额事故从每月数起降到零。财务侧月底对账差异基本消失，那个死循环脚本后来被业务方自己加了退出条件。文中数据为项目复盘口径，已做脱敏。

五、可复用经验总结

网关计费不接熔断就是敞口花钱，按部门上配额加异常检测，超了直接断，这比任何告警都管用。计量必须流式，不能在请求末才算，否则熔断永远慢半拍。异常检测用自身基线比绝对值稳，大促不会被误伤。说实话，配额额度那块我们和财务吵了好几轮才定下来，定太低业务骂、定太高等于没设，最后按历史峰值的 1.5 倍给了缓冲，既拦得住事故又不误伤正常扩张。成本这件事，业务只关心能不能用，财务只关心花多少，网关把两者之间的闸口做出来，两边才都不用来找我们扯皮。