BMC

3 秒看懂

BMC（基板管理控制器）是伺服器主機板上的獨立管理核心，通過網路在作業系統關機甚至伺服器斷電（僅待機供電）時仍能遠端完成開關機、韌體更新、感測器監控和故障恢復——為成千上萬臺 AI 伺服器的無人化運維提供帶外管理神經中樞。

3 分鐘產業解釋

BMC 是一顆嵌入式 SoC（通常基於 ARM），擁有獨立的記憶體和儲存，執行專用的 Linux 系統與管理協議棧。它不依賴主 CPU，僅靠備用電源即可工作，通過 IPMI（智慧平台管理介面）和 Redfish（現代 RESTful 管理標準）對外提供服務。在 AI 資料中心，BMC 承擔：

• 遠端控制：虛擬 KVM、虛擬儲存掛載、Serial‑Over‑LAN（SOL），可實現“像在機房裡一樣”操作任何節點。
• 環境與功耗監控：直接讀取數百個溫度、電壓、電流和風扇轉速感測器，並通過 PMBus 與電源模組互動，實現機架級功率封頂和動態散熱。
• 韌體生命週期管理：帶外更新 BIOS、GPU 韌體、NVSwitch 韌體，支援多分割槽更新和零停機滾動升級。
• 安全錨點：作為平台信任根，配合 TPM 和 PFR（平台韌體恢復）實現安全啟動、韌體完整性校驗和入侵檢測。

在大規模 AI 訓練叢集中，數以千計的 GPU 伺服器被多級 BMC 網路所覆蓋：每個主機板一個 BMC，每個高密度 GPU 基板（如 HGX）可能自帶管理模組，形成樹形帶外管理拓撲。運維工程師可以通過統一的叢集管理器（如 OpenBMC + Redfish 工具鏈）對叢集進行自動化上下電、健康輪詢、故障預測和隔離，將平均修復時間從小時級壓縮到分鐘級。

15 分鐘專家深入

AI 伺服器中的 BMC 生態位
單臺 8‑GPU 訓練伺服器的 BMC 管理範圍已遠超傳統 x86 伺服器。它不僅要監控主機板上的 CPU、記憶體、儲存，還需延伸到：

• GPU 基板：通過 I²C/SMBus 讀取 GPU 溫度、功耗、記憶體溫度，控制 GPU 斷電/復位；部分設計使用二級管理控制器，再由主機板 BMC 聚合。
• NVSwitch / NVLink 域：監測高速互連的狀態、鏈路頻寬、重訓練事件，一旦出現降級便觸發告警。
• 液冷分配單元（CDU）：在直接到晶片（Direct‑to‑Chip）冷卻方案中，BMC 監控二次側液溫、漏液檢測感測器，並調節冷卻液流量閥。
• 電源背板：通過 PMBus 向 48V/12V 電源模組索要即時效率、輸入輸出功率和故障記錄，支援整機櫃功率預算分配。

軟體棧深度
現代 BMC 普遍採用 Yocto 建置自定義 Linux 發行版，其上執行：

• 協議棧：IPMI（UDP）、Redfish（HTTPS/JSON）、SNMP 代理、MCTP（管理元件傳輸協議）用於裝置間管理訊息。
• Web UI：基於 Node.js 或輕量級 Web 伺服器的視覺化介面。
• 安全服務：審計日誌、TLS 1.3 加密、RBAC 使用者權限模型、韌體簽名驗證鏈。
• 自動修復指令碼：預先燒錄的故障恢復邏輯（例如 GPU 掛死時自動復位電源軌、記憶體 ECC 超閾值時隔離頁面）。

開源專案 OpenBMC 由 Meta 發起，已在 Hyperscaler 自有伺服器中廣泛部署，其優勢在於徹底的可定製性——雲端廠商可以刪除一切無用元件以縮小攻擊面，並整合自研監控 agent 直接向資料中心 fabrics 上報遙測。

多級管理網路
大型 AI 叢集通常架設獨立的帶外管理網路（1GbE/10GbE），通過管理交換器形成一個完全與資料流量隔離的平面。所有 BMC 在此平面內向集中管控軟體（如 NVIDIA Baseboard Manager、開源 StackHPC）註冊，運維人員可在不佔用任何 GPU 算力的情況下完成部署、診斷和恢復。典型管理網路拓撲示意：

      集中管理平台 (Redfish clients)
                │
       ┌───── Ethernet Fabric ─────┐
       │                           │
    管理交換器                   管理交換器
       │                           │
  ┌────┴────┐              ┌─────┴─────┐
  │ 機架1 BMC│              │ 機架N BMC │
  │  (主機板)  │              │  (主機板)   │
  └────┬────┘              └─────┬─────┘
       │ I²C/PMBus               │
  ┌────┼────┬──────┐      ┌─────┼─────┐
  │GPU基板│ PSU│風扇 │      │ GPU基板│ ...
  │ 管理  │ 模組 │ PWM │
  └───────┴────┴─────┘

