為什麼 AI 需要新型態的超級電腦網路 — OpenAI Podcast 第 18 集（第 2/3 段） ☕ Buy me a coffee

🧑‍🏫 這段在講 OpenAI 用大量 GPU 訓練模型時，機器之間的網路為什麼一直出狀況，以及他們用 MRC 讓網路自己避開塞車和故障。看完你會懂：新模型推出得快不快，不只看演算法，也要看資料中心裡的網路穩不穩。

• 12:33 系統越大，在相同設備成本下故障間隔越短。規模大到一個程度時，會因為太常故障，使大型同步工作負載完全做不了事，所以必須改變做法。
  ↳ 訓練模型是一種「大型同步工作」：所有晶片要一起算，只要一處壞掉，大家都得停下來。機器越多，壞的次數就越多。大到某個程度，還沒算完又壞了，工作就根本做不下去。
• 12:33 簡單的算法：如果故障彼此獨立，系統規模加倍，故障之間的平均時間就減半。
  ↳ 「平均故障間隔」就是平均多久會壞一次。如果零件各壞各的，機器多一倍，出事的機會也多一倍，所以兩次故障之間的時間就少一半。
• 13:04 每顆 GPU 對應數十甚至上百個網路元件。例如一顆 GPU 接一張網卡，光收發器內約 4 顆雷射，另一端又 4 顆，所以連到第一跳交換器時雷射數量就比 GPU 多一個數量級。
  ↳ GPU 靠網卡連上網路。網卡裡的光收發器用雷射把訊號轉成光，兩端各有約 4 顆雷射。連到第一台交換器（負責轉送資料的設備）時，雷射數量就已經比 GPU 多十倍左右。
• 13:34 再加上多層交換，網路元件數量會比網路邊緣多出好幾個數量級。
  ↳ 資料通常要經過好幾層交換器才會到目的地，每多一層，零件就再多好幾倍。所以整個網路的零件數，最後會比 GPU 多上百甚至上千倍。
• 13:34 因為需要大量頻寬，網路不能縮減元件，否則 GPU 會吃不到資料而閒置，浪費時間、金錢和能源，模型也會訓練得更慢。
  ↳ 那能不能少裝一點？不行。AI 訓練需要很大的傳輸量（頻寬），網路一縮水，GPU 就等不到資料、只能空轉。這等於白白燒錢燒電，模型也會練得更慢。
• 14:05 他們蓋了非常大的網路，同一棟建築內有數百萬條光纖連結。
  ↳ 規模有多誇張：光是一棟建築裡，傳資料用的光纖連線就有幾百萬條，每一條都可能出問題。
• 14:05 主持人提到：過去使用者用雲端服務時，可能只跟一台伺服器溝通；現在資料中心內部電腦彼此溝通的量，跟幾年前相比大不相同。
  ↳ 以前你用雲端服務，多半只是你的電腦跟某一台伺服器來回傳資料。現在資料中心裡面，機器彼此之間的溝通量，已經跟幾年前完全不是同一個等級。
• 14:38 2017 年光通訊研討會 OFC 上，一位 Facebook 講者展示：資料中心內部流量爆炸成長，送給終端使用者的流量卻持平。這發生在 GPU 叢集和 AI 之前。
  ↳ OFC 是光通訊領域的研討會。2017 年有 Facebook 講者指出：資料中心內部機器互傳的量暴增，送到使用者手上的量卻沒變。而且這還是 AI 叢集出現之前的事。
• 15:08 AI 把過去既有的系統挑戰全部放大到「11」。
  ↳ 意思是這些網路難題本來就存在，AI 只是把它們全部開到最大。以前還能忍的小毛病，現在都變成大問題。
• 15:08 為了處理這些問題，他們開發了 Multipath Reliable Connection（MRC），核心想法是管理網路中的壅塞，並把幾個技術組合起來。
  ↳ 所以他們做了 MRC（多路徑可靠連線）。它主要處理網路壅塞（congestion），也就是資料擠在同一處、排隊排到滿出來而掉資料。做法是把幾種技術組合起來用。
