DeepSeek-V4 RL 现已通过 Miles 正式落地于搭载 ROCm™ 的 AMD Instinct™ MI355X GPU 之上。其核心原理并不晦涩：强化学习过程中，SGLang 需负责生成候选路径（即 rollout），而 Megatron 则承担训练任务，两者必须在统一的策略下实现紧密配合——当 Miles 将更新后的权重反复传回在线部署引擎时，需要确保 token 概率保持对齐，这一协同至关重要。

真正增加挑战难度的，在于 DeepSeek-V4 Flash 模型自身的独特架构：混合压缩注意力机制、mHC 残差混合模块以及 MoE 路由选择，每一环节都让模型对齐操作变得极具复杂性。我们在 SGLang 与 Megatron 之间逐项校准了模型行为，保障量化状态在在线权重更新过程中不被破坏，并最终构建出完整的四节点工作流。为了验证精度，我们采用一个有界化的训练-部署对数概率差异作为判定标准；在更持续的运行周期中，离线 AIME-2024 基准分数不断攀升，在线奖励同步呈现正向增长——这才是真正有效的信号。

核心要点

• DeepSeek-V4 Flash RL 现已通过 Miles 在 AMD Instinct MI355X GPU 上成功运行。 我们攻克了在 ROCm 平台上实现端到端执行时所遇到的模型对齐与在线更新难题。
• 四节点验证已顺利完成。 超过 100 个优化步骤的端到端运行均获成功；训练-部署对数概率差异保持有界，在线奖励持续优化，离线 AIME-2024 评估得分稳步提升。
• 下一步工作重点：性能优化。 未来将聚焦于低精度训练、端到端性能调优以及在更大规模集群上的扩展实践。

一图看懂 DeepSeek-V4 Flash

DeepSeek-V4 Flash 是一个拥有 2840 亿参数的 MoE 架构模型，每一 token 仅激活 130 亿参数。本次实验所采用的配置包括 43 个解码器层、256 个路由专家（采用 top-6 选择策略）、4 条 mHC 残差流，并引入了一种结合 128 token 滑动窗口与压缩长上下文注意力的混合注意力机制。

C4 层从经过 4:1 压缩后的 KV 序列中提取前 512 个条目，而 C128 层则在经 128:1 压缩的序列上进行密集注意力计算。结合 mHC 残差混合与 MoE 路由，这些正是 SGLang 与 Megatron 必须精确对齐的主要架构特定路径。

图 1. 简化的 DeepSeek-V4 模块示意图，展示了 mHC 残差混合、混合压缩注意力及 top-6 MoE 路由机制。

Miles 技术栈

Miles 负责协调这一异步循环的全过程。SGLang 生成候选回复与部署对数概率；Megatron 对相同序列进行评分、计算策略更新并训练 actor 模型；随后 Miles 将更新后的权重传回正在运行的 SGLang 工作节点。

当前的 FP8 路径使用 FP8 Hugging Face 检查点进行部署，并采用 BF16 Megatron torch_dist 检查点进行 actor 训练。因此，两个引擎以不同的执行格式代表同一个策略——这使得格式转换、重新评分及在线更新行为都成为正确性边界中不可忽视的组成部分。

图 2. 提示（Prompts）流入 SGLang 部署层；轨迹与 log 概率通过 Miles 传递给 Megatron actor；更新后的权重在下一轮部署启动前返回给 SGLang。

挑战一：弥合训练与部署之间的对数概率差距

强化学习训练依赖于 SGLang 与 Megatron 对同一生成的 token 赋予相近的概率。我们建立了一套逐 token 比较的工作流：SGLang 首先生成一个序列，两个引擎对相同的 token 进行评分，逐 token 差异能够在代价高昂的多节点验证之前，有效暴露模型层面的不匹配问题。

