Skip to content

refactor(srt): take cluster fabric values from runners.yaml via @fabric refs - #3820

Draft
adibarra wants to merge 10 commits into
refactor/composed-fingerprintfrom
refactor/srt-fabric-refs
Draft

adibarra wants to merge 10 commits into
refactor/composed-fingerprintfrom
refactor/srt-fabric-refs

Conversation

@adibarra

@adibarra adibarra commented Oct 8, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

Recipes no longer hardcode cluster NIC and fabric facts.

  • Fabric record: new typed slurm.srt-slurm.fabric record per cluster in runners.yaml, with lists instead of comma strings. Fields: ucx-net-devices, rdma-devices (the RDMA NIC list that NCCL, Mooncake and MORI all read), socket-ifname, mooncake-gid-index, mori-rdma-tc, mori-io-tc.
  • References: a fragment opts in per value with a whole-value reference such as UCX_NET_DEVICES: '@fabric.ucx-net-devices', valid in env, args, or services[i]...device_name.
    • The binder resolves references for the job's cluster after variant selection.
    • An unknown name, a reference embedded in a longer string, or a cluster without that field fails before submission.
    • Nothing resolves at plan time, so fingerprints stay cluster-independent.
  • Recipes: in 72 active recipes, 181 literals were replaced, but only where the literal exactly equals the cluster's fact.
  • infx generate: resolves references when the point's runner label maps to exactly one cluster.
  • Docs: CONFIGS.md and RECIPES.md updated.

Left as recipe literals on purpose

  • The MI355X UMBP recipe's permuted rail order and its host_setup command.
  • b200-nscale Mooncake device_name (4 of the 8 HCAs). Nothing shows it is the cluster fact.
  • Empty Mooncake device_name: '' on b300 and h100 single-node recipes.
  • h200-dgxc network-interface stays "" (autodetect) while its recipes pin eth0. Merging them would change srtslurm.yaml.

Verification

  • Harness (not committed): ran 3622 launches (every srt row × every reachable cluster) through the real python -m infx.launch. Of the 3620 compared, all have 0 differences in the srtctl-resolved recipe, argv, env, srtslurm.yaml and the AgentX client plan. 448 of those launches use references, across 6 clusters. The 2 launches not compared are the pre-existing no-selector gb200 row from refactor(srt): compose fixed-sequence recipes from fragments and bind the matrix point #3809, which fails the same way on the base.
  • Tests: resolution in env, args and list items; error cases; driver wiring; infx generate with a label on one cluster and on two.
  • Suite: the full CI pytest command passes 2275 tests, and ruff is clean.

Open questions

  • mi355x cluster env.MORI_RDMA_TC and host-setup.env.IBDEVICES duplicate the new fabric values. Should cluster env accept references?
  • Reference names are only checked at launch or infx generate, not at plan time.
  • Plan-time check: each @fabric.<name> in a selected variant must name a Fabric field that every reachable cluster sets.
  • Cluster env and srt-slurm.host-setup.env accept @fabric.<name>; mi355x-amds uses it for MORI_RDMA_TC/IBDEVICES.

@github-actions

github-actions Bot commented Oct 8, 2026

Copy link
Copy Markdown
Contributor

Thanks for the contribution!

  • Review: If this PR changes files owned by someone other than a repository admin or @SemiAnalysisAI/core, ask one eligible CODEOWNER to complete the latest PR_REVIEW_CHECKLIST.md before contacting a core maintainer on Slack. Follow the template exactly, including As a PR reviewer and CODEOWNER, I have reviewed this and have, so sign-off verification triggers.
  • PR verification: Sweeps run only when the PR appends an inferencex-e2e/perf-changelog.yaml entry and carries exactly one primary label: full-sweep-fail-fast (strongly recommended; canary plus per-matrix fail-fast), full-sweep-enabled (canary; matrix jobs continue after a failure), or non-canary-full-sweep-enabled (no canary or fail-fast). The modifiers all-evals, evals-only, and agentx-fast require a primary label. On fork PRs, a maintainer applies the label. See sweep labels and reuse.
  • After merging: PR authors must ensure all GitHub Actions jobs pass. Transient failures often pass on rerun; see how to rerun failed jobs.
中文

感谢你的贡献!

  • **审阅:**如果 PR 修改的文件归属于仓库管理员及 @SemiAnalysisAI/core 之外的 CODEOWNER,请先联系一位有资格的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md,再通过 Slack 联系核心维护者。必须严格遵循模板,并保留 As a PR reviewer and CODEOWNER, I have reviewed this and have,才能触发签核验证。
  • **PR 验证:**只有当 PR 在 inferencex-e2e/perf-changelog.yaml 末尾追加了条目,并且恰好带有一个主标签时,才会运行扫描:full-sweep-fail-fast(强烈推荐;canary 加逐矩阵 fail-fast)、full-sweep-enabled(有 canary;矩阵任务在失败后继续运行)或 non-canary-full-sweep-enabled(无 canary,也无 fail-fast)。修饰标签 all-evals、evals-only 和 agentx-fast 必须与主标签一起使用。fork PR 的标签由维护者添加。参见扫描标签与复用。
  • **合并后:**PR 作者必须确保所有 GitHub Actions 任务通过。临时性失败通常可以通过重新运行恢复;参见重新运行失败任务的说明。

