本文由半導體產業縱橫（ID：ICVIEWS）編譯自semianslysis

AMD or NVIDIA?

長期以來，業界一直有觀點認爲，在總擁有成本（TCO）下，AMD 的 AI 服務器推理性能優於英偉達。過去六個月，本文通過對英偉達和AMD 提供的推理解決方案進行全面分析與基準測試，對這一說法展開了調查驗證。原本期待得到一個簡單結論，但結果遠比想象中複雜且令人意外 —— 不同任務（如聊天應用、文檔處理 / 檢索、推理任務）的性能表現存在顯著差異。

對於直接擁有並運營GPU 的超大規模企業和企業客戶，本文發現：在某些工作負載中，英偉達的每美元性能（perf/$）更具優勢；而在另一些工作負載中，AMD 的每美元性能更優。但對於通過 Neoclouds 進行中短期租賃（租期不足 6 個月）的客戶，英偉達的每美元性能始終佔優 —— 這是由於 AMD 的 Neoclouds 生態缺失，導致 MI300X、MI325X 的租賃市場價格高企；相比之下，英偉達 GPU 擁有數百家提供 H100、H200 等顯卡租賃的 Neoclouds，形成了競爭性的市場租賃價格。

AMD MI355X 本應是 B200 的競爭對手，MI325X 則被視作 H200 的對標產品。但正如後文將談到的，MI325X 的發貨延遲導致其進入市場時，大多數客戶已選擇跳過它而轉向 B200。

在2024 年 12 月發佈 AMD 培訓文章之前，本文從2024 年第三季度起就與 AMD 展開了密切合作。AMD 已採取行動改善其推理解決方案的開發者體驗與質量，並增加了持續集成（CI）自動化測試。近六個月後，本文認爲有必要進行重新評估。測試顯示，儘管AMD 迄今已做出有意義的改進，但本文仍認爲其存在較大提升空間—— 後文將討論遇到的問題及 CI 覆蓋不足的情況。

主要觀點

對於購買硬件並使用vLLM/SGLang 的客戶，根據工作負載和延遲要求，單節點 H200 部署與單節點 MI325X 的每美元性能（perf/$）呈現 “各有勝負” 的特點：部分場景 H200 更優，部分場景 MI325X 更優。

在大多數測試場景中，MI300X 與 H200 相比缺乏競爭力，無論是絕對性能還是每美元性能均表現較差。但對於 Llama3 405B 和 DeepSeekv3 670B 模型，MI300X 在絕對性能和每美元性能上均優於 H100。

對於採用中短期合同（不足6 個月）租賃 GPU 的客戶，由於僅有少數提供商提供 AMD GPU 短期租賃，市場供應緊張推高了價格，導致英偉達 GPU 的每美元性能始終更優。反觀英偉達生態，超百家 Neoclouds 提供商提供中短期租賃服務，充足的供應形成競爭性市場，有效降低了成本。

MI325X 本應與 H200 競爭，但核心問題在於：其大規模出貨推遲至 2025 年第二季度，此時 HGX B200 已出貨一個季度，導致多數供應商選擇 B200 而非 MI325X，進而造成 MI325X 銷量低迷（除 Meta 外，未見大規模超算級採購）。

MI355X 計劃於 2025 年底開始出貨，比 B200 晚兩個季度。

當前B200 和 GB200 的軟件仍未完全成熟。例如，FP8 精度的 DeepSeek V3 在 TensorRT-LLM（TRT-LLM）、vLLM 或 SGLang 上無法完全正常運行。

在目前可部署的工作負載和模型中，B200 佔據主導地位，MI325 和 H200 的性能甚至無法接近其水平。

英偉達的TRT-LLM 推理框架素以 “開發者體驗差” 著稱。儘管發佈 PyTorch 後端和類似 vLLM 的單行 CLI 服務命令後有所改善，但在開發者體驗上仍無法與 vLLM 或 SGLang 比肩。

TRT-LLM 仍需全面支持 DeepSeek，並提供預構建的 TRT-LLM-serve 容器鏡像。

服務框架提供的大量配置標誌導致“組合爆炸”，使全面基準測試幾乎不可能完成。AMD 通過添加環境變量進一步複雜化了問題（儘管本文此前建議刪除這些變量）。大多數用戶無法獲得最佳性能，因爲若不對每種工作負載進行深度調優，根本無法確定最優標誌和變量組合。

