Prhub

#41653 [Test] Add DeepSeek MTP parallel-load tests

原始 PR 作者 stecasta 合并时间 2026-07-21 22:38 文件变更 2 提交数 8 评论 11 代码增减 +265 / -0

执行摘要

新增 DeepSeek MTP 并行加载测试

防止类似 #29545 (TP+EP 加载时崩溃) 的 bug 在没有回归门的情况下合入。跟踪 Issue #36264。

值得关注其测试设计思路:_spec_decode_num_drafts 指标用于验证 drafter 非空,避免无声回退;_token_match_ratio 以相似度容忍硬件差异。对于负责测试策略的工程师,这是一个良好的多并行测试模板。

讨论亮点

review 中的核心讨论包括:

  • 数据并行清理问题:gemini-code-assist[bot] 指出 _generate 函数缺少分布式环境清理,可能导致后续测试失败;stecasta 随后添加了 try/finally 块。
  • 源文件依赖范围:benchislett 要求缩小 CI 触发范围,仅依赖 spec decode 基础提案器和 EAGLE 文件,而不是整个 spec_decode 目录。
  • 正确性断言从精确匹配改为相似度:benchislett 质疑精确 token 匹配在不同并行度下不可靠;stecasta 改用 0.8 相似度阈值并解释原因。
  • EPLB 参数调整:benchislett 指出原来的 window_size=128 / step_interval=1024 在短生成中永远不会触发重排;stecasta 改为 window_size=2 / step_interval=4 确保 EPLB 实际运行。

实现拆解

实现分为 5 步:

  1. 定义并行配置枚举:通过 InlineConfig dataclass 定义 TP=2、EP=2、EP=2+EPLB、PP=2(跳过)四种配置。
  2. 构造引擎参数:_inline_kwargs 根据配置生成 LLM 初始化参数字典,包括启用 EPLB 时的窗口和步长参数。
  3. inline 测试函数:test_deepseek_mtp_load_inline 为每个配置分别构建 spec 和 no-spec 的 LLM,生成输出后使用 _token_match_ratio 检查 token 序列的相似度不低于 0.8,并通过 _spec_decode_num_drafts 确认 drafter 实际生效(非空)。
  4. 数据并行测试函数:test_deepseek_mtp_load_dp 使用 AsyncLLM 模拟 DP=2 的启动方式,生成输出并比较 spec/no-spec 结果。
  5. CI 配置:在 .buildkite/test_areas/spec_decode.yaml 中新增 Spec Decode DeepSeek MTP Parallel Load (B200) 任务,依赖 EAGLE 和 spec decode 相关源文件,使用 2 卡 B200 运行。
文件 模块 状态 重要度
tests/v1/e2e/spec_decode/test_mtp_parallel_load.py 并行加载测试 added 7.76
.buildkite/test_areas/spec_decode.yaml CI 配置 modified 4.07

关键符号

_token_match_ratio _inline_kwargs _generate_token_ids_inline _spec_decode_num_drafts test_deepseek_mtp_load_inline test_deepseek_mtp_load_dp _generate

分析完成后,这里会展示 LLM 生成的相对完整源码片段和详细注释。

评论区精华

数据并行测试缺少分布式环境清理 正确性

gemini-code-assist[bot] 指出 _generate 函数缺少 cleanup_dist_env_and_memory 和 torch.accelerator.empty_cache(),可能导致状态泄漏。建议添加 try/finally。

结论:stecasta 采纳并添加了 try/finally 块。 · 已解决

CI 源文件依赖范围太宽 设计

benchislett 要求将 source_file_dependencies 从整个 vllm/v1/spec_decode/ 缩小到仅 EAGLE 和 spec decode 基础文件,避免误触发。

结论:stecasta 按照建议缩小了范围。 · 已解决

精确 token 匹配在不同并行度下不可靠 正确性

benchislett 质疑精确匹配不保险;stecasta 切换为相似度比 0.8,并解释随机权重模型无法使用 GSM8k。

结论:采用相似度比,并添加非空指标。 · 已解决

EPLB 参数不适用于短生成 正确性

benchislett 指出初始参数 window_size=128 / step_interval=1024 在 MAX_TOKENS=8 的生成中永远不会触发重排;建议减小或增加生成长度。

结论:stecasta 改为 window_size=2 / step_interval=4,确保 EPLB 实际运行。 · 已解决

风险与影响

低风险:本 PR 仅添加测试文件和 CI 配置,不修改任何核心代码。风险点包括:

  1. 新 CI 任务使用 2 卡 B200,增加了资源占用,但设为 optional(可选),不影响主流水线。
  2. 测试模型为随机权重的小型模型(5 层 DeepSeek-V3),不会产生实际推理误差。
  3. 如 benchmark 显示,inline 测试运行约 493 秒(约 8 分钟),DP 测试约 38 秒,总 CI 时间增加可控。

对用户无直接影响;对团队的好处是新增了 DeepSeek MTP 在多种并行配置下的回归测试,防止未来类似 #29545 的 bug 逃避检测。对系统(CI)的影响是新增一个可选但依赖多 GPU 的测试任务。

新增多 GPU 测试 CI 时间增加 依赖随机权重模型

关联 Issue

#29545 [Bugfix] Fix DeepSeek R1 MTP weight loading
#36264 [Tracking issue]: NVIDIA CI improvements

完整报告

参与讨论