Skip to content

[AMD][MI35X] Add HiCache and TP2/EP1 arms to the Qwen3.5 MXFP4 MI355X AgentX sweep - #2693

Open
yichiche wants to merge 2 commits into
mainfrom
amd/qwen3.5-fp4-mi355x-agentic-hicache-tp2ep1
Open

[AMD][MI35X] Add HiCache and TP2/EP1 arms to the Qwen3.5 MXFP4 MI355X AgentX sweep#2693
yichiche wants to merge 2 commits into
mainfrom
amd/qwen3.5-fp4-mi355x-agentic-hicache-tp2ep1

Conversation

@yichiche

Copy link
Copy Markdown
Collaborator

Motivation

Two structural gaps remain between qwen3.5-fp4-mi355x-sglang-agentic-mtp and its B200 counterpart qwen3.5-fp4-b200-sglang-agentic-mtp, and both make the current AgentX comparison misleading.

First, KV offload. The B200 arm carries a HiCache host-DRAM KV tier and rides it past the GPU-KV ceiling to concurrency 64+, while MI355X runs GPU-resident KV only and stops at concurrency 40. The MI355X curve therefore ends where the B200 curve is still climbing, and the difference measured at the top of the sweep is a cache-tier difference rather than a hardware difference.

Second, the 2-GPU point. B200 sweeps TP2/EP1; MI355X sweeps TP2/EP2. Those are not the same partitioning, so the 2-GPU columns are not comparable across the two fleets.

Modifications

Add a HiCache host-DRAM KV tier to benchmarks/single_node/agentic/qwen3.5_fp4_mi355x_sglang_mtp.sh, gated on KV_OFFLOADING=dram with KV_OFFLOAD_BACKEND=hicache through the shared require_agentic_kv_offload_backend helper. KV_OFFLOADING and TOTAL_CPU_DRAM_GB join the script's check_env_vars list, matching the B200 and dsv4 AgentX recipes.

The tier uses --enable-hierarchical-cache with ratio 1.5, write_through, direct io, and page_first_direct layout. That combination is the one already validated on cluster:mi355x-amds by dsv4_fp4_mi355x_sglang_mtp.sh and glm5.2_fp4_mi355x_sglang_mtp.sh; every knob stays overridable via environment variable for tuning. Unlike the B200 sibling this arm keeps --page-size 16, so the kvnone and kvdram points differ only in the cache tier.

In configs/amd-master.yaml, replace the TP2/EP2 arm with TP2/EP1 and add two kvdram arms:

arm kv-offloading conc-list
TP4/EP1 none 1, 4, 8, 12, 16, 20, 24, 28, 32, 40 (unchanged)
TP2/EP1 none 1, 4, 8, 12, 16, 20 (replaces TP2/EP2)
TP4/EP1 dram (hicache) 40, 48, 56, 64
TP2/EP1 dram (hicache) 20, 24, 28, 32

Each kvdram arm repeats its kvnone neighbour's last concurrency (40 at TP4, 20 at TP2) so the host tier's gain is measured at a fixed operating point rather than inferred across a concurrency step. This follows the same idiom as dsv4-fp4-mi355x-sglang-agentic-mtp, which repeats concurrency 16 across its two arms.

The sweep grows from 16 to 24 points.

Accuracy Tests

No accuracy-affecting logic changes in this repo. The kvdram arms change where KV lives, not what is computed; the AgentX eval rows continue to run real target-model verification.

Benchmarking

Repo validation was run locally:

  • python -m pytest utils/matrix_logic/ -q → 232 passed.
  • bash -n benchmarks/single_node/agentic/qwen3.5_fp4_mi355x_sglang_mtp.sh → clean.
  • python utils/matrix_logic/generate_sweep_configs.py full-sweep --config-files configs/amd-master.yaml --model-prefix qwen3.5 --precision fp4 --scenario-type agentic-coding → 24 configs: TP4/EP1 kvnone 10, TP2/EP1 kvnone 6, TP4/EP1 kvdram-hicache 4, TP2/EP1 kvdram-hicache 4. No TP2/EP2 points remain.

End-to-end MI355X AgentX numbers will come from the sweep triggered on this PR (full-sweep-fail-fast). HiCache ratio 1.5 is the starting point inherited from the sibling recipes on this cluster; if the host pool is oversubscribed or the hit rate is poor, HICACHE_RATIO is the first knob to retune.

