认识NVIDIA Run:ai

先说一个很容易让老板血压升高的场景。

公司咬牙买了一批 GPU。训练组说资源不够，推理组说排队太久，运维打开 nvidia-smi，却发现有些卡满得冒烟，有些卡安静得像没通电。更离谱的是：一个只吃 8GB 显存的小模型，也可能霸着一整张 80GB GPU，剩下 72GB 谁都用不了。

硬件花了真金白银，利用率却在演“空城计”。

这就是 NVIDIA Run:ai 想解决的问题。2026 年 10 月 13 日，NVIDIA 把此前商业化多年的完整 Run:ai 平台正式开源；当前最新稳定版是 3.0.20，于 10 月 11 日发布。

GPU 不够用，很多时候不是卡真的少，而是“谁能用、用多少、什么时候让出来”这三件事没人管明白。

什么是 NVIDIA Run:ai

NVIDIA Run:ai 是一个运行在 Kubernetes 上的开源 AI 工作负载与 GPU 编排平台。它不训练模型，也不替代 vLLM、PyTorch 或 Kubeflow；它站在更下面一层，负责把有限的 GPU 分给开发、训练和推理任务。

一句话定位：给共享 GPU 集群装一个懂 AI 工作负载的总调度台。

普通 Kubernetes 调度器看到的往往只是“这个 Pod 要一张 GPU”。Run:ai 还会继续追问：

• 这是交互式 Notebook、分布式训练，还是在线推理？
• 需要整张卡，还是 0.5 张、0.25 张就够？
• 八个训练 Pod 必须一起启动，还是可以先跑七个？
• A 团队没用完的配额，B 团队能不能先借走？
• 高优先级推理来了，低优先级训练是否应该暂停或让路？

这几个问题看着像管理琐事，落到几十、几百张 GPU 上，就是一笔巨大的钱。

核心架构：控制平面 + 集群服务

Run:ai 的架构可以先记成两层：

• Run:ai Control Plane（控制平面）：集中管理工作负载、项目、部门、配额、策略、身份与平台配置，同时汇总监控和分析数据
• Run:ai Cluster（集群服务）：部署在每个 Kubernetes 集群内，包含控制器、准入 Webhook 和调度相关服务，真正决定任务落到哪台机器、哪张 GPU

用户可以通过 Web UI、CLI 或 REST API 提交任务。控制平面把策略同步给目标集群，集群完成调度，再把工作负载与资源状态回传。一个控制平面可以连接多个集群，所以本地机房、云上和混合环境能放到同一套视角里管理。

完整平台之外，NVIDIA 还把四块核心能力拆成了可以独立采用的开源组件：

• KAI Scheduler：GPU 感知的 Kubernetes 调度器，也是 Run:ai 的调度内核
• GPU Fractioning Operator：把 CUDA 原生 GPU 切分能力接进 Kubernetes
• KAI Resource Management：管理项目、部门、配额、资源借用和异构节点池
• Workload Map：把 PyTorchJob、RayCluster 和自定义 CR 等不同资源统一看成“一个工作负载”

你可以整套部署，也可以只拿 KAI Scheduler 填补现有平台的调度短板。这个模块化思路我挺喜欢：不强迫你为了一个功能吞下整头大象。

NVIDIA Run:ai 的核心特点

