大模型最難的AI Infra，用Vibe Coding搞定

機器之心發布

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

然而，當我們目光轉向實際的系統，特別是 AI Infra 這種復雜系統時，Vibe Coding 就會常常會陷入「水土不服」的困境。

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

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

而這些問題背后的根源在于：AI Infra 到底還是個復雜系統，動輒數萬行代碼、成百上千個相互關聯的決策點，而當前的對話式編程缺乏持久化、結構化的決策管理機制。

換句話說，Vibe 本身是模糊且不穩定的，無法支撐嚴肅復雜的 Infra。

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

將復雜系統的關鍵決策前置到設計階段，通過結構化文檔讓開發變得有章可循，大幅降低復雜度門檻。

程序員只需要專注于高層設計決策，AI 負責代碼實現細節，真正實現「幾乎不寫一行代碼，就可以完成復雜功能」。

整個過程通過詳細的設計規范和代碼邏輯來約束 AI 生成，確保實現復合預期，同時提升系統健壯性。

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

AI Infra 中的資源調度系統，尤其是面向 Agentic RL，正是這樣一個理想試驗場。該系統是數萬行代碼的分布式訓練系統，面臨 GPU 利用率優化的復雜挑戰，涉及核心調度邏輯改動。

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

第一部分：Agentic RL 中的 GPU 利用率挑戰

在 Agentic RL 的采樣過程中，系統需要支持越來越高的交互輪數，讓智能體有足夠的環境交互來處理復雜任務。然而，這一趨勢帶來了顯著的資源調度挑戰。

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

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

1.2 方案對比與技術優勢

業界針對 Agentic RL 訓練存在兩種主流解決方案，但都存在根本性缺陷：

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

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

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

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

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

以 4GPU 系統為例，我們比較各個方案的任務執行時間線。

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

各個方案的優缺點

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

正是在這一背景下，我們創新性地采用了文檔驅動的 Vibe Coding 方法論，通過系統化的設計文檔驅動開發流程，顯著提升了復雜系統的實現效率和代碼質量。

第二部分：文檔驅動的 Vibe Coding 方法論

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

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

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

設計文檔正是實現這一目標的關鍵工具：它通過結構化的方式，將高層的設計思路逐步細化為具體的代碼改動，完整記錄每一個決策點。

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

設計文檔驅動的氛圍編程和傳統的 vibe coding 的工作流對比

這三種開發方式的優缺點

2.1 核心方法論：設計文檔驅動開發

在明確了設計文檔的必要性后，我們需要建立一套系統化的方法論來指導實際操作。設計文檔驅動開發不僅僅是編寫文檔，更是一種全新的開發范式：通過結構化的文檔組織決策過程，通過迭代審閱確保決策質量，通過分步實施降低實現風險。

這一方法論的核心在于將復雜的系統開發問題分解為三個可管理的環節：內容組織（如何構建決策體系）、審閱修改（如何確保決策質量）、分步實施（如何將決策轉化為代碼）。每個環節都有明確的操作流程和質量標準，確保整個開發過程的可控性和可預測性。

2.1.1 流程概覽

設計文檔的審閱是一個迭代優化的過程，需要人和 AI 協作來確保文檔質量。我們建立了系統化的審閱流程，通過多輪迭代逐步完善設計文檔，直到達到實施標準。

總體審閱流程

2.1.2 如何組織內容：開發者與 AI 共同完成

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

具體而言我們的設計文檔模板包含如下內容：

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

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

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

審閱挑戰與解決方案對照表

2.2 設計文檔的實施

2.2.1 如何分步計劃和實施

當 Section 5 完成所有 API 和 Implementation 的設計后，我們需要將這些設計轉化為可執行的代碼。這個轉化過程分為兩個階段：首先規劃 Section 6 制定實施步驟，然后進入 AI 輔助的增量開發循環。

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

規劃完成后，我們得到一個清晰的依賴圖，指導后續的增量開發：

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

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

2.2.2 防御性編程：讓復雜系統更可靠

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

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

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

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 自動展開驗證邏輯： 當 AI 根據設計文檔生成代碼時，會自動將標注中的模式 ID 展開為具體的驗證邏輯。參數范圍驗證會展開為完整的條件檢查語句，后置條件會生成帶有詳細錯誤信息的 assert 語句。這種自動展開機制避免了人工編碼時的遺漏和不一致。

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

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

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

第三部分：在生產級別的大規模集群上驗證

3.1 實驗配置

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

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

3.2 性能對比分析

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

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

3.3 系統開銷分析

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

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

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

第四部分：團隊介紹

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

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

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

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

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