產業深度 · 算力超週期 · ISSUE #243
CUDA 護城河沒有消失：AgentX 揭開代理式推論的四層戰場｜算力超週期系列 18
當同一段 30 萬 token 的歷史被送錯伺服器，最快的晶片也得重算。代理式推論正在把競爭單位從 GPU 改成一整套工作狀態系統。
SemiAnalysis 蒐集超過 8,000 個代理式工作階段、340 萬個請求與 6,100 億 token，背後花費超過 300 萬美元，再從中整理出 393 個工作階段的 AgentX v1.0 公開子集。這批工作軌跡的中位輸入長度是 142k token，也就是 14.2 萬 token；44% 含子代理。
這批資料揭露一個比 GPU 排名更重要的轉折：代理式推論的瓶頸，已經從「這顆晶片能算多快」移到「一段不斷增長的工作狀態能否被留住、找到、搬動並正確續跑」。
AgentX 把跑分單位從一個請求換成一段生命週期
傳統 8k/1k 跑分把服務想成固定的 8,000 token 輸入與 1,000 token 輸出。這種方法適合量 kernel、精度與基本吞吐，卻看不到代理式工作真正昂貴的部分：前一輪的全部歷史會進入下一輪，工具執行讓 GPU 暫停等待，子代理突然帶來一批冷預填，主代理又要等分支完成後才繼續。
AgentX 的公開子集有 175 個工作階段含子代理，共 1,697 次子代理分支，每個工作階段中位數 4 次。中位輸出只有 444 token；中位輪次間隔 3.84 秒，子代理中位工作時間 2.27 分鐘。
這種形狀說明，服務成本的大頭往往是歷史狀態，新生成的內容只有幾百個 token。
公開 AIPerf 文件同時替「真實」畫出邊界。它保留提示長度、前綴共用、子代理扇出與輪次間時間，但原始程式碼、工具參數與內容被匿名化，重播使用長度與快取結構對齊的合成填充。
這是一套高度接近真實流量形狀的系統壓力測試，並非生產內容的逐字複製；目前公開實作也仍標示為會演進的初版。
1.1單一吞吐數字為何不夠
同一套服務可以把併發拉高，換得更漂亮的總吞吐，同時讓每次新輪次的第一個 token 等更久。因此 AgentX 至少要把下列指標並排：
| 指標 | 它回答的問題 | 可能藏住的代價 |
|---|---|---|
| 每顆 GPU 輸出 tok/s | 每張卡聚合產出多少 | 高併發可能拖慢單一工作 |
| tok/s/user | 串流開始後有多快 | 不含第一個 token 的等待 |
| TTFT 第 90 百分位 | 長上下文輪次要等多久才開始 | 受冷預填、排程與路由影響 |
| 端到端延遲 | 整個請求多久完成 | 受輸出尾端分布影響 |
| HBM／DRAM 命中率 | 重用的前綴留在哪一層 | 命中後仍要付查找與搬移成本 |
我的判斷是，代理式推論的有效產出應以「在既定互動性與錯誤率下完成多少工作階段任務」來衡量。token 仍是必要的計量單位，但已不足以單獨代表完成的工作。
四層競爭地圖：晶片只佔第一層
把 AgentX 促成的修正攤開，可以整理成四層。這張地圖比「NVIDIA 對 AMD」的二元排名更有用，因為一個操作點的勝負通常來自多層一起成立。
| 層級 | 核心問題 | 代表元件 | 失配時會發生什麼 |
|---|---|---|---|
| 算力層 | 模型形狀、精度、kernel 與平行策略是否對齊硬體 | B300、MI355X、TRT-LLM、ATOM、AITER | 紙面算力無法轉成特定模型的吞吐 |
| 記憶體層 | 前綴能否留在 HBM，溢出後能否低成本搬回 | KV 管理器、HBM、主機 DRAM、Mooncake、LMCache | 重算長前綴，或把時間花在查找與傳輸 |
| 控制平面 | 工作階段是否回到正確的快取持有者，排程是否兼顧預填與解碼 | 路由器、排程器、Dynamo、前端 | 命中率理論值很高，實際卻被錯誤路由打穿 |
| 生態系層 | 新模型是否首日可用，各項優化能否同時開啟並長跑正確 | vLLM、SGLang、映像、持續整合、回歸測試 | 展示用峰值無法變成客戶可部署產品 |
SemiAnalysis 表示，AgentX 在數月內推動超過 70 個上游 PR，範圍從快取保留、路由、卸載、增量 token 化到傳輸與正確性。這些工作裡，很多最大增益沒有更換算術 kernel。
SGLang 把上下文長度改為執行期純量後，在併發 384 的特定 AgentX 測試中，輸出吞吐提升 26.75%，平均 TTFT 改善 36.25%；MiniMax M3 的 NIXL 搬移修正則把關鍵路徑 KV 第 99 百分位從 26.74 秒降到 125ms。
更重要的是正確性。報告列出一項 127,500-token 共用前綴的修正，結果從 128 次只有 2 次正確，變成 128 次全數正確。跑得快但輸出錯誤，對生產服務等於零。
這也解釋了為何 CUDA 護城河不能只數函式庫或 kernel：長工作階段的狀態正確性與跨層組合，已經成為性能本身的一部分。
當 HBM 放不下，下一顆 token 要付三次帳
長上下文讓 HBM 容量從規格表數字變成可服務併發。SemiAnalysis 列出的 DeepSeek V4 特定組態中，B300 在併發 384、DEP8 與 3TB DRAM 下，約有 91% HBM 命中率，HBM 工作集約 43M token，也就是 4,300 萬 token；B200 在併發 196 時約有 73% HBM 命中率，工作集約 22M token，也就是 2,200 萬 token，並有近 20% 落到 DRAM。
這組對照只代表特定模型與設定，但物理含義很清楚：前綴可重用卻放不下時，系統有三種帳要選擇。
1. 重算帳：工作階段被送到沒有快取的節點，數十萬 token 的前綴重新預填。 2. 容量帳：增加 HBM，讓更多活躍工作階段的狀態留在 GPU。 3. 搬移帳：把 KV 快取放到主機 DRAM 或次級儲存，再於命中時搬回。
vLLM 官方的「OffloadingConnector」已把這條路產品化：完成的 KV 區塊可移到 CPU 主機記憶體，並能再接次級儲存層；目前文件標示支援 CUDA、ROCm 與 XPU。可是只有 CPU 主要層能直接與 GPU 溝通，後面的層級仍要經 CPU 中轉。
於是「有卸載」只代表多了一個容量選項，查找、寫穿、DMA、排隊與第一個 token 延遲並不會自動消失。
這裡的投資含義先停在需求層。AgentX v1 直接支持 HBM 容量、主機 DRAM、快取軟體與資料搬移的重要性上升；它尚未量測 NVMe 卸載，因此不能把這份報告直接翻譯成固態硬碟或 NAND 訂單。