多例項 GPU

3 秒看懂

一句話定義： 多例項 GPU (MIG) 是 NVIDIA 自 Ampere 架構起引入的一項硬體級 GPU 分割槽技術。它允許將一塊物理 GPU（如 A100、H100）從計算單元（SM）、視訊記憶體、L2 快取到視訊記憶體頻寬，全維度切割成多個完全隔離、效能可預測的獨立 GPU 例項。

核心比喻： 不是合租公寓裡的幾個室友（共享廚房、衛生間，易互相干擾），而是一棟擁有獨立產權、獨立水電燃氣表、獨立入戶門的多戶住宅樓。每個 MIG 例項（每戶）擁有嚴格物理隔離的專屬資源，一個例項的任務崩潰、滿載或出現記憶體錯誤，對其他例項幾乎無影響。

3 分鐘產業解釋

它是什麼：

MIG 並非傳統意義上的軟體虛擬化或時間片輪轉共享。它是一種深入到 GPU 硬體底層的“分割槽”機制。具體而言，NVIDIA 在其旗艦資料中心 GPU（目前支援的產品線主要包括 A100、H100、H200 等）內部，將成組的流處理器（SM）、記憶體控制器、L2 快取切片以及高頻寬記憶體（HBM）的物理分割槽，靜態或準靜態地配置給最多七個獨立的硬體例項。每個例項在作業系統和 CUDA 驅動層面，均表現為一塊擁有獨立 PCIe 裝置 ID、獨立記憶體空間、獨立錯誤報告通道的“完整”物理 GPU。在 Ampere 架構的 A100（40GB/80GB 版本）上，最大可劃分為 7 個例項；到了 Hopper 架構的 H100/H200，結合第四代張量核心與更高頻寬的 HBM3/HBM3e，MIG 的配置彈性和每個計算切片（GI）的絕對算力得到進一步增強。

為什麼重要（解決了什麼痛點）：

1. 提升 GPU 硬體利用率（打破“獨佔陷阱”）： 雲端端和企業資料中心的頂級 GPU（如 H100）購置成本極高且供給受限。大量研發測試、中小模型推論、模型微調、Jupyter Notebook 開發等任務，往往只需要一塊 H100 十分之一到三分之一的算力。在無 MIG 環境下，使用者只能獨佔整張 GPU，導致大量算力資源被閒置。MIG 實現了硬體資源的“化整為零、按需分配”，可將一塊 H100 分配給多個不同團隊或任務並行執行，使 GPU 物理硬體的平均日利用率（Daily Utilization Rate）從傳統獨佔場景的不足 50% 拉昇至 80% 以上（資料來源：NVIDIA 2021 年 MIG 技術白皮書示例場景，具體部署環境存在差異）。

2. 嚴格的服務質量保障（QoS）與效能隔離： 這是 MIG 與軟體時間片共享方案的根本分水嶺。在一個非 MIG 的共享 GPU 環境中，一個任務引發的視訊記憶體頁錯誤、大量 L2 快取驅逐（Cache Thrashing），或一個迴圈中佔滿所有 DRAM 頻寬的 Kernel，會即刻導致同一 GPU 上其他所有任務的效能出現不可預知的劇烈抖動（Jitter），甚至使延遲敏感的線上推論服務超時。MIG 通過硬體圍欄，為每個例項嚴格保障了其所分配的視訊記憶體頻寬（Memory BW）、L2 快取容量、SM 執行單元的獨享。一個例項內部的資源飽和，不會越過硬體邊界去侵擾另一個例項。

3. 增強的故障域和安全隔離： 在雲端環境多租戶場景下，單一租戶任務因非法記憶體訪問（如寫入越界）導致 GPU 出現“Uncorrectable ECC Error”或 XID Fatal Error，進而引發整張 GPU 掉卡（Fallen off Bus）或必須進行功能級復位（FLR），是非 MIG 模式下的典型痛點。在 MIG 模式下，硬體錯誤報告被嚴格限定在對應的物理分片內。一個例項出現致命錯誤，通常僅需重置該例項本身，而同一塊 GPU 上的其他例項不受影響，可繼續保持業務連續性。此外，每個例項擁有獨立的頁表（Page Table）、獨立的地址對映空間，一個租戶無法通過任何 CUDA API 窺探或訪問另一個例項的視訊記憶體資料，形成硬體級安全邊界。

4. 適配混合工作負載並簡化叢集管理： 資料中心管理者可以根據到貨批次和硬體庫存，將特定節點上的 GPU 統一配置為固定的 MIG 組合（例如，將一組 H100 每個均切為 3 個例項）。隨後，利用 Kubernetes 及 NVIDIA GPU Operator 中的 MIG-Strategy（Mixed/Single），將不同優先順序的推論（Inference）、訓練（Training）、開發除錯（Debug）等性質各異的負載，有針對性地排程到相應規格的 MIG 例項上，避免了手動指定裝置（Device Pinning）帶來的運維複雜度。

誰在用：

主要使用者由三類驅動：第一類是頭部雲端服務提供商（AWS、GCP、Azure、阿里雲端），將單一物理 GPU 拆分為從 “1/7 塊 GPU” 到 “整塊 GPU” 的多種算力例項規格，覆蓋更廣的客戶付費層級；第二類是中大型企業內部 AI 平台（尤其是金融風控建模、藥物分子動力學模擬、自動駕駛感知訓練等場景），利用 MIG 在同一臺 GPU 伺服器上同時承載線上推論服務與離線評測任務，實現算力“峰谷互補”；第三類是高校與研究機構的高效能運算（HPC）中心，為不同課題組提供有資源保障的、互不干預的共享 GPU 池。