• Gang Scheduling（成组调度）：分布式训练的多个 Pod 要么一起拿到资源，要么一个都不启动，避免“八缺一”时七张卡白白干等
• 公平共享与弹性配额：团队有保证配额，闲置资源可以被别的团队借走；原团队任务回来时，再通过优先级和抢占机制收回
• 拓扑感知与装箱调度：结合 GPU、节点和网络拓扑做放置，并尽量把小工作负载装进合适的卡，减少资源碎片
• 多种 GPU 共享方式：支持 MIG、MPS、time sharing、HaMi，以及 CUDA 13.4 MPS fractioning
• 按需 GPU 切分：任务可以申请分数 GPU，不需要管理员提前在每台节点上手工切卡；适合 Notebook、小模型推理和开发会话
• 硬显存隔离：GPU Fractioning Operator 依靠 CUDA 驱动限制每个工作负载可见和可用的显存，避免“邻居”突然多吃显存把你挤爆
• 项目与部门治理：配额不再只是一堆 Kubernetes ResourceQuota，而是能映射到真实组织结构，支持项目、部门、层级与节点池
• 异构工作负载统一管理：训练、推理、交互任务，以及 PyTorch、Ray、Kubeflow、Argo 等生态资源可以纳入统一提交和观测
• 多集群统一入口：控制平面集中管理一个或多个 Run:ai 集群，适合云上、本地和混合部署
• 可观测与权限控制：提供利用率、分配和工作负载视图，配合用户管理与 RBAC，让“谁拿走了 GPU”不再靠群里喊
• Apache 2.0：主仓库代码采用 Apache 2.0 协议；不过从 NGC 下载 Community Product 仍需接受对应的 NVIDIA 软件条款，且不含企业支持

Run:ai 提升的是“有效资源利用率”，不是凭空把一张 GPU 的算力变成两张。调度器能减少空转和碎片，但模型 Kernel 写得慢，它也救不了。

谁在用 NVIDIA Run:ai

Nebius：半张 GPU 保住 77% 吞吐

NVIDIA 与 AI 云厂商 Nebius 做过一组联合基准测试，环境不是两张消费卡凑出来的小 Demo，而是两套生产级集群：

• 本地集群：64 张 NVIDIA H100 NVL
• Nebius AI Cloud：32 张 NVIDIA HGX B200
• 测试模型：Llama 3.1 8B、Phi-4-Mini 3.8B、Qwen3-14B、Qwen Embeddings 0.6B

结果很有意思：

• 给模型分配 0.5 张 GPU，仍保留整卡 77% 的吞吐
• 并发用户容量保留到 86%：8,768 人对整卡配置的 10,200 人
• 在上述负载下，首 Token 延迟仍控制在 1 秒以内
• 0.5、0.25、0.125 GPU 的吞吐扩展接近线性
• 把聊天、推理和 Embedding 模型混部后，总用户数接近整卡独占方案的 3 倍，综合吞吐超过 35 万 token/s

最扎眼的是 Qwen3-14B：模型大约需要 28GB 显存，只占一张 80GB H100 NVL 的约 35%。如果仍按“一模型一整卡”分配，另外 52GB 就只能在旁边看热闹。

分数 GPU 的价值，不是把大模型硬塞进小显存，而是别让小模型拿着整张卡装阔。

Nebius 也不是只发一篇联合稿。完整 Run:ai 开源后，它已经把平台做成 Nebius AI Cloud Applications 的一键部署应用，底层跑在 Nebius Managed Kubernetes 上。这算是很现实的采用信号：云厂商愿意把它直接塞进产品目录，而不是只在 PPT 上写“即将支持”。

八家生态伙伴同步集成

NVIDIA 公布完整开源时，同时列出了 8 家正在集成 Run:ai 的 DSX 生态伙伴：

• Crusoe：接入 Crusoe Managed Kubernetes
• Mirantis：集成进 k0rdent AI，做从裸金属到模型的全生命周期管理
• Nebius：作为 AI Cloud Applications 一键部署
• OpenNebula Systems：通过 OneKS 接入开放和主权 AI 云
• Rafay：把 GPU 基础设施、集群、控制平面和租户自动化，提供托管服务
• Saturn Cloud：用于 Token Factory 的多租户推理、按 Token 计量与自动计费
• Spectro Cloud：集成进 PaletteAI Studio
• vCluster：用预验证模板为每个租户建立独立环境，同时共享同一 GPU 池

这些案例共同说明一件事：Run:ai 不是“又一个 Kubernetes 面板”，而是在往 AI 云的资源治理层发展。

初体验：先在本地 Kind 集群跑起来

