NVIDIA 开源 srt-slurm：面向 Slurm GPU 集群推理的 YAML 编排层

8 月 27 日 20:00（UTC，北京时间 8 月 28 日凌晨 4 点），SemiAnalysis 官方账号（X 平台，约 15.8 万关注者，企业认证）发文介绍 NVIDIA 开源的 srt-slurm：一个面向 Slurm GPU 集群推理部署的 YAML 编排层，仓库位于 github.com/NVIDIA/srt-slurm，当前为公开状态。

仓库里实际交付的是一个名为 srtctl（SLURM Runtime Control）的命令行工具。README 的定位是：面向 SLURM 集群与直连 GPU 主机的分布式 LLM 推理基准 CLI，用声明式 YAML 取代复杂的 shell 脚本和 50 多个 CLI 参数，底层支持 TensorRT LLM、SGLang 与 vLLM 三种引擎。 GitHub API 元数据显示，仓库创建于 2026 年 1 月 6 日；截至 8 月 28 日核验时，最新 tag 为 v1.0.80，公开仓库有 52 个 star、86 个 fork、99 个未关闭 issue，LICENSE 文件为 Apache License 2.0（Copyright 2025 NVIDIA CORPORATION & AFFILIATES）。

为什么 Slurm 上跑一个推理服务容易、跑一套拓扑很难

SemiAnalysis 把问题概括成一句话：多数生产推理服务跑在 Kubernetes 上，靠声明式配置协调分布式服务；而"在一个 Slurm 作业里跑一个推理服务器很容易，在多个容器和节点上跑生产级拓扑则不是"（"Running one inference server in a Slurm job is easy; running a production-style topology across multiple containers and nodes is not."）。

srt-slurm 补的正是这一层。按 SemiAnalysis 的表述，它协调 sbatch 与 srun 提交、GPU 放置、网络、就绪检查与清理，面向的系统形态包括 prefill/decode 分离、多 worker、Dynamo 前端、KV-cache 感知路由与 KV-cache offload 服务；分析机构给出的适用场景是"在已经跑着 Slurm 的 GPU 集群上快速部署代表性推理系统，用于测试与基准"（该描述为 SemiAnalysis 的评估口径）。

一个 YAML 文件，替代 shell 脚本和 50 多个 CLI 参数

srtctl 的使用方式很直白：srtctl apply -f config.yaml 提交作业，srtctl dry-run 只校验不提交，--serve-only 只部署推理端点不跑基准，--tags 给实验打标签；README 还提供 --bash 模式，把单节点 recipe 渲染成 Docker 脚本，在直连 GPU 主机上运行。安装后的 make setup 会下载 NATS 与 etcd，并生成集群配置文件 srtslurm.yaml。

仓库的 examples/example.yaml 展示了最小配置：一个 YAML 文件分 name、model、resources、backend、benchmark 五段。resources 里用 prefill_nodes/decode_nodes 与 prefill_workers/decode_workers 声明分离式拓扑（注释示例为 1 个 prefill 节点配 4 个 decode 节点），backend 段给 SGLang 的 prefill 与 decode 分别传 disaggregation-mode 参数，benchmark 段写基准类型 sa-bench、输入输出长度与并发度列表。

提交之后，编排发生在 Slurm 作业内部。架构文档描述：srtctl 生成 sbatch 脚本并提交，作业内的 SweepOrchestrator 按阶段启动头部基础设施（NATS 消息总线与 etcd）、backend worker（SGLang 后端每个 worker 一个 srun 进程）、前端与基准，最后统一清理；ProcessRegistry 管理所有进程的生命周期与故障处理。

就绪检查通过 HTTP 健康端点完成，Dynamo 前端查 /health、SGLang 路由器查 /workers，逐个核对期望的 prefill/decode worker 是否就绪。端口按段分配避免冲突（HTTP 30000+、bootstrap 31000+、KV events 5550+、NATS 4222、etcd 2379），worker 跑在 Enroot 容器（.sqsh 镜像）里。

集群兼容性也做成了配置项：slurm-faq 说明，--segment 指令让 prefill 与 decode 节点落在同一网络段以保证互连性能，--gpus-per-node、--exclusive 可按集群能力开关；srtslurm.yaml.example 里还预留了健康检查窗口（默认最多尝试 180 次、每次间隔 10 秒，约 30 分钟），给大模型冷加载留时间。

KV 感知路由与 KV offload 也进了 YAML

