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