AMD AI 負責人 Anush 及其團隊正努力提升 ROCM SGLang 的 CI 覆蓋率至與英偉達持平，但目前覆蓋率仍不足 10%，差距顯著。

AMD 應利用其雄厚財務資源增加內部研發集羣投入。上個季度，AMD 花費 7.49 億美元用於股票回購，而內部研發集羣資源投入僅約 1300 萬美元。研發集羣資源匱乏是其開發者體驗落後於英偉達的關鍵原因，也是 AMD 在 AI 軟件領域持續滯後的根源。本文認爲，即便從回購資金中劃撥一小部分用於研發集羣，也能在不犧牲短期股東回報的前提下，帶來更優的長期價值。

由於缺乏CI 測試和數值精度內核，與 CUDA 相比，模型在 ROCM 上的各項評估得分普遍更低。

H100 vs MI300X vs H200 vs MI325X vs B200 vs MI355X

推理的解碼階段往往受內存帶寬限制，因此兩大核心繫統規格爲HBM 容量和帶寬。測試顯示，單個 MI300 節點（1536GB HBM 容量）相比 H100 節點（640GB HBM 容量）具有顯著優勢 ——H100 甚至無法在單節點中容納 DeepSeek V3 FP8 模型。英偉達於 2024 年第三季度大規模量產 H200，其 144GB HBM 容量解決了容量瓶頸問題，測試中性能優於 MI300。AMD 對 H200 的回應是 MI325X，但遺憾的是其上市時間滯後，導致客戶轉而選擇 B200。

來源: SemiAnalysis

MI325X 原計劃與 H200 同期（2024 年第三季度）出貨，但因延遲至 2025 年第二季度才批量上市，直接與 2025 年第一季度推出的 HGX x86 B200 SXM 競爭。大多數客戶選擇 B200 而非 MI325X，這也是除 Meta 外，MI325X 未獲超大規模採購的主因。

需要說明的是，量產延遲並非AMD 獨有問題：英偉達 GB200 NVL72 因集成 NVLink 背板的挑戰及集羣運營商缺乏調試工具，同樣面臨大規模延遲。

AMD 與英偉達數據中心 AI GPU 的市場份額

自2023 年第一季度以來，AMD 在數據中心 AI GPU 市場份額持續增長。但 2025 年第一季度，英偉達 Blackwell 大規模投產，而 AMD 的應對產品推遲至第三季度，導致其市場份額相應下降。預計 2025 年第二季度 AMD 份額將繼續下滑，但隨着 MI355X 在年底推出及軟件改進加速，AMD 有望在明年底或 2026 年初重新奪回部分市場份額。

來源:SemiAnalysis Accelerator Model, AMD Earnings, Nvidia Earnings

推理基準測試方法 - 在線吞吐量與延遲

爲了使本文的基準測試儘可能接近真實的推理工作負載，本文的推理基準測試方法強調分析給定配置下的在線吞吐量與每個用戶的端到端延遲，而不是基於傳統的離線基準測試。與離線基準測試不同，離線基準測試在理想條件下測量吞吐量，不考慮實際延遲影響，本文的方法明確捕捉系統同時處理的用戶數量與每個用戶體驗的延遲之間的權衡。通過逐步增加併發用戶數量，本文測量延遲如何增加，使本文能夠得出直接反映操作條件和用戶體驗的現實吞吐量指標。

下面將首先解釋需要理解的關鍵指標以及這些指標的定義。

吞吐量衡量在給定時間內完成的工作量，例如，每個GPU 每秒可以處理多少個令牌。更高的吞吐量意味着系統可以同時處理更多的請求，提高整體容量、效率和收入。

延遲指的是完成單個請求所需的時間，從發出請求到交付最終響應的時間。更低的延遲意味着更快的響應和更好的用戶體驗。在本文的框架中，本文關注端到端（E2E）延遲，本文在下面定義。

在推理基準測試中，這兩個指標是相關的。通過添加更多的併發請求來增加吞吐量通常會增加單個用戶體驗到的延遲。這是因爲當系統處理許多併發用戶時，資源變得更加緊張，導致單個請求等待更長時間。相反，優化低延遲通常會限制整體吞吐量，因爲同時處理的請求更少，以保持響應迅速。

