# 策展 · X (Twitter) 🔥🔥

> 作者：Fireworks AI (@FireworksAI_HQ) · 平台：X (Twitter) · 日期：2026-05-05

> 原始來源：https://x.com/FireworksAI_HQ/status/2051372704301990272

## 中文摘要

前沿RL基礎設施遠比想像中便宜。

傳統RL基礎設施觀念錯誤，正阻礙團隊在最前沿競爭。
本文駁斥「巨型叢集」敘事，強調無需每次更新都傳輸1 TB權重，透過delta壓縮與非同步RL，可利用分散式容量大幅降低成本，讓更多團隊進入前沿RL領域。

**RL基礎設施核心**

RL訓練包含兩個獨立工作：
- 訓練器執行前向傳遞、獎勵計算、反向傳遞與參數更新，需要密集緊密耦合的硬體。
- 滾出現（rollout fleet）從最新策略採樣軌跡，即執行最新模型推論，需要高吞吐量的並行請求處理。

與僅需訓練器的預訓練不同，RL需同時處理兩者，故基礎設施挑戰在於維持滾出現產生足夠新鮮資料，而非僅飽和單一同步訓練任務。

**1 TB權重傳輸迷思**

典型前沿檢查點約1 TB，若每次策略更新皆需完整傳輸至滾出現，則需巨型同位叢集具RDMA級內部網路，將訓練與推論置於同一fabric，避免遠距傳輸，將遠端容量視為次等。

此「巨型叢集」故事讓前沿RL看似僅少數公司可入場，其他團隊在基礎設施經濟上即被排除，尚未比拼演算法或產品執行。

但前提錯誤：無需每次移動完整1 TB。

**關鍵洞見：98%稀疏性利用**

相鄰RL檢查點間，多數權重僅微幅變化，故可傳送相對於前一檢查點的壓縮delta，而非重傳完整1 TB。

去年實證觀察，bf16格式下連續檢查點超過98%權重位元相同，低精度時不變比例更高；原因在於後訓練更新極細粒度，RL提供稀疏訊號（每滾出僅數位元），學習率小，多數參數在fp32僅微動，常未達改變16位元或更低精度表示的門檻。

近期論文《Understanding and Exploiting Weight Update Sparsity for Communication-Efficient Distributed RL》提供理論基礎，實務RL情境稀疏度常達99%。

本文範例中，完整檢查點為1024 GiB，相鄰檢查點平均delta僅20.3 GiB（1.98%），50步驟視窗內跨區傳輸量較全模型傳輸減94%。

節奏為：每N步發布完整基底檢查點，中間傳送壓縮delta，僅變動權重，checksum重建確保滾出叢集從共享儲存無損重建。

此delta壓縮權重更新，讓跨區同步在普通網路連結上實用，無需訓練與滾出推論共享RDMA fabric。

**非同步RL與管線化**

非同步RL（或稱Pipeline RL）明確認換輕微off-policy，換取高效運算；閒置採樣器昂貴，轻微策略陳舊常可接受，以重疊訓練與滾出現。

此權衡需策略更新快速，delta壓縮讓分發新檢查點至全球滾出叢集端到端僅數分鐘，限制off-policy延遲；GPU記憶體權重交換可在1分鐘內，下载與解壓多為管線先行。

訓練器亦管線化：每步上傳更新權重至共享物件儲存，各rank快取前次上傳僅傳差異；上傳分片於訓練GPU，下載分片於推論複本，壓縮、傳輸、訊號化背景管線化，訓練不阻塞。

實務效益：同步時少等檢查點移動，多以更新權重產生滾出，提高吞吐。

**陳舊度（staleness）考量**

非同步運行意味滾出現永遠落後訓練器數步，此差距稱staleness，為真實權衡，需直指。

系統層不消除staleness，演算法須容忍off-policy資料；系統可將差距界定且可預測，delta壓縮將策略移動轉為例行背景作業，而非停機事件。

**多區域名彈性滾出現**

此系統優勢具策略性：多數團隊無閒置完美連續巨叢集，而是容量分散於區域名、雲端、可用區，組裝單一巨型採樣艦隊繁瑣，即便總GPU數足夠。

權重更新小後，碎片容量可用於RL而非閒置；各滾出叢集獨立從相同delta鏈下載重建，無需直連訓練叢集。

Fireworks即以此架構支援Cursor的「Composer 2」訓練，Federico Cassano於X表示：「Composer 2 RL運行分散於全球3（有時4）不同叢集。」

此讓滾出現具彈性：依容量成本增減叢集、重平衡區域名，皆指向同一策略更新流；在Fireworks Virtual Cloud，叢集抽象於單一控制平面，呈現統一容量池，而非使用者個別管理區域部署。

**不適用情境**

此架構非萬能：

- 模型小到訓練與滾出推論舒適置單節點或緊密叢集，頻寬非瓶頸，簡單設定勝出。
- 檢查點發佈頻繁，delta管線未及分發下個更新即失效，staleness限縮，緊密共置更合理。
- 滾出堆疊未清晰分離推論與訓練，將滾出工作者視標準推論艦隊不合，分散設計吸引力減。

對無此限制的前沿規模模型，此為將碎片容量轉高效RL吞吐的實務途徑。

**Fireworks訓練平台**

Fireworks支援三種RL運行：

- 全託管RL：提供資料集與評估器，Fireworks執行訓練器、滾出推論、檢查點與權重更新流程。
- Tinker相容SDK：自訂訓練流程，仍託管GPU密集訓練與推論於Fireworks。
- 自帶訓練器：訓練器留原位，上傳檢查點至共享物件儲存，使用Fireworks作滾出服務與權重更新協調。

自帶訓練器介面仍為標準推論部署，附加RL專屬：

- OpenAI相容採樣端點用於滾出。
- 權重更新API訊號新檢查點可用。
- 更新進度狀態回報。
- 訓練-採樣數值對齊功能，如MoE層返回選定專家實作router replay。
- 權重更新時prompt快取行為細控。

各部署模式共通需求：模型更新小、可驗證、例行化。

巨型共置叢集適合同步預訓練，不意味RL滾出須同居巨叢集；關鍵在系統能否廉價可靠更新分散採樣艦隊，利用所有可用容量。

欲探索，可從Fireworks Training SDK介紹入手，涵蓋Tinker相容控制迴圈、檢查點、權重更新與訓練/採樣流程；欲討論滾出架構或配對Tinker式訓練器與Fireworks滾出，電郵inquiries@fireworks.ai或Discord聯繫。

## 標籤

研究論文, 產業趨勢, 其他, RL