核心概念

非同步強化學習（Async RL）訓練流程中存在一個根本性的工程瓶頸：每個訓練步驟，訓練器必須將完整模型權重傳輸給推理引擎（vLLM）以產生新的 rollout。對於 7B 模型（bf16 格式 = 14 GB），這已相當可觀；而對 1T 參數模型，每步傳輸成本高達 1 TB，全程都是推理停機等待。

Hugging Face TRL 團隊在 2026 年 5 月提出 Delta Weight Sync 方案，從數學基礎出發徹底解決這個問題。

bf16 稀疏性的算術保證

核心洞見來自 bf16 浮點數的精度特性：bf16 只有 7 個尾數位元，相鄰值間距約為 |w|/128。RL 訓練通常使用極小的學習率（η ≈ 3×10⁻⁶），配合 Adam 優化器的 momentum 平滑後，每步的實際參數更新量往往低於 bf16 的可見閾值（約 10⁻⁵ ~ 10⁻⁴）。

結果：大多數參數的 bf16 位元表示在相鄰步驟間完全不變。Fireworks、Cursor 及 PULSE 論文的測量結果一致：跨 Qwen2.5、Llama-3.2、Gemma-3 等主流模型，平均稀疏度達 99%，最壞情況不低於 98%，且標準差僅 0.2~0.4%（400 步內）。這不是巧合，而是低學習率與 bf16 截斷行為的算術結果。

HF Bucket 作為傳輸通道

傳統做法透過 NCCL 廣播整個模型，需要訓練器與推理服務器在同一集群。TRL 的解法引入 Hugging Face Bucket——基於 Xet 內容定址儲存（CAS）的新型 Hub repo 類型，支援高頻上傳、無 commit 儀式、自動內容去重。

架構從點對點通信改為三箱模型：

  • 訓練器 → 上傳 delta 到 bucket
  • vLLM 推理服務 ← 從 bucket 下載並應用 delta
  • 兩端從不直接交換 IP，只交換一個小型 JSON：{"repo_id": ..., "filename": ...}

這讓訓練器與推理服務器可以在不同雲、不同網段、甚至不同國家運行，無需配置 VPN 或開放端口。

兩種檔案格式

系統用 safetensors 格式儲存兩種檔案：

Anchors（完整快照，每 N 步一次，預設 N=10）：記錄完整模型，作為後續 delta 的重建基礎。

Deltas（稀疏補丁，每步間隔）：只記錄改變元素的位置（indices, int32）與新值（values, bf16）。對於 99% 稀疏度的模型，Qwen3-0.6B 的每步 payload 從 1.2 GB 縮減至 20-35 MB，縮減 34-60 倍。

停機時間的分離

以往整個同步時間（例如 9.4 秒）全部是推理停機等待。Delta Sync 將過程拆解：

  1. 上傳 delta 到 bucket（推理繼續運行）
  2. 短暫暫停 vLLM，發送 bucket 座標
  3. vLLM 下載並應用 delta，立即恢復

實測數據：同樣的 9.4 秒總時間，推理實際停機只有 1.1 秒，其餘 8.3 秒是後台上傳，推理同步進行。

關鍵要點

  • 大模型收益更顯著：Llama-3.1-405B（bf16 = 810 GB），使用 NCCL 需廣播 810 GB（8 秒停機）；Delta Sync 每步只有約 6 GB，停機壓縮至 2 秒。1T 模型推估 delta 約 15 GB（原始 1024 GB），縮減 65 倍。

  • BF16ChangeDetector：訓練器側透過 optimizer pre/post hooks 自動偵測哪些參數位元改變，不需修改訓練主迴圈邏輯，CPU 端保留一份 bf16 snapshot 用於比對。

  • vLLM 30 行擴展：推理側實作 DeltaWeightTransferEngine，以 --worker-extension-cls 接入，不需 fork vLLM 原始碼。

  • 多副本推理零額外成本：多個 vLLM 實例從同一 bucket 下載相同 delta，Xet 的 CDN 邊緣快取自動去重，適合大規模 rollout 採樣場景。

  • 可調試的線路格式：safetensors 是標準格式，可用 safe_open() 直接檢查 delta 的稀疏度與變化參數清單，有別於 NCCL 的不透明二進制流。

實務應用

最低門檻的 Async RL：單 GPU + Hugging Face 帳號即可完成分離式訓練。訓練器在本地，vLLM 推理在 HF Space（L4 GPU），環境在另一個 Space，全部透過 Hub bucket 協調，無需開放任何端口或配置集群網路。

前沿規模的可行性：Fireworks 報告中提到 1T 模型的分散式 RL 訓練原本需要 RDMA fabric 才能完成每步的權重廣播；Delta Sync 將此需求降至普通物件存儲即可處理。

與現有庫的定位：根據 HF 對 16 個開源 RL 庫的調查，NCCL + Bucketing 是目前最常見的重量同步方案，而 Delta Sync 是針對全參數訓練場景的下一步優化。使用 LoRA 的場景可用 adapter-only sync 達到類似效果（adapter < 50 MB，同步時間 < 1 ms）。

相關頁面：vLLM V0 升級 V1：強化學習訓練的後端正確性優先原則、非同步連續批次推論：LLM 推論的 CPU/GPU 並行加速、AWS 基礎模型訓練與推論四層架構、LLM推理驅動的太空船姿態控制：GRPO強化學習框架

延伸觀點

Weight Sync 是 Async RL 的核心瓶頸，業界已有多條平行解法正在收斂。Hugging Face 對 16 個開源 RL 訓練庫（verl、SkyRL、NeMo-RL、PRIME-RL 等）的全面調查顯示，所有庫都遭遇相同的基本問題：生成 rollout 主導 wall-clock 時間，訓練 GPU 閒置。解法方向有三條：（1）Delta/稀疏 sync（本文方案）；（2）LoRA adapter-only sync（8 / 16 庫採用，adapter < 50 MB，sync 時間 < 1 ms）；（3）NCCL + bucketing 雙緩衝（verl 的實作，停機壓縮至 20 ms）。

PULSE 論文（arxiv 2602.03839）從理論層面驗證了 99% 稀疏性的普遍性。PULSE 進一步將相同原理擴展至分散式多訓練器之間的 DiLoCo 風格 FP32 偽梯度同步（PULSELoCo），實現 17 倍通信量縮減，表明稀疏性不只是訓練器→推理方向的特權，多訓練器協調也適用。

待解問題：MoE 路由一致性。兩份資料均未提到 MoE 模型的特殊挑戰，但 HF 調查指出 DeepSeek-V3.2 發現推理（vLLM）與訓練（Megatron）的 expert routing 浮點差異會導致不同專家激活子集，delta weight sync 傳輸的是 bf16 快照差異，不攜帶路由遮罩資訊——這是當前方案的一個未解邊界案例。

反向連結

以下頁面引用了本頁：