SGLang 与 Miles 团队称在预发布 Vera Rubin 上跑通 Kimi K3 推理和端到端 RL，自测 FP8 MLA 提速最高约 20%

10 月 9 日，LMSYS Org 网站刊出：团队在两台预发布（early access）的 NVIDIA Vera Rubin 节点（共 8 块 GPU）上把 SGLang 推理和 Miles 强化学习训练跑通，为 Kimi K3 的 NVFP4 推理优化 attention、MoE 与投机验证 kernel（内核），并称 SGLang 为 Miles 在 Rubin 上的端到端 RL 提供 rollout。同日，并附博客链接，帖文发布于 10 月 9 日 23:23 UTC。

帖文列出的三个高亮数字与博客一致：batch 1、128K 上下文下 FP8 MLA 最高提速约 20%；KDA 验证 kernel 快 20%、输出逐位一致；MoE 尾部融合让每个 decode step（解码步）少发 276 次 kernel launch（内核启动），端到端提速约 5.9%。这些数字来自团队在预发布硬件上的自测。

Vera Rubin 的三处硬件变化：327 KiB 共享内存、212 个 SM 与 NVLink 6

博客称，Vera Rubin 是 NVIDIA Blackwell Ultra（GB300 NVL72）之后的一代 GPU。博客列出对 kernel 工作影响最大的三处变化：每个 CTA 的共享内存上限升到 327 KiB（Hopper 和 Blackwell 上是 227 KiB）、团队手上的节点有 212 个 SM（流式多处理器）、以及 NVLink 6。

博客把改动分成两路：一路把 Blackwell 时代的 kernel 按新上限重调，一路消除在 Rubin 上分析 Kimi K3 时发现的额外开销，包括 kernel launch、barrier 停顿和隐藏的数据拷贝。帖文提到，这轮优化是与 NVIDIA 密切合作完成的；博客文末致谢写明，这项工作由 RadixArk 的 SGLang & Miles 团队与 NVIDIA 合作完成。

Kimi K3 的 MLA：更深的流水线、更快的 split-KV 归约

Kimi K3 是一个 2.8T 参数的混合模型，上下文窗口 1M token。按博客给出的结构，93 个 attention 层里，69 层 KDA 线性注意力与 24 层 MLA 交错；每个 attention 输出都通过 Attention Residuals 按 block 做 bank 与聚合。FFN（前馈网络）是 LatentMoE：896 个 expert、top-16 路由、运行在 3,584 维 latent 空间里。团队服务的是 NVFP4 的 checkpoint（权重文件），搭配 RadixArk 的 DSpark 块投机解码，因此每个 decode step 先做一次短 draft，再对候选 token 做一次 verify。

四项 attention 相关改动都围绕这套结构展开：

更深的 MLA 流水线。长上下文下 MLA 解码大部分时间在等从 HBM 读 KV，办法是让更多读取同时在途。Blackwell 上的 FP8 kernel 已经用满 227 KiB 共享内存（3 个 K stage、2 个 V stage），Rubin 的 327 KiB 上限刚好多放一个 K stage 和两个 V stage；流水线加深后，batch 16、128K 上下文下的 MLA 快 16%，输出逐位一致。
更快的 split-KV 归约。低并发时，一个请求的 KV cache 会切给很多 CTA，由第二个 kernel 合并部分结果；原实现先加载一份、等一次、再加载下一份，每份都付一次 L2 延迟，改成先发出所有加载、再从寄存器累加后，batch 1、128K 上下文下完整 FP8 MLA 提速最高约 20%。
64 路 split-KV。batch 1 的解码请求给 attention kernel 的并行工作太少，默认 32 路 split 下 Rubin 的 212 个 SM 大部分空闲；针对 K3 的形状翻倍到 64 路后，FP8 KV 下端到端多出 1.9%。
原生 FP8 转换。把 KV/Q 转成 FP8 时，如果不做饱和转换，编译器就不会使用打包的硬件转换指令、改走慢速软件路径；换成饱和转换（溢出钳到 ±448 而不是变成 NaN）后，准备阶段的 kernel 快了 2.5 倍。

MoE 与 KDA：合并小 kernel，减少 barrier 等待

