AMD AI 加速
超大規模 AI 叢集設計：從節點互聯到智算中心網路
超大規模 AI 叢集設計：從節點互聯到智算中心網路
帶團隊評估過幾次大型訓練叢集的架構之後，我愈來愈確定一件事：真正卡住進度的，很少是加速器本身，而是加速器之間怎麼被連起來。
這篇從 HPC 與超算中心工程師的角度，談叢集互聯的兩種尺度、AMD 參與推動的開放網路標準，以及散熱與電力效率為什麼是規模化的先決條件，不是收尾才處理的枝節。
你將學到什麼
兩種尺度的互聯
機櫃內的加速器對加速器連結，跟跨機櫃的資料中心網路，是兩種完全不同的設計問題。
開放標準是共同語言
AMD 參與推動的互聯標準，目的是讓不同廠牌的硬體能照同一套規格互通。
拓撲決定訓練效率
分散式訓練的通訊模式，會直接影響節點該怎麼排、怎麼連。
散熱電力是隱形天花板
叢集規模愈大，散熱與供電能不能跟上，往往比算力本身更早成為瓶頸。
一套 AI 叢集能不能撐得住上千顆加速器同時運算，答案往往不在晶片本身，而在加速器之間怎麼被連起來。
分散式訓練，對網路提出了什麼要求
訓練一個大模型，通常需要把工作拆給成千上萬顆加速器同時處理，再把各自算出的中間結果同步回來。
這個同步動作要跑很多輪，任何一段連結的延遲或頻寬不足，都會讓所有加速器一起等待，整體訓練時間因此被拉長。
所以叢集設計的第一個問題，從來不是單顆加速器夠不夠快，而是這麼多顆加速器要怎麼有效率地互相溝通。
兩種尺度：機櫃內的擴展，跨機櫃的擴展
業界慣用兩個詞描述叢集互聯的兩種尺度：機櫃內、甚至單一運算單元內的高速連結稱作 scale up；跨機櫃、跨資料中心的規模化連結稱作 scale out。
| 尺度 | 設計重點 |
|---|---|
| scale up（機櫃內互聯） | 極低延遲與極高頻寬，讓加速器彼此像存取同一份記憶體一樣快速交換資料。 |
| scale out（跨機櫃網路） | 節點數量大得多，重點轉向穩定性與可擴充性，讓叢集能持續往外長而不崩潰。 |
AMD 參與的開放網路生態
依 AMD 官方部落格（2026 年），AMD 把自己的策略描述成橫跨前端網路、機櫃內互聯與跨機櫃互聯的一套連貫系統，並強調整套做法根植於開放乙太網路標準與生態系。
- Ultra Accelerator Link（UALink）：AMD 與其他業者共同推動的開放互聯標準，鎖定機櫃內加速器對加速器的高速連結。
- Ultra Ethernet Consortium（UEC）：鎖定跨機櫃、跨資料中心的規模化乙太網路連結，處理擴展這一段。
- ESUN 等相關生態組織：進一步補齊開放網路標準的拼圖。
這條路線的核心主張，是讓不同廠牌的加速器、交換器與網卡都能照同一套開放規格互通，不必整套都綁在單一供應商身上。
不要只問「這顆加速器多快」，接著要問「這一批加速器之間怎麼連、用的是不是開放標準」。後面這個問題，往往才是決定能不能順利擴充的關鍵。
散熱與電力效率：規模愈大，愈早碰到的天花板
單顆加速器的耗電與發熱看起來不大，但乘上一整座叢集動輒成千上萬顆的規模，就變成機房等級的工程問題。
電力能不能穩定送到每一機櫃、熱能能不能即時排出，直接決定叢集能撐到多大規模，也決定它能不能長時間全速運轉而不降頻。
這也是為什麼液冷與更精細的電力管理，愈來愈常跟超大規模 AI 叢集的討論綁在一起，不是機房裝修的枝節，而是規模化的先決條件。
很多規劃在紙上先定好要買幾百顆加速器，後面才發現機房電力容量或散熱系統跟不上。反過來從電力與散熱的實際上限往回推機台數量，通常比較不會踩坑。
給工程師的實務思考
- 先確認訓練任務的通訊模式，再決定節點怎麼排、機櫃內外的連結要怎麼設計。
- 開放標準的雲端可用性還在逐步展開，評估方案前先查目前實際能取得的區域與規模。
- 把散熱與電力當成規劃的先決條件，不是等叢集蓋好才處理的收尾工作。
延伸學習
ChatGPT 很強，但真正讓你下班的是 Google
六小時完整實錄。從「AI 很厲害，為什麼你還是每天加班」這個問題出發，把 Google Workspace 當成真正的工作平台重新設計一次流程 ── Sheets 的資料結構、Drive 與 Docs 的文件流、Gmail 與 Calendar 的通知系統，再用 Apps Script 讓它自己跑起來，最後收斂成一張屬於你自己的 AI 工作能力地圖。
NT$ 4,599
AI Native 工作法
四小時完整實錄。工作已經不是以前的工作了 ── 這門課拆解 AI Native 的四個核心能力，帶你把自己的工作做成一份可執行的 AI Native Blueprint，從「會用 AI 的人」變成「工作本身就長在 AI 上的人」。
NT$ 2,599