機(jī)器之心發(fā)布

Andrej Karpathy 大神力薦的 Vibe Coding，正在成為開發(fā)者的新寵。這種「只需聊一聊，AI 可以把功能寫出來」的體驗(yàn)，極大提升了簡(jiǎn)單任務(wù)的開放效率。

然而，當(dāng)我們目光轉(zhuǎn)向?qū)嶋H的系統(tǒng)，特別是 AI Infra 這種復(fù)雜系統(tǒng)時(shí)，Vibe Coding 就會(huì)常常會(huì)陷入「水土不服」的困境。

總結(jié)下來，主要有這三個(gè)方面的問題。

首先是上下文丟失問題：對(duì)話歷史被壓縮，關(guān)鍵設(shè)計(jì)決策在多輪交互中逐漸遺忘，導(dǎo)致后續(xù)生成的代碼與前期討論脫節(jié)。其次是決策偏離困境：AI 在面對(duì)復(fù)雜系統(tǒng)時(shí)需要做出大量技術(shù)決策（如架構(gòu)選擇、接口設(shè)計(jì)、錯(cuò)誤處理策略等），自主決策容易偏離開發(fā)者意圖，生成的代碼難以符合預(yù)期。最后是質(zhì)量不穩(wěn)定挑戰(zhàn)：即使提供了完整的需求描述，生成代碼的質(zhì)量仍然波動(dòng)很大，同樣的需求在不同時(shí)間可能得到截然不同的實(shí)現(xiàn)方案。

而這些問題背后的根源在于：AI Infra 到底還是個(gè)復(fù)雜系統(tǒng)，動(dòng)輒數(shù)萬(wàn)行代碼、成百上千個(gè)相互關(guān)聯(lián)的決策點(diǎn)，而當(dāng)前的對(duì)話式編程缺乏持久化、結(jié)構(gòu)化的決策管理機(jī)制。

換句話說，Vibe 本身是模糊且不穩(wěn)定的，無(wú)法支撐嚴(yán)肅復(fù)雜的 Infra。

不過 Vibe Coding 的發(fā)展不可逆，其廣泛應(yīng)用的潛力不應(yīng)就此止步。要讓 Vibe Coding 真正適用于 AI Infra 開發(fā)，我們實(shí)踐了文本驅(qū)動(dòng)的 Vibe Coding方法：通過設(shè)計(jì)文檔將所有關(guān)鍵決策體系化、持久化。

將復(fù)雜系統(tǒng)的關(guān)鍵決策前置到設(shè)計(jì)階段，通過結(jié)構(gòu)化文檔讓開發(fā)變得有章可循，大幅降低復(fù)雜度門檻。

程序員只需要專注于高層設(shè)計(jì)決策，AI 負(fù)責(zé)代碼實(shí)現(xiàn)細(xì)節(jié)，真正實(shí)現(xiàn)「幾乎不寫一行代碼，就可以完成復(fù)雜功能」。

整個(gè)過程通過詳細(xì)的設(shè)計(jì)規(guī)范和代碼邏輯來約束 AI 生成，確保實(shí)現(xiàn)復(fù)合預(yù)期，同時(shí)提升系統(tǒng)健壯性。

而要驗(yàn)證這一新范式的有效性，我們需要一個(gè)兼具高復(fù)雜度、強(qiáng)工程約束和真實(shí)業(yè)務(wù)價(jià)值的典型場(chǎng)景。

AI Infra 中的資源調(diào)度系統(tǒng)，尤其是面向 Agentic RL，正是這樣一個(gè)理想試驗(yàn)場(chǎng)。該系統(tǒng)是數(shù)萬(wàn)行代碼的分布式訓(xùn)練系統(tǒng)，面臨 GPU 利用率優(yōu)化的復(fù)雜挑戰(zhàn)，涉及核心調(diào)度邏輯改動(dòng)。

新開發(fā)范式是如何在這一場(chǎng)景實(shí)操的？阿里巴巴未來生活實(shí)驗(yàn)室與智能引擎團(tuán)隊(duì)帶你進(jìn)一步來看。

