英伟达开源 Run:ai 深度：KAI Scheduler 与 3 至 6 倍加载加速

10 月 18 日，英伟达把完整的 Run:ai 平台以 Apache 2.0 协议开源，源码托管在 GitHub 的 dsx-ai-factory/run-ai 仓库，Run:ai 由此成为 NVIDIA DSX AI Factory 平台的一部分。一句话结论：过去需要付费订阅才能用到的 GPU 调度与配额治理层，现在可以自己装、自己看源码、自己改，团队共享集群时最贵的那块软件成本直接归零。

这次开源的意义不在于多一个仓库，而在于 GPU 调度层的定价权被改写了。当模型的推理成本已经压到每百万 Token 一元级别时，集群管理员手上一块 H100 到底分给谁、给多少、能不能抢占，这些调度决策带来的效率差异，会直接体现在账单上。Run:ai 把这层能力交到用户手里，代价是自己要承担运维。

Run:ai 到底是什么：Kubernetes 之上的 AI 工作负载层

Run:ai 在架构上属于编排系统之上的扩展层。官方文档写得相当直白：它不替换 Kubernetes、容器运行时或 CI/CD 系统，它跑在这些东西之上，只补上 Kubernetes 原生调度缺失的 GPU 感知能力。整个平台分两层，control plane 负责集中管理资源、工作负载、策略与组织结构，cluster 组件部署到每一个真正跑负载的 Kubernetes 集群上，把配置和调度请求同步下去并执行。

控制面内部是一组可独立部署的微服务，通过发布订阅事件总线通信。身份与访问这条链上，gateway-hub 是所有请求的入口，负责校验 bearer token 并根据请求子域名解析租户；identity-manager 对接外部身份提供商、本地用户与服务账号，完成认证并签发令牌；authorization 拿这个身份去比对 RBAC 角色与访问规则，算出最终有效权限。组织结构这条线上，tenants-manager 管租户生命周期，多租户部署时每个租户拿到独立的 UI、API 与 CLI；org-unit-service 保存部门与项目层级以及每级配额，并同步到所有受管集群，保证调度与配额执行面对同一份权威记录。

对外接口有四套：Web UI、CLI、REST API，以及 MCP Server。第四套是这次开源里比较新的东西，它把控制面操作暴露成 AI 智能体可调用的工具，配合 Agent Skills 使用，意味着 Claude Code、Cursor 这类编码助手可以直接接管一部分 GPU 配额与工作负载管理动作。Go、Node 和 Java 都不需要装在宿主机上，全部构建跑在容器内。

拆成可独立采用的模块：调度、分数、配额与工作负载地图

一次性的整体交付很难让用户接受，英伟达这次把它拆成了四块，每块都能单独拿走。

KAI Scheduler 是其中的调度内核，一个 Kubernetes 原生调度引擎，本身也是 Apache 2.0，并且已经进入 CNCF Sandbox。它提供成组调度、按时间公平共享、拓扑感知、装箱与 DRA 支持。这个仓库在 GitHub 上有 1598 个 star，与 Volcano、Kueue 同处一个赛道但更贴 AI 负载的形状。

GPU Fractioning Operator 把 CUDA 13.4 原生的 GPU 分数能力带进 Kubernetes，由驱动层为每个负载强制施加硬性显存上限。这一点很关键，分数调度在软件层模拟很容易出现越界，驱动层强制才能保证一个声明 0.3 卡的任务不会吃掉整卡显存。

KAI Resource Management 提供项目、部门、配额与节点池管理，官方示例给出的保证是研究团队可获得集群 50% 的资源。Workload Map 是一个 Go 库，负责描述 PyTorchJob、RayCluster、KServe 这类负载类型，它本身不做调度，只做负载类型到平台模型之间的翻译。

配套的 model-streamer 仓库可以单独使用，它把模型权重直接送进显存。vLLM 与 SGLang 都能通过 load-format runai_streamer 接入。

3 到 6 倍的模型加载速度是怎么来的

官方给出的数字来自微软在 8 台 H100 虚拟机上的公开基准：使用 Run:ai Model Streamer 后，模型加载速度比默认加载器快 3 到 6 倍，吞吐维持在 80 Gbps，而默认路径大约是 40 Gbps。

这个指标为什么值得关注，原因是模型加载在推理服务里是一个纯粹被浪费掉的环节。70B 模型加载一次要几十秒到几分钟，如果每次服务重启、每次扩缩容都要重来一遍，一组副本滚动更新时的空窗期就被这个数字直接决定。吞吐翻倍意味着同样的 NVLink 或 InfiniBand 链路能在单位时间内灌进更多权重，链路不再是瓶颈。

配套的 local-dev.sh 脚本让开发者在本地跑完整栈：容器里编译约 50 个 Go 服务，拉起一个固定在 Kubernetes v1.32.5 的 5 节点 Kind 集群，用模拟的 8 个 Tesla-A10 GPU 顶替真实硬件。Linux 主机要求 4 核 CPU、16 GB 内存与 100 GB 空闲磁盘，macOS 上的 Podman 虚拟机至少要 12 GB 内存，一次完整构建会留下约 44 GB 缓存。对想读代码改代码的人来说，这套环境意味着不必先采购 GPU 才能开始。

与 Volcano、Kueue、vLLM、Slurm 的位置关系

这是最容易搞混的部分。官方用一张表把层次划清楚了，下表按官方口径整理。

官方给了一条判断标准可以直接拿去用：如果需要跨团队共享同一套 Kubernetes GPU 资产，并且要做 GPU 共享、配额强制与多租户治理，这就是 Run:ai 填的缺口；如果只是单个团队在专用 GPU 上跑自己的任务，原生 Kubernetes 调度通常已经够用。

