一、项目背景

这个项目的起因很现实：我们对接的某头部美妆品牌商，在一个季度末盘账时才发现 AI 相关支出已经超过年初预算约四成，但钱具体花在哪些业务线、哪些模型上，没人说得清。更尴尬的是，调用没有任何前置闸门，某个临时上线的营销文案生成脚本因为循环逻辑 bug，一夜之间把整月配额烧掉大半。业务团队对成本毫无感知，财务对账单只能看到一个总额，无法归因，更谈不上预警。

我们当时被要求做一件事：让 AI 支出变得"看得见、管得住、降得下"。落到技术层面，就是在我们采用的 AI 网关的计量层之上，构建一套部门级预算配额与成本治理机制——每一笔调用在进模型之前先过配额闸门，超预算的部门实时拦截或告警，事后还能下钻到具体接口、具体用户、具体模型，看清楚钱到底花在哪。没有这套机制之前，AI 在中台里更像一笔糊涂账，业务随便调、平台背黑锅。

二、落地场景

落地场景有四个。第一是部门预算配额：按组织架构把预算拆到二级部门，网关在计量层维护每个部门的额度池与消耗速率。第二是超预算拦截与告警：当部门当月消耗接近阈值（如 80%）触发告警，达到 100% 则按策略软拦截（拒绝新请求并提示原因）或硬熔断。第三是成本归因下钻看板：从"部门—应用—接口—模型—用户"五级维度做下钻，定位成本大头。第四是优化建议：基于画像数据，把"用贵模型做的简单任务"识别出来，建议替换为性价比更高的小模型，把降本从口号变成具体动作。

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

预算配额分部门。 最初的难点是配额粒度。按人配额太碎、按公司太粗，我们最终选二级部门为配额单元，但允许部门内设置子账号共享池。配额数据存在网关计量层的分布式计数器里，用滑动窗口统计当月消耗，避免月初清零导致的突刺。这里要处理并发扣减的精度问题，我们用了带 CAS 的原子计数，确保多实例网关部署下不超卖——否则一个部门在并发高峰可能被多扣或漏扣，额度账就对不上。

超支实时拦截。 拦截不能等批处理对账，必须实时。我们在网关路由层前置一个配额中间件，每次请求先查部门剩余额度，不足则直接返回 429 并带上剩余额度和重置时间。但纯硬拦截会误伤关键业务，所以策略做成可配置：核心交易类应用设为"告警+限速"，营销类长尾应用设为"硬拦截"。阈值也分档：80% 黄灯告警、95% 橙灯限速、100% 红灯拦截，业务方在管控台可以自助调整，不用改代码。

成本归因下钻。 归因的本质是把每一笔 token 消耗打上完整的维度标签。我们在计量层记录每次调用的 department_id、app_id、api_path、model_id、user_id 以及 token 数和折算费用，写入时序库。看板用这些维度做多维聚合。难点在于"模型—成本"的折算口径要统一：我们和模型注册中心的能力画像共用同一套每千 token 成本基准，保证路由层算出来的成本和计量层对账的数字对得上，否则下钻出来的账单财务不认。

预算告警。 告警不能只在月底响。我们设计了基于消耗速率的预测告警：根据当月已过天数和当前累计消耗，线性外推月末是否超支，提前约 7 天预警。告警通过网关管控台和消息总线双通道推送，避免漏看。同时给每个部门负责人开放自助看板，让成本责任下沉到业务侧，而不是只压在平台团队身上——这一步对落地效果影响很大，业务方看到自己的账单才会主动优化。

四、效果数据

运行约两个月后，关键治理指标如下（均为脱敏示意值）：

最直观的变化是，财务第一次能拿着部门级账单去和业务对齐，而不是甩一个总数让对方自己猜。平台团队也从"背锅侠"变成了"提供工具的人"。

五、可复用经验总结

第一，先有预算再谈优化。我们当时的教训是，没有配额闸门时谈"降本"全是空话，因为根本不知道钱花哪。预算配额是成本治理的地基，先把额度划清楚，优化才有抓手，预警才有基准线。

第二，归因下钻找浪费。真正省下那约 28% 的成本，靠的不是砍预算，而是下钻后发现大量"用贵模型做的简单分类任务"，把它们路由到小模型后费用大幅下降。可见性带来的是结构性优化，而非粗暴限额，业务体感也更好。

第三，拦截策略要分级。一刀切硬拦截会误伤核心业务，按业务重要性分级（告警/限速/拦截）才落得下去。把成本责任下沉到部门负责人，比平台团队单方面限速更有效，也更符合"谁用谁负责"的治理逻辑。

案例片段（已脱敏）： 预算配额与告警配置片段（网关计量层策略）：yaml quota:  department: marketing-ai  monthly_budget_cny: 50000  shared_pool: true  policy:    - threshold: 0.80      action: alert        # 黄灯告警    - threshold: 0.95      action: throttle     # 橙灯限速    - threshold: 1.00      action: block        # 红灯拦截  critical_apps:    - order-review    - risk-check  critical_policy: alert_only   # 核心应用只告警不拦截 alert:  forecast: true          # 基于速率预测月底超支  lead_days: 7  channels: [console, mq]