第一部分：Agentic RL 中的 GPU 利用率挑戰(zhàn)

在 Agentic RL 的采樣過程中，系統(tǒng)需要支持越來越高的交互輪數(shù)，讓智能體有足夠的環(huán)境交互來處理復(fù)雜任務(wù)。然而，這一趨勢(shì)帶來了顯著的資源調(diào)度挑戰(zhàn)。

在實(shí)際采樣中，智能體執(zhí)行任務(wù)的時(shí)間分布呈現(xiàn)典型的長(zhǎng)尾特征：絕大多數(shù)樣本能夠在較少輪數(shù)內(nèi)快速完成采樣并得出結(jié)果，而只有少數(shù)復(fù)雜樣本需要執(zhí)行到最大輪數(shù)限制才能終止。這種極不均勻的執(zhí)行分布成為 GPU 資源利用的核心瓶頸。

問題的本質(zhì)在于分布式計(jì)算中經(jīng)典的 "落后者效應(yīng)"（Straggler Effect）：無(wú)論有多少樣本已經(jīng)完成，系統(tǒng)都必須等待最慢的那個(gè)樣本執(zhí)行完畢，才能進(jìn)入下一階段。等待過程成為整個(gè)訓(xùn)練流程的性能瓶頸，更造成 GPU 資源浪費(fèi)。

1.2 方案對(duì)比與技術(shù)優(yōu)勢(shì)

業(yè)界針對(duì) Agentic RL 訓(xùn)練存在兩種主流解決方案，但都存在根本性缺陷：

共置方案采用嚴(yán)格的串行執(zhí)行策略：所有 GPU 首先統(tǒng)一投入 rollout 階段，等待全部樣本采樣完成后再切換至 training 模式。這種方案存在雙重效率問題。首先是階段內(nèi)的資源閑置：在 rollout 階段，由于落后者效應(yīng)的存在，大量 GPU 在短樣本完成后進(jìn)入閑置等待狀態(tài)，無(wú)法有效利用。其次是階段間的嚴(yán)格串行限制：rollout 和 training 完全無(wú)法并行執(zhí)行，training 階段必須等待 rollout 完全結(jié)束才能開始，導(dǎo)致整體迭代時(shí)間被顯著拉長(zhǎng)。

異步分離方案通過靜態(tài)分配專用的 rollout GPU 和 training GPU 實(shí)現(xiàn)流水線并行。雖然理論上能夠縮短單輪迭代時(shí)間，但引入了嚴(yán)重的 "雙邊空泡" 問題。在 rollout 側(cè)，短樣本快速完成后，rollout GPU 進(jìn)入閑置狀態(tài)等待長(zhǎng)尾樣本執(zhí)行完畢；在 training 側(cè)，訓(xùn)練任務(wù)完成后需要等待新一輪 rollout 數(shù)據(jù)，training GPU 同樣處于閑置狀態(tài)。使得理論上的并行優(yōu)勢(shì)在實(shí)際運(yùn)行中大打折扣。

我們提出的時(shí)分復(fù)用方案通過 GPU 池動(dòng)態(tài)分配機(jī)制解決上述問題。其核心創(chuàng)新基于一個(gè)關(guān)鍵洞察：異步訓(xùn)練過程中，rollout 對(duì) GPU 資源的需求呈現(xiàn)動(dòng)態(tài)波動(dòng)特征。在 training 觸發(fā)前，大量樣本已進(jìn)入完成階段，系統(tǒng)處于樣本數(shù)目的低谷期，此時(shí)對(duì) GPU 資源的需求自然下降。相反，在訓(xùn)練結(jié)束后，新一輪大量樣本涌入系統(tǒng)，對(duì) GPU 資源的需求急劇激增，形成明顯的高峰期?；谶@一波動(dòng)規(guī)律，我們?cè)O(shè)計(jì)了智能資源調(diào)度機(jī)制，在采樣需求低谷期分配部分 GPU 資源用于執(zhí)行訓(xùn)練任務(wù)，從而實(shí)現(xiàn)需求波動(dòng)與資源調(diào)度的有效匹配。

