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

機器之心發(fā)布

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1.1 流程概覽

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

總體審閱流程

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

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

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

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

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

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

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

2.2 設計文檔的實施

2.2.1 如何分步計劃和實施

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

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

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

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

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

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

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

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

設計階段的驗證標注： 在 Section 5 的設計文檔中，我們不直接編寫完整的驗證代碼，而是用標準化的注釋標注驗證需求。以 shrinksampler () 函數(shù)為例，通過 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 根據(jù)設計文檔生成代碼時，會自動將標注中的模式 ID 展開為具體的驗證邏輯。參數(shù)范圍驗證會展開為完整的條件檢查語句，后置條件會生成帶有詳細錯誤信息的 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 行時，內聯(lián)展開會讓代碼變得臃腫難讀。對于這類復雜驗證，我們在設計文檔中定義專門的驗證函數(shù)，詳細描述驗證項和錯誤處理策略。例如 validategpuallocation () 函數(shù)負責驗證 GPU 分配邏輯的完整性，包括檢查 targetgpus 非空、確保 GPU ID 在有效范圍內等。在實施計劃中，我們會安排專門的步驟來實現(xiàn)這些復雜驗證函數(shù)，為后續(xù)的核心邏輯步驟提供堅實的基礎。

#### 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 邏輯

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

3.1 實驗配置

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

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

3.2 性能對比分析

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

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

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

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

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

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

第四部分：團隊介紹

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

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

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

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

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