prefill/decode 分离只是第一步，跨节点搬运 KV cache 同样进了编排范围。config-reference 记录了 KV events 特性：这是 Dynamo 前端的 kv-aware routing 能力，worker 通过 ZMQ 发布缓存与调度信息，供 Dynamo router 做路由决策；基准类型里还有专门的 mooncake-router（基于 Mooncake trace 的 KV 感知路由）。

KV 传输后端则给了 Mooncake 一等支持：mooncake-kv-store 文档说明，在 backend 段加一个 mooncake_kv_store 块，srt-slurm 就会自动拉起 mooncake master、向所有 prefill/decode worker 注入环境变量，让跨节点的 KV 传输走 RDMA 或 TCP；SGLang 与 vLLM 两种后端都支持。仓库还按硬件与引擎预置了 recipes 模板（b200/gb200/gb300/h100/h200、qwen3.5、trtllm/vllm/sglang 等）。

开源前，vLLM 已经用它复现 25K TPS/GPU

最硬的"已在用"证据来自 vLLM 团队。8 月 6 日的官方博客报告，Qwen3.5 在 GB200 NVL72 集群上达到每 GPU 2.5 万 tokens/s 的总吞吐（Qwen3.5-397B-A17B-NVFP4，ISL/OSL=8192/1024，decode 侧单端点 DEP8、prefill 侧 4 到 8 个 DEP2 端点）。复现清单明确写着：vLLM nightly Docker 镜像、Dynamo 1.2.0.dev20260526、srt-slurm v1.0.32；文章全部 recipe 存放在 srt-slurm-recipes 仓库，"每条配置用一条命令启动：srtctl run --file <recipe>.yaml"。

博客还演示了准确率验证流程：在 recipe 里加一个 benchmark: type: "gsm8k" 块就能跑 GSM8K，五个配置的准确率均为 88%。 vLLM 官方 X 账号 8 月 7 日转发该文："Everything is reproducible: recipes for every configuration live in srt-slurm-recipes, one command each"（每个配置的 recipe 都在 srt-slurm-recipes 里，一条命令一个）。

在 SemiAnalysis 报道（8 月 27 日）之前近三周，这个工具已经以 v1.0.32 的版本号支撑第三方团队的基准复现，而仓库当前最新 tag 已迭代到 v1.0.80。

从 "Real ones know" 到 "离 Kubernetes 还有多远"

SemiAnalysis 在推文末尾把功劳指向 NVIDIA 的 @0xishand 与 @NVIDIAAI 团队。 @0xishand（账号名为 ishan，简介自称在 NVIDIA 做 Dynamo 与 SGLang 的 inference 工作）随后引用该推文写道："Real ones know about the version under ishandhanani/srt-slurm"，按他的说法，srt-slurm 早有一个挂在他个人名下的版本。

更系统的解读来自 Straggler Liu 的 X 账号（简介自称追踪 AI 资本开支与算力约束）。他的第一篇长文认为，工具的实质是把"过去几个月的 Slurm 折腾变成一个配置文件"，并点出商业逻辑："NVIDIA 不卖这个软件，他们卖 GPU。让 GPU 更好用，就是最终的销售动作"；同时提醒边界：srt-slurm 是规定性的，假设 NVIDIA 自家栈与自家拓扑，只面向 Slurm，而云世界跑在 Kubernetes 上。第二篇给出更激进的判断：开源的真实目的是把推理部署层从 Kubernetes 拉到 NVIDIA 可控的软件栈上，"市场把它当作基准工具，市场错了"。

推文回复区提出了相反方向的疑问。AI 工程师 Nick Thorp 问：这些 Slurm 拓扑与人们实际跑生产的 Kubernetes 栈（尤其 KV 路由与 offload）有多接近？自称有二十年经验的云架构师 Yuliyan Tsvetkov 则写："单节点 Slurm 是一个作业。生产是拓扑：gang scheduling、GPU 隔离，以及 drain 之后副本再也不会回来的情况。" 这些属于发帖人观点，不是对工具能力的验证。

仓库里还留着"刚公开"的痕迹

仓库状态本身透露出这是一次把内部工具推向公开的发布：架构文档版本 1.1 更新于 2026 年 1 月 27 日，与仓库创建时间（1 月 6 日）吻合，说明工具公开前已在 NVIDIA 内部开发了大半年；README 快速开始里的 clone 地址至今还写着占位符 your-org/srtctl；GitHub 上还有 99 个未关闭 issue。仓库最后一次推送发生在 8 月 27 日 21:57（UTC）。

对 Slurm 集群用户来说，验证成本很低：clone 下来，一条 srtctl dry-run -f config.yaml 就能校验配置而不真正提交作业。