系統(tǒng)采用兩階段執(zhí)行流程來實(shí)現(xiàn)這一設(shè)計(jì)理念。在全力采樣階段，所有 GPU 協(xié)同處理大多數(shù)樣本，快速推進(jìn)系統(tǒng)至需求低谷狀態(tài)。當(dāng)采樣完成度達(dá)到訓(xùn)練要求時(shí)，系統(tǒng)執(zhí)行縮容操作，釋放固定的 rollout GPU 資源轉(zhuǎn)入訓(xùn)練模式。隨后進(jìn)入并行執(zhí)行階段，被釋放的 GPU 專門執(zhí)行訓(xùn)練任務(wù)（充分利用低谷期的閑置資源），而長(zhǎng)尾樣本被遷移至剩余 GPU 繼續(xù)處理。訓(xùn)練任務(wù)完成后，系統(tǒng)立即執(zhí)行擴(kuò)容操作，回收所有 GPU 資源恢復(fù)全力采樣狀態(tài)，為應(yīng)對(duì)下輪需求高峰做好準(zhǔn)備。

這種基于工作負(fù)載特征的智能時(shí)分復(fù)用策略，不是簡(jiǎn)單的資源分割，而是將訓(xùn)練的快速執(zhí)行特性與 rollout 需求波動(dòng)在時(shí)間維度巧妙匹配提升了整體的 GPU 資源利用效率。

以 4GPU 系統(tǒng)為例，我們比較各個(gè)方案的任務(wù)執(zhí)行時(shí)間線。

時(shí)分復(fù)用方案的核心挑戰(zhàn)在于系統(tǒng)復(fù)雜度的顯著提升。為了追求高性能，需要精細(xì)復(fù)雜的控制機(jī)制，在分布式高并發(fā)的系統(tǒng)中實(shí)現(xiàn)尤其困難。相比串行執(zhí)行和靜態(tài)資源分配，動(dòng)態(tài)調(diào)度引入了諸多技術(shù)難點(diǎn)：分布式環(huán)境下的精確同步控制，以及擴(kuò)縮容操作的原子性保證，并發(fā)場(chǎng)景下樣本狀態(tài)的無(wú)縫遷移。

各個(gè)方案的優(yōu)缺點(diǎn)

在一個(gè)包含數(shù)萬(wàn)行代碼的分布式 RL 系統(tǒng)中，手工編碼不僅周期長(zhǎng)，更易引入隱蔽的狀態(tài)不一致 bug。傳統(tǒng)的開發(fā)方式已難以應(yīng)對(duì)這種「高價(jià)值、高復(fù)雜度」的功能迭代需求。

正是在這一背景下，我們創(chuàng)新性地采用了文檔驅(qū)動(dòng)的 Vibe Coding 方法論，通過系統(tǒng)化的設(shè)計(jì)文檔驅(qū)動(dòng)開發(fā)流程，顯著提升了復(fù)雜系統(tǒng)的實(shí)現(xiàn)效率和代碼質(zhì)量。

第二部分：文檔驅(qū)動(dòng)的 Vibe Coding 方法論

前文提到的氛圍編程三大痛點(diǎn)，上下文丟失、決策偏離、質(zhì)量不穩(wěn)定，其根源都指向同一個(gè)問題：缺乏持久化、結(jié)構(gòu)化的決策管理機(jī)制。

要理解設(shè)計(jì)文檔如何解決這一問題，我們需要先認(rèn)識(shí)到代碼實(shí)現(xiàn)的本質(zhì)：它是由成百上千個(gè)相互關(guān)聯(lián)的決策點(diǎn)構(gòu)成的。從頂層的架構(gòu)選擇、接口設(shè)計(jì)，到底層的變量命名、錯(cuò)誤處理，每個(gè)決策都影響著最終的代碼質(zhì)量。在理想情況下，如果 AI 已經(jīng)掌握了完整的代碼改動(dòng)（如代碼遷移任務(wù)），它可以直接復(fù)制執(zhí)行這些修改。但現(xiàn)實(shí)中，我們要解決的往往是全新的問題，比如本文的 "訓(xùn)練 - 推理時(shí)分復(fù)用優(yōu)化" 功能此前從未實(shí)現(xiàn)過。

