成本治理与限流

月底账单爆了，却说不清是哪个租户、哪个接口烧的——这种事在各服务直连供应商时几乎无法避免：token 消耗散落各处、归因无门、限流各自为战。治理要生效，前提是流量先收敛到一道统一卡口。

核心论点

网关是所有 LLM 流量的唯一出口，只有在这里做集中计量、限流、配额与预算熔断，治理才能 100% 覆盖——前提是出口网络策略强制流量经网关（呼应 01 篇）。内嵌进各业务服务、或某服务绕过网关直连供应商，永远有漏网的子调用、算不清的账。

为什么治理必须集中

决策：治理覆盖率 = 卡口唯一性。卡口唯一是结构前提，不是默认成立——这是 01 篇论点的直接推论，也是成本可治理性的根。只要有一个服务直连供应商，那张账单就永远对不上。

三层治理：计量 → 限流 / 配额 → 预算熔断

请求入网关 ↓ ① 计量：按租户 / API Key 记 token 消耗 → "谁花了多少" ↓ ② 限流 / 配额：全局令牌桶 + 租户桶，防单租户打爆 ↓ ③ 预算熔断：超预算即截断，防失控账单

三层里"计量准不准"决定后两层的意义——估算偏差会误伤（正常流量被截断）或漏拦（失控账单没触发熔断）。计量是治理地基。

计量准确性：骨架估算 vs 生产真实计数

决策：预算熔断的阈值基于计量。骨架的近似估算用于限流和预算预警够用，但不能用于精确计费——生产必须接真实 token 计数（Prometheus 指标 + Langfuse 链路）。

网关/metrics暴露的关键字段：

这些指标随gatewayjob 被 Prometheus scrape，供 09 篇业务可观测派生 golden signal。

限流 / 配额如何落地

令牌桶（token bucket，一种按速率放行的限流算法）的原理引分布式系列第 4 篇，本篇只写"网关如何做集中限流 + 租户隔离"。

双桶结构：

请求先扣租户桶、再校全局桶，任一层耗尽即触发限流/熔断。桶为配置驱动、可热更新。

关键设计：建连前limit_check决策——不是发完请求再算账，而是在请求出门前就判断"这次该不该放行"。否则限流就成了事后统计，拦不住已经在路上的请求。

预算熔断的上下游联动

三层治理不是孤岛，是成本防线的"计量—限流—熔断"三段：

阈值设定思路：按租户月预算线性摊到日/小时速率基线，超基线倍数（如 2×1h 基线）即预警；触硬上限则熔断并降级（按 06 跨平面处置总表），避免单租户耗尽全局桶。

阈值取"可观测突增"而非"贴脸上限"，留缓冲给人工干预——贴脸熔断意味着没有任何提前量，发现问题时账单已经爆了。

核心要点

• 成本治理的本质是"卡对位置 + 计量准"：唯一出口保证覆盖，真实计数保证熔断不误判。
• 三层治理：计量 → 限流/配额 → 预算熔断，计量准不准决定后两层有没有意义。
• 阈值取"可观测突增"而非"贴脸上限"，留缓冲给人工干预。
• 计量—限流—熔断三段不是孤岛，与 09 告警、05 自愈联动成成本防线。