一、项目背景

有个月底，某部门的 token 费用突然涨了三倍。财务找过来，我们挨个问调用方，问了一圈才知道是有人把一份很长的文档塞进循环里反复调用，单次看着不大，乘上循环次数就炸了。但问题在于，调用方自己根本看不见自己的用量，只能找我们查，我们查一次要翻网关日志、聚合、下钻，半天就这么没了。这种"费用异常靠人肉排查"的模式，随着接入的部门变多，迟早把我们团队淹掉。

我们意识到，网关作为统一计量入口，本该让每个调用方自助看到自己的用量和费用，异常波动能自己归因，而不是每次都来敲我们的门。

二、落地场景

我们在网关管控台给每个调用方开了自助用量看板。看板按时间维度展示 token 消耗、调用次数、费用，并且能下钻到应用、到用户、到具体模型。调用方登录就能看到自己这个月烧了多少、花在哪些场景。

成本异常这块，我们配了波动告警：某应用日用量偏离自身基线超过阈值，自动推告警给该应用的负责人，而不是等月底对账才发现。告警里直接带 Top 消耗来源，负责人点开就能看到是哪个人、哪类请求、哪个模型拉高了。对于确认的异常，调用方可以在看板侧自助设临时限额，超了自动降级或拦截，不用再走工单等我们批。

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

用量实时聚合是个工程坑。网关每天产生的调用记录以亿计，实时聚合到调用方维度对存储和算力都是压力。我们做了分层：近实时走预聚合窗口，历史走离线数仓，看板优先读预聚合结果，秒开。这里我得说，最初我们想全实时，结果看板一打开就卡，后来改成预聚合加离线兜底，体验才正常。

成本下钻粒度要够细才有用。只到应用级，负责人还是不知道是谁干的；下钻到用户和单次请求特征，才能定位到"某人在循环调长文本"。但粒度太细又有隐私和性能问题，我们折中到下钻到用户加请求类型，够定位又不至于过度。

异常波动识别要防误报。业务本身有自然波动（比如周一比周日高），简单同比会误杀。我们用每个应用自己的历史基线做偏离度，而不是全局统一阈值，误报少了很多。

权限设计也要想清楚。看板默认只给调用方看自己名下数据，跨应用看不到，避免一个部门能翻另一个部门的用量，引发不必要的比较和猜测。财务视角单独开汇总权限，看全局不看出细。我们早期把明细全开放，结果两个部门为谁更费吵了一架，后来收紧到各看各的才消停。临时限额的粒度也放开到应用内用户组，确认异常时能精准拦某一撮人，而不是误伤整个应用正常流量。

历史追溯我们也兜住了。调用方偶尔要查三个月前的某笔异常消耗，看板默认只给近三十天，更久的走离线导出。我们做了冷热分层，热数据秒开，冷数据异步生成，既不拖慢日常也不丢审计。财务月底对账时就靠这个导出，把某笔超额追溯到具体用户和请求类型，账才对得平。可追溯性这层，平时无感，出事时是底气。

我们把看板也接进了预算流程。部门月初在网关侧设本月额度，超了自动预警并限流，财务不用月底才发现问题。这层让成本从事后追溯变成事前框定，几个花钱猛的部门被框住后，整体预算可控多了，我们也少了救火式查账。

案例片段（已脱敏）： 某应用日费用基线约 420 元，某日突增至 1380 元。告警触发并下钻，定位到用户 U_2073 的"合同摘要"类请求，单次平均输入 tokens 从 1800 升至 21000，且调用频次翻倍。查看请求特征，发现该用户脚本未去重，将同一份 20 页合同在循环里重复提交。负责人在告警发出后 20 分钟内确认并设了单用户日限额，次日该应用费用回落至 450 元。全程未占用平台侧排障人力。

四、效果数据

异常发现时效从原来平均约 2 天（月底对账）提升到告警触发的分钟级，那次暴涨若是早两天发现能省一大笔。费用超支在自助限额上线后下降明显，几个高频异常应用月费用回归基线。查账人工时长，平台侧从每月约 30 人时降到接近 0，调用方自助率超过九成。

财务那边最满意的是可解释性，每一笔超额都能说清是谁、哪类请求造成的，不再是糊涂账。

五、可复用经验总结

网关让调用方自助看用量，是降低成本扯皮最划算的一步。费用异常要下钻到人和请求类型，只到应用级等于没定位，我们早期查一次半天就是卡在这。告警按应用自身基线做偏离度，别用全局阈值，不然业务自然波动能把你淹在误报里。自助限额要放开给调用方，确认异常当场就能拦，不用走工单等我们批。把成本可见性交出去，平台团队才能从救火查账里抽身，去做更值钱的事。