理解吞吐量和延遲之間的平衡對於選擇正確的配置至關重要—— 交互式應用程序優先考慮低延遲以獲得響應迅速的用戶體驗，而批處理任務則優先考慮更高的吞吐量，即使每個請求的延遲增加。

首令牌時間（TTFT）表示用戶從發送請求到接收第一個生成的令牌所經歷的初始延遲，反映了預填充整個輸入提示令牌的時間。

輸出令牌之間的時間（TBOT）量化了生成初始令牌後連續令牌之間的延遲，捕捉穩態推理性能。

端到端（E2E）延遲計算爲 E2E 延遲 = TTFT+（輸出序列長度 ×TBOT）。這是本文分析用戶體驗的首選指標，因爲它包含了處理請求時的所有各種延遲源。這與一些僅比較每個GPU 的吞吐量與 TBOT 的分析形成對比。

來源: SemiAnalysis

傳統的離線基準測試忽略了這些延遲交互和併發效應，未能模擬現實的用戶條件，從而產生與實際操作環境脫節的過於樂觀的吞吐量數字。當離線基準測試分析吞吐量與批量大小時，結果並不準確，因爲即使給定批量大小下每個GPU 的吞吐量相同，不同的 AI 芯片也可能有非常不同的延遲。

離線吞吐量基準測試，來源：Signal65

推理基準測試方法 - 模型選擇

現實生產工作負載的模型主要有兩類：密集架構和稀疏混合專家（MoE）架構。

對於密集模型，本文測試了FP16 精度的 Llama3 70B 作爲中等規模 FP16 部署的代表，以及 FP8 精度的 Llama3 405B 作爲大規模密集場景的代表。

爲了對稀疏MoE 模型進行基準測試，本文選擇了FP8 精度的 DeepSeekV3 670B。在算術強度、近似活動、總參數計數和內存訪問模式方面，DeepSeekV3 的模型架構與 OpenAI 的 4o/4.1/o1/o3/o4 等前沿封閉模型非常匹配。因此，DeepSeek 是基準測試 OpenAI 內部模型架構的最佳代理模型。

推理基準測試方法 - 輸入 / 輸出令牌長度

本文對三種不同的輸入和輸出令牌長度組合進行基準測試，以反映現實的推理場景和性能特徵。

第一種使用4K 輸入和 1K 輸出令牌場景。這代表了以大型預填充通用矩陣乘法（GEMM）操作爲特徵的摘要任務。這種場景嚴重依賴計算，有利於英偉達 GPU 等在計算密集型預填充方面始終表現出色的架構。

第二種場景，輸入1k 令牌，輸出 1k 令牌，與翻譯或對話工作負載非常一致，平衡了預填充和解碼性能需求。

最後，本文測試了1k 輸入和 4k 輸出令牌場景。這代表了輸出大量推理令牌的推理密集型任務，這意味着性能通常受內存帶寬限制，而不是計算。評估所有這三種輸入 / 輸出長度場景可以全面瞭解模型和硬件在不同推理工作負載中的性能。

推理基準測試方法 - 推理引擎

對於Llama3 70B 和 405B 的推理基準測試，本文選擇vLLM 作爲本文的主要推理引擎。雖然許多用戶現在由於更好的性能而轉向QWEN，但 Llama3 仍然是使用最多的模型。vLLM 是這些模型中使用最廣泛的推理框架。由於其優化的性能、易用性和魯棒性，它得到了英偉達和 AMD 的認可和積極推薦。對於 H200 GPU 平臺，除了 vLLM 之外，本文還評估了TensorRT-LLM（TRT-LLM）服務。雖然 TensorRT-LLM 最初基於 C++ 的實現歷史上提供了次優的用戶體驗，但英偉達在 12 月推出了一個基於 Python 的版本，在功能和使用風格上與 vLLM 和 SGLang 類似。然而，根據本文的最新測試，這個基於Python 的 TensorRT-LLM 實現的整體用戶體驗和成熟度仍然落後於 vLLM，儘管持續的改進正在縮小這一差距。爲了完整起見，本文對這兩種實現進行了基準測試。

TRT-LLM 通過其新的 python pytorch 後端、用於啓動推理實例的簡單單行命令行界面以及兼容 OpenAI 的 HTTP 服務器，使用起來變得容易多了。然而，它仍然存在很多問題 —— 例如，DeepSeek 在 TRT-LLM 上運行不佳，英偉達也尚未發佈 python TRT-LLM-serve docker 鏡像，導致數小時的時間浪費在從源代碼安裝上。本文建議TRT-LLM 團隊修復 DeepSeek V3 實現併發布 TRT-LLM-serve docker 鏡像。

