你的后端基础设施并非为流式响应而设计

每个基于并发的自动伸缩器都运行在一个关于并发含义的模型之上。默认模型假设处理大量并发请求的 Pod 正处于高负载状态，而处理少量请求的 Pod 则处于空闲状态。当并发请求可以作为 CPU 压力的代理指标时，这是一个合理的模型，因为每个请求都需要 CPU 来提供服务，并且只占用很短时间的资源。信号与底层约束高度相关。

流式处理（Streaming）打破了这种相关性。一个 Pod 可以持有 100 个并发连接，但 CPU 使用率仅为个位数，因为每个连接的工作主要是等待上游供应商的字节流，然后进行转发。基于并发的自动伸缩器读取这个数字，判定 Pod 过载，并部署更多副本。新副本启动后，接管了连接池中的份额，CPU 使用率同样保持在个位数。仪表盘现在显示整个集群的 CPU 运行率只有 5%，而自动伸缩器仍在继续扩容，因为它识别到的唯一信号表明并发量很高。

这里的成本框架是没人画进图表的部分。5% 利用率下的双倍副本数量，与 10% 利用率下的单个副本账单相同，但现在团队支付了两倍的闲置容量费用，且在用户感知的吞吐量没有变化的情况下，每个流的成本实际上翻了一番。财务团队批准的容量模型说的是“每秒请求数”，而现在的底层物理逻辑是“并发流乘以平均持有时间”，这是一个不同的单位，也会产生不同的账单。

修复方法需要让自动伸缩信号与实际约束相匹配。对于流式网关（Streaming Gateway），约束通常是打开的连接数——不是 CPU，也不是内存，而是 Pod 在其连接表或文件描述符数量饱和之前可以持有的正在进行的流的数量。自动伸缩器应该直接根据该数值进行缩放，利用率定义为连接上限的比例，而不是每个 CPU 的并发量。队列深度指标或待处理请求时间指标是领先指标；CPU 则是一个滞后指标，流式处理已经有效地将其与负载解耦。

按持有时间计费，而非按请求计费​

确立服务成本基础的容量规划对话是围绕每秒请求数展开的。成本模型认为：在峰值时我们每秒处理 N 个请求，每个请求的基础设施成本为 X 美分，因此我们的月度账单是可预测的。当每个请求都是计算资源的瞬时消费者时，这个模型是对的。但现在它错了，因为流式请求消耗的资源不是 CPU 秒，而是连接秒（Connection-seconds）——连接秒的价格取决于连接持有的时间，而不是单位时间内到达的连接数量。

一个每分钟到达一次并持有连接 50 秒的请求，比一个每分钟到达 60 次并持有 0.5 秒的请求消耗更多的基础设施资源，尽管前者的请求率只有后者的六十分之一。传统的成本模型会对后者定更高价。而实际的账单会对前者定更高价。在开启流式处理后没有重新推导其成本模型的团队，其运营所基于的定价假设与平均生成长度增长的倍数一样错误。

随之而来的架构认知是：流式处理使得模型的行为——它的 Token 速率、平均响应长度、推理深度——成为基础设施账单的直接输入。决定启用一个推理时间更长、能力更强的模型的产研决策，同时也是一个基础设施成本决策，而这两个决策是由不同团队做出的。当 AI 团队选择模型而平台团队支付持有时间费用时，成本分摊缺口就出现了，而且两者之间的联系在任何一个团队的仪表盘上都不可见。一个根据预期持有时间（源自实际流量，并在模型更改时刷新）为每个请求定价的容量模型，才能弥补这一缺口。否则，平台团队将永远对上游模型选择带来的基础设施后果视而不见。

从一个 SLO 变成两个​

该服务之前的 SLO 只有一个数字：P99 请求延迟低于 2 秒。在响应简短且原子化时，它抓住了核心关注点。对于流式工作负载，它没有任何实际意义，因为 SLO 设定的 2 秒是你在看到任何输出之前等待的时间——这与请求完成所需的总时间是两回事。

弥补这一差距的模式是两个 SLO，共同负责但分别跟踪。一个是首个 Token 时间（Time-to-first-token）SLO，定义了用户感知的延迟：响应开始流出的速度有多快。这是映射到“系统是否有响应”的指标。另一个是流完成（Stream-completion）SLO，定义了正文发射概况：完整响应渲染了多长时间，以及是否在没有断开连接的情况下完成。这是映射到“系统是否可靠完成”的指标。

这两个 SLO 测量的是正交的故障模式。首个 Token 时间的回退意味着请求路径变慢了——可能是网关、队列或供应商预热问题。流完成的回退意味着连接层变得不那么可靠了——可能是负载均衡器的超时设置过紧、网络路径存在间歇性丢包，或者是供应商的后端在生成中途断开了流。单一的传统 SLO 会用一个数字掩盖这两者，导致两个团队都无法根据其采取行动。拆分后，网关团队负责第一个，连接层团队负责第二个，并允许值班轮换将告警发送给真正能修复故障的人。

究竟什么是流式传输 (Streaming)​

在内部，流式传输 (Streaming) 被宣传为一种用户体验 (UX) 的提升，并作为一项配置更改发布。但值班人员最终会发现一个事实：流式传输是一种完全不同的请求形态，必须告知技术栈的其他部分。负载均衡器的空闲超时、链路追踪流水线的 Span 约定、自动扩缩器的利用率信号、成本模型的计费单元，以及 SLO 中对延迟的定义 —— 所有这些都包含了对先前请求形态的假设，而且默认情况下都无法直接沿用。

如果团队将流式传输作为一项完成的 UX 功能发布，却没预算好用于更新这五个维度的基础架构工作，这并不代表他们精简了路线图，而是将一类事故推迟到了下个季度。相反，如果团队将流式传输视为一个除了 UX 变更外，还包含五个基础架构交付物的项目，那么他们最终得到的流式网关，其仪表盘依然清晰可读，账单依然可预测，值班人员也能在轮值期间安稳入睡。延迟交付的代价体现在三个方面：仪表盘的分位数不再代表其原本的含义、自动扩缩器在默默地过度分配资源，以及每个流的基础架构单位成本从未被计入发布计划中。

教训隐藏在这些故障模式之下。响应离开系统的协议层级变更，是与 API 网关下游所有环节的一次契约变更，而这个契约必须明确地重新协商。流式响应在传输线路上并非免费。总有人要为持有时间付费，而那些没有预算好由谁付费的团队，最终仍会收到账单，只是这笔账单会以难以理解的形式，散落在各个与发布毫无关联的基础架构层面上。