2026年9月的一個清晨，有一台由64塊NVIDIA GB300 GPU組成的集群，正在訓練一個總參數量744B、每次實際激活40B的超大模型GLM-5.2。它要學習的不是寫詩或者聊天，而是在真實的命令行終端里完成編程任務，一步步敲代碼、跑測試、看報錯、再改。這活兒聽起來就很難，而更難的是：這台集群要一邊不停地"出題考試"（生成模型的操作軌跡），一邊不停地"批改試卷"（訓練更新參數），兩件事還必須嚴絲合縫地對齊，中間不能有任何數據對不上號。
這就是這篇論文要講的系統，叫Miles。它不是在做一個新的算法，而是在解決一個更樸素也更硬核的問題：怎麼把強化學習訓練大模型這件事，從"能跑通"做到"能在生產環境裡穩定、高效、可信地跑"。
**這件事到底難在哪**
先說說背景。強化學習*（Reinforcement Learning，簡稱RL）：一種讓模型通過嘗試和反饋來自我改進的訓練方式，模型做出一個動作，獲得一個獎勵分數，再根據這個分數調整自己的行為傾向。
用來訓練大語言模型，早已不是什麼新鮮事，但過去幾年,這個"生成-反饋-更新"的循環已經變得遠比想像中複雜。以前可能就是讓模型寫一段話，打個分，更新一下權重，一輪就結束了。但現在的任務是多輪的：模型要在終端里連續操作幾十步，中間要調用工具、讀取環境反饋，還可能因為一次失誤讓整個任務前功盡棄。生成這類"軌跡"（也就是模型一次完整的任務嘗試）往往需要幾十秒到幾十分鐘不等，長短差異極大。
而承擔生成任務的引擎，往往要伺候的是萬億參數級別的混合專家模型*（Mixture of Experts，簡稱MoE）：一種模型架構，它不是讓每個參數都參與每次計算，而是像開會一樣，每次只挑選一部分"專家"模組來處理當前的輸入，這樣能在保持強大能力的同時省下大量算力。
這就帶來了兩個幾乎所有做過大規模系統的人都會撞上的坑。第一個坑是效率：生成軌跡是個磨洋工的活兒，慢吞吞的；訓練更新則講究火力全開的吞吐量。兩種節奏放在一起，稍不注意就會出現一邊乾瞪眼等著另一邊幹完活的情況，GPU利用率直接打對摺。第二個坑更隱蔽，也更致命：生成軌跡的引擎和訓練用的引擎，即便用的是同一套權重，算出來的概率也可能對不上。這個"對不上"如果沒被發現和糾正，訓練出來的梯度信號本質上就是在優化一個從沒真實發生過的軌跡，整個訓練目標可能就是錯的，而且系統不會報錯，它只會安靜地把模型訓廢。
Miles這套系統，就是奔著把這兩個坑填平去設計的，它建立在一個叫slime的項目基礎上，圍繞著"組件要經過驗證、代碼要乾淨、系統要可定製"這三條原則，把強化學習訓練的每一個環節都重新梳理了一遍。
**生成引擎怎麼又快又准：SGLang與請求路由的門道**
Miles的生成端建立在SGLang*（一種高效的大模型推理服務框架）：可以理解為專門給大模型"接客"的服務系統，它決定了模型推理請求怎麼被安排、怎麼被處理。
之上,但真正決定吞吐量高低的,是一個聽起來很技術但道理很樸素的東西:請求路由。
一次多輪對話里，每一輪都要用到前面所有輪次積累的上下文。如果處理第一輪的引擎，和處理第二輪的引擎是同一台機器，那這台機器的顯存里其實已經緩存了前面的計算結果（這叫KV緩存），第二輪只需要算新增的那一小段就行。但如果路由把第二輪的請求隨手甩給了另一台機器，那台機器對前面發生了什麼一無所知，只能把整個歷史重新算一遍。
這就好比你去醫院複診，如果每次都換一個新醫生，醫生就得把你的病歷從頭看一遍才能開始看病；但如果一直是同一個醫生，他打開電腦，病歷都在，直接接著上次的思路往下問。如果不做這個"綁定"，每一輪對話都相當於讓醫生重新讀一遍病歷，輪次越多，浪費的時間呈線性甚至更快地增長。
Miles管這種綁定叫"親和性"，用SGLang的按鍵路由，給每個多輪會話貼一個穩定的路由標籤，路由器看到這個標籤就知道該送到哪台引擎去。同時，Miles還有個叫"會話伺服器"的組件專門負責管理這些多輪對話的身份和路由標籤，如果一個請求沒帶這個標籤，Miles會直接報錯，而不是偷偷按負載均衡隨便扔一個引擎，因為那樣雖然不會崩潰，但會悄悄拉低緩存命中率，出了問題還查不到原因。
但只做親和性綁定還不夠，因為不同軌跡的長度天差地別，一台機器如果分到好幾個特別長的任務，就會被拖著走，而分到短任務的機器很快就閒下來了。所以Miles還加了一條規則：新會話開始時，交給當前活躍請求最少的那台引擎。兩條規則疊加起來，在論文的實測數據里，這套組合拳能讓緩存命中率維持在96%。
**讓生成和訓練同時跑起來：全異步強化學習
**
傳統的做法，是生成和訓練輪流上場，訓練等生成的批次全部完成再開始，生成也等訓練算完新權重才能繼續。這種做法有個致命傷：只要一個批次里有一條軌跡特別慢（比如那種要跑三十輪工具調用的任務），整個批次就得死等它，其它GPU全部閒置。
Miles的解法是全異步調度*（Fully Asynchronous RL）：讓生成引擎持續不斷地產出軌跡，訓練器則隨時從已經完成的軌跡里挑一批出來訓練,兩邊互不等待。
這個設計要求生成和訓練必須使用兩組獨立的GPU資源，Miles甚至明確拒絕在同一批GPU上同時跑生成和訓練時啟用全異步模式，因為共享GPU意味著兩邊天然要搶資源，異步就沒了意義。
這就像一個自助餐廳，如果所有顧客必須排成一隊，等前面那個人磨磨蹭蹭挑完菜、結完賬才能輪到下一個，隊伍效率完全被最慢的那個人拖累。而如果餐廳開了多個取餐口和結賬口，顧客各取所需，誰快誰先走，整體效率立刻上去了。如果不做這種拆分，長上下文和調用工具的任務會讓大量批次陷入等待，GPU利用率被死死摁在低位。
生成端為了保持穩定的產出速度，還設計了一個"補位規則"：一條軌跡一完成，它占用的生成名額立刻空出來，新的任務馬上補上，而不是非要等整組任務全部完成才補位。這個"按條補位"是全異步模式下的默認策略，能讓並發生成的軌跡數量始終貼近上限，即便軌跡長度相差一個數量級也不受影響。
生成完的軌跡放進一個有容量上限的數據緩衝區里，等訓練器來取。這個緩衝區還承擔了一個重要職責：判斷一條軌跡是不是"過期"了。
新鮮度*（Staleness）：指一條軌跡是用多久之前的模型權重生成的。如果軌跡在緩衝區里等了太久，訓練器已經更新了好幾輪權重，這條軌跡相對當前的模型就"過時"了，用它來算梯度可能會產生誤導。
Miles的定義很保守，只要軌跡里有任何一個token是用最舊的權重生成的，整條軌跡的新鮮度就按這個最舊的算，絕不高估軌跡的"新鮮程度"。緩衝區還會實時上報隊列長度、平均新鮮度等一堆指標，讓人一眼就能看出到底是生成端跟不上，還是訓練端在空等。
**多輪對話里，怎麼保證模型看到的和生成時一模一樣**
這是整篇論文裡我覺得特別值得展開講的一個設計，叫token級精確記錄（TITO，Token-In-Token-Out）。
問題出在哪呢。一般的多輪對話流程是這樣的：模型生成一段文字，這段文字經過消息解析、工具調用、模板渲染，才變成下一輪的輸入。這中間每一步都有可能悄悄改變分詞方式，比如把工具調用的參數重新序列化了一下，或者省略了推理過程的某些內容。這些變化通常不會報錯，但它們會導致訓練器最後看到的token序列，和模型實際採樣出來的token序列不是同一個東西。
這就像你錄了一段語音備忘錄，結果轉寫軟體在轉文字的時候，自己悄悄改了幾個詞、刪了幾句話，你以為自己說的是A，系統記錄下來的卻是經過"美化"的B。等你之後根據這份文字記錄去復盤自己當時的思路，復盤的其實是從來沒發生過的對話。如果不精確記錄原始token，訓練器算出來的每一步概率，都是針對一個"從未真實存在過"的軌跡在計算，梯度更新自然是錯的，而且這種錯誤是無聲無息的。
Miles的解法是讓"會話伺服器"這個組件全權接管分詞工作，而不是任由外部框架各自為政。第一輪對話時，伺服器把消息渲染成token；每完成一輪，就把這輪的輸入token、輸出token、每個token的概率還有專家路由結果全部存成一個"檢查點"；後面每一輪，只需要在這個檢查點基礎上，對新增的部分做增量分詞。這樣最終拼出來的整條軌跡，是一份完全精確的、和實際推理過程逐字對應的記錄。
針對不同的智能體框架，Miles還設計了兩種延伸歷史的規則，線性和分支。線性適合那種嚴格按順序往前走的對話，一個會話只產生一條訓練序列；分支則允許歷史記錄長成一棵樹，適應像Claude Code這類會自己"摺疊"或"分叉"上下文的智能體框架，一個會話可以產生多條訓練軌跡。
**混合專家模型里的路由漂移問題**
這是個非常有意思的細節。在MoE模型里，每個token要被送到哪幾個"專家"模組去處理，是由一個評分函數決定的，選分數最高的幾個。問題是，如果生成引擎和訓練引擎用的計算精度、算子實現有一丁點差異，同一個token在兩邊可能會被路由到不同的專家上。
假設生成時某個token被送去了2號和7號專家，但訓練時因為精度差異，同一個token被路由到了2號和8號專家。這時候，訓練更新打在了8號專家身上，但真正處理過這個token、需要被糾正的其實是7號專家，它卻什麼都沒學到。論文裡提到，這種路由錯位如果任其發展，會在成千上萬步的訓練中不斷累積，甚至導致訓練徹底崩潰。
Miles的解決辦法叫R3*（Rollout Routing Replay，生成路由重放）：把生成階段記錄下來的專家路由結果，當作數據的一部分保存下來，訓練時直接照搬這個路由結果，不再重新計算。
這就好比考試時老師已經把每道題該找哪位閱卷老師批改都標註好了，閱卷老師直接按標註去改，而不是自己重新判斷這道題該歸誰管，從根本上杜絕了張冠李戴的可能。當然，這個方案不是沒有代價的，每條軌跡的路由資訊本身要占用不少儲存空間，一個3.2萬token的長序列，60層網路，每層選8個專家，光路由數據就要占大約60MB，而且這個開銷會隨著序列長度線性增長。
**訓練端怎麼把萬億參數塞進有限的顯存里**
這一部分講的是Miles在低精度訓練和內存管理上的功夫。
先說精度。GPU的算力會隨著數值精度降低而翻倍提升，從16位浮點到8位再到4位。但強化學習訓練里，如果生成端和訓練端用不同的量化方式計算同一份權重，兩邊算出來的結果會一層一層地累積誤差，最終導致災難性的訓練崩潰。
Miles的應對策略是建立"精度契約"：生成和訓練必須用完全一樣的量化邏輯。目前跑通的格式有三種，FP8分塊量化已經比較成熟，MXFP8和NVFP4還處於測試階段。這裡有個細節挺有意思，NVFP4這種格式要求"誰碰權重誰就必須量化"，所以不能出現訓練器留在BF16精度、但生成引擎用NVFP4的搭配，這種組合是不被支持的。
再說內存。一個超大模型的優化器狀態（也就是訓練過程中用來記錄每個參數歷史更新趨勢的額外數據）往往比模型本身占用的顯存還多。Miles設計了兩套內存釋放機制：一套是訓練間隙把整個訓練進程的狀態挪到GPU之外，給同一批GPU上的生成引擎騰地方；另一套是把優化器狀態乾脆存到硬碟上，需要更新哪部分參數就臨時加載對應的那一小塊回顯存，用完立刻釋放。
這就像你搬家時，如果家裡東西太多塞不下，一種辦法是暫時把所有家具搬到樓道里給裝修騰地方，裝修完再搬回來；另一種辦法是把不常用的東西直接存進附近的倉庫，需要用的時候再去取。論文裡提到，在Qwen3-30B-A3B這個模型上，用了硬碟流式加載優化器狀態後，訓練進程的暫停時間從24秒縮短到5.2秒，恢復時間從8.9秒縮短到1.3秒，效果相當直觀。
在案例研究中，那台跑GLM-5.2的64卡集群，實際上正是靠著這套硬碟流式方案，才把一個每個數據並行副本要占279GB顯存的優化器狀態給塞進了GPU里，這個數字本身就已經超過了單張GPU的顯存容量，硬碟流式在這裡不是錦上添花，而是"不這樣做根本跑不起來"的剛需。
**權重從訓練器傳到生成引擎，怎麼傳得又快又穩**
每次訓練更新完權重，都得把新權重同步給正在生成的引擎，這個過程如果處理不好，會變成整條流水線里最大的堵點。論文裡給了一個很直觀的數字：Kimi K2這個1萬億參數的模型，用最普通的廣播方式同步一次權重，要花將近一分鐘。
Miles準備了三種傳輸方式。默認的廣播方式，是用NCCL*（NVIDIA的一套GPU間通信加速庫）：讓多張GPU卡之間能夠高速交換數據的底層通信協議。
把權重一次性發給所有生成引擎，簡單可靠，但當訓練集群和生成集群規模都很大時，會成為瓶頸，因為每個發送方都要把完整數據發給每一個接收方，哪怕對方根本用不上那部分權重。
第二種是點對點傳輸，讓多個訓練節點同時直接往生成節點的顯存里寫數據，用的是RDMA*（遠程直接內存訪問，一種繞過CPU直接在兩台機器的內存間傳輸數據的技術）。
這種方式的效率提升非常驚人：在16節點對16節點的GLM-5模型上，廣播要58.3秒，點對點只要8.48秒，降幅85.5%；Kimi K2上更誇張，從53.28秒降到7.23秒。但論文也誠實地指出了這個方案的短板，在單機部署時點對點反而比廣播慢了將近70%，因為單機場景下沒有額外的聚合頻寬可用，點對點還要額外承擔主機端權重重排和內存暫存的開銷。這提醒我們，沒有一種傳輸方式是萬能的，取決於你的集群到底是"又寬又扁"還是"又窄又深"。
第三種是磁盤增量更新，這個思路挺巧妙的：連續兩步訓練之間，模型權重變化的字節數往往只占很小一部分，那與其每次都把整個模型重新傳一遍，不如只把變化的部分寫到一個大家都能訪問的共享文件系統里，各個生成節點自己去讀取增量、打補丁。這種方式不需要訓練端和生成端之間有直接的網路通道，只要有個共享文件系統就行，非常適合那些物理上分離、沒有專用高速網路連接兩邊的部署場景。
**除了強化學習，Miles還能做什麼**
Miles並沒有把自己局限在"標準強化學習"這一件事上，它把生成引擎、訓練器和權重同步這三大件當作可以自由組合的積木，搭出了另外幾種訓練範式。
低秩適配強化學習*（LoRA RL）：不更新模型的全部參數，而是凍結原始權重，只訓練一小對低秩矩陣作為"補丁"疊加在原模型上。
這樣做的好處立竿見影：優化器狀態只需要覆蓋這一小撮新增參數，每一步訓練算得更快，權重同步時也只需要傳輸這一小部分補丁，而不是整個模型。論文提到，Kimi K3和2.4萬億參數的Qwen3.8這兩個模型，發布當天能立刻用上強化學習訓練，靠的正是LoRA，因為完整參數微調這麼大的模型，根本塞不進現有集群。
另一個很有意思的方向是在線蒸餾（On-Policy Distillation）。傳統蒸餾是讓學生模型去模仿老師寫好的文字，但學生自己幾乎不會主動生成那樣的文字，學習效果打折扣。在線蒸餾反過來做：讓學生自己生成，然後拿老師模型去給學生生成的每一個token評分，看看老師覺得這個token出現的概率有多高，學生和老師評分的差異就成了訓練信號。
這就好比學寫作文，與其讓學生反覆抄一篇範文，不如讓學生自己寫一篇，再請一位經驗豐富的老師逐句點評"這句話你寫得比我更自信，但其實這裡應該更謹慎一點"，這種基於學生自己產出的反饋，往往比單純模仿更有針對性。論文裡給了一個具體例子：Qwen3.5-35B-A3B模型經過五步蒸餾訓練後，回答長度從14070個token壓縮到6132個token，減少了56%，而準確率幾乎沒有變化（84.0%到85.2%，這個差距在統計誤差範圍內）。也就是說，模型學會了用更少的話說清楚同樣的事，這本身就是一種進步，儘管論文很誠實地沒有誇大成"準確率提升"。
還有一種叫"真正的同策略對齊"（True-On-Policy Alignment），這個設計的野心更大：讓生成引擎和訓練器對同一個token算出的概率完全一模一樣，一個比特都不差。要做到這一點，得把兩邊用的注意力計算方式、矩陣乘法核心，甚至隨機性來源全部鎖死到位。這個方案目前只在Qwen3的0.6B和4B這兩個較小的模型上驗證過，代價是犧牲了一部分推理速度，畢竟為了追求"絕對確定性"，很多原本能加速的優化手段都得關掉。
**這套系統跑起來到底什麼樣：GLM-5.2的真實案例**
論文最後給出了一個完整的實測案例，非常有參考價值。64塊GB300 GPU，一半做生成一半做訓練，訓練GLM-5.2這個744B總參數、40B激活參數的模型，任務是在真實的終端環境裡完成編程任務。
訓練這邊把32塊GPU按張量並行、流水線並行、上下文並行、專家並行四個維度切分，用盡了所有能用的並行手段。生成這邊跑著FP8精度的模型副本，配合多token預測技術，一次前向傳播能吐出不止一個token，加快生成速度。
實測結果里有幾個數字值得記一下。前30步訓練的中位數耗時是263秒，第一步因為要做各種初始化和預熱，花了1042秒，這個數字被單獨排除在中位數統計之外，是合理的處理方式。訓練和生成之間的對數概率偏差，平均值是0.0369，這個數字雖然不是零，但被截斷式重要性採樣這個糾偏機制穩穩地兜住了。原始任務獎勵的九步滑動平均，從0.438爬升到0.556，論文很謹慎地說，單次實驗沒法把這個提升和隨機波動完全區分開，所以只當作一個觀察結果來報告，而不是一個確鑿的結論。這種謹慎的表達方式，其實比誇大其詞的宣傳更值得信任。
論文還提到一點很實在的工程細節：整個系統在緩衝區隊列長度、專家路由重放開銷、權重傳輸耗時這些環節上都做了詳細的可觀測性設計，出了問題能快速定位到底是生成慢了還是訓練慢了，而不是像個黑箱一樣，出問題了只能幹瞪眼。
寫在後面
讀完這篇論文，最讓我意外的其實不是某個具體的算法創新，而是它把強化學習訓練大模型這件事,從"研究實驗"的語境徹底搬到了"生產系統"的語境。研究論文裡常見的表述是"我們的方法在某個數據集上取得了最優結果"，但Miles這篇論文裡反覆出現的卻是"這個功能目前處於測試階段""這個路徑只覆蓋某幾個模型家族""這個結論的置信度不夠，我們只作為觀察報告"。這種克制感在工程系統的文檔里其實挺少見的,大多數系統宣傳都傾向於把能用的場景說滿,把不能用的場景模糊帶過。
另一個讓我反覆琢磨的細節是那個"路由重放"的設計。混合專家模型的路由機制本來是為了省算力而設計的巧思，結果在強化學習訓練里反倒成了一個容易被忽視的坑，稍不注意就會讓訓練悄無聲息地跑偏。這提醒我一件事：一個系統里某個模組的"優點"，放到另一個應用場景里，完全可能變成"隱患"，工程設計從來不是孤立地評判一個模組好不好，而是要看它和整個系統其它部分之間會不會產生意想不到的化學反應。
論文裡沒有解決的問題也挺明確的：視覺語言模型目前還接不進這套精確的token記錄系統，量化格式還在往4位精度的邊界摸索，點對點權重傳輸目前只支持幾個特定的模型家族。這些"未完成"的部分，某種程度上比"已完成"的部分更真實地反映了這個領域現在所處的位置：不是已經解決了所有問題，而是剛剛把最難啃的幾塊骨頭啃下來，剩下的還有很長的路要走。
那麼下一次，當你在新聞里看到某個千億或萬億參數的模型又完成了一輪強化學習訓練，不妨想一想，在那句簡短的公告背後，可能藏著幾十個像"路由重放""磁盤增量更新""會話伺服器"這樣毫不起眼卻缺一不可的工程細節，正是它們撐住了那個看起來輕描淡寫的"訓練完成"四個字。
Q&A
Q1：Miles是什麼系統，主要用來做什麼？
A：Miles是RadixArk開發的一套面向生產環境的大模型強化學習後訓練系統，用於解決超大模型（如萬億參數混合專家模型）在做多輪智能體強化學習訓練時的效率和數值一致性問題，支持全異步調度、多種精度格式和三種權重同步方式。
Q2：Miles為什麼要設計token級精確記錄（TITO）機制？
A：因為傳統多輪對話流程中，消息解析、工具調用、模板渲染等環節會悄悄改變分詞結果，導致訓練器看到的token和模型實際生成的不一致，進而讓梯度更新對著一個從未真實發生的軌跡計算，TITO通過讓會話伺服器統一控制分詞來避免這個問題。
Q3：GLM-5.2案例里用了多少GPU，訓練效果如何？
A：案例使用64塊NVIDIA GB300 GPU，一半用於生成一半用於訓練，前30步訓練中位耗時263秒，訓練與生成間的概率偏差平均0.0369，任務獎勵九步滑動平均從0.438升至0.556，但論文說明單次實驗無法排除隨機波動。
