機器之心發(fā)布

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

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

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

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

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

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

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

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

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

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

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

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

新開發(fā)范式是如何在這一場景實操的？阿里巴巴未來生活實驗室與智能引擎團隊帶你進一步來看。

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

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

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

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

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

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

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

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

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

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

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

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

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

各個方案的優(yōu)缺點

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1.1 流程概覽

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

總體審閱流程

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

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

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

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

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

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

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

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

2.2.1 如何分步計劃和實施

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 實驗配置

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

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

3.2 性能對比分析

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

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

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

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

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

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

第四部分：團隊介紹

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

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

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

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

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