技術原理

MIG 的核心在於將 GPU 視為一個由多個對稱建置塊（Building Blocks）組成的資源池，並在驅動初始化時，通過硬體配置描述符將這些建置塊進行“焊接”或“割裂”，構造出邏輯上互不連通的例項。具體實現涉及以下幾個維度的協同隔離：

1. 計算資源（SM）的硬體分割槽：

GPU 的 SM 單元在物理版面配置上依 GPC（Graphics Processing Cluster，圖形處理叢集）聚合。MIG 在 GPC 粒度上對 SM 進行集合管理，但分配給一個例項的最小可排程單元稱為“計算切片”（Compute Slice）。以 A100 為例，整個 GPU 擁有固定的 GPC 與 SM 拓撲，MIG 支援的例項大小就體現為獲得幾個 GPC 中包含的 SM 比例。Hopper 架構在 GPC 與 SM 的數學配比上進行了重構，使得 MIG 例項的算力階梯更加線性。被分配給某個 MIG 例項的 SM 物理單元，其排程器、暫存器檔案、張量核心均僅對例項內部可見，其他例項無法向其發射任何執行緒束（Warp）。

2. 視訊記憶體與頻寬的靜態繫結：

MIG 將 GPU 物理 HBM 按固定的物理 Channel（即記憶體控制器）進行切分。每個 MIG 例項被分配一或多個專屬的 HBM 控制器通道及對應的物理 DRAM 分割槽。這意味著此例項所擁有的視訊記憶體擁有特定且獨立的物理行列地址（Row/Column Address），在資料匯流排上產生請求時，其仲裁優先順序與時間配額由硬體保證。這從根源上杜絕了傳統共享方案中，一個例項發出大量無序訪問請求，阻塞其他例項 Dra 記憶體訪問命令的情形，實現視訊記憶體頻寬的 QOS 隔離。

3. L2 快取的分割槽與 QoS 策略：

MIG 允許不同例項擁有自己獨立的 L2 快取切片和對應的快取替換策略。L2 控制器硬體內部，會根據配置將快取行對映至固定的例項標籤域。當例項 A 發生快取失效並引入新資料時，它僅能在屬於自己的 L2 配額區間內進行替換（Eviction），從而杜絕跨例項的快取汙染（Cache Pollution）。此特性對延遲極度敏感的即時推論任務至關重要：它能確保推論任務需要的模型權重常駐於 L2 中，不被其他訓練任務的中間梯度張量沖刷掉。

4. 控制面與錯誤隔離：

每個 MIG 例項在 SoC 內部擁有獨立的虛擬機器 ID（VMID），並由 GPU 內部的系統處理器（如 Falcon 控制器）進行上下文劃分。當發生 GPU 計算資料錯誤（Dbe Error）或 XID 異常時，中斷處理程序可以通過 VMID 直接溯源至故障例項，並將錯誤播報封裝在該例項的特定驅動棧中，實施精準隔離的例項級重置（GPU Reset Scope 僅作用於故障例項）。

5. NVLink 與 P2P 通訊限制：

這是 MIG 設計中極為重要，也常被開發者忽視的一個技術約束。在 MIG 模式下，晶片內部的 xBar 及晶片外部的 NVLink/NVSwitch 高速跨 GPU 通訊通道，對 MIG 例項表現為“不可直接訪問（Not Accessible）”。CUDA 的 P2P（Peer-to-Peer）記憶體訪問、GPUDirect RDMA 以及 NCCL 建立跨例項環網的操作均被禁止。這種設計是為了嚴格避免高速旁路通道破壞硬體隔離的安全模型。若有強制的跨 GPU 通訊需求（如進行分散式資料並行訓練），則不應開啟 MIG，或僅在與 MIG 例項通訊的其他節點上使用全功能物理 GPU。

┌──────────────────────────────────────────────────────────────────┐
│                   物理 GPU 晶片 (例如 H100 SXM)                     │
│  ┌───────────────┐  ┌───────────────┐  ┌───────────────┐         │
│  │   例項 0       │  │   例項 1       │  │   例項 2       │         │
│  │   2 GPC        │  │   2 GPC        │  │   1 GPC        │         │
│  │   HBM 分割槽 0-1 │  │   HBM 分割槽 2-3 │  │   HBM 分割槽 4   │         │
│  │   L2 切片 0-1  │  │   L2 切片 2-3  │  │   L2 切片 4    │         │
│  │   (獨立錯誤報告)│  │   (獨立錯誤報告)│  │   (獨立錯誤報告)│         │
│  └───────────────┘  └───────────────┘  └───────────────┘         │
│       ▲  HW 隔離圍欄（無 P2P、無快取交叉訪問）       ▲              │
│  ─────────────────────────────────────────────────────            │
│  作業系統驅動層面：出現 /dev/nvidia0, /dev/nvidia1, /dev/nvidia2   │
│  每個均有獨立的 FID, VMID 與 ECC 統計                             │
└──────────────────────────────────────────────────────────────────┘

