runners.yaml: add per-cluster directory mappings (centralize paths hardcoded in launch_*.sh) / runners.yaml:添加集群目录映射(集中管理 launch_*.sh 中硬编码的路径)
@cquil11 is already working on this.
Since Jul 1, 2026.
Assessment
This issue has not been assessed yet.
Description
Summary
.github/configs/runners.yaml currently only maps two things per cluster: labels: (scheduling-label → runner-name groups) and hardware: (available-cpu-dram-mib, gpus-per-node). Everything else that is genuinely per-cluster — most importantly filesystem directories — is hardcoded and duplicated across the 16 runners/launch_*.sh scripts. We should extend runners.yaml to be the single source of truth for these per-cluster mappings and have the launchers read from it.
Problem
Per-cluster paths are scattered across every launcher and diverge by site, so adding/moving a cluster or fixing a path means editing many bash files by hand. A grep across runners/ shows the kinds of directories currently baked in:
- HF hub cache:
/mnt/vast/gharunner/hf-hub-cache,/mnt/data/gharunners/hf-hub-cache/, ... - Squashfs / container image dirs:
/mnt/vast/gharunner/squash/,/data/squash/,/home/slurm-shared/gharunners/squash,/data/home/sa-shared/gharunners/squash/,/mnt/nfs/lustre/containers/,/data/containers/ - Model weight-staging:
/data/models/{dsv,dsr,MiniMax-M...},/mnt/nfs/lustre/models/... - AIPerf cache / dataset mmap cache:
/mnt/vast/gharunner/ai-perf-cache,AIPERF_DATASET_MMAP_CACHE_DIR - NFS home mounts:
/home/sa-shared/,/mnt/nfs/sa-shared/,/data/home/sa-shared/ - Scratch/lustre roots:
/mnt/lustre,/data/
These are exactly the values that differ per cluster and belong next to the existing hardware: metadata. A concrete example of why this matters: the gb300 NFS ELOOP workaround requires using /data/home/sa-shared/... instead of /home/sa-shared/... on that specific cluster — the sort of per-cluster path divergence that should be declared in one place, not remembered and hand-edited into a launcher.
Proposal
Add a new per-cluster section to runners.yaml, keyed by the same cluster:<name> keys already used under hardware:, e.g.:
paths:
cluster:h200-cw:
hf-cache-dir: /mnt/vast/gharunner/hf-hub-cache
squash-dir: /mnt/vast/gharunner/squash
aiperf-cache-dir: /mnt/vast/gharunner/ai-perf-cache
container-image-dir: /mnt/nfs/lustre/containers
model-weights-dir: /mnt/nfs/lustre/models
home-mount: /home/sa-shared
scratch-dir: /mnt/lustre
cluster:gb300-nv:
...
home-mount: /data/home/sa-shared # NFS ELOOP workaround, per-cluster
Then have the launchers resolve these from runners.yaml (via the same loader generate_sweep_configs.py already uses for labels/hardware, or a small shared helper) instead of hardcoding them, keeping the current values as defaults during migration.
Exact field names/shape are up for discussion — the goal is: per-cluster directories (and other cluster-specific config) declared once in runners.yaml, consumed by launchers.
Acceptance criteria
-
runners.yamlgains a per-cluster mapping (keyed bycluster:<name>) for the directories currently hardcoded inrunners/launch_*.sh(HF cache, squash/container dirs, model-weights/staging, aiperf + dataset mmap cache, home mount, scratch). - Launchers read these paths from
runners.yamlrather than embedding literals (shared loader/helper). - Per-cluster overrides (e.g. gb300
/data/home/sa-sharedNFS workaround) are expressed as data, not special-cased in bash. - Existing behavior preserved (same resolved paths per cluster) after migration.
Notes
Could also fold in other per-cluster knobs that are currently implicit (e.g. filesystem quirks, default partitions/accounts) as follow-ups. Scope this issue to directories first.
中文说明
建议在 runners.yaml 中添加每集群目录映射,将当前分散在各 launch_*.sh 脚本中硬编码的路径集中管理。
- Dominant language
- Python
- Stars
- 1.7k
- Forks
- 303
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 284
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from SemiAnalysisAI/InferenceX
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
SemiAnalysisAI/InferenceX#2125 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
SemiAnalysisAI/InferenceX#1587 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
SemiAnalysisAI/InferenceX#1369 · 3 comments ·
-
Difficulty 1/5 1-3 hours Newbie friendliness 76/100
SemiAnalysisAI/InferenceX#1359 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
SemiAnalysisAI/InferenceX#3122 · 3 comments ·
All issues in SemiAnalysisAI/InferenceX
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
bancolombia/sentinel#23 ·
-
test md OpenCI
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
integration:quickjs org:external priority:backlog topic:code-interpreter topic:middleware type:feature
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
langchain-ai/deepagents#6450 ·
-
bug client
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100