Google Pathways 正式開放：一個控制程式怎麼協調大型模型訓練？
Pathways 在 GKE 正式開放，解析單一控制、虛擬設備與非同步派送，分清 TPU 適用範圍、Slurm 預覽與大型模型訓練採用條件。
訓練大型模型時，多加晶片不一定能讓工作按比例變快。有些設備忙著計算，另一些卻可能正在等資料、等前一步結束。
Google Cloud 在 2026 年 11 月 10 日宣布 Pathways 於 GKE 正式開放，前一天的開發者文章則說明其單一控制架構，將內部用來協調大型模型工作的系統帶給雲端使用者。
它讓開發者從一個 Python 控制程式描述整份計算工作，再由分散式執行系統處理資料搬移、相依關係與硬體配置。GKE 是 Google 管理容器叢集的服務，在這裡承載相關運算環境。
這項更新處理多組設備與不同程式如何接續，尤其是流水線訓練、產生樣本與模型更新需要重疊的工作。模型演算法是否更好，仍需要另一組品質評估。
如果訓練只是同一份程式在一組設備同步執行，原有方法仍有用途。我的建議是先量清楚協調花了多少時間，再判斷單一控制方式能否處理眼前的瓶頸。
TPU 是 Google 用於機器學習的加速器。有大型 TPU 訓練需求的團隊，可以先畫出設備之間在等什麼。這個等待從哪裡出現，會決定 Pathways 是否解決自己的問題。
大型訓練為何會卡在協調，而不只卡在算力？
當不同步驟需要交換結果，設備即使有空，也可能因資料尚未送到而不能開始。這時晶片的計算能力沒有完全用上，新增硬體也可能只是讓更多設備加入等待。
傳統的大型模型訓練常採單一程式、多份資料的方式，簡稱 SPMD。多顆設備各跑相近程式，處理不同資料區塊，再依固定節奏交換結果，適合工作型態較一致的情境。
資料平行把不同樣本分給設備，模型切分則把同一個模型拆開。它們都能在合適條件下有效擴大訓練，但當不同設備要執行不同程式，協調方式就更複雜。
例如強化學習流程可能先讓模型產生多個答案，再用另一組設備評分，最後把結果交給訓練程序更新參數。產生答案、評分與更新不一定花同樣時間，也未必適合使用相同設備配置。
若各階段只能一個接著一個開始，前一階段忙碌時，後一階段的硬體就可能空著。要讓工作重疊，系統需要知道資料何時產生、哪些步驟可提前準備，以及哪些設備已可使用。
流水線訓練也有類似問題。模型分成數個階段後，輸入要依順序流過各階段，啟動與收尾時會出現空檔。若安排不佳，空檔還會在每次工作裡反覆出現。
因此，協調問題的核心是讓資料相依關係被系統看見。只知道一共有多少晶片，仍不足以決定哪一個步驟何時開始，以及如何縮短前後階段之間的等待。
單一控制程式，實際控制什麼？
控制程式描述計算圖與目標設備，數值運算仍分散在加速器執行。計算圖把工作表示為步驟與連接關係，讓系統知道某個步驟需要前面哪一份結果。
依官方架構說明，開發者從一個 Python 程式定義全域工作，再由其執行系統負責把不同運算派到設備。
圖中的節點可以是已編譯的 SPMD 程式，也就是一組晶片共同執行的計算。節點之間的連線表示傳送的張量，張量是模型用來保存數字的多維陣列，在這裡承載中間結果。
單一控制因此指向「由一處描述整份工作」。大量資料與計算仍在設備之間進行，無需把每一筆數值都先搬回那台 Python 控制機，才轉送到下一顆晶片。
這個分工有助分開開發者需要表達的邏輯，以及系統需要處理的搬移細節。程式可以先描述兩個階段的結果關係，執行系統再安排傳輸與必要的資料重分配。
它也不要求捨棄既有的一組設備同步運算。單一節點內仍可用 SPMD，Pathways 協助的是把多個這樣的計算單位接起來，形成包含不同程式的更大工作。
當程式不直接綁死每一顆實體晶片，資源安排就有機會更靈活。這需要另一個抽象層，把程式眼中的設備，對應到實際可用的硬體。
虛擬設備如何協助共享與故障復原？
程式指向的是邏輯上的設備配置，執行系統再把它對到可用的實體晶片。這種虛擬設備安排，讓計算描述和某一顆晶片的實體位置不必完全綁在一起。
資源管理系統可以掌握哪些設備屬於同一份工作，再安排實際映射。這讓多個客戶端有機會使用長時間運行的共同資源池，不必由每一個短期程式各自管理整座叢集。
開發者文章描述的共享 Pathways 服務，可讓客戶端從筆電或虛擬機器取得需要的 TPU 區組，工作結束後歸還。資源滿載時仍可能等待，共享服務沒有創造無限容量。
故障時，虛擬映射也提供重新安排的基礎。Cloud 正式開放公告說明了彈性訓練與主機快照等方式，讓部分工作有機會使用剩餘區組繼續。
快照保存某一時間點的狀態，復原時可從該狀態接續。但哪些故障能被處理、重新安排需要多久，仍依工作與部署條件而定，不能從可重新映射推論任何錯誤都零停頓。
對長時間訓練而言，復原策略會影響實際成本。正常執行的利用率即使高，若一次故障就丟失大量進度，整段工作仍可能花費更多時間，評估時應一起量測。
映射處理了資源在哪裡，下一個問題是資料何時到達。若每一步都要等前一步結束才開始配置，硬體可用仍未必能立刻工作。
非同步派送如何讓資料搬移和計算重疊？
系統可在上一步計算時，先安排下一步所需的空間與傳輸，減少結果產生後才開始準備的等待。這種提前準備，是把已知的相依關係轉成執行安排。
這套系統使用非同步派送與類似 future 的機制。Future 可以理解為一份稍後才會產生的結果承諾，系統先知道它將被誰使用，便能在數值尚未完成時安排後續。
例如第二個計算需要第一個計算的輸出，系統可以先在接收端保留空間，並排好傳送路徑。第一個計算完成後，資料便可依安排流動，減少臨時啟動下一步的成本。
這和忽略相依關係不同。第二步要用的值仍然必須等第一步產生，提前做的是可先完成的準備，不能把尚未存在的結果當成已經可用。
當計算時間足以涵蓋傳輸與準備，兩者重疊就能減少部分空檔。但如果主要瓶頸是資料量太大、連線太慢，或前後工作幾乎無法重疊，改善幅度就會受到限制。
官方動畫使用示意時程說明這個機制。圖上的區塊與時間讓讀者看見相依關係，並非對任意模型量出的速度保證，不能直接拿動畫比例計算正式訓練加速倍數。
當不同工作都已提前安排，多個設備還需要對執行順序有一致理解。否則彼此都準備溝通，卻選了不同的操作，仍然可能互相等待。
集中排序如何處理流水線與強化學習？
彼此要溝通的操作需要一致排序，否則各設備各自挑工作，可能等不到對方。集中排程能依整份計算圖安排順序，減少不同控制程式各自判斷產生的衝突。
這對集合式通訊特別重要。集合式通訊是一組設備共同交換或彙整資料的操作，例如合併多顆晶片的部分結果，參與者必須對同一項工作達成一致。
若某些設備先做甲操作，另一些先等乙操作，就可能形成難以接續的狀態。讓執行系統協調順序，有助於把程式作者需要自行管理的同步問題往下移。
流水線與強化學習包含不同階段，工作長短也可能變動。整體計算圖能讓系統看見哪些階段已有輸入、哪些可以和其他階段重疊，因此更有條件避免不必要的等待。
這仍需要模型工作被正確描述。集中控制沒有讓錯誤的相依關係自動變正確，也不代表所有阻塞都會消失。它提供的是安排全域執行的能力。
這種執行層協調，和一般叢集工作管理處理的層次不同。分清兩者，才能理解為何原文把這套系統與 Ray 視為可以搭配的工具。
Pathways 和 Ray 為何可以一起用？
Ray 管理較上層的工作與程序，Pathways 處理訓練計算如何跨晶片執行，兩者處理的層次不同。Ray 可以安排 Python 任務或持續運行的工作角色，協調整套應用的生命週期。
在這種分工下，上層框架決定何時啟動資料處理、模型服務或訓練工作，執行中的大型加速器計算，再由 Pathways 安排其資料與設備關係。
因此，採用這套執行架構不等於必須整套移除既有工作管理。團隊應先確認瓶頸發生在啟動程序、分配叢集資源，還是訓練步驟內部等待，才能選對要比較的層次。
正式開放的範圍也需要分清。Cloud 主公告說明 GKE 上的 GA 服務，與 Cluster Director 搭配 Slurm 的整合則仍屬預覽，兩個入口不能使用相同的可用性承諾。
官方列出的正式配置涵蓋 TPU v5e、v5p、v6e 與 TPU 7x，以及相應軟體版本。可用硬體仍以所選服務入口的正式支援清單為準，不同加速器的供應情況需分別確認。
哪些訓練工作值得先做比較？
先挑跨階段等待多、工作不均勻，或故障復原成本高的訓練，較容易看出協調方式的差異。若目前主要問題是模型本身的計算量，改善控制方式未必是最先該做的工作。
Google 報告，Cloud Pathways 在前九十天支援超過一億三千萬 TPU 晶片小時。這是計算資源使用時間的累積，提供已有工作規模的背景，無法當成晶片顆數、客戶數或加速倍數。
自己的比較仍應保留完整步驟耗時、設備利用率、資料傳輸與故障復原紀錄。每一項都對應不同成本，才能判斷少掉的等待是否足以抵銷部署與調整工作。
若使用共享資源池，還要量取得設備的等待時間。執行中的步驟變快，若排隊變長，使用者從送出到拿到成果的總時間仍可能沒有改善。
保留這些紀錄，才能把架構描述轉成自己的採用依據。首次測試不必追求最大的叢集，先找一段可重播、可量出等待的工作，更容易看清新安排帶來哪一項差異。
Pathways 常見問題
單一控制會讓所有資料經過同一台電腦嗎？
控制程式負責描述整體工作，數值運算與資料搬移仍由分散式設備執行。單一控制描述的是工作如何被定義與安排，並不要求所有張量先回到同一台電腦。
正式開放是否包含所有預覽整合？
11 月 10 日 Cloud 公告的 GA 重點是 GKE 路徑，Slurm 相關整合仍標示預覽。選用時應核對自己的入口、TPU 與軟體版本，避免把不同開放階段混在一起。
可以直接依官方示意圖估算節省成本嗎？
示意圖用來解釋資料與運算如何重疊，沒有提供可套用所有工作的費率或加速保證。成本需要以自己的資源用量、排隊與完整工作耗時核算。
若你的訓練已出現跨階段等待，可以從同一份工作比較開始。當利用率、總耗時與復原紀錄都支持改善，再擴大使用範圍，會比只看單一控制架構的新穎程度更有採用依據。
延伸閱讀：Google TPU 8i Max 與 8tx 發表：雙晶片長脈絡、機密推論為何是兩種系統設計？
延伸閱讀：lemonflow 把 Gemma 4 搬上 TPU：充電客服約350毫秒回應，架構改了什麼？
