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

🧑‍🏫 這一段講 OpenAI 為什麼把自家 AI 超級電腦的網路規格 MRC 公開給全業界，以及它怎麼讓網路更好擴大、更省電。最後聊到很熱門的「太空資料中心」，受訪者從實際維修和故障的角度說明他為什麼不看好。想知道 AI 背後的機房在煩惱什麼，這段講得很實在。

• 25:05 MRC 規格將透過 OCP 以開放標準釋出，開放給所有人使用
  ↳ MRC 是這集的主角，是 OpenAI 用在 AI 超級電腦上的網路規則。他們會把規格交給 OCP（Open Compute Project，業界公開分享資料中心硬體設計的組織）公開，誰都能用。
• 25:05 受訪者表示他們很相信開放標準與開源，所有網路都建在 Ethernet 這個開放標準上
  ↳ 開放標準就是規格公開、任何廠商都能照著做的規則。Ethernet（乙太網路）是讓裝置之間互相傳資料的通用規則，公司和家裡的網路線都在用。他們的網路全建在它上面。
• 25:05 產業整體前進得夠快、跟得上他們在困難面上的需求時，他們也會受益
  ↳ 他們要的東西很難，光靠自己做不完。整個產業一起進步、做出更好的設備，OpenAI 也能直接買來用，大家都有好處。
• 25:37 受訪者認為，如果大家只為了取得一點小優勢而投資完全不同的技術與硬體，導致供應鏈分裂，會很可惜
  ↳ 供應鏈是從零件到成品的一整串廠商。要是每家為了一點小優勢各搞一套不相容的硬體，廠商就得分頭生產，量少、又貴又慢，最後大家都吃虧。
• 26:07 基礎設施被形容為整個產業「命運共同體」；開源 MRC 也能讓 OpenAI 以外的人受益
  ↳ AI 能走多遠，會卡在底層的機房和網路，這是整個產業共同的難題，所以說是「命運共同體」。把 MRC 公開，其他公司也能拿去用。
• 26:07 主持人舉 Stargate（多地點、全球多個合作夥伴）與 Microsoft Fairwater 為例，說明合作越來越普遍，且算力永遠不夠
  ↳ Stargate 是 OpenAI 在多個地點、跟全球多家夥伴一起蓋資料中心的計畫。Fairwater 是 Microsoft 的資料中心。主持人的意思是：大家越來越常合作，因為運算能力永遠不夠用。
• 26:38 主持人以 Ethernet、World Wide Web 為例，說明共享協定帶來的好處
  ↳ World Wide Web 就是你用瀏覽器看到的網頁系統。它和 Ethernet 一樣，靠大家共用同一套規則（協定），不同廠牌的設備才能互通，整個生態也才長得起來。
• 27:10 受訪者表示這件事本身就夠難了，不該每個人一直重新發明輪子，希望其他人跟他們往同一方向走
  ↳ 替 AI 超級電腦蓋網路本來就很難，每家公司各自從零研究同樣的問題太浪費。他希望大家都往同一套做法走。
• 27:10 MRC 是有彈性的標準，建在 Ethernet 之上；Ethernet 擴展，MRC 也跟著擴展
  ↳ MRC 不綁死特定設備，而是疊在 Ethernet 上面運作。Ethernet 變快、能接的機器變多，MRC 就跟著受惠，不必重做。
• 27:10 Ethernet 是個別裝置彼此溝通的協定，MRC 則在它上一層
  ↳ 可以想成分工：Ethernet 負責讓一台機器和另一台之間傳得了資料。MRC 在它上面一層，管整個網路裡資料怎麼走、出狀況時怎麼辦。
• 27:40 MRC 包含 Mark 提到的 static routing，也包含 congestion control
  ↳ static routing（靜態路由）是事先排好資料要走哪條路，不臨時改。congestion control（壅塞控制）是網路塞車時的應對方式。這兩樣 MRC 都有。
• 27:40 congestion control：遇到連結故障或流量傳送方式造成的狀況時，端點該怎麼反應，讓網路被公平又有效率地使用
  ↳ 線路壞掉或傳法不好造成塞車時，收發資料的兩端（端點）要自己放慢或換路。這樣每個人都分得到頻寬（一次能傳的資料量），網路也不會浪費。
• 28:11 網路有根本極限，光速就是已知的速度上限，光在網路兩點間傳遞的時間有下限
  ↳ 再怎麼改進都有物理上限：訊號跑不贏光速。兩台機器之間有固定距離，資料最少就得花那麼多時間才到，這段時間壓不掉。