既然沒有現(xiàn)成的代碼可以參考，那么退而求其次，如果我們能夠系統(tǒng)化地枚舉出所有決策點(diǎn)，AI 就可以按照這些明確的決策逐步生成代碼。

設(shè)計(jì)文檔正是實(shí)現(xiàn)這一目標(biāo)的關(guān)鍵工具：它通過結(jié)構(gòu)化的方式，將高層的設(shè)計(jì)思路逐步細(xì)化為具體的代碼改動(dòng)，完整記錄每一個(gè)決策點(diǎn)。

經(jīng)過程序員審閱的設(shè)計(jì)文檔，意味著人與 AI 在關(guān)鍵決策上達(dá)成一致。這直接解決了氛圍編程的三大痛點(diǎn)：持久化文檔消除上下文丟失，明確決策避免 AI 偏離意圖，規(guī)范和代碼邏輯確保代碼質(zhì)量穩(wěn)定。這帶來工作方式的根本轉(zhuǎn)變：程序員從編碼、調(diào)試、測(cè)試等執(zhí)行層面，轉(zhuǎn)向與 AI 討論設(shè)計(jì)，通過文檔明確決策點(diǎn)直到完全對(duì)齊，然后 AI 負(fù)責(zé)實(shí)現(xiàn)。設(shè)計(jì)文檔同時(shí)記錄實(shí)施進(jìn)度，確?？勺匪菪浴８匾氖?，設(shè)計(jì)文檔本身由 AI 管理，大大降低了編寫門檻。

設(shè)計(jì)文檔驅(qū)動(dòng)的氛圍編程和傳統(tǒng)的 vibe coding 的工作流對(duì)比

這三種開發(fā)方式的優(yōu)缺點(diǎn)

2.1 核心方法論：設(shè)計(jì)文檔驅(qū)動(dòng)開發(fā)

在明確了設(shè)計(jì)文檔的必要性后，我們需要建立一套系統(tǒng)化的方法論來指導(dǎo)實(shí)際操作。設(shè)計(jì)文檔驅(qū)動(dòng)開發(fā)不僅僅是編寫文檔，更是一種全新的開發(fā)范式：通過結(jié)構(gòu)化的文檔組織決策過程，通過迭代審閱確保決策質(zhì)量，通過分步實(shí)施降低實(shí)現(xiàn)風(fēng)險(xiǎn)。

這一方法論的核心在于將復(fù)雜的系統(tǒng)開發(fā)問題分解為三個(gè)可管理的環(huán)節(jié)：內(nèi)容組織（如何構(gòu)建決策體系）、審閱修改（如何確保決策質(zhì)量）、分步實(shí)施（如何將決策轉(zhuǎn)化為代碼）。每個(gè)環(huán)節(jié)都有明確的操作流程和質(zhì)量標(biāo)準(zhǔn)，確保整個(gè)開發(fā)過程的可控性和可預(yù)測(cè)性。

2.1.1 流程概覽

設(shè)計(jì)文檔的審閱是一個(gè)迭代優(yōu)化的過程，需要人和 AI 協(xié)作來確保文檔質(zhì)量。我們建立了系統(tǒng)化的審閱流程，通過多輪迭代逐步完善設(shè)計(jì)文檔，直到達(dá)到實(shí)施標(biāo)準(zhǔn)。

總體審閱流程

2.1.2 如何組織內(nèi)容：開發(fā)者與 AI 共同完成

