大規(guī)模強(qiáng)化學(xué)習(xí)訓(xùn)練階段模型不是只跑訓(xùn)練迭代還要同時(shí)做大量 Rollout 生成。每個(gè)訓(xùn)練 step 都可能觸發(fā)成百上千條推理請(qǐng)求這些請(qǐng)求混合了短回復(fù)、長(zhǎng)生成、多輪對(duì)話和獎(jiǎng)勵(lì)模型打分調(diào)度起來和傳統(tǒng)在線推理服務(wù)完全不是一回事。Prefix Locality 是這幾年 KV Cache 優(yōu)化里一個(gè)很有效的思路但在混合 RL Rollout 場(chǎng)景下只靠前綴復(fù)用并不能解決所有問題。這篇文章我們不聊概念直接拆解“Scheduling Mixed RL Rollouts Beyond Prefix Locality”背后的調(diào)度問題講清楚為什么前綴局部性不夠用、混合 Rollout 到底混合了什么、調(diào)度器應(yīng)該怎么重新設(shè)計(jì)以及落地時(shí)該看哪些指標(biāo)。如果你正在做 RL 訓(xùn)練框架、推理引擎選型或者要給大模型訓(xùn)練集群設(shè)計(jì)調(diào)度模塊這篇文章可以直接收藏。全文會(huì)覆蓋核心機(jī)制拆解、調(diào)度器設(shè)計(jì)路徑、配置示例、評(píng)測(cè)方法和常見坑位避免你在實(shí)際搭建時(shí)走彎路。1. 核心概念速覽能力項(xiàng)說明主題類型大規(guī)模 RL 訓(xùn)練中的 Rollout 推理調(diào)度策略設(shè)計(jì)核心問題打破 Prefix Locality 的單一優(yōu)化視角處理混合請(qǐng)求、動(dòng)態(tài)前綴和訓(xùn)練-推理資源競(jìng)爭(zhēng)關(guān)鍵技術(shù)動(dòng)態(tài)前綴索引、優(yōu)先級(jí)調(diào)度、兩階段資源預(yù)算、冷啟動(dòng)調(diào)度策略、訓(xùn)練感知調(diào)度適用場(chǎng)景LLM RL 訓(xùn)練管道、分布式推理引擎、在線 Rollout 服務(wù)、多任務(wù)混合推理隊(duì)列主要收益提升樣本吞吐、降低訓(xùn)練空轉(zhuǎn)、提高 KV Cache 復(fù)用率、平滑訓(xùn)練早期冷啟動(dòng)波動(dòng)不適用場(chǎng)景單模型單請(qǐng)求的簡(jiǎn)單推理、無 RL 訓(xùn)練的純?cè)诰€對(duì)話服務(wù)落地難度中高涉及調(diào)度器、緩存索引、訓(xùn)練器多模塊協(xié)同先回到最基礎(chǔ)的問題Prefix Locality 是什么它利用了“多個(gè)請(qǐng)求共享同一段前綴”的特征在推理時(shí)只計(jì)算一次共享前綴的 KV Cache后續(xù)請(qǐng)求直接復(fù)用。這在共享系統(tǒng)提示詞、Few-shot 示例、多輪對(duì)話歷史等場(chǎng)景下非常有效。vLLM 的 prefix caching、SGLang 的 RadixAttention 都是這個(gè)思路的代表實(shí)現(xiàn)。但 RL Rollout 和傳統(tǒng)在線推理有一個(gè)本質(zhì)差別請(qǐng)求分布不是靜態(tài)的。策略網(wǎng)絡(luò)每輪都在更新生成結(jié)果越來越偏離初始前綴分布同時(shí) Rollout 請(qǐng)求還混著獎(jiǎng)勵(lì)模型打分、短回答、長(zhǎng)生成等不同類型。單純按前綴組織調(diào)度容易出現(xiàn)前綴樹碎片化、緩存命中率忽高忽低、訓(xùn)練器餓死等問題。下面我們把 Prefix Locality 的適用邊界和失效場(chǎng)景拆開來看。2. 為什么 Prefix Locality 在 RL Rollout 場(chǎng)景中不夠用2.1 在線推理與 RL Rollout 的差異在線推理服務(wù)里請(qǐng)求來源是用戶前綴結(jié)構(gòu)相對(duì)穩(wěn)定。比如同一產(chǎn)品的所有用戶都共享系統(tǒng)提示詞或者同一個(gè)會(huì)話的后續(xù)輪次復(fù)用之前的歷史。這種情況下前綴復(fù)用收益穩(wěn)定且可預(yù)測(cè)調(diào)度器可以放心地把緩存命中率當(dāng)作核心優(yōu)化項(xiàng)。RL Rollout 的場(chǎng)景完全不同第一產(chǎn)生請(qǐng)求的主體是訓(xùn)練器。每個(gè)訓(xùn)練 step 之后策略網(wǎng)絡(luò)的參數(shù)變了導(dǎo)致后續(xù)請(qǐng)求的內(nèi)容分布發(fā)生變化。雖然 prompt 本身可能來自同一個(gè)任務(wù)族但策略更新后生成的響應(yīng)、采樣的動(dòng)作、獎(jiǎng)勵(lì)模型打分的對(duì)象都會(huì)漂移。第二請(qǐng)求類型是混合的。同一個(gè)調(diào)度周期內(nèi)可能同時(shí)存在需要生成 512 個(gè) token 的長(zhǎng)回答只需要輸出“0/1”或一個(gè)分?jǐn)?shù)的獎(jiǎng)勵(lì)查詢需要多輪交互的狀態(tài)查詢從回放緩沖區(qū)里采樣的舊策略數(shù)據(jù)重放。這些請(qǐng)求對(duì)前綴的敏感程度、對(duì)延遲的要求、對(duì)資源的消耗完全不同。如果一個(gè)調(diào)度器只盯前綴復(fù)用很容易把資源全部喂給了長(zhǎng)序列復(fù)用請(qǐng)求導(dǎo)致短請(qǐng)求和關(guān)鍵路徑上的訓(xùn)練請(qǐng)求餓死。第三訓(xùn)練與推理共享顯存和算力。RL 訓(xùn)練環(huán)節(jié)GPU 既要跑訓(xùn)練的前向反向又要跑 Rollout 的推理生成還要跑獎(jiǎng)勵(lì)模型的打分。調(diào)度器如果不感知訓(xùn)練器的當(dāng)前狀態(tài)就會(huì)出現(xiàn)推理請(qǐng)求把算力占滿、訓(xùn)練 step 遲遲等不到 Rollout 數(shù)據(jù)的情況。2.2 Prefix Locality 失效的具體場(chǎng)景場(chǎng)景一請(qǐng)求前綴高度動(dòng)態(tài)。當(dāng)任務(wù)本身沒有穩(wěn)定共享前綴時(shí)比如每個(gè) prompt 都是獨(dú)立采樣的數(shù)學(xué)題、代碼題前綴復(fù)用率天然很低。此時(shí) Prefix Locality 的收益很小繼續(xù)按前綴聚合請(qǐng)求反而增加調(diào)度器的組織成本。場(chǎng)景二前綴樹碎片化。RL 訓(xùn)練里同一個(gè)任務(wù)族往往基于一個(gè)基礎(chǔ) prompt 做少量擾動(dòng)。這些 prompt 之間共享很長(zhǎng)一段前綴但結(jié)尾略有差異。如果調(diào)度器把每條請(qǐng)求都當(dāng)作獨(dú)立前綴插入Radix Tree 會(huì)越來越碎索引本身占用內(nèi)存緩存命中率卻沒有提升。需要定期合并、剪枝和過期清理。場(chǎng)景三訓(xùn)練冷啟動(dòng)階段。訓(xùn)練初期策略網(wǎng)絡(luò)接近隨機(jī)初始化生成的輸出五花八門前綴復(fù)用率極低。此時(shí)如果調(diào)度器執(zhí)著于“找到可復(fù)用的前綴塊”反而會(huì)延遲請(qǐng)求執(zhí)行。材料里提到的“rl 冷啟動(dòng)”就是這個(gè)問題冷啟動(dòng)時(shí)模型輸出熵高、分布不穩(wěn)定調(diào)度策略應(yīng)該偏重快速收集多樣樣本而不是追求緩存復(fù)用等訓(xùn)練中后期策略收斂、輸出分布穩(wěn)定后再逐步提高前綴復(fù)用權(quán)重。場(chǎng)景四延遲敏感的訓(xùn)練關(guān)鍵路徑。RL 訓(xùn)練中Rollout 數(shù)據(jù)是訓(xùn)練 step 的“原料”。如果調(diào)度器把所有請(qǐng)求都按最大吞吐模式排布某個(gè)關(guān)鍵 batch 的 Rollout 結(jié)果遲遲不返回訓(xùn)練器只能空轉(zhuǎn)。調(diào)度器需要區(qū)分“關(guān)鍵路徑請(qǐng)求”和“后臺(tái)請(qǐng)求”前者優(yōu)先后者可以等待。所以超越 Prefix Locality 的核心不是拋棄前綴復(fù)用而是把它從“唯一目標(biāo)”降級(jí)為“一個(gè)加權(quán)因素”同時(shí)引入訓(xùn)練感知、多樣性保障和混合請(qǐng)求優(yōu)先級(jí)。3. Mixed RL Rollouts 到底混合了什么設(shè)計(jì)調(diào)度策略之前先把“混合”這個(gè)詞拆清楚?；旌?RL Rollout 至少在三個(gè)維度上混合。3.1 任務(wù)類型混合請(qǐng)求類型輸出長(zhǎng)度計(jì)算特征典型用途生成式 Rollout中到長(zhǎng)128~1024 token高計(jì)算量KV Cache 增長(zhǎng)快策略采樣、軌跡生成判別式/獎(jiǎng)勵(lì)查詢極短1~10 token低計(jì)算量延遲敏感獎(jiǎng)勵(lì)模型打分、價(jià)值估計(jì)狀態(tài)/動(dòng)作查詢短到中中等計(jì)算量多輪決策、環(huán)境交互回放數(shù)據(jù)重放任意無在線生成只做訓(xùn)練輸入舊策略樣本訓(xùn)練不同任務(wù)類型的資源消耗差異極大。一個(gè)生成式請(qǐng)求的 token 消耗可能是獎(jiǎng)勵(lì)查詢的百倍。調(diào)度器必須按類型拆分隊(duì)列否則一個(gè)長(zhǎng)生成請(qǐng)求會(huì)阻塞后面大量短請(qǐng)求。3.2 數(shù)據(jù)分布混合RL 訓(xùn)練過程中Rollout 數(shù)據(jù)來自不同階段當(dāng)前策略采樣舊策略的 replay buffer混有探索噪聲的樣本來自不同任務(wù)群體的數(shù)據(jù)。這些數(shù)據(jù)的前綴分布不同冗余程度也不同。調(diào)度器如果只按請(qǐng)求到達(dá)順序處理可能出現(xiàn)某個(gè)任務(wù)族的樣本嚴(yán)重過采樣另一個(gè)任務(wù)族長(zhǎng)期饑餓導(dǎo)致訓(xùn)練數(shù)據(jù)分布偏移。3.3 資源需求混合訓(xùn)練機(jī)器上GPU 資源不是全部分給推理的。訓(xùn)練 step 和 Rollout 生成存在時(shí)間上的交錯(cuò)訓(xùn)練前向/反向階段計(jì)算資源被訓(xùn)練占用Rollout 階段訓(xùn)練器等待數(shù)據(jù)資源釋放給推理。調(diào)度器需要做資源預(yù)算控制明確“當(dāng)前時(shí)間片里推理最多占多少顯存和算力”。否則訓(xùn)練和推理會(huì)出現(xiàn)互相爭(zhēng)搶吞吐反而低于串行執(zhí)行。3.4 混合的意義“Mixed”是問題同時(shí)也是優(yōu)化機(jī)會(huì)。不同類型的請(qǐng)求可以互相填補(bǔ)調(diào)度空隙。例如短請(qǐng)求可以插在長(zhǎng)請(qǐng)求的 Prefill 階段中間執(zhí)行緩存復(fù)用率高的請(qǐng)求可以優(yōu)先填充等待窗口。調(diào)度器的核心設(shè)計(jì)目標(biāo)就是在這些混合請(qǐng)求之間找到一組調(diào)度順序和資源分配策略使得訓(xùn)練樣本吞吐最大化、訓(xùn)練空轉(zhuǎn)時(shí)間最小化。4. 調(diào)度器核心設(shè)計(jì)思路超越 Prefix Locality4.1 設(shè)計(jì)目標(biāo)調(diào)度器不再追求單一指標(biāo)例如緩存命中率而是維護(hù)一個(gè)綜合目標(biāo)調(diào)度收益 前綴復(fù)用收益 訓(xùn)練關(guān)鍵路徑緊迫度 數(shù)據(jù)多樣性貢獻(xiàn) - 執(zhí)行維護(hù)成本。每一項(xiàng)都可以配置權(quán)重權(quán)重隨訓(xùn)練階段動(dòng)態(tài)調(diào)整。4.2 動(dòng)態(tài)前綴索引與老化機(jī)制Prefix Locality 仍然是重要工具但需要做三件事第一前綴索引支持動(dòng)態(tài)過期。RL 訓(xùn)練中策略更新后舊策略生成的前綴不再有復(fù)用價(jià)值應(yīng)該從索引中淘汰?？梢杂涗浢總€(gè)前綴塊的“最近命中時(shí)間”和“策略版本號(hào)”當(dāng)策略版本落后超過閾值時(shí)直接標(biāo)記失效。第二前綴合并與剪枝。對(duì)于差異極小的 prompt可以對(duì)前綴樹做自動(dòng)合并減少碎片化。相似度計(jì)算可以用公共前綴長(zhǎng)度、token 編輯距離等策略。第三分階段調(diào)整復(fù)用權(quán)重。訓(xùn)練早期前綴復(fù)用率低調(diào)度器降低復(fù)用權(quán)重優(yōu)先保證請(qǐng)求快速執(zhí)行訓(xùn)練中后期策略收斂輸出分布穩(wěn)定逐步提高復(fù)用權(quán)重。4.3 混合請(qǐng)求分類與優(yōu)先級(jí)調(diào)度器把請(qǐng)求分為三類Critical Request當(dāng)前訓(xùn)練 step 依賴的 Rollout 請(qǐng)求必須盡快完成Reusable Request前綴命中率高、可以延遲執(zhí)行換取緩存復(fù)用的請(qǐng)求Background Request回放數(shù)據(jù)、評(píng)估數(shù)據(jù)、日志生成等后臺(tái)任務(wù)可以在資源空閑時(shí)執(zhí)行。調(diào)度優(yōu)先級(jí)按 Critical Reusable Background 處理同時(shí)配合時(shí)間片限制防止高優(yōu)請(qǐng)求無限占用資源。4.4 兩階段調(diào)度資源預(yù)算分配 執(zhí)行順序編排一個(gè)大致的實(shí)現(xiàn)思路是兩階段階段一預(yù)算分配。根據(jù)訓(xùn)練器當(dāng)前狀態(tài)是否在 waiting、下一個(gè) step 需要多少樣本決定當(dāng)前調(diào)度窗口內(nèi)推理最多消耗多少顯存和算力哪些任務(wù)配額多少。階段二執(zhí)行順序。在預(yù)算約束內(nèi)對(duì)就緒請(qǐng)求排隊(duì)按優(yōu)先級(jí)、前綴復(fù)用率、預(yù)計(jì)執(zhí)行時(shí)間進(jìn)行排序選擇當(dāng)前批次的最優(yōu)組合。這種兩階段解耦的好處是資源控制與緩存優(yōu)化互不影響訓(xùn)練器側(cè)只需要關(guān)心預(yù)算接口調(diào)度器內(nèi)部可以自由調(diào)整執(zhí)行策略。4.5 冷啟動(dòng)調(diào)度策略對(duì)應(yīng)“rl 冷啟動(dòng)”問題調(diào)度器需要在訓(xùn)練初期采用不同參數(shù)調(diào)度參數(shù)冷啟動(dòng)階段穩(wěn)定訓(xùn)練階段前綴復(fù)用權(quán)重低高批量請(qǐng)求大小小快速出結(jié)果大追求吞吐多樣性采樣權(quán)重高覆蓋任務(wù)分布中按需調(diào)整緩存過期時(shí)限短舊前綴盡快清理長(zhǎng)保留穩(wěn)定前綴關(guān)鍵路徑放松度高優(yōu)先喂數(shù)據(jù)給訓(xùn)練器中平衡吞吐冷啟動(dòng)階段的目標(biāo)是“快速產(chǎn)生多樣且有效的 Rollout 數(shù)據(jù)”讓訓(xùn)練器盡快收斂到一個(gè)分布更穩(wěn)定的策略上。等策略穩(wěn)定后再切換到高復(fù)用、高吞吐模式。5. 調(diào)度器核心模塊與實(shí)現(xiàn)路徑這里給出一個(gè)簡(jiǎn)化的調(diào)度器模塊劃分與實(shí)現(xiàn)思路。注意下面代碼是設(shè)計(jì)示例不是某個(gè)特定開源項(xiàng)目的完整實(shí)現(xiàn)落地時(shí)需要結(jié)合你的推理框架和訓(xùn)練框架接口調(diào)整。5.1 模塊劃分整體可以拆成五個(gè)核心模塊請(qǐng)求接收器接收訓(xùn)練器、回放緩沖區(qū)、評(píng)估任務(wù)發(fā)來的請(qǐng)求統(tǒng)一封裝為RLRequest。前綴索引器維護(hù)動(dòng)態(tài)前綴樹支持插入、命中、過期、剪枝。預(yù)算控制器從訓(xùn)練器獲取資源狀態(tài)計(jì)算調(diào)度窗口的 GPU 資源預(yù)算。優(yōu)先級(jí)隊(duì)列按分類和優(yōu)先級(jí)組織就緒請(qǐng)求。執(zhí)行器與推理引擎交互提交 batch收集結(jié)果。5.2 請(qǐng)求封裝與優(yōu)先級(jí)打分代碼示例# 請(qǐng)求封裝示例 import time from dataclasses import dataclass, field dataclass class RLRequest: req_id: str prompt_tokens: list task_type: str # generation / reward / state_query / replay max_tokens: int arrival_ts: float field(default_factorytime.time) is_critical: bool False # 當(dāng)前訓(xùn)練 step 是否依賴 policy_version: int 0 # 生成該請(qǐng)求的策略版本 prefix_hit_len: int 0 # 調(diào)度時(shí)動(dòng)態(tài)填充 python # 優(yōu)先級(jí)打分示例 def score_request(req: RLRequest, weights: dict) - float: prefix_score req.prefix_hit_len / max(len(req.prompt_tokens), 1) critical_score 1.0 if req.is_critical else 0.0 waiting_score min((time.time() - req.arrival_ts) / 60.0, 1.0) score ( weights[prefix] * prefix_score weights[critical] * critical_score weights[waiting] * waiting_score ) return score5.3 前綴索引示例實(shí)際前綴樹實(shí)現(xiàn)比較復(fù)雜這里給一個(gè)基于字典的簡(jiǎn)化版本便于理解核心邏輯# 簡(jiǎn)化前綴索引示例 class PrefixIndex: def __init__(self, expiry_version_threshold: int 3): self.trie {} self.expiry_threshold expiry_version_threshold def insert(self, token_ids: list, policy_version: int): node self.trie for tid in token_ids: if tid not in node: node[tid] {children: {}, version: policy_version, hits: 0} node node[tid][children] node[_end] {version: policy_version, hits: 0} def match(self, token_ids: list, current_version: int) - int: node self.trie hit_len 0 for tid in token_ids: if tid not in node: break node node[tid][children] if node.get(_end) is None: # 非完整前綴按需判斷是否記錄 hit_len 1 elif current_version - node[_end][version] self.expiry_threshold: node[_end][hits] 1 hit_len 1 else: break return hit_len生產(chǎn)環(huán)境中建議使用 Radix Tree 或類似 SGLang RadixAttention 的 Prefix Cache并加上并發(fā)鎖和異步清理策略。5.4 調(diào)度主循環(huán)示例# 調(diào)度主循環(huán)偽代碼 def scheduling_loop(ready_queue, prefix_index, budget_controller, executor): while True: requests ready_queue.get_ready_batch(max_batchbudget_controller.current_batch_size()) for req in requests: req.prefix_hit_len prefix_index.match(req.prompt_tokens, req.policy_version) requests.sort(keylambda r: score_request(r, current_weights()), reverseTrue) selected budget_controller.filter_by_resource_budget(requests) if selected: executor.submit(selected) for req in selected: prefix_index.insert(req.prompt_tokens, req.policy_version) budget_controller.release_waiting_resources() time.sleep(0.01)核心要點(diǎn)是排序前先做前綴匹配排序混合多因子提交前再做資源預(yù)算過濾。這樣可以在不犧牲資源控制的前提下吸收 Prefix Locality 的部分收益。6. 接口與配置設(shè)計(jì)調(diào)度器通常通過 gRPC 或 HTTP 與訓(xùn)練器交互。下面給出一個(gè)通用的配置和請(qǐng)求示例落地時(shí)按項(xiàng)目調(diào)整。6.1 調(diào)度器配置示例# scheduler_config.yaml 示例 scheduler: max_batch_size: 32 scheduling_interval_ms: 10 queue_capacity: 4096 weights: prefix: 0.4 critical: 0.4 waiting: 0.2 policy: cold_start_steps: 200 # 訓(xùn)練前 200 步視為冷啟動(dòng) cold_start_prefix_weight: 0.1 # 冷啟動(dòng)時(shí)降低前綴復(fù)用權(quán)重 stable_prefix_weight: 0.4 # 穩(wěn)定階段恢復(fù) prefix_ttl_steps: 5 # 前綴塊策略版本過期閾值 budget: max_gpu_memory_mb: 40960 training_reserved_mb: 20480 # 為訓(xùn)練保留的顯存 max_inference_mb: 20480 # 推理可用顯存上限 executor: engine: vllm # 也可以是 sglang / tensorrt-llm timeout_seconds: 1206.2 訓(xùn)練器提交 Rollout 請(qǐng)求示例import requests payload { task_type: generation, prompt: Solve the following math problem step by step., max_tokens: 512, is_critical: True, policy_version: 12, } resp requests.post(http://127.0.0.1:8900/submit_rollout, jsonpayload, timeout10) print(resp.json())6.3 調(diào)度器返回結(jié)果示例{ req_id: rl_20250101_00001, status: accepted, estimated_batch: batch_20250101_0003, queue_position: 2, prefix_match_length: 128 }實(shí)際生產(chǎn)環(huán)境建議用 gRPC 流式接口支持長(zhǎng)連接和批量結(jié)果返回避免 HTTP 短連接在大規(guī)模 RL 訓(xùn)練下成為瓶頸。7. 評(píng)測(cè)方法與性能觀察超越 Prefix Locality 的效果不能只看緩存命中率需要一套針對(duì) RL 訓(xùn)練場(chǎng)景的評(píng)測(cè)指標(biāo)。7.1 核心指標(biāo)指標(biāo)含義目標(biāo)Sample Throughput每秒產(chǎn)出有效 Rollout 樣本數(shù)越高越好GPU Idle Ratio訓(xùn)練器等待 Rollout 數(shù)據(jù)的時(shí)間占比越低越好Prefix Hit RatioKV Cache 前綴命中比例輔助指標(biāo)不是唯一目標(biāo)Training Step Time單次訓(xùn)練 step 總耗時(shí)越低越好Diversity Score生成樣本的分布覆蓋度冷啟動(dòng)階段重點(diǎn)觀察Cache Memory Overhead前綴索引和緩存占用額外內(nèi)存控制合理范圍7.2 評(píng)測(cè)方法推薦做 A/B 對(duì)比Baseline 1純 Prefix Locality 調(diào)度按前綴命中優(yōu)先Baseline 2純 FIFO 調(diào)度不做特殊優(yōu)化Test混合調(diào)度前綴復(fù)用 關(guān)鍵路徑 冷啟動(dòng)策略。每個(gè)方案固定相同的訓(xùn)練數(shù)據(jù)、模型和訓(xùn)練超參數(shù)跑相同的訓(xùn)練步數(shù)對(duì)比總耗時(shí)、樣本吞吐、GPU 空閑時(shí)間和最終模型效果。評(píng)測(cè)腳本示例# 評(píng)測(cè)調(diào)度策略對(duì)比示例 import time import statistics def run_training_steps(scheduler_type, steps100): start time.time() sample_throughputs [] for step in range(steps): t0 time.time() rollout_data scheduler_collect(scheduler_type, step) train_one_step(rollout_data) cost time.time() - t0 sample_throughputs.append(len(rollout_data) / cost) total_time time.time() - start return { total_time: total_time, avg_throughput: statistics.mean(sample_throughputs), gpu_idle_ratio: compute_gpu_idle_ratio(), prefix_hit_ratio: compute_prefix_hit_ratio(), }7.3 性能觀察重點(diǎn)實(shí)際運(yùn)行時(shí)要重點(diǎn)觀察三個(gè)位置第一訓(xùn)練器側(cè)等待日志。如果訓(xùn)練 step 的日志里頻繁出現(xiàn)waiting for rollout data說明調(diào)度器沒有優(yōu)先保障關(guān)鍵路徑請(qǐng)求。第二GPU 顯存分配趨勢(shì)。訓(xùn)練和推理的顯存分配是否在交替攀升還是長(zhǎng)期互相擠壓?？梢酝ㄟ^nvidia-smi定時(shí)采樣觀察顯存水位。第三前綴索引的內(nèi)存開銷。當(dāng)請(qǐng)求量達(dá)到百萬級(jí)時(shí)前綴索引本身可能占用數(shù) GB 內(nèi)存。如果發(fā)現(xiàn)索引內(nèi)存異常增長(zhǎng)需要檢查過期清理策略是否生效。8. 資源占用與性能權(quán)衡8.1 顯存開銷前綴 Cache 是提升復(fù)用率的重要手段但會(huì)占用顯存。前綴索引本身存放在 CPU 內(nèi)存時(shí)還需要考慮 CPU 內(nèi)存和 GPU 顯存之間的搬運(yùn)開銷。經(jīng)驗(yàn)上生產(chǎn)環(huán)境會(huì)限制前綴 Cache 的最大顯存容量。比如設(shè)置一個(gè)max_cache_gpu_mb超過后觸發(fā) LRU 淘汰。調(diào)度器應(yīng)該把緩存淘汰策略暴露為配置項(xiàng)而不是寫死。8.2 CPU 調(diào)度開銷調(diào)度器本身是一個(gè)高頻決策模塊。每 10ms 做一次批次決策時(shí)如果請(qǐng)求隊(duì)列非常大排序成本不可忽視。優(yōu)化方向使用堆隊(duì)列代替全量排序?qū)ο嗤熬Y的請(qǐng)求預(yù)先分組減少排序規(guī)模調(diào)度決策異步化不阻塞請(qǐng)求接收。8.3 長(zhǎng)請(qǐng)求與短請(qǐng)求的互相影響一個(gè)長(zhǎng)生成請(qǐng)求如果占滿了執(zhí)行器的 batch 窗口后臺(tái)短請(qǐng)求就會(huì)堆積。一個(gè)常見做法是時(shí)間片輪轉(zhuǎn)執(zhí)行器每執(zhí)行 N 個(gè)長(zhǎng)請(qǐng)求后強(qiáng)制插入一批短請(qǐng)求。這比純粹按優(yōu)先級(jí)排序更穩(wěn)定。8.4 權(quán)衡總結(jié)權(quán)衡點(diǎn)偏向 Prefix 復(fù)用偏向訓(xùn)練吞吐長(zhǎng)處節(jié)省重復(fù)計(jì)算提升推理效率保證訓(xùn)練器持續(xù)有數(shù)據(jù)風(fēng)險(xiǎn)訓(xùn)練器等待、多樣性下降計(jì)算重疊增加、KV 緩存利用率下降適用階段策略穩(wěn)定、前綴穩(wěn)定冷啟動(dòng)、策略頻繁更新、任務(wù)多樣調(diào)度器的參數(shù)不應(yīng)該是一次性固定的而應(yīng)該隨訓(xùn)練狀態(tài)動(dòng)態(tài)調(diào)整。例如用訓(xùn)練步數(shù)、策略更新頻率、最近 N 步 Rollout 數(shù)據(jù)的平均熵作為狀態(tài)信號(hào)。9. 常見問題與排查方法問題現(xiàn)象可能原因排查方式解決方案訓(xùn)練 step 頻繁等待 Rollout 數(shù)據(jù)關(guān)鍵路徑請(qǐng)求優(yōu)先級(jí)不足查看調(diào)度日志中 critical 請(qǐng)求的排隊(duì)時(shí)間提高 critical 權(quán)重或?yàn)殛P(guān)鍵路徑單獨(dú)開隊(duì)列前綴命中率很高但訓(xùn)練速度反而下降過度追求復(fù)用犧牲了樣本多樣性對(duì)比命中率和樣本多樣性評(píng)分降低 prefix 權(quán)重增加多樣性采樣冷啟動(dòng)階段 Rollout 輸出無效樣本多策略未收斂調(diào)度器未切換冷啟動(dòng)模式觀察策略熵變化和輸出分布冷啟動(dòng)階段降低復(fù)用權(quán)重、縮短緩存過期時(shí)間前綴索引占內(nèi)存過大過期前綴未及時(shí)清理檢查策略版本淘汰日志縮短 prefix_ttl_steps定期合并前綴樹訓(xùn)練與推理顯存互相擠壓資源預(yù)算沒有生效查看 budget 配置和顯存采樣曲線設(shè)置訓(xùn)練保留顯存控制推理最大顯存長(zhǎng)請(qǐng)求阻塞短請(qǐng)求批次調(diào)度沒有時(shí)間片輪轉(zhuǎn)查看短請(qǐng)求的排隊(duì)時(shí)延增加時(shí)間片輪轉(zhuǎn)策略定期強(qiáng)制插入短請(qǐng)求GPU 利用率波動(dòng)大調(diào)度窗口和訓(xùn)練步調(diào)不匹配對(duì)比調(diào)度間隔與訓(xùn)練 step 時(shí)間調(diào)整 scheduling_interval_ms對(duì)齊訓(xùn)練步調(diào)回放數(shù)據(jù)與在線數(shù)據(jù)比例失衡后臺(tái)請(qǐng)求優(yōu)先級(jí)過高查看不同任務(wù)類型樣本占比降低 Background 請(qǐng)求權(quán)重限制回放請(qǐng)求配額10. 最佳實(shí)踐與落地建議第一先跑通最小閉環(huán)再上規(guī)模。建議先用一個(gè)小模型、小顯存環(huán)境把“訓(xùn)練器 - 調(diào)度器 - 推理引擎 - 結(jié)果回填”這條鏈路跑通驗(yàn)證調(diào)度器不會(huì)成為新的瓶頸再逐步擴(kuò)大請(qǐng)求量和 batch size。第二調(diào)度參數(shù)不要拍腦袋。每次調(diào)整 Prefix 權(quán)重、Critical 權(quán)重后至少跑 50~100 個(gè)訓(xùn)練 step對(duì)比樣本吞吐和訓(xùn)練總耗時(shí)。第三指標(biāo)日志要打全。訓(xùn)練器側(cè)至少記錄每個(gè) step 的等待時(shí)間調(diào)度器側(cè)記錄請(qǐng)求排隊(duì)時(shí)長(zhǎng)、每個(gè) batch 的執(zhí)行時(shí)間、前綴命中分布執(zhí)行器側(cè)記錄 KV Cache 命中率、顯存占用峰值。三者拼起來才能定位問題。第四冷啟動(dòng)和穩(wěn)定階段分開設(shè)計(jì)。不要在訓(xùn)練一開始就開滿所有優(yōu)化容易讓調(diào)度器在異常分布上自我消耗。建議階段切換使用訓(xùn)練步數(shù)和策略熵雙閾值觸發(fā)。第五合規(guī)與數(shù)據(jù)安全。RL 訓(xùn)練中涉及的用戶數(shù)據(jù)、生成內(nèi)容、獎(jiǎng)勵(lì)模型標(biāo)注數(shù)據(jù)要確保來源合法、授權(quán)清晰。涉及人臉、聲音、版權(quán)素材的生成任務(wù)必須確認(rèn)授權(quán)邊界模型進(jìn)入生產(chǎn)或商用前要對(duì)邏輯漏洞、偏見和有害內(nèi)容做額外評(píng)估。調(diào)度器相關(guān)實(shí)驗(yàn)建議在隔離的開發(fā)環(huán)境進(jìn)行并保留完整的訓(xùn)練與推理日志方便追溯。第六注意開源許可。引用或集成 vLLM、SGLang、Ray、訓(xùn)練框架等三方組件時(shí)檢查各自的 License 是否滿足你的分發(fā)要求。不要因?yàn)檎{(diào)度器的代碼只是薄薄一層就忽略底層框架的許可約束。11. 總結(jié)與下一步這個(gè)方向最值得嘗試的點(diǎn)在于把調(diào)度器從“KV Cache 的工具人”升級(jí)為 RL 訓(xùn)練管道的核心組件。具體來說就是先定義清楚訓(xùn)練目標(biāo)再把前綴復(fù)用、關(guān)鍵路徑、數(shù)據(jù)多樣性、冷啟動(dòng)策略加權(quán)融合到一個(gè)可配置的調(diào)度器里。它解決的問題是真實(shí)存在的大規(guī)模 RL 訓(xùn)練中Rollout 請(qǐng)求混雜、前綴漂移、訓(xùn)練推理爭(zhēng)資源這些問題只靠傳統(tǒng) Prefix Locality 無法根除。最先應(yīng)該驗(yàn)證的功能是兩階段調(diào)度中的預(yù)算控制。因?yàn)槿绻?xùn)練和推理的資源邊界劃不清楚后面所有優(yōu)化都會(huì)建立在沙地上。最容易踩的坑是照著在線推理服務(wù)的思路做調(diào)度把緩存命中率當(dāng)作 KPI忽略訓(xùn)練器的實(shí)時(shí)狀態(tài)。結(jié)果是緩存看起來很漂亮訓(xùn)練吞吐卻上不去。后續(xù)可以繼續(xù)擴(kuò)展的方向包括基于強(qiáng)化學(xué)習(xí)的自適應(yīng)調(diào)度參數(shù)調(diào)整、多機(jī)多卡環(huán)境下的跨節(jié)點(diǎn)前綴共享、以及調(diào)度器與訓(xùn)練器聯(lián)合編排的端到端 pipeline。這里的關(guān)鍵是“先設(shè)計(jì)訓(xùn)練感知的調(diào)度接口再逐步加緩存優(yōu)化”不要把順序搞反了。