本文: SemiAnalysis

相比之下，對於更大的DeepSeek 670B 模型，本文選擇SGLang 作爲推理引擎。SGLang 是 DeepSeek 670B 部署中最常推薦和採用的推理框架，由於其能夠高效處理更大的模型尺寸和 DeepSeek 規模推理工作負載的複雜性，它得到了英偉達和 AMD 的強烈認可。

推理基準測試方法 - 並行策略

在本文的基準測試方法中，全都系統地評估了每個GPU 架構和測試場景允許的所有實際張量並行（TP）配置。例如，在對 405B 模型進行基準測試時，AMD 的 MI300X 支持 TP=4 和 TP=8 配置，而英偉達的 H100 由於內存和性能限制，通常僅支持 TP=8。對於每個並行配置，本文測量吞吐量和延遲，以構建性能上限—— 確定在給定延遲要求下提供最大吞吐量的最佳張量並行策略。這種全面的方法確保本文準確地確定適合每個GPU 平臺和模型場景的最有效和性能最佳的並行設置。

請注意，本文只測試單節點場景—— 隨着主要 AI 實驗室在生產中使用的解耦解碼和解耦預填充的發明，多節點推理已成爲事實上的前沿標準。不幸的是，解耦解碼 / 預填充目前在 AMD 的開源軟件棧上不可用，僅在英偉達的系統上可用。

推理基準測試方法 - 如何解釋數據

本文的推理基準數據應該從每美元性能和每種GPU 類型之間的相對性能的角度來看待。通過微優化（例如，對 FP16 模型使用 FP8 KV 緩存或微優化最大批量令牌），有辦法繼續提高絕對性能，但這隻會優化每個 GPU 類型的特定數據點，而不是整個曲線。這就是爲什麼本文建議讀者關注每種GPU 類型之間的相對性能，而不是所實現的絕對性能。

此外，請注意，在將H200 與其他 GPU 類型進行比較時，本文提供了H200 在使用 TRT-LLM 推理框架和 vLLM 時的結果。TRT-LLM 提供了更強的性能，但它的開發人員體驗比 vLLM 差。本文建議查看vLLM H200 和 TRT-LLM H200 的數據點，而不僅僅是 TRT-LLM H200 的性能曲線。

本文的基準測試在Docker hub 上提供了本文嘗試過的確切vLLM 和 SGLang 版本，以便於重現。

Llama3 70B FP16 吞吐量與延遲結果

來源: SemiAnalysis

上圖顯示了在1k 輸出 / 1k 輸入場景下服務 LLaMA 3 70B 的結果，該場景映射到翻譯和聊天應用程序。本文看到，在低延遲場景下，使用vLLM 的 H100 和 H200 優於兩個 AMD GPU，但 MI325X 在更高的批量大小 / 更高的併發性下勉強領先並超過英偉達設置。

關於張量並行（TP）規模，本文發現TP=8 在低延遲場景中占主導地位，而 TP=2 或 TP=4 在更大批量 / 高併發下提供最高吞吐量。對於 AMD GPU，TP=1 從未實現最佳性能，僅 MI325X 在高併發場景下是唯一例外。本文認爲這是因爲在高併發時，通信量足夠大，使得從HBM 加載數據與通過 NVLink 通信數據的性能差異顯著。MI325X 的 TP=1 數據點體現了高 HBM 帶寬的優勢。

總體而言，搭載TRT-LLM 的 H200（標記爲 H200-TRT）在基準測試中大多佔據主導地位。本文認爲這得益於英偉達對自身硬件的深度理解和對性能調優的大量投入。

來源: SemiAnalysis

在LLaMA 3 70B 的類推理工作負載（1k 輸入，4k 輸出）中，H100 的性能明顯低於所有其他 GPU，每秒每 GPU 吞吐量迅速穩定在約 900 tokens 左右。另一方面，MI325X 的性能平臺期晚於所有其他 GPU，這意味着它在約 450 秒延遲時具有最高吞吐量。這也解釋了爲何使用 vLLM 的 H200 在高併發時超越 MI325X，儘管其在低延遲區域的性能優於 MI325X。在 300 秒以下延遲場景中，性能排名（從優到劣）清晰如下：搭載 TensorRT-LLM 的 H200、H200、MI325X、MI300X 和 H100。

