4 篇博文 含有标签「scheduling」

当一个团队的推理端点开始无法达到延迟目标时，他们做的第一件事通常是购买更多的 GPU。一个月后，他们会发现第二件事：p99 延迟几乎没变，而账单却翻了一倍。显卡利用率徘徊在 40%，而尾部延迟依然很难看。有人添加了自动扩缩容（autoscaler）。自动扩缩容频繁震荡。现在有了更多的显卡，更高的成本，以及来自同一批用户的同样抱怨。

错误在于将推理缓慢视为容量不足。事实几乎从未如此。你面临的是一个披着容量问题外衣的排队问题。LLM 端点的尾部延迟取决于大小迥异的请求如何随时间共享固定的计算池——这是典型的调度问题，而非资源配置问题。在你理解服务栈实际运行的排队规则（queue discipline）之前，你添加的每一块 GPU 都只是更昂贵的变慢方式。

每晚的微调任务在 UTC 时间 02:00 开始。它进入共享 GPU 池，占用它能找到的每一个槽位并持续持有。到 09:30，当工作日的首波推理流量到达时，自动扩缩器（autoscaler）试图声明已被连续占用七个半小时的容量。早晨的前 90 分钟，系统运行在约为基准 p99 延迟四倍的水平上。仪表盘报告了一个“喧闹的早晨尾部（noisy morning tail）”，推理团队将其归因于用户行为，因为实际的资源争用发生在一个推理团队并不拥有的任务队列中。

这是你在容量评审的成本归因幻灯片中无法捕捉到的 GPU 共享失败模式。共享被宣传为利用率的胜利——晚上训练，白天服务，填补低谷。实际交付的却是直到池按延迟类别（而非按团队或按时间）进行分区之前，你都无法摆脱的延迟长尾。

一个每日站会总结被安排在 UTC 时间 09:00。定时任务（Cron）准时触发。两秒钟后，一个工作节点容器组（Worker pod）启动。LLM 调用又耗费了四十秒的往返时间。模型在撰写总结时认为现在是去年的 2 月，因为那是其训练数据最后确信的时间点。工具层在 UTC 时间 09:00:42 根据挂钟时间（Wall clock）发送了 Slack 消息，模型从未提及具体日期，因为没人要求它这样做。消息进入了正确的频道，昨天的站会笔记被总结成了“今天的”，而且整整三周都没有人察觉。

这并不是任何单一组件的 bug。这是一种在四个不同的时钟之间、谁也没有写下来的契约，而这四个时钟都认为自己知道“现在”是什么时候。

十一个智能体在同一秒内启动。在第一个工具调用返回之前，就有三个阵亡了。那 27% 的失败率不是模型问题、提示词问题或工具问题。这是一个调度问题 —— 就像操作系统在五十个进程同时唤醒并争抢单个 CPU 时所解决的问题一样。区别在于，操作系统拥有四十年的智慧积累，而智能体运行时只有大约两年。

任何连接过超过几个并发 LLM 工作节点的人都见过类似的情况。你在 02:00 启动一个定时任务，三十个智能体同时启动，它们在 200 毫秒内同时请求同一个提供商，结果大多数都以 429、502 和连接重置告终。幸存者只能获得承诺的一半速率配额，因为提供商的公平共享逻辑已经开始对你的 API 密钥进行节流了。到 02:05 时，幸存的智能体运行结束，你的仪表盘显示的完成率足以让一个刚写出第一个生产者-消费者的计算机专业大一学生感到汗颜。你的值班人员会争论是该增加重试、增加队列，还是干脆减少运行数量。

这些方法本身都不是正确答案。正确答案是：一个智能体集群是一个小型分布式系统，需要按照分布式系统的方式进行设计。