技術原理（最深）

BMC 硬體以一顆 ARM Cortex‑A（或部分 Cortex‑M）SoC 為大腦，整合 DDR 控制器、eMMC/SPI Flash 儲存、專用管理網路 MAC、以及大量低速外設介面。其執行機制與宿主 x86/GPU 系統完全獨立。

關鍵元件與介面

• eSPI 匯流排：取代傳統的 LPC，與 PCH/南橋通訊，實現對主 CPU 的復位、開機、POST 碼讀取。
• I²C/SMBus 矩陣：通常多個多路複用器，可連線上百個感測器和從裝置（溫度、EEPROM、VR 控制器、GPU 管理晶片）。
• PWM 控制器：驅動多組風扇，配合閉環 PID 演算法動態調整。
• NCSI（網路控制器邊帶介面）：與主網絡卡共享同一物理埠，使 BMC 無需獨立網口也能對外通訊。
• MCTP over PCIe/SMBus：用於與 GPU、NVSwitch 等 PCIe 裝置的管理對話。

啟動流程與安全錨

1. 只要主機板 SB5V 待機電壓存在，BMC 即上電覆位，執行 BootROM 驗證 SPL/U‑Boot 簽名。
2. U‑Boot 載入 FIT 映象（含核心、裝置樹和 initramfs），所有韌體均經過 RSA‑2048/SHA‑256 驗證。
3. 核心掛載 eMMC 中的根檔案系統，啟動物理資源監控守護程序（如 phosphor‑hwmon）和管理服務。
4. BMC 通過 PFR（平台韌體恢復）晶片持續監視 BIOS/CPLD 韌體完整性，一旦損壞可自動回退到已知良好版本，即便主 CPU 無法啟動也可恢復。

監控與遙測迴圈 ‑‑‑ 簡化程式碼邏輯：
while(1) { read_sensors(); adjust_fans(); check_alerts(); serve_web_requests(); }
‑‑‑ 實際上由多執行緒事件驅動，但核心是硬即時感測器輪詢。在 AI 訓練場景，溫度、功耗變化極為劇烈（8 顆 GPU 瞬間從閒置跳至 4kW），BMC 的輪詢間隔通常低至 200 ms，並帶滑動視窗去抖。功耗封頂功能通過持續讀取 GPU 和電源模組功耗，呼叫 Host 或 NVML 介面下調配額實現。

AI 專屬擴充套件

• 支援 MIG（多例項 GPU）的拓撲發現，BMC 需要感知 GPU 切分後的虛擬裝置樹。
• 整合 DPU/IPU 管理，通過管理網路與 DPU 的內部 BMC 通訊，實現智慧網絡卡的監控和韌體推送。

技術演進史

• IPMI 1.5/2.0 時代（2000‑2010）：BMC 僅提供基於命令列的 SOL 和基礎感測器資料，晶片以 8 位/ARM7 為主。
• Redfish 標準化（2015 起）：DMTF 推出 Redfish，用 RESTful JSON 替代晦澀的 IPMI 命令，大幅降低自動化門檻。OpenBMC 同期誕生。
• 安全化浪潮（2018‑2022）：NIST SP 800‑193 推動 PFR 落地，BMC 成為硬體信任根；TLS 加密、UEFI 安全啟動延伸至管理面。
• AI 伺服器催生多級管理（2020‑）：HGX 基板引入獨立管理單元，BMC 角色從單板管理者升級為機內管理聚合器；巨型叢集推動 BMC 韌體容器化和零停機升級。
• CXL/PCIe 6.0 時代（2025+）：BMC 需要管理更復雜的 fabric 拓撲，支援 MCTP over PCIe 6.0 和 IDE（完整性與資料加密）管理，晶片算力持續提升。

技術路線對比

下表以典型產品代際特徵進行定性比較，未寫入具體型號與頻數，可代表行業一般演進路徑。

