feat: resolve --hardware from the node in every launcher - #2738
Merged
Conversation
A 4-GPU H200 smoke test was routed through the multi-node GB300 TP8 path, so SGLang waited for ranks that the Ray pool could not provide. Choose TP8 only when the rollout pool has at least eight GPUs, validate the engine topology before submission, and cover both H200 and GB300 launchers.
PR #2717 treated every four-GPU node as the GB300 full-model profile, which routed the single-node 4-layer H200 smoke test into TP8/EP8. Exclude the 4-layer model from the GB300 branch and keep only the two launcher regression cases that distinguish the intended profiles.
Launchers hardcode a --hardware default, so running one on anything else silently applies the wrong profile unless the flag is passed. detect_hardware() resolves the node to a NUM_GPUS_OF_HARDWARE key: compute capability picks the generation, the host CPU separates Grace from the x86 part carrying the same die, and HBM capacity splits H100 from H200. It is a lookup at the point of use, not at construction, so prepare steps keep running GPU-free; the snapshot harness freezes it. GENERATION_HARDWARE gains H200/B200/B300, and the table check now derives the hardware it requires from every launcher's --hardware literal instead of a hardcoded list that #2585 already drifted from.
`num_gpus_per_node == 4` stood in for "GB300", so the 4-GPU H200 smoke test picked up the Grace TP8/EP8 rollout profile and hung at 4/8 clients joined. The reason for tp=8 is Grace CPU RAM under colocate, so read it off --hardware, which falls back to detecting the node rather than guessing from a GPU count. Excluding the 4-layer model by name left both halves wrong: a full-model run on a 4-GPU H200 node still took TP8, and a 4-layer run on GB300 still lost it. The profile now also requires eight rollout GPUs to exist, and an engine wider than the pool asserts at submission instead of hanging in the router. _is_blackwell and its private table go with it: the shared GENERATION_HARDWARE answers the same question. The 4-layer CI test pins hardware="H200" the way the v3.2 one does. Launcher snapshots are unchanged.
min() over the pool replaces the >= 8 guard: eight GPUs where the pool has them, the whole pool where it does not. The assertion stays for the profiles that pick a fixed size.
Every launcher hardcoded a --hardware default and, separately, a num_gpus_per_node literal. Running one on anything else silently applied the wrong profile: `--hardware GB300` without `--num-gpus-per-node 4` still sized the topology for eight GPUs per node, and forgetting --hardware entirely picked whatever machine the recipe was first written on. --hardware now defaults to "auto", which asks the node through detect_hardware() and overrides nothing that was passed explicitly. num_gpus_per_node follows from the resolved hardware unless it is given, which is how a job takes four GPUs of an eight-GPU node. resolve_hardware() also rejects a hardware the launcher has no verified profile for, instead of letting a `match` fall through it. The literals this replaces were all consistent: every launcher that declared hardware hardcoded exactly NUM_GPUS_OF_HARDWARE[its default hardware], so the snapshots are unchanged. The suite pins the machine each recording represents, since a launcher that reads the node cannot be recorded on a CPU runner. Launchers without a --hardware flag keep their literal: there a partial node is often deliberate (run_qwen3_0_6b_fsdp takes 4 GPUs, examples/verifiers 2).
yueming-yuan
requested review from
Shi-Dong,
Zhichenzzz,
fzyzcjy,
guapisolo,
jybsuper and
maocheng23
as code owners
August 24, 2026 21:44
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Claude Code Review
This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.
Tip: disable this comment in your organization's Code Review settings.
A test that builds ScriptArgs directly, rather than through the launch-script harness, has nothing freezing detect_hardware, so `--hardware auto` looks for a GPU the CPU runner does not have. Pin each of them to the default its launcher carried before, which is also what keeps an e2e recipe from following whichever runner picked it up.
Collaborator
|
Open disucssion: Should we keep the hardware detect -> num gpu per node assumption logic in script level like this PR, or move it into miles launch? (like arguments.py) Okay I think current logic is better. We shouldn't let the engine know too many logics. |
Collaborator
|
/rerun-test tests/e2e/megatron/test_qwen3_4B_ppo.py |
|
✅ |
guapisolo
approved these changes
Aug 25, 2026
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
Make
--hardwarethe single source for a launcher's machine profile: it defaults to detecting the node it runs on, andnum_gpus_per_nodefollows from it.Stacked on #2735 — the first three commits are that PR. Review from
ca4fcba01.Problem
Every launcher hardcodes two things about the machine:
Two ways to get a silently wrong profile out of that:
--hardware. You get whichever machine the recipe was first written on. fix(dsv4): fix deepseek v4 hareware branch #2735 is one instance of the same class — a 4-GPU H200 smoke test took the Grace TP8 rollout profile and hung at4/8 clients joined.--hardware GB300but not--num-gpus-per-node 4. The topology is still sized for 8 GPUs per node.Fix
--hardwaredefaults to"auto", resolved once in__post_init__:detect_hardware()(added in #2735) maps the node to aNUM_GPUS_OF_HARDWAREkey: compute capability picks the generation, the host CPU separates Grace from the x86 part carrying the same die, HBM capacity splits H100 from H200.resolve_hardware()additionally rejects a hardware the launcher declares no profile for, rather than letting amatch args.hardwarefall through it:An explicit
--hardwarestill overrides, and an explicit--num-gpus-per-nodestill wins over the derivation — that is how a job takes four GPUs of an eight-GPU node.Scope
19 launchers declare
hardware; all of them change. The 33 that do not keep their literal, because therenum_gpus_per_nodeis often a deliberate partial node (run_qwen3_0_6b_fsdptakes 4,examples/verifierstakes 2) rather than the machine's shape.Verification
The replaced literals were all consistent — every launcher that declares
hardwarehardcoded exactlyNUM_GPUS_OF_HARDWARE[its default hardware], 13/13, so this is behavior-preserving at the default:tests/manual/launch_scripts/test_py_launch_scripts.py: snapshots unchanged, 182 passed (the 8 failures and 4 errors are the same set as onmainin this checkout, all underscripts/amd/**andrun_kimi_k25).tests/fast/utils/test_command_utils.py+tests/fast/launch_scripts/test_run_deepseek_v4.py: 80 passed.pre-commit run --files <changed>: passed.Two new tests keep the recording pins honest: every pinned hardware must be one the launcher accepts, and a launcher the frozen default already covers may not be pinned twice.
Review focus
resolve_hardware()reads the supported set off the field'sLiteral— that is the one piece of reflection here._HARDWARE_A_RECORDING_REPRESENTSin the snapshot suite: a launcher that reads the node cannot be recorded on a CPU runner, so the suite states which machine each recording is.detect_hardware()'s capability table is not yet verified on real hardware (sm_103 for B300/GB300,aarch64for Grace are derived from the architecture, not measured). Worth one run on a B300 / GB300 / H200 node before merge.