在解码中途缩减至零的自动伸缩器：当推理被视作无状态网络流量时

在这类事件发生后，一种常见的反射性反应是“我们要加个 PDB”。PDB 告知 eviction API 和节点排空（node drain）控制器，在它们发起主动干扰（voluntary disruptions）时要遵循最小可用性。对于滚动升级、节点维护和集群自动扩缩容（cluster autoscaler）回收，它是一个真实且有用的护栏。

但 PDB 无法保护你免受 HPA 或 KEDA 扩缩容决策的影响。在 PDB 的定义中，缩容（Scale-down）并不是一种逐出（eviction）——它是 Deployment 控制器确认副本集需要更少的副本，随后 kubelet 相应地终止 Pod。PodDisruptionBudget 协议对此保持沉默。KEDA 仓库中有一个长期讨论（#2899）正是关于这种意外：缩容决策会在繁忙的 Pod 仍在工作中途时将其终止，而 PDB 无法阻止这一点。

这里已经有所进展。KEDA 一直在开发动态调度和感知工作者的缩容（worker-aware scale-down）——其核心理念是缩容程序应知道哪些 Pod 正在处理工作，并优先终止空闲的 Pod。截至 2026 年，各缩容程序对此的支持仍参差不齐，且取决于工作负载是否暴露了真实的“我正忙碌”信号。在这一信号普及之前，你不能指望自动扩缩容程序会挑选正确的 Pod 来销毁；你必须让每个 Pod 都能安全被销毁，或者确保销毁行为根本不会发生。

更深层的教训是，“可能终止 Pod 的因素”其范围远大于遵循 PDB 的子集。竞价实例（Spot）回收、节点池合并、OOM 杀掉进程、引擎内部长时间 GC 停顿期间的存活探针（liveness-probe）失败，以及你自己的自动扩缩容程序，所有这些最终都指向同一个结果——工作消失了——而其中只有一部分是通过你控制的机制路由的。正确的心理模型应该是“任何 Pod 随时都可能挂掉”，就像对待“牛群（cattle）”基础设施一样，只是这些牛需要 28 分钟才能吃完它们的饭。

499 是你无法承受失去的“金丝雀”​

在事后分析中，最令人沮丧的细节不是 Pod 被回收了。而是这次失败几乎是不可见的。客户的 SDK 收到一个已关闭的连接，但没有显示有用的错误。应用程序日志中没有异常，因为应用程序进程是被干净地杀掉的。唯一持久的记录是网关访问日志中的一条 499 记录，而且没有人为此报警。

499 是一个非标准代码（HAProxy 和其他一些代理对相同情况使用不同的代码，Apigee 和其他 API 网关也有自己的变体），但在任何使用 NGINX、Envoy 或类似反向代理作为流式前端的推理架构中，它是流式响应在完成前被中断的关键信号。它综合了多种原因——真实的客户端断开连接、网络重置、中间代理超时以及 Pod 终止——但其中每一项都是流式推理运维人员应该关心的。

以下几种实践可以将 499 从埋没的日志行转变为有用的信号：

• 分别针对长上下文（long-context）端点和短请求端点对 499 响应的速率（rate）进行告警。客户端断开连接的基础速率是正常的；但与缩容事件相关的突然集群范围峰值则是不正常的。
• 在网关访问日志中为响应打上标签，包括上游 Pod 身份和请求生命周期阶段（排队中、预填充 prefilling、解码中 decoding）。这将单一的状态码转换为一个结构化事件，你可以将其与调度器的活动进行关联分析。
• 当推理引擎自身在处理中的解码阶段观察到 SIGTERM 时，让引擎发出一条独特的日志。将“引擎观察到 SIGTERM”加上“网关看到 499”再加上“调度器看到缩容”结合起来，就是针对这种特定失败模式的高置信度指纹。每个单一信号都是模糊的；而结合起来则是确凿的。

团队只能通过支持工单才了解到这次事件，这部分故事应该会让平台工程师感到汗颜。信号明明存在。但管道却没有将其呈现出来。

从工作负载形态重新推导成本模型​

成本驱动的缩容策略之所以如此激进，首要原因是闲置 GPU 的单位经济效益极其残酷。一个利用率为零的 H100 仍在按按需费率计费。收回资源的压力是现实且理性的。对于具有突发、短请求流量的端点，缩容至零（Scale-to-zero）确实非常有用——Modal 和 Databricks 的运营报告记录了针对正确工作负载形态可降低百分之几百的成本。

错误之处在于，将相同的策略统一应用于形态不同的端点。一个有用的重构是按工作负载类别（workload class）而不是按模型来划分推理集群。一个处理亚秒级中位延迟的短上下文聊天流量池，可以采取激进的缩容至零策略和 60 秒的排空窗口，客户永远不会察觉。而一个处理长上下文推理或文档分析的池则不能这样做，假装可以这样做只会将成本问题转嫁到你的可靠性预算上。

一旦你划分了集群，你还可以向成本团队做出更好的承诺。长任务运行在带有保守缩容策略的预留容量（reserved capacity）上。短任务运行在竞价实例（spot）和缩容至零的策略上，并将旋钮调到最大。批处理任务运行在可设置检查点（checkpointable）的工作池上，使用抢占式实例（preemptible instances），并接受尽可能便宜的计算资源，因为它可以在被逐出时存活。由于每个资源池都获得了与其真实形态相匹配的策略，而不是采用一种针对中位请求优化但在尾部请求上失效的全局策略，总账单反而会下降。

核心结论是：感知工作负载，而非感知自动伸缩器​

自动伸缩器本身并没有失效。它只是在正确执行一项策略，而该策略假设推理行为与无状态 HTTP 类似。失败的原因出在所有配置文件之上：这是一个关于系统类型的分类错误。

流式推理、持续批处理（continuous batching）、KV 缓存、长上下文解码，以及响应时间长达数分钟的推理模型，共同将推理 Pod 变成了一个恰好使用 HTTP 协议的有状态长作业工作节点。它更像是一个 Spark 执行器或视频转码器，而不是无状态的 REST 处理器。我们针对前者所使用的自动伸缩、驱逐、排空（draining）、可观测性和成本归因机制，需要结合这种特性重新应用——而这种不匹配最早体现在一个无人报警的 499 错误上，此时距离任务消失已经过去了一个小时。

修复方案的执行要点很简洁。审计你的推理缩容谓词（scale-down predicate），使其基于正在处理的序列（in-flight sequences）而非 RPS 进行判断。设置与解码时间尾部延迟相匹配的宽限期（grace periods），或者让解码过程可恢复。针对每个端点类别的 499 错误率设置报警。按工作负载形态而非模型来划分你的集群。不要让成本仪表盘上平稳的绿线欺骗你，让你以为一个此时正深入处理客户最昂贵请求、已解码三千个 token 的 Pod 处于闲置状态。