示意圖：MIG 通過硬體分割槽實現的計算資源、視訊記憶體控制器、L2 快取及故障上報的多維隔離。實際的 SM 與 GPC 數量因具體型號和 SKU 而有差異，NVIDIA 對每個型號的合法 GI 組合給出了明確的標準化配置矩陣。

關鍵引數

評估與應用 MIG 時，需要關注以下幾個技術與管理層面的硬性引數：

1. 最大例項數與基本計算單元： 在 Ampere 架構的 A100（40GB 及 80GB HBM2e）上，單個物理 GPU 最大支援 7 個 MIG 例項。Hopper 架構的 H100/H200 同樣保持此上限，但因其單個 SM 的計算能力更強（搭載第 4 代張量核心與 FP8 引擎），每個例項的絕對吞吐量更高。不同例項對應到不同數量的“GPU 例項切片（Gl）”，GI 是配置時最小規格的計算單位表示。

2. 例項配置矩陣（配置模板）： NVIDIA 為每個支援 MIG 的 GPU 型號定義了固定的“合法配置矩陣”（Valid Profiles）。管理員無法像操作虛擬記憶體那樣任意按 1GB 粒度切分，只能從這個預定義的標準化矩陣中進行選擇。例如在 A100-80GB 上，典型的配置包含：1g.10gb（最小配置，1 個計算切片，約 10GB 視訊記憶體）、2g.20gb、3g.40gb、4g.40gb、7g.80gb（等同於未開啟 MIG 的全功能整卡）。管理員必須預先根據業務負載的記憶體需求與 SM 算力需求，對 GPU 進行全盤規劃（一次性配置多個不同規格例項）。

3. 隔離度級別（Isolation Level）： 這是 MIG 區別於一切純軟體方案的關鍵差異性引數。MIG 提供的**視訊記憶體頻寬服務質量（QoS）**是硬體級的：每個記憶體控制器獨立向對應例項提供讀寫服務。而傳統時間片共享（Time-Slicing）方案，其記憶體頻寬在爭搶下呈統計分佈，實測頻寬分配波動可達 ±30% 以上，無法滿足嚴格的生產級線上推論 SLO。

4. 管理複雜度（API 與運維）： MIG 的配置通常通過 nvidia-smi CLI 工具或 NVML 庫呼叫實現，支援 JSON 格式的批次配置匯入匯出。對於 Kubernetes 環境，NVIDIA GPU Operator 中的 MIG Manager 元件可以自動化地在節點重啟或驅動重灌後重放（Replay）MIG 配置，並將每個例項註冊為 nvidia.com/mig-1g.10gb 這類形態的細粒度擴充套件資源（Extended Resource），供 Kubernetes Scheduler 精確匹配。

5. 生態相容性矩陣： 並非所有軟體棧都能透明適配 MIG 例項。需要 CUDA 版本 ≥ 11.0，並需要 NVIDIA GPU Operator 或 Device Plugin 開啟 MIG 策略。部分早期僅依賴 CUDA_VISIBLE_DEVICES 進行單 GPU 繫結的應用程式，可能在多例項共存的環境中需要額外的執行時變數（如通過 NVIDIA_VISIBLE_DEVICES 規範繫結 UUID）。目前主流雲端原生 AI 平台（如 Run:ai、KubeFlow、Volcano）均已宣佈或已完成對 MIG 的排程策略適配。

技術路線

1. 前 MIG 時代（2012 - 2019）：GPU 共享的三板斧 資料中心嘗試共享 GPU 的技術路徑主要有三種，且均存在明顯缺陷：

• 裸時間片資源競爭（Uncontrolled Time-Slicing）： 由 GPU 驅動對提交到同一上下文的多應用做分時多工。沒有視訊記憶體保護、沒有頻寬隔離，一個任務若發生 Kernel 超時（如 > 3 秒），會觸發整個 GPU 的 Lost Device 錯誤。
• vGPU（Virtual GPU）： NVIDIA 通過 GRID/vGPU 管理器，在驅動層通過軟體排程的方式將 GPU 資源分時複用給多個虛擬機器（VM）。vGPU 藉助軟體排程與視訊記憶體截獲提供了基礎的視訊記憶體隔離和多使用者遠端圖形支援，但在計算與快取層面採用時間視窗輪轉，無法實現硬 QOS，且通常 VA（虛擬應用）授權成本較高。主要用於 VDI 和虛擬工作站，高密度 AI 計算場景下效率不高。
• 容器化直接穿透（GPU Passthrough）： 在 KVM/容器環境下直接將整塊物理 GPU 透傳給單一使用者，隔離性最佳但利用率硬傷（單一任務必須買斷整卡成本）。多使用者場景只能通過排隊或預留多卡解決。

2. MIG 1.0 誕生（2020 年，A100 + Ampere 架構）： 伴隨 A100 釋出及 CUDA 11，NVIDIA 首次將 MIG 從概念變為商用產品。其在 A100 的 GA100 晶片上，通過增加 SoC 層的虛擬機器標識、修改 xBar Crossbar 路由規則、引入視訊記憶體控制器的流量整形（Traffic Shaping），實現了最大 7 例項的硬體分割。首批完全支援 MIG 的開源元件包括：NVIDIA Container Toolkit、Kubernetes Device Plugin，以及 nvidia-smi CLI。