• 28:11 每條連結會越來越快，因此每條連線同時在途的資料量會改變，需要持續工程投入，才能用好每一代硬體
  ↳ 線路越快，同一時間「還在路上」的資料就越多，傳送端要管的狀況也跟著變。所以每換一代硬體，都得重新調整，才能把效能用滿。
• 28:11 受訪者認為 MRC 提供有彈性又穩固的基礎，能撐過接下來幾代
  ↳ 他們認為 MRC 的底子夠彈性也夠穩。之後幾代更快的硬體出來，也不用把它整個打掉重來。
• 28:45 Ethernet 已跟 10、20、30、40 年前完全不同，MRC 是藉由全球網路產業的發展，搭上這波創新浪潮
  ↳ 乙太網路幾十年來一直被全球業者改良，速度早就跟當年差很多。MRC 建在它上面，等於直接搭上整個產業持續進步的順風車。
• 28:45 因為 MRC 把智慧放在網路邊緣，只要 Ethernet 持續擴展，網路核心就能跟著擴展；受訪者認為短期內看不出它不再擴展的明顯理由
  ↳ 「邊緣」指網路兩端的機器，「核心」指中間負責轉送的設備。判斷交給兩端處理，中間只要跟著 Ethernet 變快就能擴大。他說目前看不出會撞牆的理由。
• 29:16 關鍵做法是把複雜度移出網路：關掉路由，每個封包改用 source routing 通過網路
  ↳ 路由（routing）是決定資料往哪走，一般由中間設備一站一站判斷。他們關掉這個功能，改用 source routing：出發前就由發送端把整條路線寫進封包（資料切成的小包）。
• 29:16 使用 IPv6 segment routing，每個封包的位址會列出它要經過的確切交換器，因此交換器本身可以很「笨」
  ↳ IPv6 是一種網路位址格式。segment routing 讓封包的地址直接列出要經過哪幾台交換器（switch，負責轉送資料的設備）。交換器照單轉送就好，不用自己判斷。
• 29:46 在追求可靠擴展時，讓網路中段盡可能簡單，受訪者表示這帶來很大的好處
  ↳ 中間的設備越單純，會出錯的地方就越少，規模也更容易放大。他說這種做法在求穩定擴大時幫助很大。
• 29:46 他們還用 Ethernet，是因為它是開放標準、整個產業都採用；受訪者希望 MRC 也能被廣泛採用，讓下一層準備好面對 AI 的系統挑戰
  ↳ 選 Ethernet 是因為它公開、全業界都在用，零件和經驗都多。他們希望 MRC 也變成大家共用的那一層，一起面對 AI 帶來的系統難題。
• 30:16 受訪者認為若 MRC 是 OpenAI 獨占，發展不會這麼好
  ↳ 如果 MRC 只有 OpenAI 自己用，就沒有其他公司幫忙改良、做出支援它的設備，進步的速度和品質都會差很多。
• 30:46 受訪者表示他的角色是把既有資源用到最好；既然要耗電，就要用得有生產力、有效率
  ↳ 他的工作是讓現有的機器和電力發揮最大價值。電反正都要用，重點是每一度電都要換到實際的運算成果。
• 30:46 MRC 能把流量分散到多條路徑，因此可以建出更簡單、更小、裝置少得多的網路
  ↳ 流量（網路上傳的資料量）能同時分散到很多條路上，就不必靠一層又一層的設備去疏導。網路可以蓋得更小，設備也少很多。
• 31:18 網路更扁平、交換器層數少很多，耗電更少、成本更低；每瓦能做的有用工作變多，電力更直接用在 GPU 上
  ↳ 交換器疊的層數少，網路就比較「扁」。設備少，耗電和成本都會降。省下的電可以留給 GPU（負責 AI 運算的晶片）做真正的計算。
• 31:51 主持人問文字、影像、影片或多模態模型的訓練有何不同；受訪者表示無法談模型架構細節
  ↳ 多模態模型是能同時處理文字、圖片、影片等不同資料的 AI。主持人問訓練這些有沒有差別，受訪者說模型內部怎麼設計不能透露。
• 31:51 受訪者表示模型越先進，對系統的要求越難：要搬的資料量和延遲限制都更嚴苛
  ↳ 他能講的是大方向：模型越強，要搬的資料越多，對延遲（latency，資料從一端送到另一端花的時間）的要求也越嚴格。
• 32:24 訓練叢集越大、其他層優化得越好，網路稍微慢一點的代價就越來越大
  ↳ 訓練（training）是用大量資料把模型教出來。機器越多、其他環節越快，網路只要慢一點，所有機器就得一起等，浪費也越來越大。
• 32:54 研究員與基礎設施人員朝同一個目標努力；GPU 上的工作變快，網路傳輸的時間限制就更緊
  ↳ 研究員讓 GPU 算得更快，網路就得在更短的時間內把資料送到。大家目標一樣，但時間壓力最後會一路壓到網路這邊。