代碼實(shí)現(xiàn)的結(jié)果是由一系列自頂向下的決策決定的，頂層的關(guān)鍵決策包括新功能如何融入已有架構(gòu)，底層的決策如是否需要增加成員變量。組織設(shè)計(jì)文檔的核心目的是系統(tǒng)性的跟進(jìn)這些決策點(diǎn)，并逐步完善解決。由于底層的決策，往往依賴于頂層或者上層的決策，設(shè)計(jì)文檔需要層次化的拆解決策，形成決策體系。開發(fā)者需要按照章節(jié)的先后順序和目錄層次結(jié)構(gòu)審閱文檔中的自頂向下的決策過程，當(dāng)我們指出前面頂層設(shè)計(jì)的錯(cuò)誤時(shí)，AI 會(huì)自動(dòng)修改后面章節(jié)的中層和下層決策以保持內(nèi)部邏輯的一致性。因此，我們可以按章節(jié)層次和順序和 AI 逐個(gè)對(duì)齊自頂向下的決策。同時(shí)，在開發(fā)者和 AI 共同修正這些決策的過程中文檔不斷演進(jìn)，文檔需要自包含這個(gè)迭代的過程，記錄迭代的版本。最后，文檔也需要記錄代碼實(shí)施的進(jìn)度和一些衍生的待辦。

具體而言我們的設(shè)計(jì)文檔模板包含如下內(nèi)容：

2.1.3 如何審閱修改：復(fù)用 iFlow CLI 的 prompt 模板

上文描述的逐章節(jié)審閱對(duì)齊的過程理論上已經(jīng)完備，但實(shí)踐中會(huì)遇到一系列挑戰(zhàn)。為應(yīng)對(duì)這些挑戰(zhàn)，我們建立了多層次的文檔質(zhì)量保證機(jī)制。

由于這些場(chǎng)景在文檔審閱中反復(fù)出現(xiàn)，我們利用 iFlow CLI 的 Sub Command 功能，將不同場(chǎng)景的指令邏輯固化成了自定義的 prompt 模板。

審閱挑戰(zhàn)與解決方案對(duì)照表

2.2 設(shè)計(jì)文檔的實(shí)施

2.2.1 如何分步計(jì)劃和實(shí)施

當(dāng) Section 5 完成所有 API 和 Implementation 的設(shè)計(jì)后，我們需要將這些設(shè)計(jì)轉(zhuǎn)化為可執(zhí)行的代碼。這個(gè)轉(zhuǎn)化過程分為兩個(gè)階段：首先規(guī)劃 Section 6 制定實(shí)施步驟，然后進(jìn)入 AI 輔助的增量開發(fā)循環(huán)。

規(guī)劃實(shí)施步驟： 規(guī)劃的核心目標(biāo)是將 Section 5 中的方法拆解為依賴有序的小步驟。我們首先分析每個(gè)方法的 deps: 字段，識(shí)別底層 helper 方法和高層 orchestration 方法之間的依賴關(guān)系，繪制出完整的依賴圖。在拆解步驟時(shí)，我們遵循 "每步越小越好" 的原則，通常一個(gè) Step 包含 3-5 個(gè)相互關(guān)聯(lián)的方法，避免單個(gè) Step 包含超過 10 個(gè)方法。步驟的排序遵循依賴關(guān)系：Step 1 通常是基礎(chǔ)設(shè)施（配置、常量、基礎(chǔ)類），Step 2 到 Step N 按照從底層到高層的順序排列，最后一個(gè) Step 負(fù)責(zé)集成和端到端測(cè)試。每個(gè) Step 都定義清晰的驗(yàn)證點(diǎn)和測(cè)試用例覆蓋，確?？梢元?dú)立驗(yàn)證和方便回退。

規(guī)劃完成后，我們得到一個(gè)清晰的依賴圖，指導(dǎo)后續(xù)的增量開發(fā)：

增量開發(fā)循環(huán)： Section 6 規(guī)劃完成后，我們進(jìn)入實(shí)施階段。對(duì)于每個(gè) Step，AI首先讀取 Section 6 中的 purpose 和 dependencies，以及 Section 5 中相關(guān)方法的 Signature 和 Implementation，然后按照 docstring 和代碼實(shí)現(xiàn)具體代碼，同時(shí)展開 validation placeholders 為實(shí)際的驗(yàn)證邏輯。AI 完成編碼后，會(huì)自動(dòng)更新 Section 6 中該 Step 的狀態(tài)，將方法從 NOT_STARTED 改為 DONE。

