AI 加速器效能與基準
評估用於大型語言模型 (LLM) 的 AI 硬體時，需要採用一致且與供應商無關的方法，並將其做為主要工作負載。本指南說明如何比較不同供應商 (例如 NVIDIA、AMD、 Google和 AWS) 的 AI 加速器晶片效能。這些原則和方法適用於任何 AI 晶片或工作負載，但範例著重於常見的產業配對，也就是執行 LLM 工作負載的 NVIDIA 圖形處理單元 (GPU) 和 Tensor 處理單元 (TPU)。 Google
模型通常會針對特定硬體平台進行最佳化，因此只評估模型效能，不足以瞭解硬體的功能。評估 LLM 的加速器晶片時，請考量三個重要層面：微基準測試、屋頂線分析，以及訓練和推論的模型基準測試。
微基準化和屋頂線分析是瞭解特定加速器平台功能和潛力的必要做法。瞭解這項資訊後，即可在訓練和推論期間進行模型基準化，比較晶片之間的實際工作負載，並深入瞭解模型架構是否已針對特定平台最佳化。
成效維度
建議評估人員從三個層面思考效能，以便更全面瞭解特定加速器系統：
- 微基準測試：擁有最高硬體規格不代表應用程式能實際運用這些規格。您可以透過微基準化評估每秒浮點運算次數 (FLOPS)、高頻寬記憶體 (HBM) 和網路頻寬，對實際工作負載可達成的成效有何影響。
- 屋頂線分析：記憶體頻寬或運算速度可能會阻礙硬體發揮最佳效能。您可以運用屋頂線模型和不同系統元件的作業強度 (OI)，瞭解硬體和工作負載是否合適。微基準和屋頂線的組合可提供理論評估，瞭解所選硬體可為不同類型的工作負載達成哪些目標。
- 模型基準化：對訓練和推論工作負載進行基準化，以測量每個晶片的每秒權杖數 (TPS/chip)，即可評估不同平台上的相同模型。如果初始結果與微型基準化和頂線分析不同，表示需要額外的軟體工作，才能達到先前識別的頂線。舉例來說，這項工作可能包括變更分片策略或採用自訂核心。
請注意，模型基準化是針對特定模型、規模和平台，在特定時間點進行的快照方法。進階使用者評估效能時，也會考量產業趨勢 (例如模型架構)、微基準測試和屋頂線結果。
模型與硬體共同設計
進行效能評估時，必須仔細考量模型架構，並將測試的硬體納入考量。有效率設計的模型通常是針對特定硬體平台共同設計，以利用特定平台的細微差異。因此，這些模型可能無法充分運用其他平台，甚至是同一平台的不同世代。舉例來說，為 NVIDIA Hopper GPU 設計的模型可能無法充分運用 AMD GPU 或 NVIDIA Blackwell GPU。
當您在功能可能不同的硬體平台之間移動時，這項考量就特別重要，因為為某個平台設計的模型可能需要進行設定變更、軟體變更或兩者兼具，才能在不同平台上達到最佳效能。對最佳化模型進行基準化測試，是驗證供應商「理論峰值」效能行銷宣傳內容，以及評估實際結果的必要做法。獨立分析公司 SemiAnalysis 指出：「比較理論 FLOPS 只能說明部分情況。重要的是有效 FLOPS，因為在實際工作負載中，幾乎不會達到尖峰值。"
例如：gpt-oss-120B競賽項目
基準化時常見的錯誤是，在模型不適用的硬體上評估模型。OpenAI 的gpt-oss-120B 開放權重模型就是一例，說明模型架構為何必須緊密對應目標晶片。以下範例顯示模型共同設計至關重要，且必須在程序初期進行。
gpt-oss-120B 模型使用的注意力頭維度為 64。雖然這是許多 GPU 最佳化模型的標準做法，但會造成 TPU 加速器的架構不符。Trillium 和 Ironwood 等 TPU 經過最佳化，適合用於 256 的倍數矩陣維度，充分運用矩陣乘法單元 (MXU)。由於頭部維度 64 並未針對 TPU 進行最佳化，在 TPU 系統上執行 gpt-oss-120B 會導致每秒權杖數 (TPS) 和模型 FLOPS 使用率 (MFU) 降低。硬體會有效浪費時脈週期，並以零填補剩餘空間，以符合 256x256 的執行格線。
使用 gpt-oss-120B 做為 TPU 的基準，可能會錯誤地指出硬體效能不佳，但實際上反映的是軟體架構不符。如要準確評估加速器的「上限」，請使用專為特定幾何結構共同設計的模型進行測試。舉例來說，Gemma 4 等模型具有 128 或 256 個頭部維度。您可以透過自訂核心提升這個模型的效能，避免填補零，而是「填滿」MXU，但這需要專業知識，且無法達到與 GPU 相同的效能水準。您也可以變更頭部尺寸，進一步針對 TPU 進行最佳化，但這項變更會使現有模型權重失效，因此需要重新訓練。
基準化原則
為提供公平且適用於未來的評估結果，請考慮下列原則，以便在加速器之間進行基準測試：
- 著重於每美元的效能：部分供應商著重於單一晶片的原始效能，但每美元的系統層級效能更能代表整體總持有成本 (TCO) 和價值。如果晶片 A 的效能比晶片 B 高出 20%，但價格也貴了 50%，評估人員應認清晶片 B 的每美元效能增益。此外，也請將每瓦效能納入成本考量。
- 代表現代 AI 工作負載：著重於熱門的 Transformer 架構模型、大型叢集和最新架構，同時考量產業趨勢。舉例來說，業界改用稀疏混合專家 (MoE) 模型後，更難充分運用 FLOPS，同時也對網路的二分頻寬提出更高要求。
- 確保廣泛支援開發人員需求：考量不同工作負載的效能、彈性和擴充性：訓練、微調，以及為各種 LLM 和其他模型提供服務。
- 選擇不限供應商的模型和工具：選擇可在加速器之間執行的模型和引擎，方便進行跨加速器評估。舉例來說，您可以使用 Qwen 和 Gemma 等開放模型，以及在 GPU 和 TPU 上執行的開放原始碼推論引擎，例如 vLLM。避免使用特定硬體的 PyTorch/CUDA 堆疊。如要進行模型訓練基準化，當模型在各平台間保持不變時，供應商專屬的架構 (例如 TPU 的 MaxText 和 GPU 的 Megatron) 最實用。
- 模型共同設計：經驗豐富的使用者共同設計模型，充分發揮硬體平台的效用。如果模型是在晶片 A 上訓練，請勿期望在晶片 B 上有良好的「開箱即用」效能。
- 考量整個硬體系統：部分加速器可能會在 FLOPS 等領域宣傳高效能，但其他領域的瓶頸 (例如記憶體頻寬) 可能會大幅限制加速器的功能。系統的其他考量因素包括晶片規格、晶片網路和向外擴充架構。
- 硬體和軟體穩定性：大規模訓練或重要推論作業中斷可能會造成極高成本。同樣地，AI 加速器的實用度取決於其執行的軟體。成熟可靠的軟體堆疊經過大規模驗證，是發揮最大價值的必要條件。
Microbenchmark
就加速器基準化而言，微基準化會隔離特定硬體元件 (例如運算核心、記憶體和互連)，以便測量這些元件的絕對限制，不會受到複雜軟體堆疊的干擾。許多供應商會強調「單晶片尖峰 FLOPS」，但實際的 AI 是分散式系統問題。微基準化有助於瞭解晶片是否僅在獨立環境中效能強大，或是否專為資料中心規模設計。
使用微基準化評估硬體的最高效能，並瞭解系統的實際限制，與模型架構無關。評估加速器是否適用於未來或未確定的用途和模型架構時，微基準化特別有價值。
如要有效進行加速器微基準測試，請評估下列項目：
| 基準 | 說明 |
|---|---|
| 密集一般矩陣乘法 (GEMM) 使用率 | 以各種精確度執行經過高度最佳化的 GEMM 核心，測量加速器核心運算單元的原始持續數學運算能力。 |
| 高頻寬記憶體 (HBM) 串流 | 執行記憶體頻寬微基準測試，測量加速器內建記憶體的持續讀取、寫入和複製速度。維持健全的位元組與 FLOP 比率架構，可避免運算核心閒置。 |
| 分散式集合 (all-reduce 和 all-gather) | 在數千個晶片上執行標準化集體通訊測試，測量叢集擴充時，網路頻寬和延遲時間的嚴重程度。 |
| 主機到裝置 (H2D) 和裝置到主機 (D2H) 的傳輸速率 | 在主機 CPU 的系統記憶體和加速器之間，推送大量連續資料串流，以測量 PCIe 匯流排或自訂互連網路的傳輸速率。 |
| 持續熱節流和耗電 | 持續執行最高使用率的 GEMM 迴圈 48 小時，同時監控機架層級的耗電量，以評估持續的熱穩定性和實際的能源效率。 |
微基準測試比較範例
以下是兩款晶片的說明比較，假設晶片 A 看起來比晶片 B 好，但實際效能較差：
| 基準名稱 | 晶片 A 測試結果 | 晶片 A 規格 | 測試 / 規格比率 | 晶片 B 測試結果 | 晶片 B 規格 | 測試 / 規格比率 |
|---|---|---|---|---|---|---|
| 晶片對晶片網路 | 800 GBps | 1,000 GBps | 80.0% | 850 GBps | 900 GBps | 94.4% |
| gemm/peakTOPS | 1,800 TFLOPS | 2,500 TFLOPS | 72.0% | 1,800 TFLOPS | 2,000 TFLOPS | 90.0% |
| 記憶體頻寬 | 6,000 GBps | 8,000 GBps | 75.0% | 6,500 GBps | 7,500 GBps | 86.7% |
| 主機到裝置 | 58 GBps/晶片 | 70 GBps/晶片 | 82.9% | 60 GBps/晶片 | 65 GB/秒/晶片 | 92.3% |
| 裝置到主機 | 每個晶片 55 GBps | 70 GBps/晶片 | 78.6% | 每個晶片 55 GBps | 65 GB/秒/晶片 | 84.6% |
車頂線分析
屋頂線分析 (或屋頂線模型) 可提供視覺化資料，供您分析不同系統元件的運算強度 (OI)，以及特定設計是否適合特定平台。
AI 加速器晶片的處理量受限於下列三項主要因素：
- 運算能力：晶片的尖峰數學處理量 (FLOPS)。
- 記憶體頻寬：資料傳輸至晶片本機高頻寬記憶體 (HBM) 或從該記憶體傳輸資料的速率。
- 網路頻寬：在分散式訓練或推論期間，使用晶片網路在多個晶片之間分享資料的速率。例如 ICI (適用於 TPU) 或 NVLink (適用於 GPU) 的傳輸速率。
如要進一步瞭解屋頂線，請參閱「屋頂線簡介」。
標準屋頂線圖包含兩個軸：
- X 軸 (運算強度)：運算強度是指運算工作 (FLOPS) 與記憶體流量 (傳輸的位元組) 的比率，以每位元組的 FLOPS 表示。代表從記憶體擷取每位元組資料所完成的運算工作量。
- Y 軸 (可達成的效能)：可達成的效能以每秒浮點運算次數 (FLOPS) 表示。代表實際達成的運算輸送量。
「屋頂」是由兩條相交的線組成，代表硬體上限：
- 傾斜屋頂 (記憶體受限)：可達成的效能 = 記憶體頻寬上限 × 運算強度。在這條線上，效能會受到資料傳輸到運算單元的速度嚴格限制。
- 平頂 (受運算限制)：可達成的效能 = 運算尖峰容量。這條線上的資料供應速度夠快，運算單元能以最大容量運作。
這兩條線的交會點稱為「脊線點」。這項指標定義工作負載達到最高硬體使用率所需的最低 OI。
在上圖中，演算法 1 位於標示為「記憶體繫結」的圖表部分，並未充分運用運算單元。相較之下，Algo 2 的 OI 較高，且位於圖表中標示為「運算受限」的部分。如要最佳化演算法 1，使用者會嘗試修改演算法，以較少的資料移動量 (增加 OI) 執行更多運算，將效能向右移至山脊點。
低 OI 和高 OI 工作負載的範例
- 低 HBM 作業強度 (記憶體繫結)：元素作業 (例如 ReLU 或 GeLU 等活化函數)、層級正規化和自動迴歸解碼 (批量大小 = 1 推論) 等工作負載。
- 高 HBM 作業強度 (運算受限)：工作負載，例如 GEMM 或大型批次卷積神經網路。矩陣乘法會多次重複使用擷取的資料 (將資料列乘以資料欄)，因此 OI 非常高，工作負載位於平坦的運算屋頂下方。
模型基準化
模型基準化會評估實際模型效能。訓練和推論基準可讓您比較特定時間點熱門模型的效能。
下表比較模型基準化功能為訓練和推論工作負載提供的洞察資訊：
| 深入分析 | 訓練工作負載 | 推論工作負載 |
|---|---|---|
| 規模 | 通常是較大規模的測試 (1 萬個以上的晶片，最大型模型最多可達 10 萬個以上)。深入瞭解分散式工作負載、通訊負擔和叢集層級的網路限制。 | 通常是較小的測試 (1 到 64 個以上的晶片)。深入瞭解平台在負載情況下，如何處理同時上線的使用者和快速擴充。 |
| 效能 | 通常更受運算限制。測量每個晶片每秒處理的權杖數，以及模型 FLOPS 使用率 (MFU)。 | 易受到延遲影響。評估第一個權杖的產生時間 (TTFT)、權杖間的延遲時間，以及每位使用者每秒產生的權杖總數。 |
| 延遲時間 | I/O 和互連延遲，可突顯載入大型資料集時的儲存空間瓶頸，以及同步梯度更新期間節點之間的網路延遲。 | 端對端回應延遲，可突顯佇列延遲、端點延遲和使用者等待時間。 |
訓練基準
如要判斷真正的硬體和網路效率，您必須將各加速器的效能標準化為單一可比較的指標：每個晶片的每秒權杖數 (TPS/chip)，同時保持特定代表性模型架構不變。追蹤 TPS/晶片在您調整叢集大小時的行為，即可找出系統隱藏的「規模稅」。
為了將效能與加速器成本正規化，請進一步將 TPS/晶片除以每個晶片的成本，得出 TPS/晶片/$，這會成為另一個比較點。
針對每個要進行基準化測試的模型，評估下列項目：
| 基準 | 說明 |
|---|---|
| 測量基準 TPS/晶片和 TPS/晶片/$ |
在最小可行的叢集上執行目標模型。記錄全域訓練處理量 (每秒處理的總權杖數)，然後除以晶片數量，建立每晶片的基準 TPS。除以加速器成本，即可得出每晶片每美元的 TPS。 您也可以在訓練期間觀察模型 FLOPS 使用率 (MFU)，藉此評估觀察到的處理量相對於理論最大值的比例。這有助於瞭解硬體效能與基準測試的差距。不過，與 TPS/晶片相比，這項指標提供的晶片對晶片比較資訊較不實用。 |
| 評估縮放效能降低情形 | 將叢集擴充至 256、1024 和 4096 個晶片，並執行完全相同的模型。重新計算每個規模的 TPS/晶片。 |
| 有效輸送量帳戶 |
只有在模型實際學習時，原始 TPS/晶片才重要。計算有效處理量，評估直接推進 LLM 訓練狀態的有效運算速率，明確排除因硬體故障、網路停滯或檢查點復原而浪費的時間和能源。 大規模評估 AI 加速器時，相較於原始理論處理量，有效輸送量更能如實反映投資報酬率，因為有效輸送量會揭露硬體在容易發生故障的叢集中，維持效能的效率。 |
下表列出建議用於訓練基準測試的模型：
| 大小 | 架構 | 型號 | 理由 |
|---|---|---|---|
| 小型 (8B) | 密集 | Llama 3.1 8B | Llama 3 是標準模型，多年來一直受到 MLPerf 等基準測試標準的歡迎。 |
| 中 (700 億) | 密集 | Llama 3.1 70B | Llama 3 是標準模型，多年來一直受到 MLPerf 等基準測試標準的歡迎。 |
| 大型 (671B) | MoE | DeepSeek-V3 671B | DeepSeek-V3 在 2025 年為大小和效能設定了新標準，並在許多多晶片平台上經過最佳化調整。 |
範例：將每美元的成效正規化
假設您在 Chip_A、Chip_B 和 Chip_C 之間進行基準比較，並為常見模型執行訓練基準，以查看 TPS 的效能。然後查看同一模型中，Chip_A 效能與 Chip_B 和 Chip_C 效能的比率：
| 基準 | Chip_A TPS (以 Chip_B TPS 的分數表示) | Chip_A TPS (Chip_C TPS 的分數) |
|---|---|---|
| 小型密集：Llama 3.1 8B | 0.82 | 0.62 |
| MoE：Mixtral 8x7B | 0.72 | 0.55 |
| 大型密集：Llama 3.1 405B | 0.77 | 0.61 |
| 大型 MoE：DeepSeek-V3 | 0.85 | 0.62 |
| 平均值 | 0.79 | 0.60 |
根據上表資料，Chip_A 的平均效能為 Chip_B 的 0.79 倍，以及 Chip_C 的 0.60 倍。如果沒有更多資訊，結論會是 Chip_C 較為優異。
不過，如果晶片 A 的成本為 $100 美元、晶片 B 的成本為 $180 美元，而晶片 C 的成本為 $200 美元，那麼將每美元的成效 (perf/$) 標準化後，結果就會有所不同：
| 基準 | Chip_A 效能/$ (以 Chip_B 效能/$ 的分數表示) | 晶片 A 的每美元效能與晶片 C 的每美元效能比 |
|---|---|---|
| 小型密集：Llama 3.1 8B | 1.48 | 1.24 |
| MoE：Mixtral 8x7B | 1.30 | 1.10 |
| 大型密集：Llama 3.1 405B | 1.39 | 1.22 |
| 大型 MoE：DeepSeek-V3 | 1.53 | 1.24 |
| 平均值 | 1.42 | 1.20 |
以每美元的效能做為比較點時，Chip_A 的平均效能比 Chip_B 高出 42%，比 Chip_C 高出 20%。
推論基準化
訓練是龐大的前期投入成本，但服務 (因此推論) 代表長期營運支出。每晶片每秒交易數越高，支援相同作業工作負載所需的實體伺服器就越少，可大幅減少能源消耗和資料中心足跡。
在推論方面，目標是在不違反延遲時間規定的情況下，盡量提高輸送量，確保使用者體驗順暢。為固定模型標準化 TPS/晶片評估，即可直接比較不同晶片的效能。
基準化推論時，請計算 TPS/晶片/$，將效能標準化：
| 基準 | 說明 |
|---|---|
| 建立延遲服務水準協議 |
首先，請為使用者體驗設定嚴格的服務等級協議。舉例來說，可預測的尾部延遲時間 (P99) 為 100 毫秒。使用 TTFT (少於 500 毫秒) 和每個輸出權杖的時間 (TPOT)，評估回應性的使用者體驗。 |
| 推送批量大小 | 逐步增加對硬體的並行要求數量 (批量)。批量增加時，總處理量會提高，但延遲時間最終會變長。 |
| 記錄每個晶片的最高持續 TPS |
如果硬體違反 P99 延遲時間服務水準協議，請停止。記錄該確切批量大小的系統總處理量，然後除以晶片數量。這是您的 TPS/晶片值。 請注意，在大量批次負載下，某些一般用途加速器會出現「尾部延遲」(處理時間隨機飆升) 問題，導致運算人員必須以較低的利用率執行這些加速器，才能確保使用者滿意度。 請務必測量預先填入 (受運算限制) 和解碼 (受記憶體頻寬限制) 這兩個不同階段 |
| 計算每千個或每百萬個權杖的總持有成本 | 將單一晶片的攤銷資本和能源成本，除以晶片的最高持續 TPS/晶片。這項指標會將技術基準轉換為財務指標，揭露實際成本。 |
下表列出建議用於推論基準測試的模型：
| 大小 | 架構 | 型號 | 理由 |
|---|---|---|---|
| 小型 (8B) | 密集 | Llama 3.1 8B | Llama 3 是標準模型，多年來一直受到 MLPerf 等基準測試標準的歡迎。 |
| 中 (700 億) | 密集 | Llama 3.1 70B | Llama 3 是標準模型，多年來一直受到 MLPerf 等基準測試標準的歡迎。 |
| 大 (480B) | MoE | Qwen3 Coder 480B | Qwen3 480B 是領先的 OSS 程式設計模型。 |