local_buffer_size: "4GB"
protocol: "rdma"
device_name: "mlx5_0,mlx5_1,mlx5_2,mlx5_3"
device_name: "@fabric.mooncake-devices"

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

should there be an dedicated mooncake-devices, isnt this just same values as nccl-hca

i.e. it shouldnt even be @fabric.nccl-hca

maybe just @fabric.nic_devices or soemthing generic

@adibarra
adibarra force-pushed the refactor/srt-fabric-refs branch from 99bdc28 to b8b092f Compare October 8, 2026 23:04
@adibarra
adibarra force-pushed the refactor/srt-fabric-refs branch from b8b092f to 9643753 Compare October 9, 2026 11:39
@adibarra
adibarra force-pushed the refactor/srt-fabric-refs branch from 9643753 to 1ac14ae Compare October 9, 2026 17:47
@adibarra
adibarra force-pushed the refactor/srt-fabric-refs branch from 1ac14ae to 95311bd Compare October 9, 2026 18:20
@adibarra
adibarra force-pushed the refactor/srt-fabric-refs branch from 95311bd to 9215a18 Compare October 9, 2026 18:48
Comment on lines +613 to +615
ucx-net-devices: [mlx5_0:1, mlx5_1:1, mlx5_2:1, mlx5_3:1, mlx5_4:1, mlx5_5:1, mlx5_10:1,
mlx5_11:1]
rdma-devices: [mlx5_0, mlx5_1, mlx5_2, mlx5_3, mlx5_4, mlx5_5, mlx5_10, mlx5_11]

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

isnt ucx device an rdma device too

i guess ucx device speciifs the port # too on the device

@adibarra
adibarra force-pushed the refactor/srt-fabric-refs branch from 9215a18 to aff8b96 Compare October 9, 2026 23:43
@adibarra
adibarra force-pushed the refactor/srt-fabric-refs branch from aff8b96 to 528d948 Compare October 10, 2026 07:51
@adibarra
adibarra force-pushed the refactor/srt-fabric-refs branch 2 times, most recently from 6077e30 to 5cb2a51 Compare October 12, 2026 08:02
@adibarra
adibarra force-pushed the refactor/srt-fabric-refs branch 2 times, most recently from a50e3a6 to 80dca82 Compare October 12, 2026 16:01
Recipes stop hardcoding the cluster's network hardware. Each srt-slurm
cluster profile gains a typed fabric record: ucx-net-devices, nccl-ib-hca,
ib-devices, socket-ifname and mooncake-devices are lists, and
mooncake-gid-index, mori-rdma-tc and mori-io-tc are numbers. A recipe value
'@fabric.<name>' takes the job cluster's field after binding, lists
comma-joined and numbers as decimal strings. The launcher hands both
binders the cluster's rendered fabric; an unknown name, a reference inside
a longer string, or a field the cluster does not set fails before
submission. Nothing resolves references at plan time.

Literals equal to their cluster's fact become references in 72 active
recipes on gb200-nv, gb300-nv, b200-nscale, b300-dsxe, h200-dgxc and
mi355x-amds. Deliberate per-recipe values stay literal: the MI355X UMBP
recipe's permuted rail order, B200 Mooncake's four of eight HCAs, and empty
Mooncake device lists that leave discovery to Mooncake.

infx generate resolves references for a point whose runner label names one
cluster and records that cluster in the manifest; otherwise references
stay and the manifest's cluster is null.
Matrix generation now fails a row whose selected recipe variant (srt-recipe
or eval-srt-recipe) has an '@fabric.<name>' value naming no Fabric field, or
a field that a cluster the row's runner label reaches does not set. The
launcher still resolves references at bind time and fingerprints hash them
as written.

Cluster env and srt-slurm.host-setup.env values may reference the cluster's
own fabric the same way and resolve when the record loads; env keeps
rejecting commas after resolution. mi355x-amds takes MORI_RDMA_TC and
IBDEVICES from its fabric instead of repeating them.
The binder runs in srtctl's Python 3.10 venv, where importing infx.clusters fails on typing.Self.
nccl-ib-hca, mooncake-devices and ib-devices held the same RDMA HCA list on
every cluster that set them. One Fabric field, rdma-devices, now carries that
list for NCCL_IB_HCA, the Mooncake device_name, SGLang
disaggregation-ib-device and IBDEVICES, and each cluster lists its HCAs once.

Bound recipes are unchanged. Rows whose recipes reference the field get new
fingerprints, since references are hashed as written.
prefill role. Like the other recipes' NIC lists, both read '@fabric.rdma-devices',
which renders the same mlx5_0..mlx5_3 list on gb300-nv.
The workload tests already prove the multi-node binder resolves --fabric, the single-node driver case proves the launcher passes the job cluster's rendering, and the matrix tests already cover an unknown fabric name.
infx generate now raises the binder inputs' missing srt-slurm settings error instead of binding an empty fabric, and the matrix check reads the record a cluster label names instead of treating a missing one as an empty fabric.
#3701 lists the GB200 DSv4-Pro AgentX disagg Mooncake NICs literally, in
the decode stores and the prefill role. Like the GB300 recipes, both read
'@fabric.rdma-devices', which renders the same mlx5_0..mlx5_3 list on
gb200-nv.
@adibarra
adibarra force-pushed the refactor/srt-fabric-refs branch from 80dca82 to 1bc0646 Compare October 12, 2026 16:34

This branch has not been deployed

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

Labels

None yet

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

2 participants