Meta Prometheus 是什麼？Muse 訓練叢集的 85% goodput 怎麼讀
Prometheus 是 Meta 在俄亥俄州的 gigawatt 級超級叢集，Muse 與 Muse Wonder 在這裡訓練。本文依 Meta 工程文章整理硬體、跨建築網路、85% goodput 與 47K GPU 小時中斷間隔的條件，並說明哪些數字沒有交代。
訓練大型模型時，只要叢集裡有一台機器出問題，整批 GPU 都可能停下來等它。Meta 在 2026 年 10 月 19 日公開 Prometheus 的工程細節，講的就是怎麼讓幾十萬張 GPU 少停下來。
Prometheus 是 Meta 在俄亥俄州新奧爾巴尼蓋的 gigawatt 級超級叢集。gigawatt 是十億瓦，用來形容整個設施的用電規模。Meta 說 Muse 基礎模型，包含 Muse Wonder，都是在它的第一期訓練出來的。
Meta AI 官方 X 帳號在 10 月 19 日 18:14 UTC 發文，換算成台灣時間是 10 月 20 日凌晨 2:14。我查詢時貼文有 3,886 個讚、約 36.9 萬次瀏覽。
貼文提到預訓練 goodput 超過 85%、強化學習超過 90%，以及約 47K GPU 小時的平均中斷間隔。
goodput 一般指叢集花在有效訓練上的時間比例，被故障、重啟與等待吃掉的部分不算數。85% 看起來不錯，但官方文章沒有寫計算公式，也沒有說那次訓練用了多少張 GPU，所以這個數字只能當作 Meta 的自我描述。
官方文章比貼文有用得多。它交代了硬體世代、跨建築網路、備援機架、容錯機制與每一類故障的對策，也承認早期每天每 8K 張 GPU 接近 1,000 次中斷，花了一年才降低 99%。
我的判斷是，一般讀者可以把它當成一份大型訓練叢集的現場報告，重點是「故障才是主要成本」。從事 AI 基礎設施的工程師，則能直接從備援與故障分類的做法學到東西。想拿這些數字比較不同公司的訓練效率，就要小心，因為口徑不一致。
要讀懂這些數字，得先知道這個叢集長什麼樣子。
Prometheus 是什麼？Meta 的 gigawatt 級訓練叢集長什麼樣
Prometheus 目前由數十萬張 GPU 組成，分散在多棟互相連接的建築裡，包含傳統資料中心、為 AI 設計的新建築與快速部署的臨時結構。官方說它們靠長達數英里的光纖連接，運作起來像一台機器。
Meta 說目前完成的是第一期，完整規模約 100 萬張 GPU。所以「100 萬張」是目標，並非現況，現況只寫「數十萬張」，沒有給出精確數字。
新奧爾巴尼兩年前還是一個處理網站流量的傳統資料中心。Meta 因為硬體、網路與建築設計的進步，把它改成訓練前沿模型的基地。
叢集目前部署兩代 NVIDIA 平台，第三代正要到貨。以下是官方列出的規格。
| 平台 | GPU 型號 | 每 GPU 記憶體 | 官方列出的重點 |
|---|---|---|---|
| Catalina | GB200 NVL72 | 192 GB HBM3e | 72 張 GPU 為一個域，兩個機架約 120 kW |
| Clemente | GB300 NVL72 | 288 GB HBM3e | 單一機架約 135 kW，效能比 GB200 高 5% 到 10% |
| San Miguel | Vera Rubin NVL72 | 288 GB HBM4 | 每機架超過 170 kW，每瓦效能比 GB300 高 10% 到 20% |
NVL72 是把 72 張 GPU 用高速連結接成一個大 GPU 的機架設計。每張 GPU 的記憶體變大，同一個機架能放下的模型資料也變多。
Catalina 用的是 Ariel 版本，每張 GPU 配 2 張 400G 網卡，也就是每張 GPU 有 800G 的對外頻寬。Meta 說這是為了避免 GB200 的運算與記憶體大幅成長之後，網路頻寬變成瓶頸。
Clemente 則因為網卡升級，800G 變成標準配備，GPU 與 CPU 的比例改為 2 比 1，所以 72 張 GPU 能放進單一機架，施工也比較簡單。
這些規格說明，Meta 把「每個機架 72 張 GPU」當成一個配置單位，也當成一個故障單位。這個選擇影響了後面的所有可靠性設計。
延伸閱讀：Meta Muse Wonder 是什麼？主打記憶與長任務，版本、價格和成效一次看懂
硬體清楚之後，才能討論那兩個百分比與 47K 到底在量什麼。
Prometheus 的 85% goodput 與 47K GPU 小時怎麼讀？
官方文章寫的是，Muse Wonder 的預訓練 goodput 超過 85%，強化學習超過 90%，整體平均中斷間隔約 47K GPU 小時。這裡的中斷間隔是牆鐘時間，也就是現實時間，以 GPU 小時為單位表示。
GPU 小時是 GPU 數量乘以時間。我拿 8,000 張 GPU 為例，47K GPU 小時除以 8,000，約 5.9 小時一次中斷，換成每天約 4 次。
這是我依官方單位自行換算，並不代表 Muse Wonder 實際用了 8,000 張。
同一段接著寫，後來的一系列變更，包含韌體修正，把這個數字提高到超過 54K GPU 小時。官方也說，可靠性的目標是每天每 8K 張 GPU 只有 2 次中斷，約等於 100K GPU 小時。
所以 47K 約只有目標的一半，54K 也還有一段距離。這個差距很重要，因為它顯示 Meta 自己也認為目前不算完美，只是比一年前好很多。
另一個數字是中斷率。2025 年中，叢集第一期的中斷率最高接近每天每 8K 張 GPU 1,000 次，官方說現在降低了 99%。
1,000 次降低 99% 約是每天 10 次以下，47K 對應的約 4 次落在這個範圍內，所以兩個數字沒有互相矛盾。
85% 的 goodput 又該怎麼理解？假設一個工作用了 32,768 張 GPU，官方在備援段落用的就是這個規模，那 15% 的損失約等於 4,900 張 GPU 在做白工。
官方另一句說叢集能同時跑多個數萬張 GPU 的工作，所以這個規模不算離譜，但仍是我拿官方規模做的示範，不是 Muse Wonder 的真實用量。
所以 goodput 的價值是把可靠性換算成算力。以 32,768 張的規模計，每提高 1 個百分點約等於多出 330 張 GPU 的有效產能，而不必多買硬體。
但這些數字都缺少對照。官方沒有說明上一代叢集的 goodput，也沒有說別家公司的數字，所以「85% 算高還是低」，讀者只能自己判斷。
讀這類數字時，還要分清楚預訓練與強化學習，因為官方把兩者分開列。強化學習的 90% 比預訓練的 85% 高，但官方沒有解釋原因，所以不能直接說強化學習階段的叢集比較穩。
數字本身只是結果，Meta 怎麼做到的，才是這篇文章最值得讀的部分。
Prometheus 怎麼降低中斷？備援機架、容錯與逐類修故障
先看故障範圍。H100 時代的 NVL8 架構，一個高速連結域只有 8 張 GPU，到了 NVL72 擴大成 72 張，官方說故障影響範圍變成 9 倍。
Meta 的做法是每個 72 張 GPU 的機架只用 64 張，另外 8 張當機架內備援。一張 GPU 壞掉，備援馬上補上，工作從最近一次檢查點重啟，不必等硬體修好，機架也不用離開工作。
整機架故障比較罕見，Meta 另外多留約 2% 的機架備用。以 32,768 張活躍 GPU 的訓練為例，需要 523 個機架、共 37,656 張 GPU，官方寫的是比活躍規模多約 13%。
我用 37,656 減 32,768，再除以 32,768，得到約 14.9%。官方的 13% 應該是以總供應量當分母，用 37,656 除的話剛好是 13.0%。這兩種算法差約兩個百分點，讀者引用時要注意分母。
官方也說，其中 11% 是 64 比 72 的切法造成的，不算額外的可靠性稅。這個 11% 同樣是以總張數為分母，8 除以 72 約 11.1%。因為訓練的平行分組用 2 的次方最有效率，所以一個機架只用 64 張。
故障後怎麼恢復，要看影響範圍。若故障只影響一個資料平行的模型副本，就用 Meta 所說的平行感知容錯，把這個副本下線，其餘叢集重做這一步繼續訓練，壞掉的切片再到備用主機重啟並同步。
故障範圍大於一個副本時，整個工作就退回上一個檢查點。Meta 用差異檢查點與記憶體暫存，讓存檔對訓練速度的影響降到最低。
接下來是逐類修故障。官方把中斷拆成四類，每一類有各自的對策。
NVLink 訊號品質是 GB200 初期的主要瓶頸。叢集有超過 60 萬條 NVLink 連線，只要訊號稍微變差就會觸發恢復。Meta 用持續遙測與自動標記，並在上線前用診斷壓力測試找出弱連線。
記憶體可靠性在 GB300 的大容量下成為重要的中斷來源，涵蓋 HBM 與 LPDDR。Meta 與 NVIDIA 分析故障特徵，用韌體設定、記憶體掃描、改進的錯誤更正與預測性偵測，在裝置變差前就汰換。
NVLink 交換器的單點故障可能拖垮整個 72 張 GPU 域，所以用毫秒級監控與自動隔離。後端網路的鏈路事件，則由骨幹層的硬體偵測與平面式拓撲繞過。
支撐這些做法的是人與流程。Meta 在新奧爾巴尼設有現場分流團隊，3 月做了一次全堆疊的穩定性衝刺，所有修復都要先隔離驗證才能回到運算池。這也是官方文章描述的「歸因式問責」。
延伸閱讀：Meta 聯手 Nvidia ！領先 Google 與微軟，打造未來 AI 基礎建設
可靠性之外，網路與電力同樣決定這個叢集能不能運作。
Prometheus 為什麼不是一棟大樓？跨建築網路、電力與冷卻
訓練需要所有 GPU 同步，所以網路是工作負載的一部分。Meta 除了一般的資料中心網路，還有一張專用的後端乙太網路，讓 GPU 能在建築內與建築之間直接通訊。
在建築內，每個乙太網路交換網最多連接 20,736 張 GPU。初期設計使用排程式交換網，後來因為網卡能在終端重排封包，改成非排程式的版本，用 51.2T 的交換器與動態負載平衡。
建築之間用骨幹聚合網路連接，距離從 2 公里到超過 100 公里。它使用深緩衝的 Arista 交換器，每對區域有數個 Pbps 的頻寬，超過約 10 公里的鏈路用 800G 相干光學。
距離是物理限制。光速決定了延遲，所以官方說，在這種距離下做預訓練，需要與 Meta Superintelligence Labs 一起調整平行設計，避免網路拖慢訓練。
官方 2 月的另一篇文章，補充了建築之間的頻寬設計。
從建築內交換網連到骨幹聚合層的典型超額訂閱比約 4.5 比 1，也就是上行頻寬只有下行總和的約 22%，骨幹層每對區域的頻寬，文中舉例為 16 到 48 Pbps。這和前面把低頻寬需求的流量排在副本之間的設計互相呼應。
這也說明 Prometheus 為什麼不是蓋一棟大樓。官方說，分散式做法讓 Prometheus 能很快建成，代價是要面對各個地點不同的電力與冷卻限制，還要把更多地點連成一個網路。
電力則有另一種挑戰。數萬張 GPU 同步運算與通訊時，用電會在幾秒內出現 30% 到 40% 的波動，啟動或暫停一個大工作，負載可能在幾秒內變動超過數十兆瓦。
Meta 的對策叫 Dynamo Dimmer，叢集接近電力上限時逐步調降 GPU 功率上限，而不是直接停掉工作。機架內有備用電池、電容托盤，設施層級還有電池儲能，並與電力公司協調。
冷卻方面，叢集混用空氣輔助液冷、設施液冷與快速部署結構。最新的 AI 專用建築採用設施液冷，以達到最高的功率密度。官方稱這是異質叢集，不同建築採用不同世代的冷卻設計。
官方也提到，納入合作夥伴的租賃容量，加快了部署時程。所以 Prometheus 不是全部自建，這一點在新聞標題裡不容易看出來。
適合誰讀、不需要讀什麼
適合讀官方文章的，是 AI 基礎設施、資料中心與網路工程師。備援切法、故障分類與歸因流程，都是可以借用的做法，而且附了足夠的數字。
也適合想理解「為什麼訓練大模型這麼貴」的讀者。從這篇文章能看出，成本不只是 GPU 價格，還有備援比例、停機損失與電力管理。
如果你只想知道 Muse Wonder 好不好用，這篇資料幫不上忙，因為它只有一句官方描述，沒有模型效能與價格的數據。那類資訊要看 Meta 的產品與模型發布頁，站內也有另一篇整理。
至於想拿 85% goodput 去和別家公司比較的人，要先確認對方的定義。不同公司可能把備援、檢查點時間與排隊時間算在不同的位置。
Prometheus 數字的限制與沒說的事
這份文章是 Meta 自己的工程部落格，所有數字都是公司自述，沒有第三方稽核。官方也沒有附上資料表，只寫了百分比與倍數。
幾個關鍵數字沒有交代。GPU 精確數量只寫「數十萬張」，完整規模寫「約 100 萬張」，用電量只用 gigawatt 形容，沒有給具體的兆瓦數或投資金額。
goodput 的定義也沒有寫。有效訓練時間的分子、分母，是否包含排隊、備援與重新載入檢查點，文章都沒有說明，所以 85% 沒有辦法換算成成本。
另外，47K 這個數字對應的是 Muse Wonder 的訓練期間，後來提升到 54K 是「之後的變更」，不是同一次訓練的結果。比較時要分清楚是哪個時間點。
文章也強調與 NVIDIA 的共同工程模式，雙方團隊駐在現場、共享遙測並一起分析故障。這種緊密合作有助於修復，但也意味著這些做法不一定能被一般客戶複製。
最後是時間因素。文章寫於 2026 年 10 月 19 日，叢集仍在擴建，Vera Rubin 平台還沒到貨。這些數字是第一期的狀態，之後可能改變。
Prometheus 常見問題
Prometheus 目前有多少張 GPU？
官方文章寫的是數十萬張，完整規模約 100 萬張。我沒有在文中看到更精確的現況數字。
goodput 85% 代表什麼？
代表預訓練期間，約 85% 的叢集時間用在有效訓練上，其餘被故障、重啟與等待吃掉。官方沒有寫計算公式，所以只能作為 Meta 自己的指標。
47K GPU 小時是什麼意思？
這是平均中斷間隔，以牆鐘時間乘上 GPU 數量表示。官方說後來提高到超過 54K，長期目標約 100K。
Muse Wonder 就是在 Prometheus 訓練的嗎？
官方文章與貼文都寫，Muse 基礎模型包含 Muse Wonder，是在 Prometheus 第一期訓練。至於訓練用了多少 GPU 與多久，沒有公布。
看懂 goodput 的口徑，再比較各家訓練叢集
Prometheus 的文章最有價值的地方，是把大型訓練叢集的主要成本講成「故障」，並且拆成備援、容錯、分類修復與電力管理。85% 與 47K 這兩個數字，只是這套做法的結果。
但數字缺少公式、規模與對照，所以不適合直接拿來和別家公司比較。比較有用的做法，是學它如何分類中斷、為什麼 72 張 GPU 的機架要留 8 張備援，再回頭檢視自己的叢集。
想持續追蹤 AI 基礎設施與大型模型訓練的新發展，可以免費訂閱 AI 郵報，也可以回到 Meta 工程部落格核對數字是否更新。
