這支影片在講：把 RL rollout 放進任何有 GPU 的資料中心
訓練叢集不必再搬著數百 GB checkpoint 跟著 rollout 走。Modal 的 Stitch 利用低精度服務權重「多數 step 根本不變」的現象，改傳可重建的無失真 patch，讓異地 GPU 也能加入同一支 rollout fleet。
GPU 在哪裡，rollout 就得去哪裡？
訓練需要高速互連與 all-reduce；rollout 只需要取得正確模型版本，卻常被 checkpoint 跨區傳輸綁死。
梯度密，不代表服務權重常變
99% 參數可有非零梯度，但 BF16 顯示值會被有限精度吸收；可見的權重變更少於 1%。
傳 lossless patch，不傳 checkpoint
trainer 留在「cathedral」，可移動的 rollout islands 則散到不同區域與供應商，透過 sidecar 對齊版本。
這個架構為何值得注意
把同步瓶頸拆成三個可驗證的事實
完整 checkpoint 是錯的同步單位
500 GB 檔案送到另一區域要數分鐘到數小時，任何希望「幾秒內換權重」的 rollout loop 都會被網路壓垮。真正需要的是 rollout engine 所見版本的變化集合。
關鍵不是 gradient sparsity，而是 Adam absorption
梯度與 FP32 master update 都是密的；但典型 RL post-training Adam step 約 3×10⁻⁶，遠小於 BF16 的 rounding 門檻。master weight 在移動，BF16 served value 卻沒有跨過下一格。
能移動的是 rollout island，不是訓練叢集
訓練仍留在有高速網路的 cluster；sidecar 讓各種 engine 知道版本、取得 patch 並重建 bitwise-identical weights，分散的推論 GPU 因而可被編成一個彈性 fleet。
影片章節：從限制到 Stitch
拆解訓練、rollout、更新與評估各自需要什麼，以及哪些工作可離開訓練 cluster。
提出「少於 1% 權重會變」的假設，並用量化門檻與 Adam step 解釋 absorption。
說明 patch 不是近似 delta，而是重建相同服務權重；FP8、NVFP4 與 group-scaled formats 會讓稀疏變化更明顯。
以版本公告板與 engine-aware sidecar 串起分散 rollout islands，最後延伸到 Muon 與 fully async RL 的開放問題。