这种比较在两条 DeepSeek-V4 特有的路径上发现了差异：早期的哈希路由 MoE 以及 mHC 残差混合模块。我们使 Megatron 的哈希路由行为与 SGLang 对齐，并修正了 Megatron 端的 mHC 后混合逻辑，确保两个引擎保留了相同的模型语义。这些针对性调整，让部署与训练在数值上更趋一致。

挑战二：在线更新过程中保持量化语义的完整性

在强化学习中，部署服务器会反复接收更新后的策略权重，无需重启。对于量化模型而言，一次成功的传输仅仅是开始：打包后的权重、缩放张量以及依赖量化状态的运行时，都必须保留其原有的语义信息。

针对 FP4 与 E8M0 张量，AMD 让更新路径具备了数据类型感知能力，从而避免了更新后因张量被错误解读而产生无效生成。对于 FP8，Miles 已定义更新后的完整生命周期；AMD 在 ROCm 堆栈中补全了缺失的 SGLang 接口，确保 Miles 能在恢复部署前执行所需的量化处理。

这里的关键经验很明确：在线更新必须恢复模型原有的量化状态，而不仅仅是复制它的字节数据。

挑战三：在 ROCm 上实现稳定的多节点并行策略

将 DeepSeek-V4 Flash RL 扩展到多个 AMD Instinct MI355X 节点，会暴露出两个相互关联的启动问题：一是为 2840 亿参数的 MoE 模型在 4K 上下文长度下选择合适的模型并行策略，二是保持多节点集合通信的稳定性。这两者其实是紧密捆绑的。更高的张量并行度虽能降低单 GPU 内存消耗，但会相应增加集合通信流量。早期的一些多节点配置曾在 RCCL 集合通信内部卡死——例如某个张量并行 all-reduce 或专家 all-to-all 未能完成，被通信看门狗捕获进而终止整个运行。

我们最终收敛到一个既满足内存需求又能保持稳定的布局：跨越四个 8-GPU 节点，采用张量并行 1、流水线并行 4、专家并行 4 的配置，同时配合激活重计算、将优化器状态卸载到主机内存，以及有界的每 GPU token 预算。将并行度从张量并行的 all-reduce 向流水线并行和专家并行转移，再结合调优后的 RCCL 传输设置，让运行能够端到端地执行超过 100 个优化步骤而不会出现集合通信卡死。建立这个稳定的运行点是后续更长周期验证的必要前提。

在 AMD Instinct MI355X GPU 上完成四节点验证

我们在四个 8-GPU AMD Instinct MI355X 节点上对 FP8 路径进行了验证：其中两个节点用于 SGLang 部署，两个用于 Megatron actor 训练。Miles 协调了在长上下文数学工作负载（DAPO-Math-17K，4K 上下文）上的 GRPO 风格训练、奖励收集以及反复的在线权重更新，使用的模型并行配置为张量并行 1/流水线并行 4/专家并行 4。每十个步骤，我们都会在 AIME-2024 基准上运行一次离线评估，每个问题采样 8 次。部署模型采用 FP8，而 actor 则使用 BF16 进行训练。

正确性与在线奖励

一个关键的正确性检查点，在于评估部署与训练给同一批生成 token 分配的概率是否相近。在整个记录的步骤中，平均绝对对数概率差异约为 0.09。如图 3 所示，该差异在超过 100 个步骤和反复的权重更新中始终保持有界，未出现持续的向上漂移或更新后的急剧增长。这是一个令人鼓舞的初步结果，但尚不能代表最终的性能阈值。

图 3. 前 100 个训练步骤中，训练与部署的绝对对数概率差异。

除了有界的对数概率一致性，训练过程中的在线奖励也呈现持续改善态势。在一次更长时间的运行中，在线原始奖励展现出清晰的上升趋势，而非保持平缓：其均值从运行的前三分之一阶段上升到后三分之一阶段（图 4）。这充分表明 actor 在持续的 GRPO 训练和反复的在线权重更新下确实取得了进步，而不仅仅是维持原有奖励水平。

图 4. 超过 100 个训练步骤的在线原始奖励（包括每步数值、移动平均线及线性拟合）。奖励在运行过程中持续增加，呈现出正向的线性斜率。

