2026 OCP Global Summit | Microsoft、Marvell、Ranovus | Edi Roytman、Lenin Patra、Jeff Hutchins、Greg Link | Scale-up Optical Reliability and GPU-System Resiliency to Optical Link Flaps
1. 一場由三段供應鏈組成的工作坊
這場是 OCP Future Technologies Symposium 裡 Short Reach Optical Interconnect 的工作坊，主持人 Edi Roytman 投影片上的頭銜是 Marvell 資深傑出工程師（前 Microsoft），三位講者剛好對應鏈路的三段：Marvell 資料中心架構資深副總 Lenin Patra 講晶片與遙測，Ranovus CTO 辦公室總監 Jeff Hutchins 講光模組，Microsoft 負責 Cobalt 與 Maia 產品線韌體架構的 Greg Link 講 GPU 系統端。
我們已經寫過 Oracle 拆 NPO 的 flap 來源、Meta 拿出 LPO 的中斷率數據，這兩篇講的都是光模組會不會 flap。這場問的是下一個問題：flap 一定會發生，GPU 的工作要怎麼活下來。Link 的開場就把定義改掉：「世界上沒有 link flap，只有 link down 和 link up。我偵測不到 flap，我只偵測到斷線，然後希望它會回來。」
成功的指標不是鏈路正常運行時間，而是 AI 工作不中斷地跑完。
2. 拆解規模：再罕見的事件，乘上十萬條 lane 也會變成每小時一次
Marvell 的 Patra 先引用一組 2025 年的業界模型（投影片標「2025 MODEL」）：約 300 萬顆 GPU、超過 1,000 萬條光鏈路，平均每 48 秒發生一次 flap。STT 回推：一小時 75 次，除以 1,000 萬條鏈路，每條鏈路約 7,500 FIT（每十億小時 7,500 次）以下。單條鏈路看起來很穩，問題出在數量。
Microsoft 的表把這件事放到單一 pod 裡算。表格標明「不代表現場數據」，只是掃 Flap-FIT 從 10 到 100 萬、pod 從 16 到 1,024 顆 GPU 的組合。從數字反推，這張表假設每顆 GPU 有 128 條 lane。
▲ Microsoft 掃描 Flap-FIT 與 pod 規模：Flap-FIT 1 萬時，1,024 顆 GPU 的 pod 平均 0.76 小時 flap 一次，半數機率在 30 分鐘內遇到第一次（圖片來源：Microsoft｜2026 OCP Global Summit 簡報（第 28 頁））
Flap-FIT | 128 GPU 的 MTBF | 1,024 GPU 的 MTBF | 1,024 GPU 每日 flap（STT 估算） |
100 | 610 小時 | 76.3 小時 | 約 0.3 次 |
1,000 | 61.0 小時 | 7.63 小時 | 約 3 次 |
10,000 | 6.10 小時 | 0.76 小時 | 約 31 次 |
▲ pod 從 16 顆擴到 1,024 顆 GPU，MTBF 跟著縮小 64 倍；以 Marvell 引用的 2025 業界模型回推約 7,500 FIT 計，千卡 pod 約每小時 flap 一次（圖片來源：Simple Tech Trend 自製，資料來源 Microsoft、Marvell 2026 OCP Global Summit 簡報）
要讓 1,024 顆 GPU 的 pod 一週才 flap 一次，每條 lane 的 Flap-FIT 要壓到約 45（STT 估算）。Link 也提醒，前一場講者引用的 0.1 FIT 很可能是永久性硬體失效率，不是 flap 率，兩者不能混用。光模組品質是必要條件，但光靠它，千卡 pod 的數學算不過來。
3. 拆解 GPU 端：一條 lane 掉了，工作會不會跟著死
為什麼交換器不怕、GPU 怕？Link 的解釋是：AI 工作是一張相依圖，訊息一旦送進某張 NIC，就必須從那張 NIC 送到目的地。NIC 的 lane 斷了、資料卡住，相依圖跑不完，客戶寧可中止，也不願意等一個可能要好幾分鐘才回來的 lane。TCP 的重傳綁死來源與目的端；MRC 雖然能換路徑，但資料已經在那張 NIC 裡，要拉出來換到另一張，等於重寫軟體堆疊。
他用一張 800G、四條 lane 的 NIC 舉例（他說借用 Meta 的 NIC 當教材）：
1x800 模式：一條 lane flap，整個端點失效，工作中止。
4x200 模式：一條 lane flap，降級成 3x200 或 2x200，工作繼續跑。
四條同時 flap：NIC 卡死，只有在能「及時」把流量移到另一張 NIC 時，工作才活得下來。
關鍵在最後一種的機率。若四條 lane 屬於同一個 flap 故障域（同一顆雷射、同一個連接器、同一個光引擎），多 lane 同時 flap「相當常見」；若分散到不同故障域，機率約為 P⁴。
▲ 同一個 800G 端點的三種配置：1x800 一條 lane flap 就中止工作；4x200 同故障域可能整組卡死；4x200 跨故障域時四條同時掉的機率約為 P⁴（圖片來源：Simple Tech Trend 自製，資料來源 Microsoft 2026 OCP Global Summit 簡報）
這和整合趨勢正面衝突。Microsoft 投影片寫得很清楚：從 QSFP、OSFP 走到 32–64 lane 的 OBO、XPO、CPO，每個故障域、每顆雷射、每個連接器上的 lane 都變多。可插拔與板載光學靠板上銅走線打散 lane（swizzle），Link 坦言這個中間階段的佈線交錯最麻煩；到了 CPO，打散改在 SoC 晶粒內完成，他認為某種程度反而更容易，代價是光引擎（E/O）無法單獨更換。
4. 拆解恢復速度：Marvell 把時間尺度寫成五層
Marvell 的回答是 3R：冗餘（獨立資料路徑，目標是工作不中止）、韌性（硬體就地偵測與切換，不等軟體）、可靠度（遙測與機群修復，減少重複 flap）。對應的產品是 RELIANT 遙測，把每一層的恢復時間寫出來：
實體層（PCS 加光 PMD）：即時監看 BER、lane 錯誤、FEC bins、等化器統計
鏈路層重傳：近乎即時重送失敗的交易
鏈路層流量管理：負載平衡、改道、CBFC，1 毫秒以內
應用層：用 shadow state 恢復工作，約 500 毫秒
系統層：機群健康與調度，超過 1 秒
▲ Marvell RELIANT 遙測的五層架構與恢復時間：鏈路層 1 毫秒以內、應用層約 500 毫秒、系統層超過 1 秒（圖片來源：Marvell｜2026 OCP Global Summit 簡報（第 14 頁））
Marvell 另一張表也很誠實：scale-up 光學在距離（20 公尺以上）與每顆 AI SoC 頻寬（每方向 50 Tbps 以上）贏銅，pre-FEC BER（低於 1e-9）與 FEC 延遲（低於 75 ns）打平，flap（目標低於 1% 的鏈路）與現場維修性是劣勢。這和我們在 Marvell 2026 投資人日 看到的 scale-up 光學布局是同一條線，這次補上的是可靠度那一側。
問答時有人直接問：預測性失效喊了幾十年都沒成功，這次有什麼不同？Patra 的回答是在機群與 MCU 上部署小型語言模型，提早抓到雷射功率微幅下降這類訊號。這個說法目前沒有公開的準確率數據。
5. 拆解光模組端：低延遲與低 BER，把 scale-up 推向慢一點的線速
Ranovus 的 Hutchins 從另一端切入。scale-up 走 CBFC 這類流量控制，下一個區塊要等前一個收對才送；重傳太多次超過上限，就變成 link flap。所以要防的不是平均 BER，而是突發錯誤。
他以 3.2e-5 的重傳率上限為例：
乙太網 RS(544,514) FEC、只有隨機錯誤：BER 約 1e-3 就夠
同一種 FEC、只允許 3 個碼字錯誤來留突發餘裕：BER 要約 3e-5
PCIe6 式 CRC 加弱 FEC（延遲較低）：BER 要約 1e-8
▲ Ranovus 的重傳率分析：FEC 越弱、延遲越低，隨機 BER 要求從約 1e-3 收緊到約 1e-8，降速是一條路，OCI-MSA 是近期例子（圖片來源：Ranovus｜2026 OCP Global Summit 簡報（第 22 頁））
推論鏈很清楚：低延遲要弱 FEC，弱 FEC 要低 BER，低 BER 推向較低線速。他點名的例子是 OCI-MSA，我們在 Meta、Broadcom、AMD 聯手定義 OCI 200G 線側規範 拆過這套規格。Hutchins 也列出突發錯誤的七大來源，從機械衝擊、溫度與電源暫態、連接器灰塵與 MPI，到雷射反射與韌體互通；其中一部分能提早偵測，另一部分會突然出現。主持人補充，連接器污染是 flap 的主要原因之一；Hutchins 的看法是，灰塵造成插損突然大幅上升時，接收端就會出問題，他想不到鏈路端有什麼好的補救方式。
6. 風險與反面論點
表格不是現場數據：Microsoft 的 MTBF 表只是假設區間，128 lane／GPU 是 STT 從數字反推；Marvell 的「鏈路」與 Microsoft 的「lane」單位不同，7,500 FIT 只能當量級參考。
冗餘有成本：Link 自己反對某些冗餘，多一張 NIC 就是 25%（四張）到 2.5%（四十張）的閒置效能，要動 3% 的效能／TCO 都需要很強的理由。
200G 初期 flap 較多：問答中台上講者承認第一代 200G 的 flap 比成熟的 100G 多，預期量產後收斂，但沒有給數字。
CPO 可能不是 flap 的解方：CPO 端到端功耗較低、頻寬密度較高，但整合越深，每個故障域、每顆雷射、每個連接器上的 lane 越多，光引擎也無法單獨維修。
7. 對台灣供應鏈的意義
簡報沒有點名任何台廠，以下只談位置，不做公司配對。
主機板與機櫃設計：可插拔與板載光學的 lane 打散靠板上銅走線完成，這是系統 ODM 的設計工作。故障域會變成 scale-up 主機板的新設計規則，不只是光模組廠的問題。
光模組與連接器：Microsoft 列出要向供應商拿的資料，包括雷射與整模組長期可靠度、連接器對灰塵與組裝變異的容忍度、pod 規模 PoC 的 flap 統計。Ranovus 則呼籲把突發錯誤測試方法標準化。交得出這些資料，比單看良率更接近 scale-up 的採購門檻。
8. 總結
這場工作坊把光學 scale-up 的爭論從「光會不會壞」移到「壞了工作會不會停」。以 Microsoft 的算式，千卡 pod 的 flap 間隔是以小時計，光學再進步一個數量級也撐不過一天；能把 flap 變成頻寬損失而不是 job abort 的，是多埠 NIC、跨故障域的 lane 配置、毫秒級的就地切換，以及能告訴系統「這次斷線會持續多久」的遙測。
我們在 2026 OCP APAC Summit｜Broadcom｜CPO 的第三代成績單 看到的是元件端可靠度的進步；這場則提醒，元件數據到位之後，還要通過 GPU 端的故障域與軟體堆疊這一關。
銅線時代，GPU 很少需要學會處理 flap；光學時代必須學會。誰先把這件事做進 NIC 與 XPU，誰就先拿到千卡光學 pod 的門票。
本文僅供技術與產業趨勢分析，不構成任何投資建議。
留言