3. Hopper 架構的 MIG 增強（2022 年，H100/H200）： 在 H100 上，MIG 能力演進進入第二代。第一，MIG 例項可透明利用 Hopper 架構的新特性，如 FP8 Transformer Engine 和 DPX 動態規劃指令；這意味著在一個 MIG 例項內執行的 FP8 推論任務，仍然可獲得接近硬體全速的計算效率。第二，MIG 結合 Hopper 引入的 第四代 NVLink 與 NVSwitch，雖然例項間仍不能 P2P，但全卡不做 MIG 切分時，跨 GPU 通訊仍可受益於更高頻寬。第三，資源配置複雜性的簡化工具（如 NVIDIA GPU Operator 內建的自動配置管理器 mig-parted）逐步成熟。

4. 未來趨勢與 Blackwell 時代的展望（2024 起）： 在 Blackwell 架構釋出會上，NVIDIA 揭露 GB200 及 B200 等晶片的設計中心向 NVLink-C2C（晶片到晶片互聯） 與多 Die 封裝轉移。公開技術資料顯示，NVIDIA 有望將跨 Die 的可組合資源架構與 MIG 邏輯進一步融合，即未來可能出現跨多個物理 Die 但能邏輯組合為超大例項（用於訓練），或按 Die 內部更細粒度分割槽的演進 MIG 方案。目前針對 Blackwell 的 MIG 細節，NVIDIA 尚未公佈完整的 Valid Profiles 矩陣，後續需在 NVIDIA 釋出 Blackwell 架構 MIG 白皮書後進行全面追蹤。（注：截至 2025 年上半年，公開資料未見 Blackwell 具體 MIG 配置引數）

5. 技術路線對比：

特性	MIG (NVIDIA Ampere/Hopper)	多程序服務(MPS)	時間片共享 (Time-Slicing)	AMD 硬體分割槽 (僅限 MI300X 等)
隔離層級	硬體級 (SM, HBM, L2, 頻寬)	軟體上下文同享	無	硬體級 (基於 XCD 或陣列)
QoS/效能保障	強 (固定配額)	弱 (內部爭搶 L2 與頻寬)	無	較強 (可固定視訊記憶體與控制器)
故障隔離	強 (例項級錯誤不擴散)	弱 (單程序致命可帶崩 GPU)	無	強 (硬體 MC 隔離)
適用任務	異構推論/訓練切片、多租戶	提高單一應用 SM 佔有率	多使用者互不打擾的輕量開發	高密度推論、多租戶 AI
典型視訊記憶體開銷/碎片	需按配置模板劃分（1g/2g/3g/4g/7g）	無	無	根據映象方案決定物理視訊記憶體對切

上游

MIG 的功能實現完全依賴於一系列底層軟硬體廠商的技術支援與介面暴露：

• GPU 晶片設計 - NVIDIA 架構團隊： 定義 GPC、SM 與記憶體控制器的拓撲互連方式，物理實現 VMID、快取切片隔離、xBar 路由規則與錯誤報告邏輯。這是 MIG 存在的最根本物理前提。
• GPU 系統韌體與 VBIOS - NVIDIA 系統軟體部門： 提供 GPU 內部的 Falcon 控制器、安全協處理器韌體，負責初始化期間解析 MIG 分割槽表，把硬體熔絲或配置描述符對映到物理邏輯。任何一次 MIG 拓撲變更（如重分例項），都需要 GPU 級的功能級復位（FLR）或系統重啟，這會觸發韌體的重新初始化。
• GPU 核心模式驅動 - NVIDIA 與 Linux 核心社群： NVIDIA 專有核心驅動（nvidia.ko）是 MIG 能力的最主要軟體暴露者。啟動階段，驅動讀取 GPU 配置，為每個 MIG 例項註冊獨立的 /dev/nvidia* 節點、分配獨立的 BAR（Base Address Register）地址視窗、獨立的錯誤處理執行緒，並在 /proc/driver/nvidia 或 sysfs 中暴露其專屬屬性（如獨立功耗、ECC 計數、PCIe 頻寬使用率）。開源 Nouveau 驅動對 MIG 無支援。
• 虛擬化與容器執行時 - Red Hat、VMware、SUSE 等： 使用 MIG 例項的核心場景需要 GPU Operator 或虛擬化層配合。例如，VMware ESXi 需要特定的 vSphere Bitfusion 或 DirectPath I/O 策略才能將 MIG 例項透傳或重新排程，其相容性矩陣由虛擬化廠商與 NVIDIA 共同定義。Kata Containers 等安全容器亦需在核心做專屬支援，以便在輕量級虛擬機器內直接掛載 MIG 例項。

下游

MIG 作為基礎設施層的原始能力，被下游一系列平台、排程器與應用排程層所消費與封裝，形成對終端使用者透明的產品：