接下來是人工代碼審查環(huán)節(jié)。我們使用 IDE 的 Local History 功能查看當(dāng)前 step 的代碼改動(dòng)，重點(diǎn)檢查代碼是否符合 Section 5 的設(shè)計(jì)、是否正確實(shí)現(xiàn)了 validation 和 assertion、是否存在明顯 bug。如果發(fā)現(xiàn)問題，小范圍修正或進(jìn)入錯(cuò)誤處理流程（見 2.2.3）。審查通過后，我們創(chuàng)建一個(gè) git commit，commit message 遵循 "Step N: [描述]" 的格式，然后繼續(xù)下一個(gè) Step，重復(fù)這個(gè)循環(huán)直到所有 Steps 完成。

2.2.2 防御性編程：讓復(fù)雜系統(tǒng)更可靠

在分布式 AI 訓(xùn)練環(huán)境中，微小的錯(cuò)誤可能觸發(fā)級(jí)聯(lián)故障，而異步操作和資源調(diào)度的復(fù)雜性使得問題追溯本就困難。更糟糕的是，AI 編程傾向于主動(dòng)做錯(cuò)誤處理，這種 "善意" 的處理機(jī)制往往弄巧成拙，掩蓋了真實(shí)的錯(cuò)誤信息，使得問題定位變得更加復(fù)雜。我們真正需要的是防御性編程，讓錯(cuò)誤主動(dòng)暴露而不是被掩蓋。然而，傳統(tǒng)的防御性編程因其開發(fā)繁瑣性和進(jìn)度壓力常被開發(fā)人員選擇性忽略，導(dǎo)致系統(tǒng)健壯性完全依賴個(gè)人自覺。為此，我們將防御性思維前置到設(shè)計(jì)階段：在關(guān)鍵節(jié)點(diǎn)設(shè)置驗(yàn)證點(diǎn)，構(gòu)建標(biāo)準(zhǔn)化的錯(cuò)誤處理模式庫(kù)，利用 AI 技術(shù)自動(dòng)生成健壯的防御代碼，從而在保證開發(fā)效率的同時(shí)實(shí)現(xiàn)快速問題定位，顯著降低維護(hù)成本。

統(tǒng)一的驗(yàn)證模式庫(kù)： 我們維護(hù)了一個(gè)包含常用驗(yàn)證模式的庫(kù)，每個(gè)模式都有唯一的 ID 和標(biāo)準(zhǔn)化的實(shí)現(xiàn)。這些模式遵循單一定義，多處復(fù)用原則。當(dāng)需要在代碼內(nèi)增加某個(gè)驗(yàn)證邏輯時(shí)，只需在注釋中加入模式庫(kù)中的一處定義，AI 實(shí)施時(shí)會(huì)按 ID 查表展開，確保整個(gè)代碼庫(kù)中相同驗(yàn)證邏輯的一致性。

設(shè)計(jì)階段的驗(yàn)證標(biāo)注： 在 Section 5 的設(shè)計(jì)文檔中，我們不直接編寫完整的驗(yàn)證代碼，而是用標(biāo)準(zhǔn)化的注釋標(biāo)注驗(yàn)證需求。以 shrinksampler () 函數(shù)為例，通過 VALINTRANGE 標(biāo)注 GPU 列表的合法性驗(yàn)證，通過 ASTPOSTCONDITION 標(biāo)注返回結(jié)果的有效性檢查。這種標(biāo)注方式清晰表達(dá)了驗(yàn)證意圖，同時(shí)保持了設(shè)計(jì)文檔的簡(jiǎn)潔性。

def shrink_sampler (self, target_gpus: List [int]): # VAL: VAL_INT_RANGE (min=0, max=7) # 將在實(shí)施時(shí)展開為實(shí)際 validation 代碼 offload_ranks = self._calculate_offload_ranks (target_gpus) # AST: AST_POSTCONDITION (len (offload_ranks) > 0) # 將在實(shí)施時(shí)展開為 assert 語(yǔ)句 return offload_ranks