• 15:38 第一部分：把封包分散送到很多條路徑，讓各路徑負載很平均。再搭配容量足夠的網路拓撲，就不會產生熱點。
  ↳ 第一招：資料會拆成一小包一小包傳送（封包），MRC 把封包分散到很多條路上，讓每條路負擔差不多。只要網路結構的容量夠大，就不會有哪一段特別擠（熱點）。
• 15:38 這樣做之後，唯一會壅塞的地方是多個來源同時送往同一個目的地。
  ↳ 路都分散開之後，唯一還會塞的地方，是很多台機器同時把資料送到同一台，就像一群人同時擠同一個門口。
• 15:38 副作用：封包走不同路徑，抵達時順序會亂掉。一旦發生遺失，很難判斷封包是真的丟了，還是只是亂序、應該繼續等。
  ↳ 缺點是封包走不同路線，到達順序會亂掉。少了一包時，接收端分不出它是真的弄丟了，還是繞遠路晚點才到，也就不知道該請對方補送，還是繼續等。
• 16:08 第二部分是 packet trimming：佇列快滿時，傳統做法是直接丟掉封包，因而產生判斷上的模糊；MRC 改成切掉 payload，只把很小的 header 轉送到目的地。
  ↳ 第二招叫 packet trimming（修剪封包）。排隊快滿時，以前是直接丟掉整個封包；MRC 改成剪掉內容本體（payload），只把很小的標頭（header，像信封上的標籤）送到終點。
• 16:08 目的地收到 header 後可以立刻要求重傳，完全消除「是壅塞遺失還是亂序還在路上」的模糊。
  ↳ 終點收到只剩標頭的封包，就知道「這包在路上被剪了」，可以馬上請對方重送（retransmission），不用再猜是掉了還是遲到。
• 16:38 對終端使用者最大的意義：能更快從 OpenAI 拿到更好、更聰明的模型。
  ↳ 對一般使用者來說，好處很直接：OpenAI 能更快做出更強、更聰明的模型交到你手上。
• 17:08 MRC 加速了研究與部署流程的每個環節。個別使用者不必擔心工作失敗、工作如何排程，或是因為跟別人的工作放在同一個 rack 而影響效能。
  ↳ 從研究到上線，每一步都變快了。研究人員不用擔心工作跑到一半失敗、要怎麼排隊，也不怕跟別人的工作放在同一個機櫃（rack）而互相拖慢。
• 17:08 MRC 讓前沿模型的訓練更快、更可靠，整條流程運轉得更快也更可靠。
  ↳ 前沿模型（frontier models，也就是最頂尖的新一代模型）的訓練因此更快也更穩，從研究到推出的整條流程都變順了。
• 17:43 講者表示，大家可以期待接下來越來越令人興奮的一連串發表。
  ↳ 講者預告接下來會有一連串越來越讓人期待的新發表，但這段沒有說具體是什麼。
• 17:43 MRC 源自過去幾十年的研究。他們並沒有發明全新的東西，而是把別人發明的技術組合成一組功能；為此組成了一個團隊，並在去年終於部署。
  ↳ MRC 不是憑空發明的，而是把過去幾十年別人研究出來的技術挑出來，拼成一整套。他們為此組了一個團隊，去年正式上線。
• 18:18 從第一批硬體到位，到實際跑起來訓練模型、一切正常運作，只花了幾個月。
  ↳ 從第一批硬體送到，到真的開始訓練模型、一切運作正常，只花了幾個月。
• 18:18 結果之一：不再造成前面提到的壅塞。
  ↳ 成果一：前面說的塞車問題不再發生。