來源: SemiAnalysis

在處理LLaMA 3 70B 的類摘要工作負載（4k 輸入，1k 輸出）時，工作負載的預填充密集特性通常更有利於英偉達 GPU。本文看到，在30 秒延遲標記後，H100 超越 MI300X，使用 vLLM 的 H200 則領先於 MI325X。然而，MI325X 的 TP=1 配置在高併發時再次表現出色，優於使用 vLLM 的 H200。搭載 TensorRT-LLM 的 H200 則始終無人能及，從 20 秒標記開始即在所有節點提供最高吞吐量。

LLaMA3 405B FP8 吞吐量與延遲結果

來演: SemiAnalysis

在處理1k 輸入和 1k 輸出的 LLaMA 3 405B 時，本文發現大多數設置的性能迅速進入平臺期。在40 秒以下延遲時，MI325X 和 MI300X 均優於 H100，且出人意料地優於使用 vLLM 的 H200。總體而言，MI325X 持續優於使用 vLLM 的 H200、MI300X 和 H100。在 150 秒延遲限制下，H100 每秒吞吐量勉強達到 400 tokens。這表明在服務大型密集模型時，內存帶寬至關重要。

與此同時，搭載TensorRT-LLM 的 H200 再次碾壓競爭對手。它可在 150 秒延遲內實現每 GPU 近 1000 tokens / 秒的吞吐量，且在更高併發下未見平臺期跡象。本文認爲這是因爲TensorRT-LLM 對內存使用的控制更佳，從而能夠維持更高的內存利用率並提升性能。

來源: SemiAnalysis

在處理LLaMA 3 405B 的推理工作負載（1k 輸入，4k 輸出）時，內存限制的影響顯著。例如，本文看到H100 的吞吐量不及同類產品的一半。使用 vLLM 的 H200 性能也低於 MI300X，僅在更高併發（需更多計算）時纔再次超越。然而，這仍無法使使用 vLLM 的 H200 與 MI325X 競爭。MI325X 在所有場景中均優於 H100、MI300X 和使用 vLLM 的 H200。

搭載TensorRT-LLM 的 H200 再次展現技術優勢，在相似延遲下吞吐量比 MI325X 高 1.5 倍。這表明 vLLM 遠未達到最優，也解釋了爲何 vLLM 將 TensorRT-LLM 視爲主要競爭對手。

來源: SemiAnalysis

根據上圖，本文可以得出結論：服務大型密集模型是AMD GPU 的優勢。具體而言，MI325X 在所有延遲場景中均擊敗競爭對手，MI300X 甚至在約 250 秒延遲時優於使用 vLLM 的 H200。另一方面，H100 的吞吐量穩定在約 350 tokens / 秒，使用 vLLM 的 H200 爲 600 tokens / 秒。與其他情況一樣，搭載 TensorRT-LLM 的 H200 在 50 秒延遲標記後顯著超越所有其他配置，佔據絕對優勢。

儘管類摘要工作負載以預填充爲主，但運行大型密集模型仍受內存限制，這一點從圖表中也可看出。這就是AMD 選擇使用 MI300X 和 MI325X 進行大型模型服務的原因。

DeepSeekV3 670B FP8 吞吐量與延遲結果

對於DeepSeekV3 670B，本文使用SGLang 推理框架並測試了 H200、MI300 和 MI325X。本文未測試H100，因爲它無法在單個節點中容納 DeepSeekV3 670B。

在翻譯和聊天應用場景（1k 輸入 1k 輸出）中，本文看到H200 在所有延遲級別上均擊敗 MI300X。MI325X 僅在 25 至 35 秒的小範圍延遲內與 H200 競爭，其餘延遲範圍內 H200 均佔優。在低延遲、高交互性場景中，當每個模型副本同時處理 4-16 個併發用戶時，H200 是明顯的贏家。

來源: SemiAnalysis

在推理測試場景（1k 輸入 / 4k 輸出）中，H200 在所有延遲範圍內均擊敗 MI300X。但 MI325X 在超過 100 秒的延遲範圍內擊敗 H200，而在 100 秒以下延遲時，H200 仍是明顯贏家。

來源: SemiAnalysis

