机架级

「prefill 与 decode 应该分开跑」在论文里讨论了好几年，但真正把它做成机架级产品的是 NVIDIA Dynamo：1.0 版今年 4 月发布，6 月迭代到 v1.2.0，成为 GB300 NVL72 上拿到 0.123 美元每百万 token 这个数字的关键软件栈之一。为什么概念不新，落地却等到今年？ 混跑为什么不行 一次推理天然分两段：prefill 把整个输入一次性算完，是计算密集；decode 一个 token 一个 token 出，是内存带宽密集。把它们放在同一批 GPU 上混跑，长请求的 prefill 会堵住短请求的 decode 排队，用户感受到的就是「首 token 慢、出字也慢」。 分离式服务的思路是：prefill 一批卡、decode 一批卡，中间靠高速 NVLink 传 KV cache，各用各的最优 batch size。道理简单，难在工程。 2026 年才凑齐的三块拼图 机架内带宽：GB300/Vera Rubin NVL72 的第六代 NVLink，让 KV cache 在 prefill 池与 decode 池之间搬运不成为瓶颈。以前跨机柜 InfiniBand 搬 KV，延迟直接吃掉收益。 路由智能：Dynamo 的分离式路由器要判断请求在远端 prefill 还是本地分块 prefill，v1.2 还专门加了 prefill_load_scale 参数做负载打分。 多模态扩展：9 月文档进一步把 encode 也拆出来，形成 encode-prefill-decode 三段分离，给视觉编码与 LLM 不同资源池。 对部署团队的含义 分离式推理不再是大厂专利。如果你已经在 GB300 这类机架上做生产服务，Dynamo 类方案让你可以按「计算池」与「带宽池」分别扩容，而不是买一个通用大池子盲目堆卡。对自建团队，判断自己是否需要分离式，先看监控里 prefill 与 decode 的排队时间谁长——前者瓶颈在算力，后者在带宽，治理方向完全不同。 ...

10 月 7 日 NVIDIA 宣布 SpaceXAI 将部署 Vera CPU，用于加速下一代 Agentic AI 的 CPU 密集型负载：任务编排、工具调用、代码执行、数据处理与模拟。Vera CPU 本身 5 月底在 GTC 发布，是 NVIDIA 首款专为 Agentic AI 与强化学习设计的处理器，官方数据是比传统 x86 机架级 CPU 快约 50%、能效翻倍，后续宣传口径进一步提到较 x86 处理器快 1.8 倍。GPU 公司为什么突然认真做 CPU？ Agent 的一半工作不在 GPU 上 过去两年的共识是「推理靠 GPU，CPU 随便配」。Agent 把这个共识打破了。一次工具调用的完整链路是：GPU 上的模型产出动作 → CPU 解析函数调用参数 → CPU 沙箱里执行代码或调 API → CPU 把结果序列化回上下文 → GPU 再读一遍。对话越长、工具越多，CPU 承担的调度、序列化、文件读写、网络往返就越重。 NVIDIA 在发布稿里直接点名了五类负载：任务编排、工具调用、代码执行、数据处理、模拟。这五件事没有一件是矩阵乘法，但每一件都在拖慢 Agent 的端到端响应。GPU 算得再快，CPU 侧卡在编排上，用户感受到的就是「模型在发呆」。 为什么不用 x86 传统 x86 服务器 CPU 在带宽、功耗与机架内一致性上都不是为这种「高并发短事务」设计的。Vera 基于 ARM 路线，与 Rubin GPU 同机架共封装，目标是让 CPU 与 GPU 之间的数据移动距离更短、内存语义更统一。官方称之为「驱动更多数据中心 token 收入」——直白地说，CPU 不再是配套件，而是 token 经济的一部分。 ...

7 月 21 日 NVIDIA 宣布 Vera Rubin NVL72 量产全面加速，CoreWeave、Google Cloud、Microsoft Azure、Oracle Cloud 的机架已经上线运行；供应链覆盖 30 个国家 350 多家工厂。10 月初 SpaceXAI 又宣布把优化版 Vera Rubin NVL72 搬上第一代 Starmind 卫星。这颗继任者的规格表里，最值得技术人记住的不是 3.6 EFLOPS FP4，而是那 20.7TB 的 HBM4。 规格表读错的方式 官方数据：Vera Rubin NVL72 整机架 20.7TB HBM4、约 1.6PB/s 内存带宽、3600 PFLOPS NVFP4 算力；单颗 Rubin GPU 配 288GB HBM4、19.2TB/s；超芯片（Superchip）配 576GB HBM4、38.5TB/s；NVLink 进入第六代。Micron 的 HBM4 36GB 12-Hi 已在 3 月量产，单栈带宽超过 2.8TB/s。 外行看 FLOPS，内行看容量。原因在于 Agent 负载的瓶颈已经转移。 为什么容量墙先到 过去两年的推理优化，主线是「让每 HBM 字节动得更快」——KV cache 量化、分页注意力、前缀缓存。但当模型越做越大（MoE 总参数逼近万亿）、上下文越拉越长（十万、百万 token）、并发越来越高（一个 Agent 同时挂着十几个工具会话），单卡显存装不下权重加 KV，才是硬约束。 ...