AI Agent 的第二戰場：
沒有 GPU 的那台伺服器
Agent 每一次 tool call，最後都打到一台跑 CPU＋DDR5＋NVMe 的應用伺服器——美光（Micron，$MU）用一組基準測試告訴你那裡發生什麼事。
大家的目光幾乎都黏在 GPU 和 HBM 上，但 agent 真正動起來的時候，每一次查資料庫、抓檔案、搜程式碼，都是這台沒有 GPU 的應用伺服器在扛。
美光在 6th Gen AMD EPYC（$AMD）平台上跑了這組 agentic 工作負載測試——平台是 AMD 的，被測的記憶體（DDR5-8000）與 SSD（PCIe Gen6）是美光自家的，AOPS 指標也是美光自訂的。我們把焦點放在 benchmark 本身跟 agent 的資料流上，哪些數字該打折看，也會講清楚。
一句話
Agent 每問一句、動一次工具，背後可能是幾十次資料庫查詢、檔案搜尋、物件抓取——這些全部發生在一台沒有 GPU 的應用伺服器上。
美光拿 6th Gen AMD EPYC 對比上一代，每核心 AOPS（美光自訂指標）快 1.9 倍、每瓦快 2.9 倍——這兩個數字最值得信任。
常被拿出來講的「整台伺服器快 3.8 倍」，是在硬體規模也跟著翻倍（256 vs 128 核心）的情況下量出來的，不是同規模對決。
真正有意思的細節在後面：新平台 CPU 平均使用率只有 32.9%——瓶頸正在移向記憶體和儲存。
兩層架構：AI cluster 與應用伺服器
先搞懂一件事：agent 回答你問題的當下，其實有兩台伺服器在合作，不是一台。
第一層是 AI cluster——推論、規劃、調度都在這裡發生，滿是 GPU 之類的加速器，負責「思考」下一步該做什麼。
第二層是應用伺服器（application server）——沒有 GPU，跑的是資料庫、物件儲存、程式碼與 log 語料庫，負責「動手」執行 AI cluster 發出的 tool call（工具呼叫），再把結果送回去讓 agent 判斷下一步。
一問一答之間，這個來回可能發生幾十次——這篇的重點，就是那台沒有 GPU 的應用伺服器撐不撐得住。
上層是「思考」——AI cluster 規劃下一步、決定要呼叫哪個工具；下層是「動手」——應用伺服器實際查資料庫、抓檔案、跑搜尋，再把結果送回去。一問一答之間，這個迴圈可能跑上幾十次，這篇要看的就是下層那台沒有 GPU 的伺服器撐不撐得住。
Agent 實際在做什麼：四種 agent、三種動作
「應用伺服器」聽起來很抽象，拆開來看其實很具體——美光把常見的 agent 用途歸成四種，再篩出它們背後真正會用到的三種動作，拿這三種動作做 benchmark。
S3 GET——抓資產、向量分片、RAG 語料塊，走的是物件儲存（object storage，S3 協定，最初由 Amazon（$AMZN）發明，MinIO 等開源軟體相容同一套介面）。
MariaDB（開源關聯式資料庫）——查 metadata、session 狀態、目錄記錄。
ripgrep（開源命令列文字搜尋工具）——在程式碼與 log 語料庫裡搜尋關鍵字。
為什麼是這三種動作？因為 agent 跟人不一樣——它不會「盯著螢幕想」，每一步思考之間都夾著取資料：想改 bug 要先抓程式碼（S3 GET）、想知道專案結構要查 metadata（MariaDB）、想找函式呼叫點要全文搜尋（ripgrep）。LLM 在 AI cluster 想一步，應用伺服器就要動一次。
下圖裡的「cycle」是這套 benchmark 的一輪工作量：每個容器要完成 1,190 次 S3 GET（500 次 1MiB＋500 次 10MiB＋190 次 50MiB）、50 次資料庫查詢、100 次文字搜尋——模擬一個 agent 做完一個中型任務的完整資料足跡，而且是 256 個容器同時在跑。
四種 agent（改程式碼、讀文件、顧維運、跑數據分析）平常呼叫的工具五花八門，但落到這篇 benchmark，篩出三個最具代表性的動作：抓檔案（S3 GET）、查資料庫（MariaDB）、搜文字（ripgrep）。換句話說，你叫 coding agent 改一個 bug，它背後很可能就是先用 S3 抓程式碼、用 MariaDB 查專案的 metadata、再用類似 ripgrep 的工具搜尋相關程式碼片段——這三個動作，就是這篇文章真正在測的東西。I/O 特徵：物件是混合大小、資料庫固定 16KB I/O、文字搜尋 ≤4KB。
測試平台：兩代機器
美光拿自家實驗室的兩台機器對比：一台是還沒上市的 6th Gen AMD EPYC 平台，一台是現行的 5th Gen 平台。
先把規格攤開來看，才知道後面的數字是在什麼基礎上量出來的。
| 規格 | 6th Gen（EPYC 9996） | 5th Gen（EPYC 9745） |
|---|---|---|
| CPU | 256 核心 / 512 執行緒 | 128 核心 |
| 記憶體 | 2TB DDR5-8000，128GB×16 通道，峰值 1,024 GB/s | 1.5TB DDR5-6400，128GB×12 通道，峰值 614 GB/s |
| 儲存 | 2× Micron 9650 PCIe Gen6 NVMe，7.68TB | 2× Micron 9550 PCIe Gen5 NVMe，7.68TB |
| 容器數 | 256 個（每個 4GB 上限） | 128 個（每個 4GB 上限） |
核心數與容器數都翻倍
這不是同規模的對照組實驗——6th Gen 的核心數、容器數都比 5th Gen 多了一倍，記憶體通道也多了 4 條、SSD 換了世代。後面看到的每一個數字，都要放進這個框架裡解讀：這是「一代伺服器換一代」的真實部署對比，不是同規模硬體的效率測試。
兩個「第一次」
EPYC 9996 是 2026 Q4 才會正式出貨的伺服器平台——這組數字是拿還沒上市的硬體測出來的（pre-launch）。Micron 9650 則是全球第一顆量產出貨的 PCIe Gen6 企業級 SSD，循序讀取可達 28 GB/s。
結果：先看每核心與每瓦
先解釋一個字：AOPS（Agentic Operations Per Second）是美光自己定義的指標——不是業界標準，衡量的是這套 benchmark 裡，應用伺服器每秒能完成幾次「S3 GET + MariaDB 查詢 + ripgrep 搜尋」組成的 agentic 操作。
白話一點：把「完成一次 agent 需要的資料動作」當成一個單位，AOPS 就是整台伺服器每秒能消化幾個這種單位——像在算超商「每秒能結完幾筆帳」，而不是收銀機本身的時脈多快。
也要知道它能與不能告訴你什麼：AOPS 只衡量應用伺服器消化 tool call 的吞吐量，不包含模型推論的速度，也還沒有任何公信機構背書——agentic 應用伺服器這個場景目前根本沒有公認的 benchmark，這正是美光自己定義指標的原因。所以它適合比「同一套測試裡的兩代平台」，不適合拿去跟別家的數字對表。
拆成「每核心」「每瓦」來看，是因為這兩個指標把硬體規模拉平了——不管兩代機器核心數、功耗差多少，比的是同一顆核心、同一瓦電，能多做多少事。
三個應用裡，S3 GET 的延遲差距最大——37.8ms vs 178ms，快了 4.7 倍，是 6th Gen 更多記憶體通道加上 Gen6 SSD 一起帶來的效果。ripgrep 兩代都相對慢（307ms、403ms），但差距比例最小。
最關鍵的細節：瓶頸移向記憶體與儲存
跑分看完，還有一個更值得玩味的發現：同樣的工作量，新平台的 CPU 反而大部分時間是閒著的。
6th Gen 的 CPU 平均使用率只有 32.9%，5th Gen 則高達 86.5%——同樣一批 agentic 工作負載，新平台的處理器多數時間其實在待命。
但兩代的尖峰使用率都會衝到 100%——瓶頸並沒有消失，而是從「多數時間卡在 CPU」變成「CPU 多數時間在等資料，只有尖峰時刻才滿載」。
換句話說，壓力正從 CPU 移向記憶體通道與儲存子系統。這正好呼應美光自己的定位：下一代 agentic 基礎設施真正要擴的，是記憶體和儲存，不是 CPU 核心數。
| 儲存讀取指標 | 6th Gen | 5th Gen |
|---|---|---|
| 平均吞吐量 | 31,094 MB/s（31.1 GB/s） | 8,534 MB/s（8.5 GB/s） |
| 尖峰吞吐量 | 53,421 MB/s（53.4 GB/s） | 24,069 MB/s（24.1 GB/s） |
| 平均 IOPS | 612,016（61.2 萬） | 170,326（17.0 萬） |
| 尖峰 IOPS | 1,719,910（1.72M） | 734,307（73.4 萬） |
CPU 空出來的使用率，換來的是儲存子系統被榨得更乾——平均吞吐量從 8.5 GB/s 衝到 31.1 GB/s，尖峰 IOPS 從 73.4 萬跳到 1.72M。這就是「瓶頸從 CPU 移到儲存」的具體數字。
功耗呢？美光量的是 RAPL（Running Average Power Limit，CPU 內建的功耗量測介面）——只算 CPU 封裝功耗，不含記憶體、儲存、風扇等整機用電，實際牆插功耗會更高。
投資視角
拉遠來看，這篇 benchmark 真正想回答的問題不是「哪一代 CPU 比較快」，而是「agentic AI 會把需求往哪裡推」。
美光算了一筆帳：每台應用伺服器要塞 2TB DDR5 記憶體、兩顆 PCIe Gen6 NVMe SSD，才扛得住 agent 一天幾十萬次的 tool call。這個規格不是為了訓練或推論本身，而是為了「非 GPU 層」的資料存取速度。
美光引用 IDC 的預測：到 2029 年，全球會有 10 億個活躍 agent 在跑。如果這個數字成真，需要的不只是更多 GPU，還有更多能撐住這些 agent 的資料庫伺服器、物件儲存、快取層。
這條供應鏈的受惠者很直接：DRAM（尤其是 DDR5 高容量模組）跟資料中心 SSD。AMD（$AMD）則是靠著「一顆 CPU 撐 256 個容器」的 agentic 賣點，把 EPYC 定位成應用伺服器這層的首選。
硬體規格的投資意涵
2TB DDR5 ＋ 雙 Gen6 NVMe，是美光給「一台應用伺服器該長什麼樣」畫的規格線。這不是理論——是撐住這篇 benchmark 裡 256 個容器同時打 S3、查 MariaDB、跑 ripgrep 需要的真實配置。注意規格細節：2TB 是用 128GB 的高容量模組 × 16 條插滿 16 個通道拼出來的——高容量 RDIMM 正是 DRAM 廠毛利最好的產品線之一。
IDC 預測：2029 年 10 億個活躍 agent
這個數字是美光引用 IDC 的預測，不是美光自己的推算。如果照這個成長曲線走，非 GPU 層的記憶體與儲存需求會是一條長期成長的供應鏈——但別忘了，提出這個成長故事、賣這些硬體的美光（$MU），本身就是這兩樣東西最大的供應商之一：它既是賣鏟人，也是這次測試的出題者。
受惠者不只美光
高容量 DDR5 模組與資料中心 SSD 是整個記憶體產業的戰場：DRAM 三雄——美光（$MU）、三星（韓國・005930）、SK 海力士（韓國・000660）——都做這兩樣生意；企業級 SSD 陣營還有鎧俠（Kioxia，日本・285A）。美光發這篇文章是在幫自己的產品開路，但它描述的需求如果成真，整條供應鏈都會分到。
跟 HBM 故事的關係：互補，不重疊
HBM 吃的是 GPU 旁邊的預算（見「記憶體階層」篇）；這篇講的 DDR5＋NVMe 吃的是應用伺服器的預算。一套 agent 部署要同時餵飽兩邊：AI cluster 要 HBM 撐推論，應用伺服器要大容量 DRAM＋快 SSD 撐 tool call。如果 agent 數量照 IDC 曲線走，這是兩條同時往上的需求線，不是此消彼長。
名詞小抄
這篇的關鍵詞，一句話版。
- AOPS Agentic Operations Per Second
- 美光自訂指標，衡量這套 benchmark 裡應用伺服器每秒完成幾次「S3 GET + MariaDB 查詢 + ripgrep 搜尋」組成的 agentic 操作，不是業界標準。
- 應用伺服器 application server
- 跑資料庫、物件儲存、檔案系統的伺服器，agent 的 tool call 最後執行的地方，本身沒有 GPU。
- 物件儲存 object storage
- 用 key 存取整個檔案（物件）的儲存方式。S3 是 Amazon（$AMZN）發明的協定，MinIO 等開源軟體也相容同一套介面。
- MariaDB
- 開源關聯式資料庫，這篇 benchmark 用它模擬 agent 查 metadata、session 狀態、目錄記錄這類查詢。
- ripgrep
- 開源命令列文字搜尋工具，這篇用它模擬 agent 在程式碼與 log 語料庫裡搜尋關鍵字。
- 容器 container
- 這篇每個實體核心跑一個容器（4GB 記憶體上限），模擬多個 agent tool call 同時打進來的情境。
- RAPL Running Average Power Limit
- CPU 內建的功耗量測介面，這篇用它量測 CPU 封裝功耗，不含記憶體、儲存等整機用電。
- IOPS Input/Output Operations Per Second
- 每秒能處理的讀寫次數，跟吞吐量（MB/s）搭配看，才知道硬碟面對的是大檔案還是大量小請求。
- DDR5
- 目前主流的 DRAM 世代規格，這篇兩代平台都用 DDR5，差在通道數與時脈（8000 vs 6400）。
- 記憶體通道 memory channel
- CPU 與記憶體之間平行的資料通道，通道數越多，同時能搬的資料量越大——這篇 6th Gen 比 5th Gen 多了 4 條通道（16 vs 12）。
- tool call 工具呼叫
- agent 決定要「動手做」時發出的指令，例如查資料庫、抓檔案、跑搜尋——每一次 tool call 都是一趟從 AI cluster 到應用伺服器的來回。
同系列篇章：這篇講 GPU 旁邊那座記憶體金字塔——本文則是金字塔之外，沒有 GPU 的那台伺服器在做什麼。
同系列篇章：KV 快取怎麼在 GPU 端長大——這篇則是 tool call 打到 GPU 之外那台伺服器之後發生的事。