[2.0] Default resources.gpu_type and gpus_per_node from srtslurm.yaml - #392
Closed
ishandhanani wants to merge 1 commit into
Closed
ishandhanani wants to merge 1 commit into
ishandhanani wants to merge 1 commit into
Conversation
This was referenced Sep 6, 2026
Closed
ishandhanani
marked this pull request as ready for review
September 7, 2026 19:16
ishandhanani
requested review from
alec-flowers,
csahithi and
nlevin-ui
as code owners
September 7, 2026 19:16
gpu_type and gpus_per_node describe the cluster, not the deployment, yet every recipe repeated them. Make both inheritable so one recipe can move between clusters unchanged: - resources.gpu_type is now optional (str | None); a recipe that omits it inherits srtslurm.yaml default_gpu_type. - resources.gpus_per_node inherits the cluster gpus_per_node when omitted (else the existing default of 4). - ClusterConfig gains default_gpu_type. Applied in resolve_config_with_defaults; an explicit recipe value always wins. The fields stay valid in recipes so a run is self-describing for result rollups. No consumer required gpu_type to be non-None. Docs: config-reference resources + cluster tables; regenerated schema-reference. Part of the 2.0 plan: #385
ishandhanani
force-pushed
the
idhanani/srt2-07-cluster-gpu-defaults
branch
from
September 8, 2026 03:53
1c4b2b6 to
ec48340
Compare
Collaborator
Author
|
Consolidated into #407, which carries these same commits as one PR against main (this description is reproduced there as one of its parts). Closing to keep review in one place; the branch stays for per-step reference via stack #398. |
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
1 participant
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
Seventh PR of the 2.0 stack (plan: #385, Track 2 step 9). Stacked on #391; the diff against that branch is what to review.
gpu_typeandgpus_per_nodedescribe the cluster, not the deployment, yet 100% of recipes repeat them. This makes both inheritable so one recipe can move between clusters unchanged.resources.gpu_typeis now optional (str | None); a recipe that omits it inheritssrtslurm.yamldefault_gpu_type.resources.gpus_per_nodeinherits the clustergpus_per_nodewhen omitted (else the existing default of4).ClusterConfiggainsdefault_gpu_type.Applied in
resolve_config_with_defaults; an explicit recipe value always wins. The fields stay valid in recipes so a run is self-describing for result rollups. No consumer requiredgpu_typeto be non-None (it is metadata plus the TRT-LLM numactlin (...)check, which handlesNone). Additive: existing recipes are unaffected.Validation
ruffclean; full suite: 1763 passedtests/test_configs.py::TestClusterGpuDefaults: inherit when omitted, recipe value wins, loads with neither recipe nor cluster valueStack
...7 of the stack; see #386-#391 for the earlier PRs.