AI 自動(dòng)展開驗(yàn)證邏輯： 當(dāng) AI 根據(jù)設(shè)計(jì)文檔生成代碼時(shí)，會(huì)自動(dòng)將標(biāo)注中的模式 ID 展開為具體的驗(yàn)證邏輯。參數(shù)范圍驗(yàn)證會(huì)展開為完整的條件檢查語(yǔ)句，后置條件會(huì)生成帶有詳細(xì)錯(cuò)誤信息的 assert 語(yǔ)句。這種自動(dòng)展開機(jī)制避免了人工編碼時(shí)的遺漏和不一致。

# 設(shè)計(jì)文檔中的標(biāo)注：# AST: AST_POSTCONDITION (len (offload_ranks) > 0)# AI 實(shí)施時(shí)展開為帶詳細(xì)信息的斷言：assert len (offload_ranks) > 0, \ f"Post-condition: offload_ranks not empty, got {offload_ranks}"

復(fù)雜驗(yàn)證的獨(dú)立處理： 當(dāng)驗(yàn)證邏輯超過 10 行時(shí)，內(nèi)聯(lián)展開會(huì)讓代碼變得臃腫難讀。對(duì)于這類復(fù)雜驗(yàn)證，我們?cè)谠O(shè)計(jì)文檔中定義專門的驗(yàn)證函數(shù)，詳細(xì)描述驗(yàn)證項(xiàng)和錯(cuò)誤處理策略。例如 validategpuallocation () 函數(shù)負(fù)責(zé)驗(yàn)證 GPU 分配邏輯的完整性，包括檢查 targetgpus 非空、確保 GPU ID 在有效范圍內(nèi)等。在實(shí)施計(jì)劃中，我們會(huì)安排專門的步驟來實(shí)現(xiàn)這些復(fù)雜驗(yàn)證函數(shù)，為后續(xù)的核心邏輯步驟提供堅(jiān)實(shí)的基礎(chǔ)。

#### 5.2.8 _validate_gpu_allocation () - Full Specificationdef _validate_gpu_allocation (self, target_gpus, current_allocation): """ 驗(yàn)證 GPU 分配的復(fù)雜邏輯。 檢查項(xiàng)： - target_gpus 非空且元素唯一 - GPU ID 在有效范圍內(nèi) Raises: ValueError: 違反任何檢查條件 """ # 10-20 行的詳細(xì) validation 邏輯

第三部分：在生產(chǎn)級(jí)別的大規(guī)模集群上驗(yàn)證

3.1 實(shí)驗(yàn)配置

我們?cè)谏a(chǎn)級(jí)別的大規(guī)模集群上驗(yàn)證了時(shí)分復(fù)用方案的實(shí)際效果。實(shí)驗(yàn)環(huán)境采用 160 卡 GPU 集群，選擇了具有代表性的 SWE Agentic 工作負(fù)載作為測(cè)試場(chǎng)景。模型使用 Qwen3-235B-A22B，這是一個(gè)具有 235B 參數(shù)規(guī)模、22B 激活參數(shù)的大規(guī)模語(yǔ)言模型，能夠充分體現(xiàn)真實(shí)生產(chǎn)環(huán)境的計(jì)算壓力。

為了模擬真實(shí)的智能體長(zhǎng)時(shí)交互場(chǎng)景，我們將最大交互輪數(shù)設(shè)置為 100 輪，最大 token 長(zhǎng)度為 64K，batch size 為 512。我們?cè)O(shè)置異步訓(xùn)練的 async ratio 為 1，這樣的配置確保了實(shí)驗(yàn)的真實(shí)性和挑戰(zhàn)性。在對(duì)比方案設(shè)置上，我們將時(shí)分復(fù)用方案與傳統(tǒng)的異步分離方案進(jìn)行對(duì)比：baseline 采用 128 卡用于 training、32 卡用于 rollout 的靜態(tài)分配策略，而時(shí)分復(fù)用方案則采用 128 卡 training、160 卡 rollout 的動(dòng)態(tài)調(diào)度策略。

3.2 性能對(duì)比分析

實(shí)驗(yàn)結(jié)果顯示時(shí)分復(fù)用的 rollout 吞吐率提升了 3.5 倍。時(shí)分復(fù)用方案的 rollout 階段幾乎始終比完全分離的 baseline 要快，甚至在某些情況下訓(xùn)練任務(wù)無(wú)需等待 rollout 即可開始，性能提升明顯。

