按总拥有成本归一化之后，B300 vLLM 与 B200 vLLM 在 DeepSeek V4 Pro 上的聚合式性能相当接近。主要差别在于 B300 能挤出额外的吞吐量，因为它的 HBM 容量比 B200 多 50%。

真正有意思的不是这个汇总数字，而是 AgentX 服务端遥测在它下面揭示的内容。

4300 万 token 对 2200 万 token

在 384 条并发 agentic trace 的负载下，B300 vLLM DEP8 配 3TB DRAM、使用 vLLM simple offloading，取得了 91% 的 HBM 缓存命中率，外加 1.36% 的 DRAM 缓存命中率。原因是该配置下 HBM 中 KV cache 的工作集规模约为 4300 万 token，而任一时刻在途的 token 数只是略微超过这个量。

换成并发 196 的 B200、其余参数不变，情况就反过来了：HBM 缓存命中率降到 73%，部署明显更依赖 DRAM，offload 缓存命中率接近 20%。此时 HBM 中 KV cache 的工作集规模为 2200 万 token，大约是 B300 的一半。

offload 层为什么需要余量

DRAM KV offload 通常实现为写穿缓存，也就是写入 HBM 缓存的每个前缀同时也会写入 DRAM 缓存。因此，只有当可用于 offload 的 DRAM 显著大于 HBM 中 KV cache 的容量时（大约 1.5 到 3 倍）它才最有效。

正是这一性质，让 B300 额外的 HBM 产生的是叠加效应而不只是简单相加：更大的常驻工作集把更多会话状态留在快速层，慢速层因此只需服务真正的剩余部分，而不必不断吸收被淘汰的数据。

H200 这个反例

H200 SGLang FP8 能在低并发下服务 DeepSeek V4，从每美元性能看甚至可以和 B200、MI355X SGLang 一较高下。但它无法在高吞吐场景中与更新的 SKU 竞争，因为 HBM 容量不够。

它的失效方式很有教育意义：在更高并发下对 DRAM KV offload 的依赖，会随着用户数增加带来无法接受的延迟。offload 能换来容量，但并不免费；一套需要靠它来弥补结构性显存不足的部署，最终会在尾部延迟上付出代价。

本文结果只是 AgentX 1.0 的一个切面。完整分析、回放方法，以及该基准测试推动的 70 多个上游 PR，请见 AgentX - InferenceXv3：CUDA 护城河在 agentic 推理中还站得住吗？。每个数据点都可以在免费仪表板上自行探索。