Prhub

#50766 [Bugfix] serving_llama70B_tp4 benchmark was silently running at tensor_parallel_size=1

原始 PR 作者 wjabbour 合并时间 2026-08-03 10:26 文件变更 1 提交数 2 评论 2 代码增减 +1 / -0

执行摘要

修复 Llama70B TP4 基准静默跑成 TP1

PR body 说明:在构建 AMD 特定变体基准配置 serving-tests-rocm.json(镜像自 serving-tests.json)时,通过 run-performance-benchmarks.sh 中实际的 merge_serving_tests_stream 合并逻辑验证复制的条目,发现 serving_llama70B_tp4_random_128_128 的 server_parameters 从未设置 tensor_parallel_size,静默继承了文件 defaults 块中的 tensor_parallel_size: 1。测试名以及固定 8192 max_num_batched_tokens、async_scheduling 参数都是为 4 GPU 运行准备的,但实际 TP 度却默认为 1,导致该测试一直在 perf.vllm.ai 连续基准上以 tp1 而非 tp4 运行。

值得快速浏览而非精读:它是一行配置修复,但对性能基准数据的可信度有直接影响,适合负责性能监控与 CI 基准的工程师关注。核心启示是 merge_serving_tests_stream 的 defaults 合并语义——缺省字段静默继承——是配置“看起来对、实际错”的温床;建议顺手审计同文件其他条目,并在 run-performance-benchmarks.sh 侧增加合并后字段完整性断言,把这类问题从“人工发现”变成“自动拦截”。

讨论亮点

唯一的行内评论来自作者 wjabbour:他在 diff 行上说明该缺失参数最初由 PR #43262 引入,Gemini 也捕捉到了同一问题,本次是在 AMD 变体配置验证中经由真实合并逻辑暴露,而非纯视觉检查。该评论只澄清缺陷来源,没有引发设计争议;reviewer bigPYJ1151 直接批准并合并。另有一条 bot 自动评论提示 fork 来源的自动化审查被禁用,需要维护者手动触发,这与人工批准流程一致。

实现拆解

  1. 问题定位:作者在构建 AMD 版基准配置 serving-tests-rocm.json 时,用 run-performance-benchmarks.sh 中真实的 merge_serving_tests_stream 合并逻辑校验复制的条目,发现 serving_llama70B_tp4_random_128_128 的 server_parameters 缺少 tensor_parallel_size,合并 defaults 后静默得到 1。
  2. 根因确认:该合并逻辑按 defaults → 每测试覆盖的方式补全字段,缺省字段继承 defaults 块的值;该测试名与参数(8192 max_num_batched_tokens、async_scheduling)均为 4 卡设计,实际却以 TP1 运行,说明历史基准数据口径长期错误。
  3. 修复变更:在 .buildkite/performance-benchmarks/tests/serving-tests.json 的该条目 server_parameters 中显式加入 tensor_parallel_size: 4 以覆盖 defaults,共 +1/-0,为唯一文件改动。
  4. 验证与配套:通过 merge_serving_tests_stream 管道 jq 对比修复前后输出(1 → 4);jq 校验 JSON 仍合法;7 个测试名合并无回归;pre-commit 对该文件的 JSON 检查通过。无代码、测试或部署配套改动;提交历史中另有一次 merge main 操作以保证分支同步。
文件 模块 状态 重要度
.buildkite/performance-benchmarks/tests/serving-tests.json 基准配置 modified 3.68

关键源码片段

.buildkite/performance-benchmarks/tests/serving-tests.json test-coverage

唯一变更文件。为 serving_llama70B_tp4_random_128_128 的 server_parameters 显式补上 tensor_parallel_size: 4,修复其静默继承 defaults 的 TP1 而长期以错误并行度运行的问题,直接影响 perf.vllm.ai 基准数据正确性。

{
  "test_name": "serving_llama70B_tp4_random_128_128",
  "server_parameters": {
    "model": "meta-llama/Llama-3.3-70B-Instruct",
    // 本次修复:显式声明 TP 为 4,避免 merge_serving_tests_stream
    // 合并 defaults 时静默继承 tensor_parallel_size: 1
    "tensor_parallel_size": 4,
    "async_scheduling": "",
    "no_enable_prefix_caching": "",
    // 8192 的 batch 上限与 async_scheduling 均为 4 卡设计,
    // TP1 运行时既不匹配也无代表性,数据无可比性
    "max_num_batched_tokens": 8192
  },
  "client_parameters": {
    "model": "meta-llama/Llama-3.3-70B-Instruct",
    "dataset_name": "random",
    "random-input-len": 128,
    "random-output-len": 128
  }
}

评论区精华

缺失 TP 参数的引入来源追溯 正确性

作者 wjabbour 在行内评论中说明:该缺失的 tensor_parallel_size 参数最初由 PR #43262 引入,Gemini 也捕捉到了同一问题;本次修复源于 AMD 变体配置验证中发现,而非纯视觉检查。

结论:评论仅澄清缺陷背景,未引发设计争论;reviewer bigPYJ1151 批准并合并。 · 已解决

风险与影响

  1. 历史基准数据污染:修复前该测试在 perf.vllm.ai 上长期按 TP1 运行,历史 serving_llama70B TP4 数据不能作为 4 卡性能基线,需要在结果分析中标记或废弃。
  2. 默认值合并陷阱的系统性风险:merge_serving_tests_stream 的 defaults 合并语义意味着同文件其他条目也可能存在同类静默缺省(如 max_num_batched_tokens、async_scheduling),建议对 serving-tests.json 全量做一次合并后字段完整性审计。
  3. 资源依赖:显式 TP4 后该基准必须由 4 GPU 环境承接,若基准集群资源不足会直接失败而非静默降级,需要确认运行环境满足要求。

影响面集中在 perf.vllm.ai 的连续性能基准:修复后 serving_llama70B_tp4_random_128_128 将按真实 TP4 运行,得到正确的吞吐与延迟数据;对 AMD 变体配置(serving-tests-rocm.json)的验证流程也有示范意义。对最终用户无感知,无 API、模型、内核或推理行为变化。对团队的启示是基准配置需要经过真实合并逻辑的自动化校验,避免视觉检查漏判这类语义缺省。

历史基准数据口径错误 配置默认值静默继承 TP4 需 4 GPU 资源

关联 Issue

未识别关联 Issue

当前没有检测到明确关联的 Issue 链接,后续同步到相关引用后会出现在这里。

完整报告

参与讨论