与推理框架的分工同样清楚。vLLM 和 SGLang 解决的是单个服务实例内怎么把 GPU 用满，属于服务内部；Run:ai 解决的是多个团队、多个服务、多个集群之间怎么分，属于服务之间。类似 DeepSeek 开源推理框架 DeepInfer 那样在框架内部做优化的项目，与 Run:ai 处于不同层，不构成竞争。

社区版拿到了什么，失去了什么

官方文档与仓库说明里有一句很值得单独拎出来：社区版不含英伟达企业级支持。目前提供商业发行版的 DSX 生态伙伴包括 Crusoe、Mirantis、Nebius 等 8 家。

换句话说，Apache 2.0 拿到的是代码，拿到的是可自托管、可 fork、可审计的能力，拿不到的是英伟达原厂工程师的 SLA。这条线在同类产品里是通例，llm-d 1.0 走的是同一条开源路线，那套方案把 17000 节点规模下的吞吐提升 2.9 倍、首 token 延迟压掉 85%，同样是把工程实践从付费产品里剥出来交给社区。对自建团队来说，这意味着从「买许可」变成「养能力」，成本结构完全不同。

镜像与 Helm Chart 发布在 nvcr.io/nvidia/runai，源码发布说明在 GitHub Releases。安装方式有两条：推荐路径是用 runai-installer CLI 加一份配置 YAML，installer 会先做前置检查、装依赖再部署控制面与集群组件；另一条是直接用 Helm Chart 自己部署，适合用 Argo CD 管理部署的场景。当前文档默认版本为 v3.0，历史版本还可回溯到 v2.24、v2.25、v2.26。仓库最近一次发布是 3.0.20，节奏稳定在每几天一个小版本。

谁会从中受益，谁会犹豫

受益最明显的是三类团队。第一类是高校与研究机构，多个课题组共享一批 GPU，配额和公平共享机制正是日常痛点，官方示例直接给研究团队留了 50% 的集群资源。第二类是需要在多集群之间调度 AI 负载的企业，一个控制面管多个集群、每个租户独立 UI 与 API，这个能力过去很贵。第三类是想在本地读代码改调度逻辑的工程师，44 GB 缓存换一套完整的本地集群环境，门槛已经降到一台笔记本。

犹豫的理由同样清楚。企业版和社区版之间隔着 SLA 这道墙，8 家生态伙伴提供的商业发行版是另一种打包方式，需要逐一评估。开源之后原本由原厂负责的版本升级、故障排查与兼容性维护要自己接手。另外 Run:ai 只解决 Kubernetes 之上的那一层，如果团队基础设施本身还在裸金属 Slurm 或虚拟机上，迁移成本会先一步吃掉开源带来的收益。

把它放到更大的背景里看，Run:ai 开源与 英伟达 DSX AI Factory 把 AI 工厂部署周期从 6 个月压缩到 14 天是同一件事的两面：硬件交付周期压缩之后，瓶颈会转移到调度与运维效率上。把调度层开源，等于英伟达承认这一层的瓶颈是可以由客户自己解决的，而软件授权费不再是那一段的门槛。

与之相邻的技术路线还有几条正在同时推进。谷歌开源 TorchTPU 解决的是 PyTorch 迁 TPU 的迁移成本，NVIDIA 下代 Groq LPU 放弃 SRAM 解决的是大模型推理的存储墙，商汤大装置用 PD 分离把异构集群吞吐拉高 5 倍 解决的是集群内部效率，而 Recursive Flint 这类 40B 只激活 2.5B 的稀疏 MoE 解决的是单卡能装下多大的模型。Run:ai 站在它们上面一层，负责决定这些模型与硬件由谁在什么时机使用。

常见问题

Run:ai 开源后还需要付费订阅吗

不需要，社区版完全免费并以 Apache 2.0 协议发布，代码可自托管可修改。需要留意的是社区版不含英伟达企业级支持，需要企业级 SLA 的话得走 8 家 DSX 生态伙伴提供的商业发行版。

Run:ai 和 Kubernetes 原生调度有什么区别

Run:ai 不替换 Kubernetes，它跑在 Kubernetes 之上，只补 GPU 感知调度这一层。原生调度按 CPU 与内存等标准资源排队，看不见显存拓扑，也没法做 GPU 分数与部门配额。集群只服务单一团队时原生调度通常够用，跨团队共享时差距才显现。

本地零成本体验需要什么配置

运行 local-dev.sh 需要 4 核 CPU、16 GB 内存与 100 GB 空闲磁盘，macOS 上的 Podman 虚拟机至少要 12 GB 内存，一次完整构建约留 44 GB 缓存。脚本会在容器里编译约 50 个 Go 服务，拉起固定在 Kubernetes v1.32.5 的 5 节点 Kind 集群，用模拟的 8 个 Tesla-A10 替代真实硬件，全程不需要采购 GPU。

小结

Run:ai 开源把 GPU 调度与配额治理从付费产品变成了可自托管的开源栈。KAI Scheduler、GPU Fractioning Operator、KAI Resource Management、Workload Map 四个模块可独立采用，model-streamer 带来的 3 到 6 倍加载速度与 80 Gbps 吞吐是官方在 8 台 H100 上的实测数字。四套接口里最有意思的是 MCP Server，它让 AI 智能体能够直接操作 GPU 配额与工作负载，这类能力在闭源产品里几乎不可能出现。

需要提醒的是，获得代码与获得支持是两件事。Apache 2.0 解决的是所有权与可审计性，运维与 SLA 仍然要由使用方自己扛。开箱即用的门槛压到了 4 核 16 GB 的本地 Kind 集群上，值得动手试的人现在就可以开始。