AREX Feed Article
vLLM 宣布 DeepSeek-V4.1-Flash 完成 Vera Rubin NVL72 优化：自报 AgentX 吞吐达 GB300 的 58 倍
北京时间 11 月 13 日 6 时 31 分（UTC 11 月 12 日 22 时 31 分），vLLM 项目官方 X 账号 @vllm_project 发布，宣布已完成 DeepSeek-V4.1-Flash 面向 NVIDIA Vera Rubin NVL72 的优化，并自报在 SemiAnalysis AgentX 基准上达到 GB300 NVL72 吞吐的 58 倍：在 P90 387 tokens/s/user 的运行点上，每 GPU 每秒吞吐 1.7M tokens。
首帖同时给出吞吐曲线的另外两个端点：峰值吞吐 2.52M tokens/s/GPU（GB300 的 2.7 倍），单并发会话（TP，张量并行）下 1,810 tokens/s。三秒后发出的把提升拆到 kernel 层——DEP2 prefill 步进快约 28%，DEP decode 步进快约 25%。以上数字全部是 vLLM 项目单方发布口径，帖文未附配置清单或第三方核验，截至发稿没有独立核实结果。
vLLM 官方博客的图表：DeepSeek V4.1 Flash 552B 在 GB300 NVL72 上的每 chip 吞吐对 P90 交互性曲线（2026-09-11 至 2026-10-02），是本次对比中 GB300 一侧的参照曲线（数据源：SemiAnalysis InferenceX）。
倍数挂在曲线哪一点上
AgentX 的结果是一条「每 GPU 吞吐 × 每用户速度」的权衡曲线：并发越高吞吐越大，单个用户的解码速度越慢；推文里的三个倍数分别挂在这条曲线的不同位置。
「同等交互性下比倍数」是 vLLM 系列公告的惯用口径：的原话是 7.84 倍（at matched interactivity，同等交互性），也用同一格式——10.2 倍对应 546 P90 tokens/s/user。这次的 58 倍沿用的正是这套读法。
两条 vLLM 自己公布过的 GB300 数字可以让倍数含义落地。其一，公布的机架级最好成绩是 954K tokens/s/GPU（对应 P90 196），2.52M 与之相除约 2.6 倍，与首帖 2.7 倍的口径大体吻合；而 1.7M 对 954K 只有约 1.8 倍——可见 58 倍对应的是曲线上 P90 387 那个点的比较，不是峰值对峰值。其二，GB300 上专用 decode 路径的单用户速度是 826 tokens/s，这次 Rubin 帖里的单并发数字是 1,810 tokens/s，约 2.2 倍；两处同为 vLLM 自报，帖中没有给出两边配置细节，不能当作纯硬件倍数来读。
为 SM107 重写的五类 kernel：收益拆到步进与缝隙
第二帖列出的改动面是五类 kernel：MoE（混合专家）、attention、GEMM（矩阵乘）、mHC 与 indexer，全部按 Rubin 重做。两条硬件相关的表述是：带宽受限的数据留在每个 SM（流式多处理器）自己的 memory domain（本地显存域）里；SM107 更宽的 MMA（矩阵乘加）指令让每次发射做更多工作。前者与 10 月预览博客介绍的机制一脉相承：CUDA 13.4 的 locality domain 让 SM 只读离自己最近的 HBM，vLLM 当时用 split-N 策略切分 MoE 权重，小 token forward 平均拿到 1.2 倍提速。后者超出「能跑」的范围：Rubin 的编译目标是新的 sm107，Blackwell 的 sm100f kernel 虽可直接运行，但要用上更宽的 MMA 就得重写。
mHC 与 indexer 是 DeepSeek-V4.1-Flash 自身的结构组件：mHC 系数逐子层错位传递，DeepSeek 开源的 Mega-mHC kernel 把 post、delayed-pre 与 RMSNorm 融进单个 kernel；稀疏 attention 的 indexer 负责在 16K 个候选位置里挑 top-k。DEP2 则是 vLLM 为该模型选的高吞吐并行配置——DP（数据并行）attention 加专家切分，避免 TP 把共享的 KV（键值）缓存在卡间复制。
decode 侧的说明更细。vLLM 把专用 decode 路径移植到 Rubin，并为 SM107 重建了大部分；这条路径上的一步是串起来的小 kernel 链，各自已贴近延迟下限，所以收益来自缝隙——all-reduce（集合通信操作）融进它后面的 kernel、shared expert（共享专家）并进 routed GEMM、加载赶在等待之前启动。
十月铺好的路：预览、收官与同一套对比格式
这次发布有明确的前情，分三步。10 月 7 日，DeepSeek-V4.1-Flash 开源发布三周后，vLLM 在 150 TPS（每用户每秒 150 tokens）约束下把该模型在 GB300 上的 AgentX 吞吐做到发布初的 5.3 倍、低并发提速 1.9 倍，靠的是 SWA bounded replay（滑动窗口有界重放）加 CUDA graphs，以及 DeepSeek 随模型同步开源的 kernel（MegaAttention、Mega-mHC、Mega-Gate、DeepSelect）。10 月 9 日的 Rubin 预览给出了硬件底账：对 GB200 NVL72，新平台有 5 倍 NVFP4 FLOPS、约 2.4 倍 HBM 带宽（HBM3e 换成 HBM4）和 1.7 倍第六代 NVLink 带宽；当时用 MiniMax M3 测得 AgentX 每 GPU 吞吐对 GB200 7.84 倍、150 TPS 约束下 5.18 倍。预览的待办清单里还列着一项「为 DeepSeek-V4.1-Flash 集成 Rubin CSA 与 HCA kernel」。
10 月 9 日 Rubin 预览博客发布的图表：MiniMax M3 在 Vera Rubin NVL72（Dynamo vLLM）与 GB200 NVL72 上的 AgentX 对比，7.84 倍（同等交互性）、150 TPS 约束下 5.18 倍（数据源：SemiAnalysis InferenceX）。
10 月 23 日的 GB300 帖用 P/D 分离（prefill 与 decode 拆到不同实例）加 Wide-EP（大规模专家并行）把同一模型推到 954K tokens/s/GPU、单用户 826 tokens/s，decode 与 DeepSeek 自家引擎 DeepInfer 的差距压到 6% 以内。就在这条线程前一天，MiniMax-M3.1-Flash 也拿到了同一格式的 Rubin 对比帖。这次的 58 倍，是 vLLM 一个多月里「GB300 收官、Rubin 逐模型重写」节奏的最新一步。
AgentX 量什么，模型为什么跑得动
AgentX 是 ，重放真实 agentic coding 轨迹：会话中位 43 轮，中位输入 142K tokens、输出仅 444 tokens，前缀缓存命中率超过 96%，44% 的会话带子 agent。它衡量两个轴：每 GPU 吞吐和 P90 交互性（每用户每秒 tokens 的第 90 百分位）。对 agent 业务，后者决定多步循环里每次工具调用之间用户等多久。
模型侧的条件同样写在 vLLM 的博客里：DeepSeek-V4.1-Flash（总参数 552B）采用 CED（因果编码器-解码器）架构，decode 每 token 激活 16B 参数、prefill 只要 8B；CSA2（压缩稀疏注意力）、FP4 KV 缓存加层间共享，把全局 KV 压到 890 bytes/token。长上下文、短输出、高前缀复用正对上它的设计目标，这也是吞吐曲线能被推高的模型侧原因。
按 的自述，每次 AgentX 运行都存档逐请求遥测；DeepSeek V4.1 Flash 552B 名下现有 18 套配置、703 个数据点，其中 GB300 NVL72 · vLLM 是 2026-10-02 的 74 个点。
未发出的后两帖与最初回复
线程标注 1/4，目前只发出前两帖，后两帖尚未出现。首帖发布约两小时内（北京时间 13 日 8 时 30 分许）有约 14,000 次浏览、80 余次点赞。
早期回复已经有人对量级感到意外。用户 quebanboy 写道：「58x……看了一眼以为小数点错位了」。用户 Jon Cheney 则把重心放在另一个端点：「比起 58 倍，我更在意 387 tokens/s/user 这个数——它让多步 agent 循环近乎即时，而不是让人在工具调用之间干等」。两者都是普通用户的回复，不构成对数字的验证。这批 Rubin 运行是否已在 InferenceX 上有对应的公开遥测条目，帖文没有说明；能否对上，是下一步核对这组倍数的地方。