• 雲端原生排程層 - Kubernetes + NVIDIA GPU Operator: 這是當前最廣泛的下游實現。NVIDIA 開源的 GPU Operator 中，MIG Manager 模組充當“配置下發器”。其使用模式分為兩種常見的策略：“單例項模式（Single）” 即每塊 GPU 只暴露一個未分割槽的例項給 K8s；“混合模式（Mixed）” 則物理 GPU 被預先分割槽，並將不同規格的例項作為獨立的可排程資源上報。Volcano、Yunikorn 等批次排程器在此基礎上擴充套件，實現跨 MIG 例項的 Gang Scheduling 和佇列優先順序預佔。
• AI 平台與 MLOps 平台 - Run:ai、KubeFlow、Determined AI： 這類平台利用 MIG 為資料科學家的 Jupyter Notebook 或分散式訓練任務分配精準的算力配額。例如，管理員可規定“每個資料科學家最多申請 2 個 2g.20gb 例項”，平台通過其排程器直接對映到物理 MIG 切片，並可在會話空閒時超時回收。
• 雲端廠商的 GPU 例項產品線 - AWS、Azure、GCP、阿里雲端： 雲端廠商是 MIG 最大的商業變現下游。他們將 A100 或 H100 物理機進一步切分為命名不同、但資源保證相同的虛擬機器例項規格。例如，AWS 的 P4d 例項底層為 A100，通過調整配置策略，可以提供面向線上推論的、視訊記憶體精準量化的經濟型小規格產品。
• 高效能 AI 推論引擎 - NVIDIA Triton Inference Server： Triton 可以精確感知其被部署的環境是否為 MIG 例項。通過 MIG_DEVICE_UUID 等環境變數，Triton Server 的一個例項僅繫結到一個 MIG 切片上，實現多個模型在同一臺伺服器、不同 MIG 切片上的併發部署，並且每路推論服務的延遲嚴格符合分配到的硬體算力與頻寬。
• 監控可觀測性系統 - Prometheus + DCGM Exporter： NVIDIA 的資料中心 GPU 管理器（DCGM）能夠採集每個 MIG 例項獨立的 SM 佔用率、視訊記憶體頻寬利用率、幀快取使用量和 ECC 錯誤計數。運維開發人員可以在 Grafana 儀表板上，追蹤具體到某位租戶配額容器內所使用例項的即時健康狀態。

受益公司

（注：本段落僅討論產業角色與受益邏輯，不構成任何投資或交易建議，不對具體公司市值或股價做預測。）

1. 核心技術與專利持有者——NVIDIA (NVDA) MIG 是 NVIDIA 資料中心產品線“硬體+軟體+生態”護城河的核心技術組成之一。其受益邏輯體現在：直接提升了旗艦 GPU（A100、H100、H200）的銷售價值——一塊高階 GPU 的採購方可同時獲得原先可能需 3-5 塊中低端卡才能實現的業務多工併發能力。同時，MIG 使得雲端廠商客戶和大型企業客戶更深度地繫結在 CUDA 生態、NVIDIA AI Enterprise 以及配套的管理與監控工具中，形成較高的轉換成本。

2. 公有雲端基礎設施提供商——Amazon (AMZN - AWS)、Microsoft (MSFT - Azure)、Alphabet (GOOGL - GCP) 以及中國大陸阿里雲端 (BABA)、騰訊雲端等 這些公司在全球範圍內大量採購支援 MIG 的 GPU 伺服器，並將其轉化為可彈性售賣、多梯度的 GPU 算力例項。例如，通過 MIG 生成 1/4 A100 例項，雲端廠商能夠以較低的計時單價吸引海量中小型研發客戶，在物理伺服器折舊期內攤薄單位算力的運營成本。由於 MIG 硬體隔離的特點，使得雲端廠商可以在不增加客戶投訴（效能抖動）的情況下，將物理伺服器“塞得更滿”，這對毛利率有直接的正面影響。

3. AI 平台與工具鏈公司——如 Run:ai、Domino Data Lab 等 這類軟體平台內建了複雜的 GPU 資源管理與動態配額功能，MIG 為其提供了簡單的時間片所不具備的硬性 QoS 基礎。平台利用 MIG 建置“算力保障型”的排程器，向終端企業客戶收取平台訂閱費或管理軟體許可費，獲利模式為 AI 基礎設施管理的 SaaS 化。

4. 伺服器 ODM/OEM 廠商——如 Dell、HPE、Supermicro、Inspur 等 搭載 A100/H100 並經過 MIG 相容性驗證的整機伺服器或 GPU 工作站，其溢價能力和附加值高於純粹的硬體組裝。這些廠商在向企業客戶投標時，將“已通過 NVIDIA MIG 認證、可完美交付多例項環境”納入本身的資料中心解決方案專業服務包。

5. 大型企業私有雲端終端使用者（間接受益） 雖非上市公司單獨分類，但如金融巨擘（JPMorgan Chase）、汽車自動駕駛公司（Waymo，Cruise），通過 MIG 可在有限的物理 GPU 上並行執行資料預處理、模型驗證與輕量訓練，從而控制飛速增長的 AI 基礎設施資本支出。

市場規模與產能約束

（注：以下資料均為基於已有公開資料與行業規律的推估，非精確計量統計。）

1. MIG 所依附的物理載體市場——資料中心 GPU 的出貨量級 MIG 是高階資料中心 GPU 的附加屬性。根據公開市場資料，2024 年 NVIDIA 資料中心業務（包括 H100/B200 等加速器及相關網路硬體）的財務營收已突破數百億美元級別（具體財務資料可參照 NVIDIA 各財季公開財報）。目前支援 MIG 的高階型號（A100、H100 及 H200）在其中的出貨數量估測佔比較高，但公開資料未見 NVIDIA 單獨揭露支援 MIG 的 GPU 晶片出貨佔比資料。