在摘要任務場景（4k 輸入，1k 輸出）中，H200 與 MI300X 的對比結果類似 ——H200 在所有延遲範圍內均碾壓 MI300X。對於 MI325X，延遲超過 25 秒後開始超越 H200。在更偏向在線低延遲的用例中，H200 擊敗 MI300X 和 MI325X。

來源: SemiAnalysis

在大多數應用所需的中低延遲場景中，H200 擊敗 MI300X 和 MI325X，這也是 OpenAI 等實驗室選擇 H200 的原因。

每小時每 GPU 的 TCO—— 自主擁有和運營的集羣

在考慮總擁有成本（TCO）時，選擇 AMD 還是英偉達 GPU 需要仔細評估資本支出和持續運營成本。AMD 的 MI300X 和 MI325X GPU 的每小時總成本通常低於英偉達的 H100 和 H200 GPU。

對於每個延遲和模型測試場景，本文以每百萬tokens 成本爲單位計算了每美元性能，以反映計入下表所示的總擁有成本後 AMD 與英偉達的性能差異。請注意，下圖基於下表中的 TCO 生成，代表客戶自行購買 GPU 的總成本，不反映從 Neoclouds 租賃 GPU 的成本結構。

下面，本文將深入探討資本支出、運營支出和TCO 計算背後的詳細財務分析和戰略考量。

來源: SemiAnalysis

LLama3 70B FP16 每百萬 tokens 成本

來源: SemiAnalysis

在超低延遲推理中，MI325X 和 MI300X 在 LLama3 70B 聊天和翻譯任務（1k 輸入 / 1k 輸出）的每美元性能上超越所有其他 GPU。

來源: SemiAnalysis

從更長遠的延遲週期來看，當延遲超過20 秒時，價格差異開始顯現。AMD GPU 的性價比低於 H100 和使用 vLLM 的 H200，但隨着延遲增加，MI325X 因其在高併發下的出色性能而比 H200 更經濟。

來源: SemiAnalysis

轉向推理場景（1k 輸入，4k 輸出），從低延遲應用開始，MI325X 和 MI300X 在 TCO 性能上勝出。

來源: SemiAnalysis

將分析擴展到更長的延遲週期，本文發現由於性能較弱，在H100 上運行 LLaMA 3 70B 的成本效益最低。MI300X 和 MI325X 比使用 vLLM 和 TensorRT LLM 的 H200 更昂貴，但在更高延遲下更具競爭力。有趣的是，在 MI300X 上運行的成本幾乎與 MI325X 相當，這表明在此案例中 MI325X 的性能提升未能證明其價格上漲的合理性

來源: SemiAnalysis

來源: SemiAnalysis

摘要工作負載也呈現類似趨勢。AMD GPU 在低延遲區域性價比最高，H100 則落後於所有其他配置。雖然使用 vLLM 和 TensorRT 的 H200 在中延遲區域最經濟，但 MI325X 的每百萬 tokens 成本低於使用 vLLM 的 H200，並與使用 TensorRT 的 H200 相當。

LLama3 405B FP8 每百萬 tokens 成本

來源: SemiAnalysis

來源: SemiAnalysis

在聊天和翻譯場景（1k 輸入，1k 輸出）中，AMD GPU 的低價和在服務大型密集模型時的更高性能使成本效率差異更加明顯。本文看到，MI325X 的服務成本持續低於使用 vLLM 的 H200 和 H100，MI300X 也與使用 vLLM 的 H200 相當。儘管如此，搭載 TensorRT LLM 的 H200 在 60 秒延遲標記後憑藉卓越性能再次勝出。

來源: SemiAnalysis

對於405B 推理任務的超低延遲場景（1k 輸入，4k 輸出），MI325X 和 MI300X 無疑擊敗使用 vLLM 的 H200 和 H100，甚至超越使用 TRT-LLM 的 H200！

來源: SemiAnalysis

從推理任務場景的更長延遲來看，與之前所有服務大型密集模型的配置一樣，MI300X 和 MI325X 的性價比均高於 H100 和使用 vLLM 的 H200。但需注意，搭載 TensorRT LLM 的 H200 仍是所有配置中成本效率最高的，因其性能提升幅度超過了與 AMD GPU 的價格差異。

來源: SemiAnalysis

來源: SemiAnalysis

