任务提交成功得很快往往意味着客户端积累得很快。调度系统没有因此获得无限 worker也没有因此消除参数对象、返回对象和重试记录的内存开销。给大模型预处理提交几十万份切片之前应先回答允许同时存在多少份未完成工作Ray 2.59.0 发布说明提到 placement group 重试风暴和 worker lease 取消请求的修复。这是具体问题的修复证据不是“所有任务都有微秒级延迟”的保证。队列治理仍是应用责任。三个数不要混用提交窗口是客户端允许保留的未完成引用数执行并发由资源声明、可用节点和任务行为共同决定对象驻留量还包括依赖、共享引用和消费端滞后。窗口设成 100并不代表一定有 100 个进程也不代表只留下 100 个数据对象。Ray 的任务与 Actor 概念也不应被“worker 协程”统称。普通同步任务、异步 Actor 方法和长生命周期状态处理并发的方式不同。对带副作用的工作还得考虑任务重新执行是否重复写库。教学状态图窗口上限约束未完成任务数不代表 Ray 集群的实际并行度。用小账本验证提交器的约束下面不用 Ray刻意只演示有界窗口的状态约束。每轮完成最早的一项然后补到上限。所有编号恰好完成一次是这个模拟的性质不能据此推导分布式任务恰好执行一次。from collections import deque pending, done deque(), [] limit, next_id, total 3, 0, 10 peak 0 while next_id total or pending: while next_id total and len(pending) limit: pending.append(next_id) next_id 1 peak max(peak, len(pending)) done.append(pending.popleft()) assert sorted(done) list(range(total)) assert peak limit print(completed, len(done), peak_pending, peak)运行输出completed 10 peak_pending 3真实 Ray 提交器可以维护 ObjectRef 集合使用ray.wait等待部分完成再补交遇到异常要收集失败、释放引用并按预算重试。不能只在任务内部 sleep把客户端的无限提交问题留在外面。对重试也设预算每个请求都应有稳定业务 ID、截止时间和最大尝试次数。任务完成后提交结果时做幂等校验比相信网络没有重复消息更踏实。重试延迟需要抖动否则恢复的一批节点会同时收到同一批洪峰。CPU 模拟已经验证窗口和覆盖范围Ray 未安装运行未做集群压测。下一步测试应故意让一部分任务失败、让消费端变慢并同时记录在途数、对象存储占用和重试放大倍数。先保证系统能停下来再谈它能跑多快。