• 32:54 受訪者表示如果網路拖後腿，其他人的努力就白費，所以他們的工作永遠不會停
  ↳ 網路連著所有環節，只要它慢下來，其他團隊辛苦省下的時間就被吃掉了。別人一直在進步，他們也得一直跟上。
• 33:24 系統變大後，最慢那個運算的變異會增加，必須控制這個 tail；網路這邊也一樣要收斂
  ↳ tail 指最慢的那一小部分。很多台機器一起算時，要等最慢那台做完才能往下走。規模越大，越容易出現特別慢的機器，網路也得把最慢的情況壓下來。
• 33:24 不直觀的一點：沒有 MRC 就把流量拆到多條連結，tail statistics 其實會變差很多
  ↳ 直覺會覺得線路越多越順。但沒有 MRC 這種細緻的分配時，資料拆到多條線上，反而更容易有某條特別塞，最慢那部分的統計（tail statistics）會變得更糟。
• 33:56 同樣頻寬但路徑更多，就像把同樣數量的球丟進更多箱子，最滿的箱子跟平均的比值會惡化很多
  ↳ 球是資料，箱子是線路。球一樣多、箱子變多，每箱平均會變少，但隨便丟總會有幾箱特別滿。最滿的那箱跟平均差得更多，大家都得等它。
• 33:56 Mark 提到的 deterministic routing 能在大量連結間仔細做 load balancing，避免陷入需要回饋迴路才能恢復的壞狀況
  ↳ deterministic routing 是照規則事先算好每筆資料走哪條線。搭配 load balancing（負載平衡，把流量平均分給各條線），就不會塞到得靠事後回報才救得回來。
• 34:28 整個堆疊各層緊密耦合：底層網路硬體人員要懂工作負載層，工作負載層人員也要懂交換器內部
  ↳ 整套系統一層疊一層，彼此牽動很深。做網路硬體的人得懂 AI 訓練怎麼跑，寫訓練程式的人也得懂交換器裡面怎麼運作。
• 34:28 受訪者認為沒有這種垂直整合、大家往同方向努力，就無法推進系統規模的極限
  ↳ vertical integration（垂直整合）在這裡是指從底層硬體到上層應用的人互相理解、一起設計。他認為少了這點，系統規模就推不上去。
• 34:59 主持人區分訓練與推論：問 ChatGPT 時只需要幾顆 GPU 回答；並問太空資料中心相隔遙遠、受光速限制，是否會失去速度優勢
  ↳ 推論（inference）是用訓練好的模型回答問題，幾顆 GPU 就夠。主持人接著問：太空資料中心彼此距離很遠，受光速限制，會不會因此比較慢？
• 35:29 受訪者表示很難想像在太空做 Stargate 資料中心那種訓練：延遲會是大問題，背景故障率也是
  ↳ 像 Stargate 那種大規模訓練，需要大量機器緊密又即時地配合。搬到太空，距離造成的延遲會很傷。機器平常本來就會壞，這也很難處理。
• 35:29 Microsoft 和 Oracle 的技術人員每天都得進場修東西，在軌道上很難做到
  ↳ 在地面上，Microsoft 和 Oracle 的技術人員每天都要進機房修設備。衛星軌道上沒辦法每天派人上去修。
• 36:03 受訪者表示太空方案兩方都有合理論點，主要障礙之一是故障率；每一代 GPU 都更強、更貴、更重要
  ↳ 他承認支持和反對太空資料中心都有道理，但故障是一大障礙。GPU 一代比一代強、也一代比一代貴，壞掉一顆的損失越來越大。
• 36:03 他們在地面上努力自動繞過故障，但送上太空的硬體可能很快就有很多無法使用
  ↳ 在地面上，他們盡量讓系統遇到故障能自動繞開、繼續運作。但在太空壞了就修不了，送上去的硬體可能沒多久就有不少不能用。
• 36:35 受訪者表示光是讓 MRC 上線，就需要與多家公司工程師密切合作，有時還得親手到機器旁修理與測試
  ↳ 光是讓 MRC 實際上線，就得跟好幾家公司的工程師密切合作，有時還要親自到機器旁邊動手修理和測試。
• 37:06 受訪者認為要在太空做這些，得有非常強的理由；結論是多蓋地面算力中心，以增加世界上的智慧總量
  ↳ 除非有非常強的理由，否則不值得把這些搬上太空。他的結論是：多在地面蓋算力中心，讓世界上能用的 AI 能力變多。

根據影片，MRC 使用哪種技術，讓每個封包的位址列出它要經過的確切交換器？