2. MIG 在雲端端的滲透模式——GPU 例項的微觀經濟模型推估 根據主要雲端廠商 2024—2025 年的公開產品頁面，主流 GPU 計算例項（以 H100 為例）通常提供按秒/按時計費的物理整卡規格，同時也提供基於 MIG 分割的、更小規格的彈性例項。當前，通過 MIG 對小模型的推論與模型微調提供標準化例項，已經迅速成為全球主要雲端平台的“標配”而非“可選件”。依據行業第三方調研（如 Liftr Insights 對雲端例項組合的追蹤），帶有 GPU 細粒度規格的例項在部分 Region 的整體 GPU 例項家族中上架比例增長迅速。

3. 產能約束因素：

• 先進封裝與 HBM 產能： MIG 本身並不額外消耗晶圓，但大容量 HBM3/HBM3e 堆疊及台積電 CoWoS（Chip-on-Wafer-on-Substrate）先進封裝產能，是高階 GPU（H100/H200/B200）出貨的硬性物理瓶頸。只要物理 GPU 缺貨，雲端廠商開放給 MIG 例項的物理伺服器就不會大幅過剩。2024 年全年，台積電多次在法說會上調 CoWoS 產能規劃，說明該瓶頸在 2025 年後會逐步緩解，但仍主導 GPU 供需。
• 企業軟體許可授權與運維複雜度： 大規模部署 MIG 並不完全是“開啟即用”，企業內部需要投入專人完成 GPU Operator 配置、CVE 安全漏洞對應的驅動熱修復策略、不同業務線峰值爭搶時的資源回收等自動化編排工作。運維能力不足會成為企業在生產大規模推廣 MIG 的內部約束。

4. 中國區市場特殊因子： 受限於出口管制要求，中國區可獲得的合規特供版 GPU（如 H20）是否完全保留原生 MIG 的全功能支援矩陣，需參考 NVIDIA 對該型號具體的 vBIOS 功能鎖與驅動限制。至 2025 年上半年，公開資料顯示 H20 可支援部分 MIG 配置，但具體例項組合可能與全球版 H100 存在差異，此處不進行具體量化估計。

玩家對比

由 NVIDIA 主導的 MIG 和 AMD、Intel 所推行的硬體虛擬化方案，在技術路徑和商業落地成熟度上存在顯著差異。

NVIDIA MIG（行業事實標準）：

• 成熟度： 經歷兩代半架構（Ampere，Hopper）的迭代，已進入大規模生產部署驗證階段。
• 軟體棧完整度： 擁有從韌體、核心驅動、使用者態庫（CUDA）、容器執行時外掛（NVIDIA Container Toolkit）、Kubernetes 編排器統一排程（GPU Operator）到上層監控與效能剖析工具（Nsight Systems，DCGM）的全鏈路支援。
• 商業適用面： 直接嵌入全球前幾大公有雲端架構，被全球頭部企業採納為預設規格。

AMD 硬體分割槽方案（基於 CDNA3 與 MxGPU 多重路徑）：

• 資料中心 GPU 分割槽： 在 MI300X 上，AMD 採用基於其底層 XCD（加速運算晶片）陣列或 AID 硬體的物理分割槽模式。預設模式可通過amdgpu核心模組及 ROCm 驅動將多個 XCD 組合或單獨暴露，支援部分級別的時空分割槽，使一個 MI300X 可以類似地當作多個符合特定視訊記憶體容量的小規格 GPU 使用。其在錯誤程序隔離、CU（Compute Unit）精確配額頻寬 QoS 方面的硬體實現精細度，與同代 NVIDIA MIG 處於不斷追趕和對比的階段。據 2024—2025 年公開的社群文件，AMD 分割槽方案的生態整合（尤其是向上封裝到 Kubernetes 統一 Device Plugin 的自動化能力）仍低於 NVIDIA MIG 的 GPU Operator 成熟度。
• MxGPU（SR-IOV 路徑）： 基於 SR-IOV 標準，主要面向 Radeon Pro V 系列專業視覺化與虛擬桌面場景，僅在部分專業圖形處理領域與 NVIDIA vGPU 形成競爭，不適配 HPC/AI 場景的算力與視訊記憶體精細控制需求。

Intel Data Center GPU Max / Gaudi 系列： Intel Data Center GPU Max（代號 Ponte Vecchio）支援多 Tile 多棧架構，但對硬體多例項的商用配置模板公開揭露甚少。至 2025 年上半年止，公開資料未見與 NVIDIA MIG 對標的成熟商業化硬體分割槽管理工具。Intel Gaudi 系列主要通過其軟體機制實現容器化資源分配，暫未推出類似 MIG 的、面向多租戶的硬隔離分割槽方案。

綜合對比： 當前在“AI 計算硬體級分割槽”這一垂直領域，NVIDIA MIG 憑藉其縱向整合的 CUDA 生態及 Kubernetes 排程能力，在成熟度、使用者規模、生產級案例方面均處於領先身位。

風險

1. 鎖定效應與成本風險： MIG 是純專有技術（Proprietary），所有介面、驅動與管理機制均由 NVIDIA 閉源實現。長期依賴 MIG 進行基礎設施分割槽，意味著整個 AI 算力排程鏈條（從容器化外掛到 Infra 監控）緊密繫結在 CUDA 生態上，橫向遷移至其他 GPU 架構（如基於 SYCL 或 ROCm 生態的方案）的技術和人力成本極高。

