你的延迟 SLO 取决于其他团队的 Prompt 大小

弥合差距的应用端模式​

修复方案是在内部以供应商限流的相同单位来衡量容量。目前有四种模式在生产环境中发挥作用，它们通常结合使用。

在调用触发前执行的按团队 token 分配。 将供应商组织级别的 TPM 转换为内部规划工具可以本地强制执行的按团队分配。摘要团队获得一个 TPM 预算，聊天团队获得一个 TPM 预算。总和（加上预留空间）等于供应商的上限。每个团队的内部限流会在供应商限流之前触发，超过 TPM 分配的团队会在自己的仪表盘中看到限流，而不是表现为别人的延迟峰值。这就是 Kubernetes ResourceQuota 在集群级别的工作方式，这种类比可以完美映射到 LLM 容量：你付费的单位就是你做预算的单位。

在应用程序和供应商之间建立内部 token 预算网关。 来自 Portkey、TrueFoundry 和类似厂商的生产级 AI 网关展示了行业中趋于一致的模式：一个以 (tenant, workload, model) 为键的令牌桶速率限制器，按每分钟 token 数而非每分钟请求数进行限流。网关估算每个请求的 token 成本 —— 输入 token 是确切知道的；输出 token 则通过 max_tokens 或历史平均值来估算 —— 并在转发给供应商之前决定是否准入。当网关的本地 TPM 分配耗尽时，它向应用程序返回 429 错误，并附带一个根据桶补充速率计算出的 Retry-After 响应头。应用程序针对自己的限流进行退避，而不是针对供应商，从而使供应商的 TPM 上限是从下方趋近而非直接撞上。

将“其他租户的 token 消耗”列为协变量的 SLO 模型。 大多数延迟 SLO 模型假设“喧闹邻居”（noisy-neighbor）风险受限于平台的隔离保证。但在共享的 LLM 组织密钥上，没有隔离保证。诚实的 SLO 模型会记录下这一点：聊天路径的 p99 是聊天路径 token 消耗、摘要路径 token 消耗以及共享该桶的所有其他工作负载的函数。错误预算中包含了一个跨租户流量的协变量项。仪表盘在显示聊天路径延迟的同时，也会显示组织级别的 TPM 利用率。告警会在组织 TPM 利用率超过 80% 时触发，而不是等到聊天延迟超过 SLO —— 因为延迟违约是滞后指标，而桶利用率是领先指标。

为每类工作负载设置独立的组织密钥。 当隔离性比聚合效率更重要时，结构化的修复方案是停止共享桶。为每个具有明显不同 prompt 大小特征的工作负载类别配置独立的供应商组织或工作区（workspace）。Anthropic 和 OpenAI 都支持组织内的工作区级速率限制；一些团队更进一步，为批处理和交互式工作负载运行完全独立的组织。代价是运维开销 —— 更多需要轮转的密钥，更多需要对账的账单关系 —— 以及失去了跨工作负载统计复用的效率。好处是聊天团队的 SLO 不再是摘要团队 prompt 大小的函数。这种收益是否值得这些开销，取决于各工作负载脉冲式爆发重合的频率。

运行六个月后的景象​

采用令牌网关（token-gateway）和按团队分配（per-team allocation）模式的团队通常会在第一个季度发现几件事。首先是网关对输出令牌（output tokens）的预估误差是导致 429 误报的主要原因。一个 max_tokens 被保守地设定为 4,000 但通常只返回 200 个令牌的请求，会被网关计为消耗了 4,000 个令牌预算。解决方法是跟踪每个端点的实际输出令牌分布，并使用历史 p95 值作为预估，而不是使用配置的 max_tokens 上限。这在不改变供应商层级的情况下，能显著提升有效吞吐量。

第二个发现是，令牌感知型熔断器比请求感知型熔断器更重要。如果一个工作负载的令牌消耗速率增长快于其请求速率——例如长上下文回归、由于新系统提示词堆积导致的提示词膨胀、不断增长的少样本（few-shot）示例集——它就是下一个“嘈杂邻居”（noisy neighbor）。熔断器应根据每个工作负载的令牌速率而非请求速率触发。在代码审查阶段就关注提示词大小仪表盘和延迟仪表盘的工程团队，能在生产环境之外拦截提示词膨胀导致的回归。

第三个是更安静的文化转变。团队间的容量规划对话开始将 TPM 作为通用货币。引入新工作负载类别的产品发布会根据组织的 TPM 余量（headroom）而非 RPM 余量进行评审。共享账单仍然是一个限制因素，但共享的节流阀（throttle）变成了束缚性限制，团队会针对它进行明确规划。过去在事故发生时才出现的跨团队指责，现在提前到了设计评审阶段。

认知重构​

架构层面的认知虽小，影响却很深远。供应商节流的单位就是你的应用程序必须规划的单位。如果供应商以每分钟令牌数（TPM）定义容量，而你以每分钟请求数（RPM）定义预算，那么你构建的 SLO 的波动将由共享账单的每一个其他团队决定。解决方法不是去协商一个更高的上限，而是用与外部上限强制执行时相同的单位来定义内部容量，并使该单位在团队边界上可见。

做对这一点的团队会将供应商的 TPM 限制视为一种共享资源，需要像对待 Kubernetes CPU 份额、S3 请求配额或任何其他多租户容量上限一样进行分配管理。令牌预算网关、按团队分配和跨团队协变量模型并不新奇——它们只是披着令牌外壳的成熟 SRE 模式。而做错的团队，其组织级仪表盘显示 RPM 尚有余量，而 TPM 桶却已悄悄耗尽，当有人在同一个 Key 上发布长上下文功能时，他们的聊天 SLO 就会在毫无预警的情况下崩溃。

聊天服务的 p99 从来不是在衡量聊天服务本身。它衡量的是最近哪个工作负载抽干了令牌桶。在令牌桶拥有明确的主人之前，SLO 也同样无主。