AREX Feed Article
vLLM 发布 bitwise 一致 RL 训练方案，称 DeepSeek-V4-Flash 100 步 diff=0、rollout 吞吐为基线的 91.3%
vLLM 项目的官方 X 账号（@vllm_project）10 月 15 日，介绍新上线的博客《Finish RL Training Faster: Bitwise-Consistent, High-Performance, Agent-Driven》。方案的核心是让训练前向直接调用 vLLM 的推理内核，使 RL 中 rollout（采样生成）与训练两端对同一 token 算出的 logprob（对数概率）逐位一致（bitwise identical，即 diff=0），同时保留高性能推理路径。帖文称，DeepSeek-V4-Flash 在 32 块 GB200 上跑 100 步 RL，每一步的 diff 都是 0；代价是 rollout 吞吐平均为基线的 91.3%。
帖文用一句话概括要解决的问题：「同样的权重并不保证同样的策略」。推理引擎为吞吐采用低精度计算与低精度 KV-cache（键值缓存），并做通信与 kernel 优化；这些都会改变训练侧重算的 logprob，两端对同一 token 给出不同概率，on-policy（同策略）训练实际在优化另一个策略。vLLM 在不加 TIS 等算法修正的 DeepSeek-V4-Flash-Base 对照实验里报告，高性能基线的训练-推理 KL 随训练攀升、奖励回落；完整说明在里（页面日期 10 月 14 日）。
训练前向直接调用推理内核
技术选择的核心问题是哪一侧让步。训练与推理这两个引擎要达成一致，最容易的方式是运行同一段代码，而 rollout 占 RL 训练时间的大头、每个算子都按吞吐调优；如果以训练侧为数值基准，这些优化都得放弃。vLLM 反过来把推理内核当作数值基准：训练前向直接调用 vLLM 的内核，只为反向传播另算梯度，并修改这些高性能内核，让同一 token 的结果不随 batch（批次）组成、prefill/decode（预填充/逐 token 解码）阶段或并行布局变化。
对齐清单包括 FP8（8 位浮点）GEMM（矩阵乘）、稀疏注意力的 Top-K（保留得分最高的 K 个位置）、FP8 KV-cache 读取、MoE（混合专家）通信与 CUDA Graph 执行。博客把「训练与推理算同一件事」拆成四个维度：单卡 kernel 确定性（同输入必须同输出，GPU 默认不保证，比如 split-K 矩阵乘换个累加顺序结果就不同）；batch 无关性（kernel 选择不能随 batch 大小漂移）；阶段一致性（prefill 与 decode 共用读取路径）；跨 GPU 一致性（AllReduce、reduce-scatter 与 MoE all-to-all 的归约固定）。再叠加两端相同的数值契约与离散选择规则：量化与舍入方式、累加精度，以及 Top-K 并列、MoE 路由的打破平局与合并顺序。这个问题已有多种解法：TIS（截断重要性采样）、MIS（掩码重要性采样）等算法修正保留数值差异、只限制它对更新的影响；R3（rollout 路由回放）只消除 MoE 路由翻转；QAT 让训练前向模拟部署量化；Thinking Machines 的严格对齐用通用 batch-invariant 内核换一致性、付出推理性能代价。vLLM 选择的是在高性能内核上逐算子对齐。
「diff=0」有精确定义：每次更新前，在相同权重与相同 token 前缀下，逐 token 的 |p_rollout − p_train| 的最大值、均值、标准差以及 k3 KL 全部精确为 0，判据不设容差。博客称这一验收已在数学推理、多轮工具调用任务与并行布局（包括两侧布局不同）上成立。前向共享数值，反向另走校验：前向值固定来自 vLLM 内核，反向对 BF16 主权重求梯度、把 FP8 量化按恒等处理（直通估计器，STE），梯度还要对独立参考实现校验，博客明确说，逐位一致的前向并不能证明梯度正确。
DeepSeek-V4-Flash：100 步，每一步 diff=0
实验设置：8 台机器共 32 块 GB200；数学推理任务，DAPO 格式数据，GRPO，奖励含超长惩罚；每步 128 个 prompt × 8 条回复，且每步只做 1 次参数更新。两组对照都不使用 TIS、MIS 之类的修正，让引擎间的数值差异直接暴露。一致版本的 rollout 跑 4 个 vLLM 引擎（各 DP8/EP8、TP=1），训练侧用 EP32、CP4、TP=1（DP、EP、CP、TP 即数据、专家、上下文、张量并行）；两侧并行布局不同，跨 GPU 归约被移出被比较的数值路径。
100 步跑完，一致版本每一步的最大差值、均值、标准差与 KL 全为 0，奖励保持；高性能基线的训练-推理 KL 从 2e-3 升到 29.9，奖励回落。rollout 吞吐全程平均 24.22 对 26.53 output tokens/ms，为基线的 91.3%；只看前 89 步是 88.6%，第 90 步之后基线吞吐下滑，把总体比值抬高，同期基线的平均回复长度从约 3,000 tokens 降到约 1,600。因为两次运行的回复长度不同，博客提醒这是 rollout-run 测量，不是隔离的引擎基准。
博客没有把约 9% 的缺口分摊到具体算子，只列出候选：MoE 低延迟通信与后端、注意力 gather 与反量化、逐请求的 kernel 启动。博客还写明一个潜在收益：目前每步重算 old-logprob 只是为了测 diff，验收之后训练可以直接用 rollout 的 logprob，省掉一次前向。
对齐的代价：逐算子拆解
博客把取舍记录到了算子一级。密集 GEMM 去掉按 shape 选 kernel 的分支（原先 M<32 走 FlashInfer、否则 DeepGEMM），统一到带 batch-invariant 模式的 DeepGEMM：rollout 失去更快的极小 batch 内核与一处 mHC 融合，训练则每次前向都要把权重重新量化成 FP8。FP8 KV-cache 保留 FP8 存储（约为 BF16 的 57%），但 decode 不再用直接读 FP8 的 FlashMLA 内核，而是先反量化、gather 到 BF16 workspace，再走 prefill 同款稀疏注意力 kernel；代价是 decode 端多出 gather 与反量化，训练端多一份私有 cache。稀疏注意力的 Top-K 原本按线程调度打破平局，一致版本把分数与请求内位置合成唯一 key，并列时取更大的位置，并把选中项按位置降序排序；两侧各多一次排序，融合之后，一致版本在推理基准上的吞吐提升 6.7%。
主要的开销集中在 MoE 通信与后端。rollout 用 DeepEP 低延迟（LL）模式、训练用 normal 模式；要让两种布局下同一 token 的专家 GEMM 结果一致，vLLM 统一了 FP8 量化取整，并规定 SiLU(gate)×up 只在乘积处舍入一次，这让路由天然一致，不再需要 R3 路由回放。代价是 rollout 放弃 TRT-LLM MoE 的通信-计算重叠：一致版本在推理基准上最初慢 33%，其中约 83% 来自无法重叠的 LL 通信；每步 43 层 × 2 共 86 次串行 all-to-all 无法与计算重叠，试过的跨层重叠会破坏 batch 无关性，用 DBO 交织两个 micro-batch 反而慢 39%。
CUDA Graph 也被保留：纯 decode 步用整图捕获、混合步用分段捕获（FULL_AND_PIECEWISE）；图与 eager 两条路径同样必须逐位一致，博客说第一个不一致就出在这里，indexer 的短上下文捷径在捕获时按 dummy 输入长度被烧进了图，改成只依赖静态上界后修复。他们曾因一次通信配置差异花掉两天：脚本把一致版本的 DeepEP 钉在以太网 RDMA（RoCE）上，而基线用的是 MNNVL；对齐通信后端、把共享专家放到辅助流之后，一致版本在同一推理基准（GB200、DP8/EP8、256 并发、每请求输入 150 tokens、输出 3,000 tokens）上反超基线 3.2%（16,834 对 16,313 tok/s）。vLLM 给这条路线设的底线是 rollout 吞吐不低于同等优化基线的 70%，两个模型实测的比值都高于这一底线；训练侧开销没有单独测量，博客列出的来源包括每次前向重新量化 FP8 权重、逐请求串行的注意力与 Top-K、多一次路由元数据 dispatch，以及全量重算（前向跑两遍）。
迁移到 Nemotron-3.5-Lightning：Mamba-2 混合 + NVFP4
迁移测试用的是 Nemotron-3.5-Lightning-30B-A3B（NVFP4）：Mamba-2、注意力与 MoE 的混合架构，路由专家 NVFP4 W4A16，Mamba 投影 FP8，注意力用 FP8 KV-cache，跑在 GB200 上。基线用 NVFP4 QAT 训练（量化规则与导出由 NVIDIA ModelOpt 给出）加 R3 路由回放；一致版本共享 vLLM 前向，不用路由回放。任务是在远端 sandbox（沙箱）里做 SWE-bench Pro 的 agentic RL（智能体式强化学习）：每步 32 题 × 8 条轨迹、每条轨迹平均约 57K tokens，GRPO，每次运行 8 个 GB200 节点；训练子集是从 SWE-bench Pro 里筛出的 375 道题（基座模型采样 4 次既非全对也非全错、且金标补丁能在 vLLM 的 sandbox 里通过）。
结果：一致版本的训练-推理 KL 每一步精确为 0，actor 熵稳定在 0.05 附近，训练奖励从 0.56（前 10 步）升至 0.59（后 10 步）；同配方基线的训练奖励从 0.56 跌到 0.22，actor 熵从 0.05 涨到 2.6，其 KL 反而从约 0.015 降到约 0.002。前 30 步（两次运行都还健康的窗口），一致版本的 rollout 吞吐为基线的 87.5%。博客强调这些是训练奖励，不是 held-out（留出）基准分数。
递归结构另有对齐规则：Mamba-2 的 decode 精确重演 prefill 的分块算术，而不是走自己的单步递推；FlashAttention 固定 split-KV，切分数量不随 batch 变化；NVFP4 专家 GEMM 固定单一 tactic、无 split-K，按 slot 顺序做 fp32 合并；MoE all-to-all 用单边通信并固定合并顺序。博客说这套迁移的对齐由 agent（智能体）加 skill 完成。
把排查流程做成 agent skill
vLLM 把这次对齐中反复走的流程蒸馏成一个 agent skill（供智能体执行的技能包）并开源：定位第一个发散的算子 → 缩成最小复现 → 修复 → 复验 → profile（性能剖析）并优化。它以 的形式提交到 vLLM 仓库，放在 .agents/skills/ 下，并从 .claude/skills/ 建立符号链接，包含从 C0 到 C10 共 11 道带有明确通过条件的流程关卡和一组问题指南；PR 描述称其仅改动文档、不影响 vLLM 行为；截至发稿，该 PR 仍处于开放状态。
流程中有几处关键设计：先在从全模型裁出的 4～6 层小模型上解决大部分局部数值问题，再上全模型；两个 agent 并行推进，一个把普通基线调快，另一个做一致版本，基线冻结供人审，防止把基线放慢来收窄差距；踩过的坑被写进流程，比如对照实验前先确认两侧用同一种通信传输、检查点恢复后的第一步也必须验证、性能结论必须配公平基线与可追溯的原始数据。vLLM 同时说明，skill 降低的是定位与回归成本（节省幅度尚未量化），不替代人的判断：基线、精度取舍与配方仍要人审，「每步只更新一次」就是人做的决定。与 skill 一起放出的还有配方与代码，包括 DeepSeek-V4 的 verl 配方 PR，以及 Nemotron 在 vLLM、Megatron-LM、verl 上的多处改动。帖文最后致谢了 NVIDIA DevTech 的 Yan Bai 与 Inferact 的 Ao Shen。
端到端 wall-clock 尚待测量，基线未做充分调优
两组实验的基线都只用一种配置、带 R3、不含 TIS/MIS，也都没有充分调优；博客提醒，这里出现的基线下滑只反映该配方，充分调优后未必如此。端到端收益来自更少的崩溃、回滚与重跑，只有在长时间运行中才能显现。
diff=0 的成立还依赖「每步只做一次更新（step batch 等于 mini-batch）」：如果一步里有多次 mini-batch 更新，从第二次起训练权重就已偏离采样权重；在每步 4 次更新的数学任务上，他们观察到每次更新后约 7% 的 token 换了专家组合。博客写明，diff=0 是工程目标，不是训练质量的充分条件，多次更新下的路由漂移就是例子。覆盖面也有边界：MTP（多 token 预测）与投机解码不在范围内；TP>1 与 decode 阶段的上下文并行不支持，因为那会把跨 GPU 归约重新放回被比较的数值路径。
这些数字全部出自 vLLM 官方博客和帖文，属于发布方自报口径。帖文称，DeepSeek-V4.1 的训练-推理一致性也已达到 0 diff，性能优化完成后会单独发文；端到端训练 wall-clock（实际耗时）加速的对比，则写明留待以后。