2. 例項碎片化與運維複雜度激增： 開啟 MIG 之後，物理伺服器的算力抽象介面從“8 塊 GPU”瞬間擴充套件成“56 個小例項”。如果缺乏成熟的混合策略自動排程，將帶來嚴重的資源碎片化（Resource Stranding）問題——例如，GPU 上顯示仍有充足的視訊記憶體，但所有計算切片都已分配出去，導致無法利用那塊“孤島視訊記憶體”。資料中心管理員必須具備相當高超的容量規劃能力和 K8s 排程引數調優技能。

3. 多租戶下面臨的安全側通道攻擊風險（學術與前沿方向）： 儘管 MIG 提供了強力的視訊記憶體與快取隔離，學術界近年已有研究探討通過功耗側通道、溫度感應或共用電源調節模組（VRM）時鐘變化，跨 MIG 例項推測相鄰例項計算負載特徵的可能性。雖然目前此類攻擊尚無大規模實際利用案例，但對於處理極高安全密級資料（如政府、國防）的雲端環境，這是需要持續關注的風險向量。

4. MIG 例項規格變更的停機成本： 改變 GPU 的 MIG 配置（例如原本是 2g.20gb x 3 + 1g.10gb，現改為 4g.40gb + 3g.40gb）需要徹底清空該 GPU 上所有正在執行的例項，並對該 GPU 執行復位或整機冷重啟。在 7×24 小時的線上推論叢集中，這會形成一個有巨大運營衝擊的“停機視窗”，導致管理員缺乏對配置進行敏捷調優的空間。

5. 軟體棧相容性“踩坑”： 並非所有 CUDA 庫都對 MIG 完全透明。特別是某些依賴 P2P 直接記憶體訪問進行同步的第三方 C++ 數學庫，或部分成熟度低的模型伺服器，在 MIG 環境中至少需要進行一次程式碼適配或加入額外的 CUDA_VISIBLE_DEVICES 檢查。此類隱性遷移成本容易被低估。

誤讀糾偏

1. 誤讀：“MIG 就是 NVIDIA 給 GPU 加的虛擬機器，會有嚴重的效能虛耗。” 糾偏： MIG 不依賴 Hypervisor 進行每一條 GPU 指令的截獲與翻譯。它的配置是一次性通過硬體描述符“燒錄”設定到 GPU 內部路由表，分配完成後，每個例項內的 SM 排程器直接對物理單元進行排程。硬體劃分機制本身幾乎不產生持續的執行時效能稅。除初始化階段外，MIG 例項執行其分配比例資源的計算效率與年增率例資源的未分割槽物理 GPU 效能高度一致（遵從 NVIDIA 公佈的標準引數）。它將效能損失壓低到了傳統軟體虛擬化無法觸及的水平。

2. 誤讀：“一塊 H100 開了 MIG，就可以把它當成 7 張獨立的小 GPU 來訓練一個超大型模型。” 糾偏： 這是最危險的誤用之一。MIG 是單向的切割工具，嚴禁高頻寬互聯。在 MIG 模式下，NVIDIA 硬體切斷或禁止了例項間的 xBar、NVLink 與 PCIe P2P 路徑。大型模型分散式訓練通常依賴 NCCL 庫高速跨 GPU 交換資料，一旦 GPU 處於 MIG 狀態，多例項多機訓練將直接報錯或回退到極慢的主機記憶體中轉。核心結論：需要強耦合跨卡通訊的任務，請關閉 MIG；高併發、低耦合的推論與微服務，是 MIG 的最佳實踐場。

3. 誤讀：“MIG 可以動態切分，我隨時可以劃一部分視訊記憶體給另一個例項用。” 糾偏： MIG 不支援使用者態執行時的即時動態視訊記憶體熱遷移或熱插拔。所有配置均屬於“計劃內靜態劃分（Planned Partition）”。要實現配置變更，必須將對應物理 GPU 上所有例項清空，並執行 GPU 復位。這是一個計劃性停機操作，不能實現“按需突發”的彈性。

4. 誤讀：“AMD 的普通 GPU 也能通過開源工具做到和 MIG 一模一樣的事。” 糾偏： 市面上確實存在基於 ROCm 或開源驅動的 GPU 共享方案。但絕大多數屬於軟體層面的視訊記憶體超分或時間片切換，缺乏硬體級 SM 精確圍牆、L2 快取分割槽和視訊記憶體控制器的頻寬硬 QoS 保證。在面向付費使用者時，這些方案無法提供與 MIG 同級的效能反黃隔離和故障安全邊界，商業交付能力有本質差異。

最新事件（截至 2025 年上半年）