• 18:18 結果之二：網路中某處故障時，經過那裡的每條流量可能都受影響，但只影響一點點；在幾個 round trip 時間內就會停用故障連結。
  ↳ 成果二：某段線路壞掉時，經過的流量只會受一點點影響。在幾次資料來回（round trip，送出再收到回覆的時間，非常短）之內，系統就會自動停用那段壞線路。
• 18:48 因此「連結故障拖垮整個網路」的問題消失了。流量從一端網卡到另一端網卡的過程中，會自動避開故障，主持人形容這像 self-annealing。
  ↳ 所以「一條線壞掉拖垮整個網路」的狀況消失了。資料從一端網卡傳到另一端的路上會自己繞開故障，主持人形容這像會自我修復（self-annealing）。
• 18:48 傳統做法：連結斷掉時，一端或兩端的交換器發現後，要告訴所有鄰居，鄰居再告訴它們的鄰居，形成一個分散式系統問題。
  ↳ 傳統上某條線斷了，旁邊的交換器發現後要通知鄰居，鄰居再傳給它們的鄰居。一大群設備得互相協調，這件事本身就很麻煩。
• 19:18 這個問題傳統上用 BGP 解決。BGP 像 gossip protocol，消息可能要經過 5 或 7 跳才傳到遠端交換器，而且有收斂時間。
  ↳ 傳統做法是用 BGP（讓網路設備互相交換路線資訊的協定）。它像傳八卦一樣一台傳一台，可能要傳 5 到 7 次才到遠處，全部同步好還得再等一段時間。
• 19:50 MRC 打破了「需要協調」這件事：每個端點各自很快偵測到某條路徑不能用，就直接停用它。
  ↳ MRC 的做法是乾脆不協調：每台機器自己發現「這條路不通」，就自己不走，不用等別人通知。
• 19:50 這可能違反直覺，因為讓中央權威通知連結斷掉看似比較簡單；但中央權威一般來說也就是單點故障。
  ↳ 聽起來由一個總控中心統一通知比較簡單，但總控中心一壞，整個系統就跟著癱瘓，這叫單點故障。
• 20:20 傳統收斂過程可能要數秒，尾端甚至數十秒；MRC 下每個端點通常在毫秒內就發現並停用該連結。
  ↳ 差多少？傳統做法要等好幾秒，運氣差時要幾十秒；用 MRC，每台機器通常千分之幾秒內就會發現問題並避開。
• 20:20 過去連結一斷，整個工作要停幾秒等網路穩定，這段時間 GPU 都沒在做有用的事；規模越大，這種幾秒的停頓就累積越多。
  ↳ 以前線一斷，整個訓練就得停幾秒等網路穩定，這段時間 GPU 全在空等。機器越多越常斷線，這些幾秒就一直累積成很大的浪費。
• 20:50 他們在資料中心還在興建時就啟用 MRC，硬體到位後幾個月內就開始訓練。
  ↳ 他們在資料中心還沒蓋完時就啟用了 MRC，硬體一到位，幾個月內就開始訓練模型。
• 20:50 興建資料中心需要大量人工，例如某個 data hall 的光纖進來時，技術人員正在組裝另一個 data hall，所以連結頻繁上上下下，遠比自然故障頻繁。
  ↳ 蓋資料中心要大量人力。一個機房區（data hall）在接光纖時，另一區還在組裝，線路一直通了又斷，比平常自然故障頻繁得多。
• 21:22 但他們完全不在意，甚至沒察覺，因為 MRC 自動偵測「這條路徑不能用」並改走下一條。
  ↳ 但他們完全不受影響，甚至沒發現，因為 MRC 會自己判斷「這條不能走」，直接換下一條。
• 21:54 傳統上網路中仍會跑 routing protocol 來找可用路徑。但 routing protocol、交換器和交換器軟體都很複雜，也都可能故障。
  ↳ 傳統網路會跑路由協定（routing protocol），讓設備自己找出哪些路能走。但這些協定、交換器和交換器上的軟體都很複雜，本身也會壞。
