-
Notifications
You must be signed in to change notification settings - Fork 254
[AMD] Qwen3.5-FP8 MI355X SGLang disagg perf tuning: image bump to v0.5.16, TP4P+TP8D baseline, add MTP / Qwen3.5-FP8 MI355X SGLang disagg 性能调优:镜像升级至v0.5.16,TP4P+TP8D基线优化,新增MTP配置 #2557
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
ChangLiu0709
wants to merge
9
commits into
main
Choose a base branch
from
chang/qwen3.5-mi355-di-baseline-and-mtp
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
d0fb017
[AMD] Qwen3.5-FP8 MI355X SGLang disagg: image bump, TP4P+TP8D baselin…
ChangLiu0709 3a57f31
fix(qwen3.5-disagg-mtp): split MTP config for conc=128 TP4D decode
ChangLiu0709 2f9c124
fix(job.slurm): add kill -9 fallback for stuck Docker containers
ChangLiu0709 faabfa2
fix(job.slurm): pre-pull Docker image on all nodes before barrier
ChangLiu0709 6c8928f
merge: resolve perf-changelog.yaml conflict with main
ChangLiu0709 6f1de46
ci: re-trigger sweep with fresh priority classification
ChangLiu0709 b5361fb
fix: restore deleted minimaxm3 entry in perf-changelog.yaml
ChangLiu0709 f2f806c
ci: re-trigger sweep after removing conflicting label
ChangLiu0709 e4ecc2c
merge: resolve perf-changelog.yaml conflict with main
ChangLiu0709 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,20 @@ | ||
| #!/usr/bin/env bash | ||
| # Run `docker` under the 'docker' group. | ||
| # | ||
| # Why: Slurm launches job steps without the user's 'docker' supplementary group | ||
| # in the active credential set. The user IS a docker-group member (getent group | ||
| # docker lists them) but the group is missing from `id -G` inside the step, so | ||
| # the group-owned socket (/var/run/docker.sock, 0660 root:docker) is unreachable | ||
| # via a plain `docker` call. `sg docker -c` re-activates the group for this one | ||
| # command — no sudo, no password, no persistent host change. | ||
| # | ||
| # Used by job.slurm's DOCKER_CMD detection as the fallback when plain `docker` | ||
| # fails but `sg docker -c 'docker ps'` succeeds. | ||
| # | ||
| # argv is passed across the `sg` shell hop by NUL-delimited base64 (NOT string | ||
| # re-quoting): naive `printf %q` mangles the big multiline `docker run ... bash | ||
| # -lc '<script>'` argument (trailing newline became a literal 'n', spawning a | ||
| # stray `$n`). base64 round-trips arbitrary bytes (newlines, quotes) exactly, | ||
| # and only the base64 blob (safe chars) is interpolated into the sg command. | ||
| b64=$(printf '%s\0' "$@" | base64 | tr -d '\n') | ||
| exec sg docker -c "bash -c 'mapfile -d \"\" -t __A < <(printf %s \"$b64\" | base64 -d); exec docker \"\${__A[@]}\"'" |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟡 The new
qwen3.5-fp8-mi355x-sglang-disagg-mtpentry (configs/amd-master.yaml:332-351) runs decodetp: 8for the entireconc-list [8,16,32,64,128], but the PR's own results table andperf-changelog.yamlstate that at conc=128 TP8 decode causes 'MTP collapse' and that the documented numbers (interactivity 39.5, tput/GPU 5147) were actually measured on TP4P+TP4D. A sweep of this config will therefore reproduce the known-collapse topology at conc=128 instead of the validated one. Consider splitting conc=128 into its own arm with decodetp: 4, matching the pattern used elsewhere in this file (e.g.dsr1-fp8-mi355x-sglang-disagg-mtp).Extended reasoning...
The committed
qwen3.5-fp8-mi355x-sglang-disagg-mtpsearch-space arm (configs/amd-master.yaml:332-351) is a single block coveringconc-list: [8, 16, 32, 64, 128]withdecode: { tp: 8, ep: 1, ... }applied uniformly to every concurrency point. There is no second arm carving out conc=128 with a different decode topology.However, the PR description's own MTP benchmark table daggers the conc=128 row explicitly: 'conc=128 MTP uses TP4P+TP4D (8 GPU) — TP8 decode at conc=128 causes MTP collapse; TP4D resolves it with +83% tput/GPU.' The accompanying
perf-changelog.yamladdition echoes this independently: 'at conc=128 the decode TP8 bottleneck causes MTP collapse (-38% tput/GPU), which is resolved by switching to TP4D.' Both artifacts agree the author already discovered and worked around this collapse during local validation, but that workaround (switching decode to TP4 at conc=128) was never encoded back into the committed YAML.The result is a config/documentation mismatch: the recipe as written will always exercise the TP8 decode topology at conc=128, which is the exact case the author's own text says degrades throughput by ~38%. A sweep run against this config cannot reproduce the row of numbers (interactivity 39.5, tput/GPU 5147) that the PR presents as the MTP conc=128 result, because those numbers came from a TP4D run this config doesn't perform. This isn't a case of stale prose describing correct code — the YAML and the changelog/description are making mutually exclusive factual claims about which topology conc=128 runs on.
This pattern (splitting a conc range into separate arms with different decode tp/DECODE_MTP_SIZE per topology) is already established elsewhere in this same file — see
dsr1-fp8-mi355x-sglang-disagg-mtpanddsr1-fp4-mi355x-sglang-disagg-8k1k-mtp, both of which use multiple per-conc arms specifically to match validated topologies. That makes the fix straightforward and consistent with existing conventions: drop conc=128 from the current TP8D arm and add a second arm withconc-list: [128],decode: { tp: 4, ... }, mirroring the existingqwen3.5-fp8-mi355x-sglang-disaggbaseline entry's TP4P+TP8D pattern but with decode tp=4.Concrete walkthrough: (1) a maintainer runs the full sweep on
qwen3.5-fp8-mi355x-sglang-disagg-mtp; (2) at conc=128 the recipe launches decode with tp=8 per the single committed arm; (3) per the PR's own analysis this triggers MTP collapse, so the sweep records materially worse throughput (~38% lower tput/GPU per the changelog) than the TP4D figures published in the PR description's table; (4) anyone comparing the recorded sweep data against the PR's stated 5147 tput/GPU for conc=128 will find it doesn't match, because the committed recipe never runs the TP4D topology that produced that number.Impact is data-quality/reproducibility rather than a hard failure: the run will complete and produce a valid (if degraded) data point rather than crashing, since the sibling spec-none baseline arm also runs conc=128 on TP8D deliberately for apples-to-apples comparison. For that reason this is best treated as a fix-before-merge nit rather than a blocking correctness bug.