更值得關(guān)注的是任務(wù)完成率的提升。在 baseline 的完全分離方案中，由于 rollout 資源受限（僅 32 卡），導(dǎo)致采樣速度較慢，大量任務(wù)觸發(fā)了環(huán)境默認(rèn)的超時(shí)限制，采樣軌跡的 timeout 比例居高不下。而時(shí)分復(fù)用方案通過動(dòng)態(tài)釋放更多 GPU 資源用于 rollout，顯著加快了采樣速度，完全避免了 timeout，提升了整體訓(xùn)練的穩(wěn)定性和樣本利用效率。

3.3 系統(tǒng)開銷分析

在評(píng)估時(shí)分復(fù)用方案時(shí)，我們也仔細(xì)分析了引入的系統(tǒng)開銷。參數(shù)同步開銷方面，由于時(shí)分復(fù)用方案需要在更多的 GPU 之間進(jìn)行參數(shù)同步（160 卡 vs 32 卡），相比分離方案會(huì)產(chǎn)生額外的通信開銷，但這一開銷在整體訓(xùn)練整體時(shí)間中占比極小。

縮容操作的開銷主要來自于 rollout 模型參數(shù)的 offload 過程。當(dāng)系統(tǒng)需要將部分 GPU 從 rollout 模式切換到 training 模式時(shí)，需要從顯存中將 rollout 參數(shù)釋放，實(shí)測(cè)耗時(shí)在秒級(jí)。盡管這一操作引入了額外的同步點(diǎn)，但由于縮容操作開銷極低，因此并未成為性能瓶頸。

綜合來看，時(shí)分復(fù)用方案通過智能的資源調(diào)度策略，在引入極小系統(tǒng)開銷的前提下，顯著提升了 GPU 利用率和訓(xùn)練效率，特別是在降低 timeout 率方面表現(xiàn)突出，充分證明了該方案在大規(guī)模 Agentic RL 訓(xùn)練中的實(shí)用價(jià)值。

第四部分：團(tuán)隊(duì)介紹

本文是 ROCK & ROLL 團(tuán)隊(duì)使用 iFlow CLI 在開源框架實(shí)踐中的探索成果，后續(xù)相關(guān)功能將持續(xù)迭代并陸續(xù)發(fā)布。

ROCK & ROLL 由阿里巴巴未來生活實(shí)驗(yàn)室與智能引擎團(tuán)隊(duì)聯(lián)合打造，致力于開拓強(qiáng)化學(xué)習(xí)（RL）的未來，探索面向未來的創(chuàng)新生活方式。ROLL 是靈活高效的 Agentic RL 訓(xùn)練框架，支持從十億到千億參數(shù)大模型的優(yōu)化訓(xùn)練；ROCK 是易用、可擴(kuò)展的沙箱環(huán)境管理器，可在分鐘級(jí)拉起海量環(huán)境。我們堅(jiān)持工程系統(tǒng)與算法協(xié)同創(chuàng)新，持續(xù)關(guān)注 RL 社區(qū)發(fā)展并分享開源實(shí)踐，為 RL 在不同場(chǎng)景中的規(guī)?；涞靥峁﹫?jiān)實(shí)的基礎(chǔ)設(shè)施支持。

iFlow CLI 是阿里巴巴未來生活實(shí)驗(yàn)室推出的一款終端 AI 智能體，支持通過自然語(yǔ)言進(jìn)行交互。它能夠高效分析代碼倉(cāng)庫(kù)、完成各類編程任務(wù)，并準(zhǔn)確理解特定的上下文需求；同時(shí)可將從基礎(chǔ)文件操作到復(fù)雜工作流的流程自動(dòng)化，顯著提升開發(fā)者的工作效率。

歡迎關(guān)注、Star、試用并貢獻(xiàn)代碼，一起推動(dòng) RL for LLM 走向更廣闊的實(shí)用化未來。

• ROCK： https://github.com/alibaba/ROCK
• ROLL：http://github.com/alibaba/ROLL
• iFlow CLI： https://cli.iflow.cn/