特性	傳統 BMC (2015 前)	現代 AI 伺服器 BMC (2020 後)	開源 OpenBMC 方案 (Hyperscaler 常用)
管理協議	IPMI 2.0，無原生 Redfish	IPMI + Redfish 全面支援，含事件流	Redfish 核心，IPMI 可裁剪
安全架構	有限的安全啟動，無硬體信任根	PFR、TPM 整合、韌體籤驗、RBAC	按需定製，可整合 MCTP over SPDM 等強認證
AI 專項	無 GPU 管理支援	直連 GPU 基板、NVSwitch、液冷和功耗封頂	完全可定製，可接入任何帶外感測器
擴充套件性	單一主機板，管理平面封閉	支援與機架級管理器聯動，Redfish 聚合服務	原生支援大規模叢集發現和自動化部署
韌體更新	多數需要重啟，機制繁複	支援多分割槽、邊帶更新，部分零停機	雙備份分割槽 + 容器化 OTA，升級視窗極短
CPU 架構與算力	單核 ARM9/ARM11	雙核至四核 Cortex‑A 系，記憶體 GB 級，eMMC 數十 GB	不限，可使用高效能 SoC，但易被軟硬一體化替代

注：具體晶片迭代可參考 ASPEED AST2500→AST2600→AST2700 路徑，準確規格請查閱原廠資料手冊 [未充分揭露]。

上下游

上游：矽與韌體

• BMC SoC 設計：ASPEED（信驊）、Nuvoton（新唐）、Microchip 等。ASPEED 憑藉龐大相容性資料庫佔據全球約 70% 出貨。
• 韌體與軟體：AMI（MegaRAC SP‑X）、Phoenix Technologies、OpenBMC 社群。AMI 提供面向 Redfish 的完整方案，OpenBMC 被 Meta/Google 大幅修改用於自研伺服器。
• 安全晶片：用於 PFR 的 FPGA/CPLD 或專用安全 MCU（如 Lattice、Infineon）。

中游：整合與製造

• 伺服器 ODM/OEM：廣達、英業達、緯穎、Supermicro 等負責將 BMC 晶片焊接到主機板上，移植/配置韌體，並與雲端廠商聯合設計管理策略。
• AI 基板整合：NVIDIA HGX 系列將基板管理微控制器與主機板 BMC 對接，形成統一上報通道。

下游：資料中心與使用者

• Hyperscaler：自研 BMC 韌體甚至硬體（如 Meta 的 Yosemite 平台），極度關注安全與自動化。
• 企業 AI 叢集：通過 OEM 渠道購買，依賴原廠 BMC 提供統一管理平台（如 Dell iDRAC、HPE iLO，本質均為整合 BMC 的定製套件）。

關鍵指標

對於評估 BMC 在 AI 系統的適用性，以下指標值得關注：

• 感測器通道數：決定能管理多少 GPU、NVSwitch 和散熱單元，大型 AI 節點需百條以上 I²C 匯流排。
• 管理網口頻寬：1GbE 是標配，部分高階已向 2.5GbE/10GbE 演進以承載影片流和批次遙測。
• 安全認證等級：是否支援 FIPS 140‑2/3、加解密硬體加速。
• 韌體更新粒度：能否只更新 BMC 自身、BIOS、GPU 韌體之一而不影響其他，面向 AI 叢集尤為重要。
• 平均故障恢復時間：包括 BMC 看門狗復位、自動重刷韌體等自愈能力。
• 功耗：通常 <5 W，不影響整機散熱預算，但對大規模叢集累積功耗有邊際影響。

具體數值因代際而異，高代次晶片在計算和 I/O 能力上倍增，但詳細引數 [未充分揭露]。

供需與市場資料

AI 伺服器出貨量激增直接推升 BMC 晶片需求。由於每臺伺服器至少配 1 顆主機板 BMC（部分 AI 定製節點可能包含多顆管理晶片），市場容量與 AI 伺服器數年複合高增長強相關。據部分行業分析，2023‑2027 年全球伺服器 BMC 晶片市場規模的年複合增長率可超過 15%，主要由 AI 和邊緣計算驅動 [具體數值未獲得公開財報核實]。ASPEED 作為行業龍頭，其月度營收被市場視為伺服器行業景氣度風向標；近年多次出現因 AI 急單導致 BMC 晶片供應緊張的局面。

在 Hyperscaler 側，自研 OpenBMC 比例上升，但硬體晶片仍向 ASPEED 等採購，並未顛覆矽層格局。安全法規趨嚴（如歐盟 Cyber Resilience Act）迫使所有伺服器供應商升級 BMC 安全能力，推動價值量提升。