每个 MoE 层的结尾都是同样的四步：收尾 expert 输出、加 shared expert、跨 8 块 GPU 做 all-reduce、再做 RMSNorm。每一步的 kernel 都很小，launch 开销占主导，而 K3 的 92 个 MoE 层每一层都要重复一遍。团队推迟收尾动作，把四步折进一个集合通信 kernel，每个 decode step 少 276 次 launch，端到端提速 5.9%。

另外两处 MoE 相关改动：融合后的尾部对小 batch 用 push 式 all-reduce、对更大的 batch 用 pull 式，而在 Vera Rubin 上 push 到 256 行都更快，交叉点因此后移，32 个并发请求下的解码吞吐提高 3.6%；MoE latent 上投影的算术开销（每线程超过一千次标量 FMA、几十次 warp shuffle）被搬到 mma.m16n8k16 tensor core（张量核心）指令上、一次处理 4～8 行，解码步耗时再降 1.1%。

KDA 一侧，融合的 verify kernel 原先大量时间花在 barrier 等待上：每个 CTA 都要把 conv 权重拷进共享内存，然后等一次全块 barrier。现在每个 warp 把自己的权重留在寄存器里，warp 内部的 state 交接不再需要 CTA barrier；v warp 提前完成预计算后，用空出来的时间计算 output-norm gate。输出保持逐位一致，在 Rubin 上，用于生产的 verify kernel 提速 20%。

还有一处小修：每个 KDA 层的 gated RMSNorm 的 gate 取自融合 QKVG 投影的一个列切片，切片不连续，PyTorch 每次调用前都会静默拷贝一次（2.6 µs，每步 69 次）；让 norm kernel 通过 stride 直接读 gate 后，这笔拷贝消失，解码步耗时再降 1.8%。

Miles 的端到端 RL：GSM8K 奖励从约 45% 升到约 95%

训练一侧，Miles 用 SGLang 做 rollout、用 Megatron 做训练，整个 RL 流程在 Vera Rubin 上端到端运行，只需要一个容器镜像。有了 Rubin-enablement PR，这些 RL 任务用 Miles 开箱即可在单 tray（4 块 GPU）上启动。博客给出两组 GSM8K 结果：

Qwen3-30B-A3B：每次 rollout 用 256 条 prompt、每条 8 个样本，最多 1,024 个响应 token；50 个 rollout 之内奖励从约 45% 升到约 95%，博客称曲线与 GB300 上的奖励增长吻合。
DeepSeek-V4-Flash（4 层，FP8）：每步 32 条 prompt、每条 8 个样本，最多 256 个响应 token；FP8 路径在 rollout 与训练两端都端到端跑通。

博客把这两组结果称为初步结果，说它们展示了 Miles 在 Vera Rubin 上的就绪程度；下一阶段聚焦扩大规模、继续提升性能。

Vera CPU 上的 64 个沙箱：agentic RL 的第一步

作为在 Vera Rubin 上做 agentic RL（智能体式强化学习）的第一步，团队在一台 tray 上跑起 NeMo Gym 的 mini-SWE-agent 环境：每个 episode 分到自己的沙箱，沙箱与负责服务、训练 Qwen3.5-35B-A3B 的 GPU 同处一台 tray，用的是 tray 上的 Vera CPU，同时跑 64 个沙箱。

团队选 SWE-bench Verified，是因为它提供预构建的 arm64 任务镜像，并且他们验证过在这些镜像上的评分可用；每步从 64 个任务的池子里采样 8 个任务、每个任务 8 次尝试，每个 episode 最多 64K token。结果是，当环境全部放在 Arm 架构的 Vera CPU 上时，训练正常进行：奖励稳定在约 0.6，episode 时长缩短约 30%，rollout 与训练保持接近（见下图右栏的 train–rollout KL）。

Cognition 的 4.8 倍与 Vera CPU 的规模化条件

博客还引用了一组第三方的数字：Cognition 已部署 Vera Rubin NVL72，用的是自建、基于 SGLang 的栈，并报告总 token 吞吐相较 GB200 NVL72 最高提升 4.8 倍。脚注把这组数字的口径标得很清楚：结果来自 Cognition 自己的私有 SGLang fork 和基准设置。

博客说，这只是 SGLang 和 Miles 在 Vera Rubin 上的初步观察（first look）；agentic RL 要从单台 tray 的 64 个并发沙箱再往上走，还取决于 Vera CPU 服务器何时规模化可用。

参考链接