轉向摘要場景（4k 輸入，1k 輸出），MI325X 是明顯的贏家。在低延遲時，MI325X 超越包括搭載 TensorRT LLM 的 H200 在內的所有配置，且在高延遲時仍具競爭力。MI300X 在高延遲時的成本效率也優於使用 vLLM 的 H200，在低延遲時接近搭載 TensorRT LLM 的 H200。令人驚訝的是，儘管性能更優，搭載 TensorRT LLM 的 H200 此次未能證明其價格的合理性。

DeepSeekv3 670B FP8 每百萬 tokens 成本

來源: SemiAnalysis

在聊天和翻譯任務（1k 輸入，1k 輸出）中，MI300X 的每美元性能無法與 H200 競爭，而 MI325X 僅在 25 至 40 秒延遲內與 H200 有一定競爭力，但優勢不大。每美元性能的微小提升不足以抵消切換和採用 ROCM 的成本。

來源: SemiAnalysis

在推理任務（1k 輸入，4k 輸出）中，本文看到延遲超過100 秒後，MI325X 優於 H200，每美元性能比 H200 高 20%。但在低延遲 / 中高交互性場景（即延遲低於 100 秒）中，H200 仍輕鬆勝出。MI300X 在推理任務的每美元性能上無法與 H200 競爭。

來源: SemiAnalysis

在摘要任務（4k 輸入，1k 輸出）中，H200 在低延遲 / 高交互性的每美元性能上勝出。

來源: SemiAnalysis

在摘要任務的中高延遲場景中，MI300X 與 H200 具有競爭力，MI325X 的每美元性能比 H200 高 20-30%。

爲何除了超大規模企業外沒人用 AMD？

上述每TCO 性能分析聚焦於直接購買場景 —— 比較大型超大規模企業或企業直接購買硬件時的 AMD GPU 與英偉達 GPU，而非從 Neoclouds 租賃 GPU 的情況。

在GPU 租賃方面，成本差異顯著。AMD 相比英偉達面臨顯著競爭劣勢，主要原因是供應有限和市場競爭不足。

目前，超過100 家不同的 Neocloud 提供商提供英偉達 GPU 的短期（不足 6 個月）租賃，形成價格競爭並壓低租賃成本。相比之下，僅有少數提供商提供類似的短期 AMD GPU 租賃。

租賃市場的這種稀缺性導致AMD GPU 租賃價格人爲高企，削弱了其整體成本競爭力。因此，在租賃市場中，無論延遲要求如何，英偉達在每美元性能上始終優於 AMD。這種不平衡解釋了爲何除主要超大規模企業外，AMD GPU 的採用率極低 —— 超大規模企業通常直接進行長期 GPU 採購，可利用 AMD 有利的硬件經濟性，而無需面對 AMD 租賃市場的價格限制。

對於推理計算的租賃者，AMD GPU 需達到何種租賃價格才能與英偉達競爭？

2025 年第二季度，H200 的當前 1 個月期合同市場租賃價格約爲 2.5 美元 / 小時 / GPU，低質量雲服務的價格差異較大且更低。MI325X 的 1 個月期租賃合同尚不存在，而 MI300X 的 1 個月期租賃價格超過 2.5 美元 / 小時，這使其在租賃中缺乏競爭力。以下是本文計算的MI300X 和 MI325X 需達到的約 1 個月期租賃價格，以使其與租賃英偉達 H200 競爭。

來源: SemiAnalysis

在翻譯和聊天工作負載（1k 輸入，1k 輸出）中，MI300X 租賃價格需定爲 1.9 美元 / 小時才能與 H200 競爭，MI325X 的 1 個月期合同價格需低於 2.5 美元 / 小時才能與 H200 競爭。

來源: SemiAnalysis

在推理推理任務（1k 輸入，4k 輸出）中，MI300X 的 1 個月期合同價格需低於 2.1-2.4 美元 / 小時，才能在每美元性能上與 H200 競爭。MI325X 則需根據交互性定價在 2.75-3 美元 / 小時 / GPU 之間，以具備競爭力。

來源: SemiAnalysis

在摘要任務（4k 輸入，1k 輸出）中，MI325X 的 1 個月期合同價格應爲 2.75-3 美元 / 小時，MI300X 則應定價在 2.1-2.4 美元 / 小時之間。

B200 性能初探

由於目前缺乏軟件支持，本文未在完整基準測試中納入B200。在撰寫本文時，大多數主要服務框架尚未對 B200 GPU 提供穩定支持。vLLM 的標準發佈鏡像尚未支持 B200（參考），SGLang 團隊也未公佈支持 B200 的明確時間表。在 AMD 方面，本文未對MI355X 進行基準測試，因爲生產單元尚未上市。儘管存在工程樣品，但漏洞尚未完全修復，因此係統尚未準備好進行測試。