代表公司與資本對映

• ASPEED Technology（信驊，5274.TW）：全球 BMC SoC 龍頭，每顆 AI 伺服器的管理核心幾乎必有信驊晶片。資本市場將其視為“AI 伺服器的賣鏟人”，營收與 AI 伺服器出貨量高度共振，享有較高估值溢價。
• Nuvoton Technology（新唐科技，4919.TW）：BMC 第二供應商，通過收購 Panasonic 半導體部門擴大產品線，在部分伺服器平台獲採用。
• AMI（未上市）：韌體霸主，提供 MegaRAC 系列，很多 OEM 的 BMC UI 和管理功能均基於 AMI 架構，其設計授權費用隨伺服器出貨而增長。
• OpenBMC 生態：不直接上市，但 Meta、Google、Microsoft 等雲端巨頭貢獻程式碼，減少了對 AMI 的依賴，長期影響專有韌體供應商的議價權。

投資邏輯

1. 量價齊升：AI 訓練/推論伺服器相比通用伺服器，BMC 需管理更多器件、支援更復雜的安全特性，單顆價值量提升；同時伺服器出貨量高速增長，形成雙擊。
2. 競爭壁壘高企：BMC 需與海量 CPU、GPU、儲存和電源微碼相容，客戶切換成本極高；ASPEED 的“軟硬體相容性護城河”短期內難以被突破。
3. 開源趨勢下硬體為王：OpenBMC 削弱了韌體供應商鎖定，但無法替代 BMC 晶片，反而因為通用化可能擴大可定址硬體市場。
4. 前瞻指標屬性：信驊月度營收對伺服器供應鏈具有 2‑3 個月提前指示意義，可輔助判斷 AI 基建投資節奏。
5. 風險：自研 BMC SoC（如某些雲端巨頭定製 ASIC）可能侵蝕商業晶片份額，但規模效應和持續相容性投入仍是巨大防禦。

常見誤讀糾偏

• 誤讀：“BMC 就是主機板上一個小晶片，和 AI 無關。”
  糾偏：AI 叢集的運維人力成本極高，無人值守全靠 BMC。一旦 BMC 韌體出現漏洞（如歷史上 CVE‑2019‑6260 等），攻擊者可持久化控制整個節點並橫向移動，風險遠超單臺 PC。

• 誤讀：“OpenBMC 會殺死 ASPEED。”
  糾偏：OpenBMC 是一套韌體架構，可以執行在 ASPEED 硬體上。它取代的是韌體廠商（如 AMI）的收費方案，而不是晶片。Hyperscaler 部署 OpenBMC 時仍大量採購 ASPEED 晶片，硬體需求不變。

• 誤讀：“有 GPU 管理工具就不需要 BMC。”
  糾偏：GPU 供應商提供的管理庫（如 NVML）是 In‑band、依賴主 CPU 和作業系統；當系統宕機或 OS 崩潰時，僅 BMC 仍能遠端復位或重灌。兩者協同，而非替代。

學習路徑

1. 入門：閱讀 IPMI Specification v2.0 概述，理解感測器資料模型和命令格式。
2. 實踐：在樹莓派或虛擬機器搭建 OpenBMC 環境，嘗試 Redfish API 呼叫。
3. 硬體：查閱 ASPEED AST2600 資料手冊（官網可獲取），學習 BMC 的硬體框圖、引腳功能和啟動流程。
4. 安全：研讀 NIST SP 800‑193《Platform Firmware Resilience》和 OCP Security Profile。
5. AI 管理：探索 NVIDIA MGX 架構白皮書中 BMC 與管理模組的連線方式，瞭解大規模叢集的帶外管理設計。

一句話總結

BMC 是 AI 伺服器中那個“永不掉線”的管理核心——它讓數十萬 GPU 組成的叢集可以在黑暗中自動呼吸、自我修復。

延伸閱讀與來源

• DMTF Redfish 標準資源：redfish.dmtf.org
• OpenBMC 專案倉庫：github.com/openbmc
• ASPEED 產品線：aspeedtech.com
• 相關 CVE 分析，理解 BMC 安全重要性的實際案例。
• 本文技術描述基於公開行業知識及典型的 AI 伺服器設計，具體晶片型號和指標因未獲得直接檢索證據，未予定量，請以原廠最新手冊為準。