AIME-2024 离线评估

在线通过率是在训练工作负载上测量的，难免受到动态采样的干扰，带来一定偏差。因此，我们每十个步骤增加了一个保留的离线基准测试——AIME-2024，每个问题采样 8 次。这是衡量模型真实质量的黄金标准。在前 100 个步骤中，离线 AIME pass@1 从 0.39 提升至 0.49，pass@8 从 0.53 提升至 0.67；同时，在 4096 token 上限下发生的响应截断比例，从 60% 下降至 55%。单次准确率与多样本覆盖率同步提升，说明这并非仅仅是模型在已有解决方案上的“尖锐化”，而是在 GRPO 训练下获得了实质性的能力增长。对于一个只有 30 道题的基准测试而言，每次评估的数值本身会有噪音，所以真正的信号在于整体趋势，而非某一个孤立的点。

图 5. 前 100 个 RL 训练步骤中的离线 AIME-2024 pass@1/2/4/8（每 10 步评估一次，每个问题 8 个样本）。无论是单次准确率（pass@1）还是覆盖率（pass@8），均呈现出清晰的向上趋势。

经验总结

离线基准评估才是诚实的信号。 在训练工作负载上的在线通过率容易受到动态采样和过度采样的干扰；每十步进行一次保留的 AIME-2024 评估，才能提供一个可靠的模型质量度量。我们建议，每次 RL 运行都应辅以周期性的离线评估。

RL 同时提升了准确率与覆盖率。 在 100 个步骤内，离线 AIME pass@1 从 0.39 上升到 0.49，pass@8 从 0.53 上升到 0.67。pass@1 与 pass@k 的同时提升，表明策略确实获得了新能力，而不仅仅是围绕着已有解进行了“锐化”。

跨引擎的一致性在长时间运行中保持稳定。 训练-部署的对数概率差异在 100 多个步骤和反复的权重更新后依然有界，这确认了启动阶段的对齐效果在远超初始验证窗口的时间范围内依然有效。

响应截断是当前绝对评估分数的天花板。 大约 55-60% 的 AIME 回答都会触及 4096 token 的生成上限；提高评估响应的预算，是提升绝对准确率最高杠杆的手段。

要看趋势，而不是看单独的某一步。 每步的在线奖励和每次评估的通过率都带有噪音（在线奖励的步间波动范围在 0.36-0.77）；移动平均线和周期性的离线评估，才是可靠的进展信号。

未来规划

• 启用 FP8 actor 训练。 将 Megatron actor 从 BF16 扩展到 FP8，并评估其对训练-部署对齐以及训练质量的影响。
• 性能分析与瓶颈定位。 识别端到端 RL 流水线中最大的性能差距，并优先处理影响最高的瓶颈。
• 性能优化。 提升部署吞吐量、训练效率，并优化部署与 actor 执行之间的重叠。
• 规模扩展。 在更大的集群上评估吞吐量、效率和正确性，然后调整分布式执行以维持扩展效率。

启动命令

实验使用了一个外部的 Ray 集群和一个统一的启动命令，在 ROCm 容器内运行。

Docker 镜像：rlsys/miles:rocm7.2-mi35x-dsv4

关键配置如下所示；完整的 RCCL 传输和飞行记录器环境变量在启动脚本中设置。