雖然TensorRT-LLM 支持 B200，但僅針對少量模型進行了優化，且明顯缺少 FP8 DeepSeek V3。因此，本文使用TensorRT-LLM 對 B200 進行了部分模型和場景的基準測試，作爲對 B200 性能的初探。下圖展示了 LLaMA 70B 和 405B 在推理工作負載（1k 輸入，4k 輸出）中的表現。

來源: SemiAnalysis

搭載TensorRT LLM 的 B200（標記爲 B200-TRT）在 LLaMA 70B 基準測試中全面領先，整體延遲更低、吞吐量更高。MI325X 和 MI300X 與 B200 的競爭力相差甚遠。

來源: SemiAnalysis

對於LLaMA 405B，B200 在所有延遲和吞吐量指標上再次碾壓所有其他配置，甚至在本文測試的最高請求速率下仍未進入平臺期。

到目前爲止，B200 在本文運行的基準測試中表現出極高性能。爲確保全面性，本文將在未來幾個月內報告MI355X 和 B200 的訓練和推理性能。

推理過程中的 AMD 和英偉達漏洞

在基準測試過程中，本文遇到了多個障礙。

服務框架中的大量調優標誌導致配置組合呈爆炸式增長。例如，vLLM 使用 max-num-seq、max-num-batched-tokens、num-scheduler-steps 和 max-model-len 等參數；其中大多數配置關於每個標誌對性能的具體影響文檔不足。這使得基準測試極其耗時，且無法保證找到實現最佳性能的正確組合。因此，本文不得不依賴英偉達和AMD 工程師提供的最佳配置。本文希望所有服務框架改進每個標誌對性能影響的文檔，並理想地實現自動調優。這是AMD 和英偉達應投入 GPU 資源並公開提供的服務，本文樂於合作。

由於服務框架代碼更新速度極快，本文在獲取最新性能結果時遇到了困難。即使採用最佳配置，每種GPU 類型的基準測試運行仍需 60 到 120 小時，而服務框架幾乎每週都會更新代碼。由於 vLLM 從 v0 過渡到 v1、SGLang 的 CUDA 圖捕獲失敗、SGLang 在 AMD 上的分段錯誤等問題，本文不得不從頭開始進行基準測試，並且在被要求重新配置標誌時多次重啓。更糟糕的是，AMD 多次要求本文啓用反饋週期中新開發的功能，導致多次重新運行和軟件版本不一致。本文希望未來通過發佈實時基準測試網站來緩解這一問題。

基準測試耗時較長的另一個原因是本文無法在多臺機器上並行進行實驗。本文發現雲服務提供商的機器在吞吐量和延遲方面存在不可忽視的差異，這導致AMD 和 NVIDIA 要求本文重新進行所有實驗。

最後，AMD 維護獨立的代碼分支和配置導致了嚴重的延遲。由於 AMD 維護了一個獨立的 vLLM 分支，本文不得不編寫單獨的基準測試設置。在撰寫本文時，AMD 已結束並棄用了其 vLLM 分支。本文歡迎這一變化，並希望AMD 在其他軟件中也採用這一做法。在配置方面，他們添加了與 AITER 相關的環境變量，這讓本文回想起PYTORCH_TUNABLE_OP 的問題。本文已表達了對使用環境變量啓用功能的不滿，並希望該做法能像PYTORCH_TUNABLE_OP 一樣被移除。

AMD SGLang 持續集成測試缺乏覆蓋 parity

在過去的5 個月裏，AMD 的整體持續集成（CI）有了很大的改進。5 個月前，AMD 的 SGLang 推理 CI 測試爲零，現在已經有了一些。不幸的是，其 CI 測試覆蓋率仍遠不及 NVIDIA。

三週前，AMD 的 AI 負責人 Anush 要求他們的一位核心工程師 “996” 工作以修復 SGLang 的 CI 問題。AMD 雖然取得了一些進展，但遺憾的是仍有數十個單元測試缺失。如果沒有適當的測試，AMD 的軟件質量將繼續較差，存在更多漏洞，導致開發者體驗不佳和採用速度緩慢。

來源：SemiAnalysis, SGLang, Github