先泼一盆冷水：完整 Run:ai 面向的是 Kubernetes / OpenShift 集群，不是一个 pip install 就能玩的 Python 包。想看真实 GPU 调度效果，你还需要 NVIDIA 驱动、GPU 节点和相应 Operator。

但如果只是想看看控制平面和集群服务怎么拼起来，官方仓库提供了本地开发脚本。准备好这些依赖：

• Docker 或 Podman
• make、git、curl、python3、openssl

kind、kubectl 和 helm 会由脚本自动安装。然后执行：

git clone https://github.com/dsx-ai-factory/run-ai.git
cd run-ai
./local-dev.sh

这条命令会完成三件事：从源码构建控制平面与集群服务、创建一个自包含的 Kind 集群、部署 Run:ai。

部署后先看 Pod 是否起来：

kubectl get pods -A
kubectl get nodes

改了配置、不想重新构建，可以只重新部署：

./local-dev.sh --skip-build --skip-cluster

玩完清理：

./local-dev.sh --teardown

本地 Kind 环境主要用来理解架构和参与开发，没有真实 GPU 时不要拿它测“利用率提升”。那就像拿停车场沙盘测试早高峰，路线能看懂，堵不堵得上真车才知道。

生产部署支持 Kubernetes 或 OpenShift，也支持联网与离线环境。官方给了两条路：

• 推荐：使用 runai-installer CLI + YAML 配置，先做预检，再安装依赖、控制平面和集群服务
• 手动：直接管理官方 Helm Chart，适合已经用 Argo CD 等 GitOps 工具的团队

发布镜像和 Chart 默认放在 nvcr.io/nvidia/runai。如果你只是想体验，不想自己搭整套环境，也可以使用 NGC Community Product 或 Nebius 的一键应用。

版本、开源与几个容易误会的地方

截至 2026 年 10 月 15 日，Run:ai 主仓库最新稳定版是 3.0.20。完整平台在 10 月 13 日开源，但它的调度内核 KAI Scheduler 更早已在 2025 年 4 月以 Apache 2.0 开源，并进入 CNCF Sandbox。

有三条边界值得提前说清：

• 开源版不等于企业支持版：NGC Community Product 不要求付费订阅，但也不包含 NVIDIA 企业支持；要 SLA 仍需购买相应商业产品
• 分数 GPU 不是万能药：Notebook、Embedding、小模型推理很适合切分；大模型训练或吃满显存带宽的任务，整卡甚至多卡才合理
• 利用率要先定义：显存占用、GPU kernel 活跃时间、SM 利用率和业务吞吐是四回事。别只拿一个 nvidia-smi 百分比就宣布优化成功

我的建议很朴素：先挑一类最容易碎片化的工作负载做试点，比如开发 Notebook 或多个小模型推理端点；记录吞吐、P95 首 Token 延迟、排队时间和实际 GPU 成本，再决定是否扩大。不要上来就把全公司训练任务迁过去，基础设施最怕“理论正确，周一全挂”。

进阶

Run:ai 真正值得关注的，不是“NVIDIA 又开源了一个项目”，而是 GPU 正在从一块块被人认领的硬件，变成可借、可还、可切分、可治理的集群资源。

这条路线很像当年 CPU 从物理服务器走向虚拟化：最开始大家觉得一台机器就该跑一个业务，后来发现真正值钱的是资源池和调度层。今天的 GPU 还在重复这段历史，只是单卡更贵，浪费起来更肉疼。

继续往下学，可以按这个顺序：

1. 先读 NVIDIA 完整开源公告，理解四个模块各管什么
2. 再看 Run:ai 主仓库 的控制平面与集群架构
3. 想单独替换 Kubernetes 调度器，研究 KAI Scheduler
4. 想做小模型混部，重点看 GPU Fractioning Operator 和 Nebius 联合基准
5. 真上生产前，用自己的模型、流量和 SLA 重跑一遍基准，别拿厂商数字替你签字

更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。