• NVIDIA Blackwell 釋出與 MIG 細節待公佈： 在 GTC 2024 與 2025 年度更新中，NVIDIA 釋出了 Blackwell 架構。公開資訊強調了第二代 Transformer Engine、NVLink-C2C 互聯與 RAS（可靠性、可用性、可服務性）引擎，但對於 Blackwell 的 MIG 演進（例如是否支援跨 Die 組合例項、例項最大數目限制等），截至 2025 年上半年，NVIDIA 尚未釋出詳細的技術白皮書與配置矩陣。產業中仍在持續追蹤相關資訊。
• 頭部雲端廠商大規模上線 H200 例項： 2024 年末至 2025 年初，CoreWeave、Lambda、AWS 陸續宣佈 H200 例項正式可用。H200 擁有容量大幅增加的 HBM3e，理論上 MIG 切片例項獲得的視訊記憶體區也會年增率例放大，適合更大引數量的模型推論切片化部署。在此時間視窗，許多企業開始評估 H200 上 MIG 例項對主流開源大型模型（如 Llama 3 70B 等）的單例項承載能力。
• AMD 強調 MI300X 分割槽生態進展： AMD 在 2024 年及 2025 年初的技術峰會上，頻繁演示了基於 MI300X 的硬體分割槽及開源 ROCm 容器化部署工具，並在 Databricks、Microsoft Azure 等部分企業平台中逐步投入測試與應用。目前全球公開測試使用者基數仍小於 NVIDIA MIG 部署規模，但 2025 年被部分行業報告視為“MI300X 分割槽例項進入生產級”的時間點。
• 中國合規 GPU（H20 等）的 MIG 功能限制現狀： 國內通過不同渠道到貨的合規 GPU 型號，MIG 功能是否啟用存在批次差異。尤其在部分國內雲端平台的公開文件中，對於 H20 是否開放完整的 7 例項硬體分割並承諾效能隔離，措辭趨於審慎，僅保證部分有效配置。企業採購時需對特定批次進行實際韌體與驅動的相容性驗證。

追蹤指標

1. NVIDIA 架構演進與技術白皮書釋出頻率： 每次新一代資料中心 GPU 架構釋出，重點查閱官方 MIG 章節中關於最大例項數、合法配置矩陣以及是否引入“跨 Die 組合”或“動態區域性重配”的字眼，這是技術迭代節奏的最高可信指標。

2. 主要雲端廠商 GPU 例項規格清單變化： 定期掃描 AWS EC2（如 P5, P5e）、Azure ND、GCP A3 系列的例項型別。如果來自同一物理卡規格的“中型”、“小型”MIG 例項種類增加並逐漸成為預設推薦，標誌著 MIG 在進一步下沉為其商業模式支柱。

3. Kubernetes GPU Operator 及 NVIDIA Container Toolkit 的更新日誌（GitHub）： 關注對 MIG 策略（Mixed/Single）的增補、對 MIG 分割槽碎片自動重整功能的引入，以及是否出現針對 MIG 例項層的細粒度 GPU 監控指標。這些變更直接反映 NVIDIA 對運維側痛點的解決進展。

4. 第三方雲端提供商（如 CoreWeave，Lambda， Vultr）的公開硬體清單： 由於此類 GPU 密集型雲端往往較早拿到新卡，它們提供 MIG 切分例項的動態，可視為衡量該功能在新架構（如 B200）上就緒度的先行訊號。

5. AMD ROCm 硬體分割槽例項在主流架構（PyTorch， JAX）的 CI/CD 覆蓋率： 如果 PyTorch 和 JAX 上游的每日建置流水線開始正式納入基於 MI300X 分割槽例項的自動化測試，表明 AMD 分割槽方案已經越過從“樣板間”到“全棧生產就緒”的關鍵瓶頸。

6. 企業年度基礎設施部署調查（如 CNCF 雲端運算年度報告）： 檢查在“GPU 算力排程”條目下，關於 MIG（或等同的硬體分割槽技術）的選擇比例變化。這是判斷在企業私有雲端環境中，硬體分割槽是否成功內化為生產級標準架構的長期訊號。

信源

1. NVIDIA 官方技術文件與白皮書：

   • NVIDIA Multi-Instance GPU (MIG) 使用者指南及白皮書（針對 Ampere 及 Hopper 架構）；
   • NVIDIA GPU Operator 文件（K8s 外掛與 MIG Manager 配置部分）；
   • NVIDIA H100 與 B200 架構技術概述白皮書（查閱其 MIG 相關章節）。
   • 提示：可在 NVIDIA Technical Blog 及 Docs 站點檢索上述技術名稱。

2. GPU 雲端廠商公開產品頁面：

   • Amazon Web Services - EC2 P4d, P5 以及相關例項型別文件；
   • Google Cloud GPU Platforms - A3 系列例項說明；
   • Microsoft Azure - ND A100 v4 系列、ND H100 v5 系列規格表；
   • 阿里雲端 GPU 計算型例項規格族文件（對應 ecs.gn 系列）。
   • 提示：資訊截至 2025 年上半年公開可查資料。

3. 行業追蹤與第三方技術分析：

   • Liftr Insights — 追蹤主流雲端廠商提供的例項型別與晶片配售變化；
   • SemiAnalysis — 針對 GPU 硬體架構和資料中心 AI 基礎設施的深度通訊（部分內容付費）。

4. 開源社群與程式碼庫：

   • NVIDIA/k8s-device-plugin (GitHub) — 檢視 Issues/PR 中關於 MIG Strategy 的實際案例；
   • ROCm/ROCm (GitHub) — 檢視關於 MI300X 分割槽與 ROCm SMI 工具鏈進展。

5. 對比參考與虛擬化方案：

   • AMD MxGPU 與 ROCm 硬體分割槽相關的官方開源文件；
   • Linux 核心郵件列表（LKML）中關於 amdgpu 和 nouveau 對多例項功能支援的討論。

---

*宣告：本文件整合了 NVIDIA 公開白皮書、主要雲端服務商公開資訊、以及截至 2025 年上半年第三方產業分析與開源專案（如 Kubernetes GPU Plugin、ROCm）的公開進展。文中涉及的上市公司名稱僅供產業環節闡述，不應被誤解為任何形式的投資或交易建議。本文不含任何對股價、營收或市場