# 1) 启动Ray集群（一个head节点+三个worker节点），在ROCm容器内运行# head节点：ray start --head --node-ip-address=$HEAD_IP --port=6379 --num-gpus=8# 每个worker节点：ray start --address=$HEAD_IP:6379 --node-ip-address=$WORKER_IP --num-gpus=8# 2) 从head节点启动DeepSeek-V4 Flash RLexport MASTER_ADDR=xxxexport MILES_SCRIPT_EXTERNAL_RAY=1export RAY_ADDRESS=xxxexport PYTHONUNBUFFERED=1export NCCL_SOCKET_IFNAME=xxxexport GLOO_SOCKET_IFNAME=xxxexport TP_SOCKET_IFNAME=xxxexport NCCL_IB_HCA=xxxexport NCCL_IB_GID_INDEX=1RUN_ID=dsv4-fp8-4node-2roll-tp1-pp4-ep4-$(date +%Y%m%d_%H%M%S)LOG=/workspace/miles/${RUN_ID}.log/opt/venv/bin/python3 scripts/amd/run_deepseek_v4.py train --run-id "${RUN_ID}" --mode normal --enable-eval --num-nodes 4 --actor-num-nodes 2 --rollout-num-nodes 2 --num-rollout 200 --num-steps-per-rollout 1 --rollout-batch-size 32 --n-samples-per-prompt 8 --context-length 16384 --rollout-max-response-len 4096 --max-tokens-per-gpu 8192 --sglang-max-running-requests 48 --sglang-max-total-tokens 524288 --tensor-model-parallel-size 1 --pipeline-model-parallel-size 4 --decoder-last-pipeline-num-layers 10 --context-parallel-size 1 --expert-model-parallel-size 4 --expert-tensor-parallel-size 1 --extra-args '--wandb-team xxx --use-tis' --extra-env-vars 'TORCH_NCCL_DUMP_ON_TIMEOUT=1 TORCH_NCCL_TRACE_BUFFER_SIZE=200000TORCH_FR_BUFFER_SIZE=200000 TORCH_NCCL_DESYNC_DEBUG=1 TORCH_NCCL_ASYNC_ERROR_HANDLING=1TORCH_NCCL_DEBUG_INFO_TEMP_FILE=/workspace/miles/nccl_fr_trace_ GPU_MAX_HW_QUEUES=2NCCL_P2P_NET_CHUNKSIZE=262144' 2>&1 | tee "${LOG}"

总结

我们通过在 SGLang 部署与 Megatron 训练之间对齐模型行为，并在在线权重更新过程中保留量化状态，成功在 ROCm 上实现了一套端到端的 DeepSeek-V4 Flash RL 训练工作流。

在四节点 AMD Instinct MI355X 验证中，Miles 协调了 FP8 部署、BF16 actor 训练、奖励收集以及超过 100 个优化步骤的反复策略更新。训练-部署的对数概率差异在整个过程中保持有界，在线奖励持续改善，离线 AIME-2024 基准分数也从 pass@1 的 0.39 提升至 0.49（pass@8 从 0.53 提升至 0.67）。下一步，我们将启用 FP8 actor 训练、进行性能优化，并在更大的规模上评估这套工作流。

致谢

这项工作建立在来自 SGLang 和 Miles 社区对 DeepSeek-V4 支持的基础之上。我们感谢与 AMD 合作的 Miles 团队，以及所有为 Megatron、AITER、Triton、TileLang、Transformer Engine 和 ROCm 做出贡献的开发者们——正是他们的软件构成了完整的端到端技术栈。

AMD 贡献者： Xinyu Kang, Liz Li, Yuankai Chen, Zhiyao Jiang, Kailesh Gogineni, Yao Fu, Wen Xie, Gowtham Ramesh, Cheng Yao, Xiaobo Chen, Shekhar Pandey, Sree Rohith Pulipaka, Wen Chen, Yuzhen Zhou, Xinyu Jiang, Hai Xiao, Andy Luo, Zhenyu Gu.

Miles 贡献者： Yusheng Su, Jiajun Li, Banghua Zhu, 以及 Miles 团队全体成员。

附录

ROCm 运行时及内核路径映射

本次报告的运行中，对于直接影响跨引擎一致性和在线更新的模型组件，使用了以下路径。

表 1. 本次报告的 ROCm 配置中使用的运行时路径。

启动器使得选定的后端明确可见，同时 Docker 作用域内的补丁移除了 Megatron 和 Transformer Engine 依赖路径中残留的 CUDA 专属假设。这确保了所测试的配置可以复现和审查。