月底账单爆了却说不清是哪个租户、哪个接口烧的——这种事在各服务直连供应商时几乎无法避免token 消耗散落各处、归因无门、限流各自为战。治理要生效前提是流量先收敛到一道统一卡口。核心论点网关是所有 LLM 流量的唯一出口只有在这里做集中计量、限流、配额与预算熔断治理才能 100% 覆盖——前提是出口网络策略强制流量经网关呼应 01 篇。内嵌进各业务服务、或某服务绕过网关直连供应商永远有漏网的子调用、算不清的账。为什么治理必须集中部署形态成本统计限流阈值租户隔离内嵌式各服务自调供应商碎片化归因无门各服务各自为战阈值冲突难做独立网关唯一出口全量经一道天然全覆盖统一卡口阈值一致按 API Key/tenant 天然隔离决策治理覆盖率 卡口唯一性。卡口唯一是结构前提不是默认成立——这是 01 篇论点的直接推论也是成本可治理性的根。只要有一个服务直连供应商那张账单就永远对不上。三层治理计量 → 限流 / 配额 → 预算熔断请求入网关 ↓ ① 计量按租户 / API Key 记 token 消耗 → 谁花了多少 ↓ ② 限流 / 配额全局令牌桶 租户桶防单租户打爆 ↓ ③ 预算熔断超预算即截断防失控账单三层里计量准不准决定后两层的意义——估算偏差会误伤正常流量被截断或漏拦失控账单没触发熔断。计量是治理地基。计量准确性骨架估算 vs 生产真实计数维度骨架当前生产计数方式按字符数近似估算后端 usage 回写真实 token误差来源流式首包难预知总长 / 多模态计价不同 / 部分后端不返回 usage同上需明确口径用途限流与预算预警精确计费决策预算熔断的阈值基于计量。骨架的近似估算用于限流和预算预警够用但不能用于精确计费——生产必须接真实 token 计数Prometheus 指标 Langfuse 链路。网关/metrics暴露的关键字段指标含义gateway_requests_total请求数按租户/模型维度gateway_tokens_totaltoken 数按租户/模型维度gateway_request_latency_seconds延迟 Histogramgateway_injection_denied_total/gateway_loop_guarded_total/gateway_governance_error_total护栏/循环/注入相关计数这些指标随gatewayjob 被 Prometheus scrape供 09 篇业务可观测派生 golden signal。限流 / 配额如何落地令牌桶token bucket一种按速率放行的限流算法的原理引分布式系列第 4 篇本篇只写网关如何做集中限流 租户隔离。双桶结构桶作用耗尽时行为全局总桶平台总预算硬上限触发限流单租户桶每租户月/日配额触发限流请求先扣租户桶、再校全局桶任一层耗尽即触发限流/熔断。桶为配置驱动、可热更新。关键设计建连前limit_check决策——不是发完请求再算账而是在请求出门前就判断这次该不该放行。否则限流就成了事后统计拦不住已经在路上的请求。预算熔断的上下游联动三层治理不是孤岛是成本防线的计量—限流—熔断三段信号处置衔接篇超预算触发熔断截断流量本篇成本突增但未超预算驱动告警09-LLM业务级可观测失控循环调用处置动作衔接05-自动操作回复与自愈闭环阈值设定思路按租户月预算线性摊到日/小时速率基线超基线倍数如 2×1h 基线即预警触硬上限则熔断并降级按 06 跨平面处置总表避免单租户耗尽全局桶。阈值取可观测突增而非贴脸上限留缓冲给人工干预——贴脸熔断意味着没有任何提前量发现问题时账单已经爆了。核心要点成本治理的本质是卡对位置 计量准唯一出口保证覆盖真实计数保证熔断不误判。三层治理计量 → 限流/配额 → 预算熔断计量准不准决定后两层有没有意义。阈值取可观测突增而非贴脸上限留缓冲给人工干预。计量—限流—熔断三段不是孤岛与 09 告警、05 自愈联动成成本防线。