我們針對基於代理式應用程式伺服器工作負載,評估了第 6 代 AMD EPYC™ 處理器相比上一代的效能提升。AMD Advancing AI 現場直播,2026 年 7 月 22 日。
「您需要一艘更大的船。」 — Chief Brody
隨著 AI 的應用轉向代理式模型,對資料中心基礎設施的要求也將隨之提高。這推動了單台伺服器在 CPU、記憶體、儲存效能及密度方面的指標不斷提升,但理想的代理式應用程式伺服器究竟應具備怎樣的形態? 您如何測試它?
我的團隊構建了一個基準測試,用於模擬代理式 AI 可能對您的基礎設施發起的工具呼叫負載;我們還與 AMD 資料中心生態系統應用工程團隊合作,於 7 月 22 日在「AMD Advancing AI」活動上示範了該基準測試。我們測試了一款第 5 代 AMD EPYC 128 核心 CPU,而 AMD 則測試了其新款第 6 代 AMD EPYC 256 核心 CPU。採用 Micron® DDR5-8000 記憶體和 9650 PCIe® Gen6 NVMe™ SSD 的第 6 代 AMD EPYC 處理器,實現了代際效能提升:效能達到原來的 3.8 倍,且 CPU ×能效提升了 2.9 倍×。
值得慶倖的是,AMD 為我們造了一艘更大的船。
代理式應用程式伺服器
代理式 AI 的部署執行在兩個不同的運算層級上。推理工作部署在 AI 叢集上,由配備大量加速器的主機執行語言模型和代理框架。每當代理呼叫工具時,該請求便會離開 AI 叢集並傳送至應用程式伺服器。應用程式伺服器執行工作並返回結果,隨後由代理決定下一步操作。
圖 1. 代理式 AI 資料流程 該基準測試對以橙色醒目標示的應用程式伺服器進行了特性分析。
應用程式伺服器正是我們著手進行特徵分析的對象。當每個主機涉及數百次工具呼叫時,CPU、記憶體和 NVMe 子系統是決定回應時間的關鍵因素。這是一個涉及儲存裝置、記憶體和運算的綜合性問題。
代理基準測試設計
我們分析了生產環境中的代理工作流程,並設計了一項測試,利用實際應用程式來模擬應用程式伺服器的常見操作。
- 編碼代理拉取資產,查詢構建中繼資料,並對原始碼樹執行 grep 搜尋。
- 文件分析代理負責擷取文件、查詢策略資料庫以及搜尋語料庫。
- 營運代理擷取記錄檔,查詢指標儲存,並 grep 操作手冊。
- 資料分析代理擷取原始匯出資料,查詢目錄資料庫,並搜尋既往報表定義。
具體細節雖有不同,但工作負載特徵相似。
圖 2. 對應於三個基準應用的四種代表性代理工作流程:使用 S3 GET 擷取資產與語料,使用 MariaDB® 進行中繼資料與工作階段查詢,並使用 ripgrep 進行文字與程式碼搜尋。
- 物件型儲存:針對本地 MinIO™ 端點的 S3 GET 流量。代理擷取文件、影像、向量分片以及 RAG corpus 區塊。我們採用了混合物件大小分佈(每個容器包含 500 個 ×1 MiB、500 個× 10 MiB 和 190 個× 50 MiB 的物件)來測試 NVMe 層的輸送量極限。
- 針對 MariaDB 的結構化查詢:每個週期執行 50 次查詢,涵蓋五種查詢模式(點查詢、範圍掃描、聚合、有序掃描、去重)。這展示了代理如何存取其中繼資料、工作階段和長期記憶儲存。
- 使用 ripgrep 進行程式碼與文字搜尋:在完整的 Linux 核心和 CPython 原始程式碼樹中,每個週期執行 100 次 ripgrep 搜尋。文字搜尋既消耗大量 CPU 資源,又會佔用主機記憶體;這種操作常見於編碼代理、記錄分析代理以及需要在語料庫中查找引用的工作流程中。
每個代理都在其獨立的 Docker™ 容器中執行,記憶體限制為 4GB。每個容器執行一個週期:1,190 次 S3 GET 請求、50 次 MariaDB 查詢和 100 次 ripgrep 搜尋。
AMD Advancing AI 與第 6 代 EPYC 中央處理器
在「AMD Advancing AI 2026」大會上,AMD 發佈了第 6 代 AMD EPYC 伺服器中央處理器,旨在為代理式 AI 時代提供領先的效能。AMD 將領先的核心密度(單插槽高達 256 核心與 512 執行緒)與業界頻率最高的 AI 主機節點(達 5GHz)及業界領先的 PCIe Gen 6 I/O 子系統相結合,後者使單鏈路頻寬較上一代翻了一番。AMD 將其定位為擴充代理的理想高密度運算 AI 主機節點,同時也將其作為一套廣泛且針對工作負載進行優化的產品組合,以支援企業日常營運所需的通用工作負載、資料庫、儲存及 CPU 推理工作。
全新第 6 代 AMD EPYC 系統支援美光 DDR5-8000 DRAM,與第 5 代 AMD EPYC 系統上使用的 DDR5-6400 相比,資料速率提高了 25%,並將記憶體通道從 12 個增加到 16 個。綜合這些因素,峰值記憶體頻寬從第 5 代 EPYC 系統的 614 GB/s 提升至第 6 代 EPYC 系統的 1,024 GB/s(增幅達 1.7 倍),同時每個插槽擁有更大的容量,足以容納數百個併發代理的工作集。
儲存技術也實現了代際飛躍。美光 9650 SSD 是首批投入量產的 PCIe Gen6 資料中心級 SSD 之一;它利用翻倍的介面頻寬,在代理主機產生的混合 I/O 負載下,能夠更快速地完成物件與語料資料的讀取操作。第 6 代 AMD EPYC 系統採用了 PCIe Gen6 規格的美光 9650 硬碟,而第 5 代 AMD EPYC 系統則使用了 PCIe Gen5 規格的美光 9550 硬碟。
| 平台軸 | 第 6 代 AMD EPYC 處理器 | 第 5 代 AMD EPYC 處理器 |
|---|---|---|
| CPU | 第 6 代 AMD EPYC CPU 9996 (256 核心) | 第 5 代 AMD EPYC CPU 9745 (128 核心) |
| 主機 RAM | 2 TB DDR5-8000 (128GB x 16 通道) | 1.5 TB DDR5-6400 (128GB x 12 通道) |
| 併發容器 | 256 | 128 |
| 容器記憶體限制 | 4 GB | 4 GB |
| 儲存裝置 | 美光 9650 PCIe Gen 6 NVMe SSD (2 x 7.68TB) | 美光 9550 PCIe Gen 5 NVMe SSD (2 x 7.68TB) |
| CPU 拓撲 | NPS2(2 個 IO 晶粒);SMT 關閉 | NPS1(1 個 IO 晶粒);SMT 關閉 |
效能結果
關鍵指標是「每秒代理運算元」(AOPS),即容器內所有正在執行的工作負載所完成操作的總數除以完成這些操作所需的時間,該指標反映了整個系統處理操作的速度。第 6 代 EPYC CPU 實現了 2,185 AOPS 的持續效能,而 Turin 為 581.4 AOPS,提升了 3.8 倍。這是在容器數量為 2 的情況下得出的結果,意味著第 6 代 EPYC CPU 在幾乎只有一半的時間內完成了兩倍的工作量。
綜合能動性表現
圖 3. 總計 AOPS:第 6 代平台為 2,185,第 5 代平台為 581.4。圖 4. 每個實體核心的 AOPS:第 6 代平台為 8.5,第 5 代平台為 4.5。
我們的結果顯示,在第 6 代平台上,總 AOPS 增加了 3.8 倍。這實際上衡量了系統完成 1,190 次 S3 GET 操作、50 次 MariaDB 查詢以及 100 次 ripgrep 搜尋(並乘以部署的容器數量)所需的速度。第 6 代 EPYC 系統在 157 秒內完成了 343,040 次操作,而第 5 代 EPYC 系統則耗時 299 秒完成了數量僅為其一半的操作。在單核心層面,第 6 代 EPYC 系統在利用雙倍核心數執行雙倍數量容器的同時,實現了每個核心多出 1.9 倍 AOPS 的效能表現。
按工作負載劃分的應用程式延遲
即使執行的容器數量增加了一倍,第 6 代 AMD EPYC CPU 在所有工作負載中仍實現了更低的應用程式延遲。S3 充分利用了美光 9650 在 PCIe Gen 6 介面下的混合 I/O 效能,MariaDB 受益於整個系統的效能提升,而 ripgrep 則高度依賴 CPU 效能。
圖 5. 每個工作負載的容器平均延遲。
CPU 效能
第 6 代 EPYC CPU 的所有核心平均利用率為 33%,而第 5 代 EPYC CPU 為 87%,但這並不能反映全貌。在各項測試中,兩款 CPU 均頻繁出現暫態佔用率達到 100% 的情況。
圖 6. 每個作用中視窗期間的 CPU 利用率:測得的平均值與峰值。
儲存效能
圖 7. 測量了平均及峰值總儲存讀取輸送量。圖 8. 測量了平均及峰值聚合儲存讀取 IOPS。
儲存工作負載較為複雜:S3 產生大量的隨機 I/O,MariaDB 使用 16KB 的 I/O,而 ripgrep 則發起 4KB 或更小尺寸的 I/O。在使用兩塊硬碟的情況下,美光 9650 的突發效能高達 53 GB/s(170 萬 IOPS),非常接近單塊硬碟 28 GB/s 的理論最大值。這證明了 9650 不僅能夠處理極高的輸送量,而且在複雜的混合 I/O 工作負載下也能勝任。
CPU 封裝功耗與能源效率
圖 9. 測量了 CPU 封裝 RAPL 功耗的平均值與峰值。圖 10. 實測每瓦封裝功耗的 AOPS:第 6 代平台為 5.2,第 5 代平台為 1.8。
在第 5 代 EPYC CPU 上,CPU 封裝的 RAPL(執行平均功耗限制)功耗平均值為 320.6 W,峰值達到 456.4 W。第 6 代 EPYC CPU 平均功耗為 422.8W,峰值功耗為 604.7W。憑藉更高的 TDP 和翻倍的核心數量,第 6 代 EPYC CPU 確實消耗了更多電量,但也利用這些電量完成了更多工作。從能效角度來看,第 5 代 EPYC CPU 的每 CPU 封裝瓦特 AOPS 為 1.8,而第 6 代 EPYC CPU 為 5.2,這意味著 CPU 能效提升了 2.9 倍。
在資料中心全面推進 AI 應用
AMD 和美光開發了這一基準測試,旨在展示隨著單台主機上的代理數量增加及其多樣性提升,系統效能的表現。IDC 預測,到 2029 年,全球將有超過 10 億個活躍部署的 AI 代理,每天執行 2170 億次操作,每天消耗 3.7 萬億個代幣和 API 呼叫來應對這些負載1。Gartner 預計 2026 年代理式 AI的支出將達到 2,019 億美元,並呈增長態勢,到 2029 年將達到 7,530 億美元。2。在機架層面,這意味著每台主機上執行更多的代理程式,每個代理程式處理更多的併發 I/O,同時伺服器內部的各個子系統也承受著更大的負載。
搭載第 6 代 AMD EPYC 處理器、執行 256 個容器的系統實現了 2,185 AOPS 的持續效能,在總 AOPS 和單核 AOPS 方面分別比上一代高出 3.8 倍和 1.9 倍,同時能效提升了 2.9 倍。
歡迎在 7 月 22 日的「AMD Advancing AI」活動上觀看我們的示範。我們很樂意為您詳細介紹工作負載設計、遙測資料,以及這些資料對於您規劃 2027 年伺服器規格的意義。
表揚
美光與 AMD 組建的跨職能團隊執行了這項測試。謝謝您們。
AMD
Milind Damle,軟體與解決方案資深總監;
Anre Kashyap,雲端工程資深經理
;Abimanyu Shah,資深軟體系統設計師;
Gigi Khmaladze,軟體系統設計者
;Apostolos Kotsiolis,AMD EPYC 產品行銷經理;
Ketan Sanghrajka,IHV 解決方案架構師
;Chandana Ambekar,AI 推理效能工程師
美光
John Mazzie,技術人員;
Dilim Nwobu,資深首席系統效能工程師
;Amit Bodas,合作夥伴工程
參考資料
1. IDC(2025 年 12 月 10 日)。「代理應用:IT 產業的下一個重大轉捩點。」 到 2029 年,全球將有超過 10 億個處於活躍部署狀態的 AI 代理,每天執行 2,170 億次操作。https://www.idc.com/resource-center/blog/agent-adoption-the-it-industrys-next-great-inflection-point/
2. Gartner(2026 年 1 月 15 日;源自 2026 年 2 月 26 日的 Software Strategies 部落格匯總)。預計 2026 年代理式 AI 相關支出將達 2019 億美元,並於 2029 年增長至 7530 億美元。https://softwarestrategiesblog.com/2026/02/26/roundup-of-agentic-ai-forecasts-and-market-estimates-2026/
AMD、AMD 箭頭標誌、EPYC 及其組合均為 Advanced Micro Devices, Inc. 的商標。Micron 和 Micron 標誌均為 Micron Technology, Inc. 的商標或註冊商標。PCIe 是 PCI-SIG 的註冊商標。NVMe 是 NVM Express, Inc. 的商標。Docker 是 Docker, Inc. 的商標或註冊商標。MariaDB 是 MariaDB plc 或其子公司的商標或註冊商標。MinIO 是 MinIO, Inc. 的商標。所有其他商標均為其各自所有者的財產。
單路 AMD EPYC™ 9745 HPE ProLiant DL345 Gen11 生產系統(1 x 128 核心),1.5TB 記憶體 (12 x 128GB DDR5-6400),2 x Micron 9550 Pro 7.68TB 硬碟,Ubuntu 24.04.4 LTS,Kernel Linux 6.8.0-134-generic,BIOS 2.2(確定性功耗模式),測試日期:2026 年 7 月 14 日。
單路 AMD EPYC™ 9996 參考系統(1 x 256 核心),2.0TB 記憶體(16 x 128GB DDR5-8000),2 x Micron 9650 7.68TB 硬碟,NPS=2,Ubuntu 24.04.4,Kernel Linux nigeria-4370-os 6.18.2-amdsos-build70-ubuntu-24.04+,(確定性enable=功耗模式),測試日期:2026 年 7 月 10 日。