任務提交成功得很快往往意味著客戶端積累得很快。調(diào)度系統(tǒng)沒有因此獲得無限 worker也沒有因此消除參數(shù)對象、返回對象和重試記錄的內(nèi)存開銷。給大模型預處理提交幾十萬份切片之前應先回答允許同時存在多少份未完成工作Ray 2.59.0 發(fā)布說明提到 placement group 重試風暴和 worker lease 取消請求的修復。這是具體問題的修復證據(jù)不是“所有任務都有微秒級延遲”的保證。隊列治理仍是應用責任。三個數(shù)不要混用提交窗口是客戶端允許保留的未完成引用數(shù)執(zhí)行并發(fā)由資源聲明、可用節(jié)點和任務行為共同決定對象駐留量還包括依賴、共享引用和消費端滯后。窗口設(shè)成 100并不代表一定有 100 個進程也不代表只留下 100 個數(shù)據(jù)對象。Ray 的任務與 Actor 概念也不應被“worker 協(xié)程”統(tǒng)稱。普通同步任務、異步 Actor 方法和長生命周期狀態(tài)處理并發(fā)的方式不同。對帶副作用的工作還得考慮任務重新執(zhí)行是否重復寫庫。教學狀態(tài)圖窗口上限約束未完成任務數(shù)不代表 Ray 集群的實際并行度。用小賬本驗證提交器的約束下面不用 Ray刻意只演示有界窗口的狀態(tài)約束。每輪完成最早的一項然后補到上限。所有編號恰好完成一次是這個模擬的性質(zhì)不能據(jù)此推導分布式任務恰好執(zhí)行一次。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等待部分完成再補交遇到異常要收集失敗、釋放引用并按預算重試。不能只在任務內(nèi)部 sleep把客戶端的無限提交問題留在外面。對重試也設(shè)預算每個請求都應有穩(wěn)定業(yè)務 ID、截止時間和最大嘗試次數(shù)。任務完成后提交結(jié)果時做冪等校驗比相信網(wǎng)絡沒有重復消息更踏實。重試延遲需要抖動否則恢復的一批節(jié)點會同時收到同一批洪峰。CPU 模擬已經(jīng)驗證窗口和覆蓋范圍Ray 未安裝運行未做集群壓測。下一步測試應故意讓一部分任務失敗、讓消費端變慢并同時記錄在途數(shù)、對象存儲占用和重試放大倍數(shù)。先保證系統(tǒng)能停下來再談它能跑多快。