• 21:54 他們發現 MRC 本身就能找出哪些路徑還能用，於是關掉 routing protocol，在最大規模下讓交換器使用完全 static routing；部分路徑壞了也無所謂。
  ↳ 他們發現 MRC 自己就能找出能走的路，於是把路由協定關掉，讓交換器改走固定路線（static routing）。就算有部分路線壞了，也沒關係。
• 22:25 這移除了網路管理中一整套不再需要的複雜度，也不用在意 switch control plane 是否收斂。交換器開機時載入設定，之後路由表永遠不變。
  ↳ 這等於拿掉一整套管理負擔：交換器開機載入設定後，路線表就再也不變，也不用再管交換器的控制系統有沒有同步好。
• 22:25 合作夥伴方面，他們與 Microsoft 合作，由 Microsoft 為他們建造 Fairwater 資料中心。
  ↳ 場地方面，OpenAI 跟微軟合作，由微軟幫他們蓋名為 Fairwater 的資料中心。
• 22:55 他們與 NVIDIA、Broadcom、AMD、Intel 合作標準化這份規格，並一起打造新超級電腦的硬體。
  ↳ 他們也跟 NVIDIA、Broadcom、AMD、Intel 一起把這套規格標準化（訂成各家都能照著做的共同規格），並共同打造新超級電腦的硬體。
• 22:55 主持人指出：外界常把新模型當成每年一次的軟體更新，但每個模型本質上都是研究專案，取決於訓練過程。這種可靠性會是巨大優勢。
  ↳ 大家常以為新模型就像每年固定一次的軟體更新，其實每個模型都是一個研究專案，成果好壞取決於訓練過程。所以訓練穩定，是很大的優勢。
• 23:25 講者提到早期同事的慘痛經驗：經常半夜被叫醒；在餐廳看到網路團隊愁容滿面，因為不知道訓練為何中斷。
  ↳ 講者回憶，以前同事常半夜被叫醒處理問題；在餐廳也常看到網路團隊一臉愁容，因為搞不清楚訓練為什麼又中斷了。
• 23:57 使用 MRC 的叢集獲得一致正面的回饋：非常穩定，研究人員不用再煩惱網路。但統計數據顯示，其實一直有東西在壞，只是沒人察覺。
  ↳ 用上 MRC 的叢集，大家一致說很穩，研究人員不再煩惱網路。但數據顯示其實一直有東西在壞，只是被 MRC 默默處理掉，沒人察覺。
• 23:57 講者表示，由於他們一直在挑戰基礎設施的極限，永遠不可能完全忽略 infra，理想世界裡研究人員不用想這件事，但現實不會如此。
  ↳ 講者也承認，他們一直把基礎設施（infra，機房、硬體、網路這些底層設備）推到極限，所以永遠不可能完全不管它。研究人員完全不用想這件事，只是理想。
• 24:27 講者認為，當研究人員不再提到網路、不需要知道某個叢集用什麼網路協定時，就算贏了；這也移除了持續擴展的關鍵障礙之一。
  ↳ 他認為真正的勝利，是研究人員不再提到網路，甚至不必知道某個叢集用什麼協定。這也拿掉了規模繼續擴大的一大障礙。
• 24:27 講者坦言仍有很多其他東西會壞、還有很多工作要做。但 MRC 讓他們能更快交付更新更好的模型，他們希望在各方面擴展，包括速度。
  ↳ 講者坦白，還有很多別的東西會壞，工作也還很多。但 MRC 讓他們能更快推出更新、更好的模型，他們也希望在各方面繼續擴大，包括速度。
• 25:01 主持人提到：他們決定把這項技術開放給所有人使用。
  ↳ 最後主持人提到，OpenAI 決定把這項技術開放給所有人使用。

根據影片，MRC 中的 packet trimming 在佇列快要溢出時會怎麼做？