… AgentX sweep

Add a HiCache host-DRAM KV tier to the AgentX script, gated on KV_OFFLOADING=dram with KV_OFFLOAD_BACKEND=hicache. The ratio 1.5 / write_through / direct / page_first_direct combination is the one already validated on cluster:mi355x-amds by the dsv4 and glm5.2 AgentX recipes, and every knob stays overridable. The arm keeps --page-size 16 so only the cache tier differs between the kvnone and kvdram points.

Replace the TP2/EP2 arm with TP2/EP1 to match qwen3.5-fp4-b200-sglang-agentic-mtp's 2-GPU point, and add kvdram arms at TP4 concurrency 40-64 and TP2 concurrency 20-32. Each kvdram arm repeats its kvnone neighbour's last concurrency so the host tier's gain is measured at a fixed operating point.
@github-actions

Copy link
Copy Markdown
Contributor

Thanks for the contribution! Please reach out to respective companies' CODEOWNER to fill in the latest PR_REVIEW_CHECKLIST.md before pinging core maintainer on Slack for review. In order for the signoff PR check bot to trigger, you must follow the PR_REVIEW_CHECKLIST.md template correctly, including the phrase As a PR reviewer and CODEOWNER, I have reviewed this and have.

For PR verification, add the full-sweep-fail-fast label (strongly recommended) to this PR — the benchmark sweep only runs on labeled PRs. Use full-sweep-enabled only if you need matrix jobs to keep running past a failure.

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. See GitHub's docs on re-running failed jobs


感谢你的贡献!请联系相应公司的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md,然后再在 Slack 上联系核心维护者进行审阅。为了触发 signoff PR 检查机器人,你必须正确遵循 PR_REVIEW_CHECKLIST.md 模板,包括保留英文语句 As a PR reviewer and CODEOWNER, I have reviewed this and have

如需进行 PR 验证,请为此 PR 添加 full-sweep-fail-fast 标签(强烈推荐)— 基准测试 sweep 仅在带有标签的 PR 上运行。仅当需要矩阵任务在失败后继续运行时才使用 full-sweep-enabled

PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动(flake),重新运行失败的任务即可解决。参见 GitHub 关于重新运行失败任务的文档

1 similar comment
@github-actions

Copy link
Copy Markdown
Contributor

Thanks for the contribution! Please reach out to respective companies' CODEOWNER to fill in the latest PR_REVIEW_CHECKLIST.md before pinging core maintainer on Slack for review. In order for the signoff PR check bot to trigger, you must follow the PR_REVIEW_CHECKLIST.md template correctly, including the phrase As a PR reviewer and CODEOWNER, I have reviewed this and have.

For PR verification, add the full-sweep-fail-fast label (strongly recommended) to this PR — the benchmark sweep only runs on labeled PRs. Use full-sweep-enabled only if you need matrix jobs to keep running past a failure.

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. See GitHub's docs on re-running failed jobs


感谢你的贡献!请联系相应公司的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md,然后再在 Slack 上联系核心维护者进行审阅。为了触发 signoff PR 检查机器人,你必须正确遵循 PR_REVIEW_CHECKLIST.md 模板,包括保留英文语句 As a PR reviewer and CODEOWNER, I have reviewed this and have

如需进行 PR 验证,请为此 PR 添加 full-sweep-fail-fast 标签(强烈推荐)— 基准测试 sweep 仅在带有标签的 PR 上运行。仅当需要矩阵任务在失败后继续运行时才使用 full-sweep-enabled

PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动(flake),重新运行失败的任务即可解决。参见 GitHub 关于重新运行失败任务的文档

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Automated review found no functional bugs — the only finding is a nit-level pr-link metadata mistake in the changelog entry (already flagged inline). Given a candidate accuracy-eval-arm-selection concern was raised and ruled out this run, leaving this note for the record.

Extended reasoning...

Beyond the inline nit, I also checked whether the accuracy eval row silently moved to a different arm (kvnone to the new HiCache conc=64 arm) in configs/amd-master.yaml — the eval row selection is independent of which arm this PR adds, so it's not affected.

Comment thread perf-changelog.yaml
@github-actions

Copy link
Copy Markdown
Contributor

2 similar comments
@github-actions

Copy link
Copy Markdown
Contributor

@github-actions

Copy link
Copy Markdown
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

1 participant