AI云公司CoreWeave：推理延迟不触发告警就悄悄劣化的三种结构性原因

生产推理服务最难诊断的问题不是宕机，而是'不宕机但一直在变慢'。CoreWeave博客作者Tara Madhyastha和Nisha Nadkarni在2026年6月发表的博客中用一个假设场景说明这种困境：一个医疗问答服务连续运行三周，没有失败告警、没有错误尖峰、仪表盘全绿，但用户投诉陆续到来——回答变慢了，中途有卡顿。拉取指标后发现p99首token延迟从180毫秒升至240毫秒，峰值时段可用性从99.9%滑到99.1%，两者都没有越过告警阈值。用户已经体验了将近两周的质量劣化，而系统从未被判定为'故障'。

作者将这种静默漂移归因于三类结构性原因，它们随负载增长相互叠加。第一是基础设施层的资源争用：通用云为灵活异构负载设计，而推理是连续、延迟敏感、对资源竞争高度敏感的。小规模时请求很少争抢资源，到生产规模GPU争用变成常态，调度开销随请求量增长——在每秒50个请求时可忽略的延迟，到每秒5000个时变得显著。共享网络路径上的邻居噪声最先出现在尾部延迟，p50看起来正常，p99已经不同。

第二是模型服务配置随负载漂移。作者用一个类比解释批处理问题：静态批处理像旅游大巴，等坐满才发车，快请求被迫等最慢的那个；连续批处理像地铁，每站都有人上下，GPU保持满载。但地铁有自己的问题：一个长输入提示（prefill）会占住站台，让已经在途的所有请求（decode）等待，产生token间延迟抖动。KV缓存压力是另一条路径：上下文窗口变长、会话增多时，引擎开始驱逐或抢占在途请求来腾空间，重算开销不体现在错误率里，但体现在p99里。

第三是流量模式与扩缩容的错配。自动扩缩容系统响应已观测到的需求，有固有滞后：新pod大约90秒上线，新节点需要数分钟。突发流量到来时，扩缩容跟不上，请求排队、延迟攀升，持续足够久就开始超时。作者还指出一个更隐蔽的版本：请求形状不均等。如果基础设施按平均复杂度配置，当最重的请求集中出现时，容量饱和速度会快于扩缩容策略的预期。

针对这三类原因，文章给出三个诊断信号：p99持续攀升而p50稳定，指向基础设施变异或配置漂移而非负载问题；TTFT在负载稳定时上升，指向GPU争用或批处理配置；goodput（满足延迟SLA的请求数）与throughput（处理的总请求数）出现差距，说明系统'在运转'但部分用户实际经历了失败——一个95%吞吐量的系统可能仍在让五分之一用户超时，而监控从未记录这次失败。

作者的核心结论是：这些团队把可靠性当作架构属性而非监控问题来设计，选择显式GPU分配、流量感知扩缩容、基于实际负载验证的SLA和可预测网络。需要指出的是，CoreWeave本身销售专用推理基础设施，这一结论与它的商业定位一致；文中所有数字均为假设示例，非实测生产数据。经过良好调度的通用云环境配合拓扑感知调度和预分配策略，也能在相当程度上缓解所述问题。