--- url: /runai/introduction.md description: >- NVIDIA Run:ai是什么？刚刚完整开源的Kubernetes原生GPU编排平台，用Gang Scheduling、公平配额和GPU切分提升AI集群利用率，半张GPU保住77%吞吐 --- # 认识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` 会由脚本自动安装。然后执行： ```bash git clone https://github.com/dsx-ai-factory/run-ai.git cd run-ai ./local-dev.sh ``` 这条命令会完成三件事：从源码构建控制平面与集群服务、创建一个自包含的 Kind 集群、部署 Run:ai。 部署后先看 Pod 是否起来： ```bash kubectl get pods -A kubectl get nodes ``` 改了配置、不想重新构建，可以只重新部署： ```bash ./local-dev.sh --skip-build --skip-cluster ``` 玩完清理： ```bash ./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 完整开源公告](https://developer.nvidia.com/blog/nvidia-runai-is-now-open-source-as-part-of-nvidia-dsx-ai-factory-platform)，理解四个模块各管什么 2. 再看 [Run:ai 主仓库](https://github.com/dsx-ai-factory/run-ai) 的控制平面与集群架构 3. 想单独替换 Kubernetes 调度器，研究 [KAI Scheduler](https://github.com/kai-scheduler/KAI-Scheduler) 4. 想做小模型混部，重点看 [GPU Fractioning Operator](https://github.com/kai-scheduler/gpu-fractioning) 和 [Nebius 联合基准](https://developer.nvidia.com/blog/unlock-massive-token-throughput-with-gpu-fractioning-in-nvidia-runai/) 5. 真上生产前，用自己的模型、流量和 SLA 重跑一遍基准，别拿厂商数字替你签字 更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。