--- title: "NVIDIA Run:ai 开源：GPU 编排不等于软件工厂" canonical: https://wavect.io/zh/blog/nvidia-runai-open-source-gpu-software-factory/ language: zh description: "解读 NVIDIA Run:ai 完整开源范围与 NGC 社区版条件，比较 MIG、时间切片和 GPU 显存份额，并明确 ESF 软件工厂仍需独立验证、证据与发布审批。" image: "https://wavect.io/img/blog/headers/header_nvidia-runai-open-source-gpu-software-factory.png" author: ["Kevin Riedl"] published: "2026-10-15" updated: "2026-10-15" reviewed: "2026-10-15" --- # NVIDIA Run:ai 开源：GPU 编排不等于软件工厂 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 分钟 阅读 · 2026年10月15日 最近审核 2026年10月15日 [**下一篇**](/zh/blog/netflix-vllm-triton-inference-stack/) 要点速览 NVIDIA 于2026年10月13日宣布开源完整 Run:ai 平台。其自身代码采用 Apache-2.0；NGC Community Product 另有发行条款，且不包含企业支持。Run:ai 管理 GPU 容量、工作负载与访问权限。MIG、时间切片和 CUDA 原生显存份额提供不同隔离边界。ESF 这类软件工厂负责另一条流程：从任务到已验证补丁。将两者用于生产前，必须分别检验容量分配与独立验证。 *核查日期：2026年10月15日。依据为 NVIDIA 文档与公开代码仓库。本文是来源分析，并非 Run:ai 部署、ESF 集成测试或 GPU 性能实测。* GPU 忙得不可开交，软件却仍然无法上线。 这正是 NVIDIA 宣布开源 Run:ai 后值得讨论的问题。分配算力和验收软件变更，是两项不同的工作。开源 GPU 编排可以改善前者，却不能省掉后者。 真正有用的问题不是 Run:ai 能否取代所有 AI 平台，而是：**哪些基础能力不必再从头开发，哪些决定仍然必须由你掌握？** ## NVIDIA 这次究竟开源了什么？ **2026年10月13日，NVIDIA 宣布开源完整的 Run:ai 平台，而不只是 KAI 调度引擎。**公告将 Run:ai 纳入 NVIDIA DSX AI Factory Platform，同时提供完整平台和可单独采用的组件。 [查看 NVIDIA 的发布公告。](https://developer.nvidia.com/blog/nvidia-runai-is-now-open-source-as-part-of-nvidia-dsx-ai-factory-platform/) Run:ai 仓库包含控制平面、集群服务、安装器、CLI、MCP 服务器以及开发环境。仓库将自身代码的许可证标为 Apache-2.0，同时单独说明第三方内容和品牌资产的许可。因此，更准确的表述是“平台自身代码采用 Apache-2.0，附带内容需分别查看许可证”，而不是“一切都采用 Apache-2.0”。 [核对仓库范围与许可说明。](https://github.com/dsx-ai-factory/run-ai/blob/45a0a23a8460dbe4d9789d88b3924d41237a537f/README.md) 这改变了自建与采购之间的选择。原本需要采购商业平台才能获得的基础能力，如今可以检查、修改和复用。但依赖组件、模型权重、技术支持和 GPU 并不会因此全部免费。 ## 开源 Run:ai 可以免费使用吗？ **公告明确表示，NGC Community Product 不要求付费的 Run:ai 订阅，也不要求 NVIDIA 支持权益，但不包含 NVIDIA 企业支持。**下载该发行包仍需接受适用的 NVIDIA 软件协议和 AI 产品条款。源代码许可证、发行包条款以及支持合同，应当分开核对。 实际获取还有一个需要注意的细节。在本次核查时，公告链接到的 NGC 集合页面仍显示订阅提示，页面更新日期为2026年9月23日。较旧的目录页面不能推翻较新的公告，但我们没有登录，也没有完成 Community Product 下载。部署前应确认具体 Helm chart、镜像版本和获取路径。 [查看 NGC 集合及其当前显示的条款。](https://catalog.ngc.nvidia.com/orgs/nvidia/runai/collections/run-ai-self-hosted/-) 许可证费用归零，不代表硬件或云租赁、电力、存储、网络、升级、故障处理和工程时间归零。只有当利用率提升帮助你减少实际账单，或避免购买额外容量时，它才转化为现金节省。用好已付费的 GPU 是收回闲置容量，不一定意味着账单随之下降。 ## Run:ai 与 KAI Scheduler：你需要哪一层？ **选择能够解决已测量问题的最小组件。**已有 Kubernetes 平台可能只缺调度器或 GPU 共享机制，而不是另一套完整管理系统。 | 组件 | 主要职责 | 不能取代什么 | | --- | --- | --- | | Run:ai 平台 | 跨已连接集群协调工作负载、组织策略、权限和可观测性。 | 软件验收标准与发布审批。 | | KAI Scheduler | 根据队列、配额、公平共享、优先级和成组调度来放置工作负载。 | 模型推理服务引擎或智能体的推理循环。 | | GPU Fractioning Operator | 在节点上执行受支持的 GPU 显存份额分配，并提供指标。 | 额外的物理显存或通用硬件级隔离。 | | KAI Resource Management | 管理项目、部门、节点池以及资源使用权益。 | 产品优先级或合并代码的授权。 | | Workload Map | 以一致方式描述不同 Kubernetes 工作负载类型的结构。 | 从任务到补丁的验证流水线。 | KAI 文档列出了分层配额、超额使用权重、资源回收、基于时间的公平共享，以及整组工作负载全部就绪才分配的机制。这些能力解决不同问题：配额定义权益，公平共享协调资源争用，成组调度帮助分布式任务取得所需的一整组资源。它们都不负责证明任务输出正确。 [查看 KAI 的调度能力。](https://github.com/kai-scheduler/KAI-Scheduler) KAI Resource Management 在队列之上增加组织层定义。多个团队共享不同型号的 GPU 时，这很有价值。如果一个团队已经在专用硬件上运行可预测任务，收益就可能有限。 [了解资源管理层。](https://github.com/kai-scheduler/kai-resource-management) 说 Run:ai“没有语义”并不准确。Workload Map 理解工作负载的结构、角色和状态，让其他工具能够以一致方式管理不同资源类型。它不表达的是：生成的补丁是否满足客户要求。这个更具体的区别才重要。 [阅读 Workload Map 的职责范围。](https://github.com/dsx-ai-factory/workload-map) ## MIG、时间切片和 GPU fractioning 是同一回事吗？ **不是。它们以不同方式共享硬件，提供的边界也不同。**“像切披萨一样切 GPU”很好记，却掩盖了租户隔离和延迟表现中最关键的细节。 MIG 在支持的设备上创建硬件分区 GPU 实例。NVIDIA 将其描述为具有专用计算和显存资源、实例间相互隔离的机制。可用配置和兼容性取决于具体 GPU。 [阅读 NVIDIA 的 MIG 介绍。](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/introduction.html) 时间切片让多个工作负载轮流使用 GPU。NVIDIA 明确将它与 MIG 区分：普通时间切片不提供副本之间的显存隔离或故障隔离。向调度器报告更多资源槽位，不会产生更多物理 GPU 容量。 [比较 GPU Operator 对时间切片的保证。](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-sharing.html) 新的 GPU Fractioning Operator 接入 CUDA 原生显存限制。文档描述了在容器启动前注入限制、由驱动强制执行，并提供每个 Pod 的指标。其前提包括 CUDA 13.4/r615 或更新版本、支持 NRI 的兼容容器运行时，以及相互匹配的 GPU Operator、工具包和设备插件版本。这些是该 fractioning 路径的要求，不能当成所有 Run:ai 部署的统一最低配置。 [核对 fractioning 行为及完整兼容性要求。](https://github.com/kai-scheduler/gpu-fractioning) | 方式 | 主要边界 | 应测试什么 | | --- | --- | --- | | MIG | 兼容 GPU 上的硬件分区实例。 | 受支持的配置能否满足模型显存、缓存和延迟要求。 | | 时间切片 | 按时间共享访问，不具备与 MIG 等同的隔离。 | 争用、故障影响，以及租户是否适合共享硬件。 | | CUDA 原生 fractioning | 在兼容软件栈中，由驱动执行显存上限。 | 实际限额执行、显存不足行为以及负载下的相互干扰。 | 显存硬上限不等于恒定的每秒 token 数、平均分配的计算时间，也不等于面向恶意租户的完整安全边界。容量规划仍需包含权重、运行时分配、上下文缓存和并发。给模型更少显存，不能让原本放不下的模型自动装进去；模型压缩或分布式推理属于另一项决策。 如果问题在推理服务层而非 GPU 分配层，请看我们的 [vLLM 与 Triton 生产架构分析](/zh/blog/netflix-vllm-triton-inference-stack/) 。Run:ai 可以管理推理服务器所用的容量，推理服务器仍需正确提供模型服务。 ## RBAC、SSO 和 OPA 能让编程智能体安全吗？ **它们约束特定权限和策略，并不能证明软件正确。**Run:ai 的服务参考文档列出了身份提供方集成、基于角色的访问控制、工作负载策略执行、审计服务以及运行时限制。这些都是真实能力，不应因为它们位于智能体之下就被忽略。 [检查平台的身份、策略和审计服务。](https://github.com/dsx-ai-factory/run-ai/blob/45a0a23a8460dbe4d9789d88b3924d41237a537f/docs/developer/services.md) OPA 的说法需要更精确。我们核查的用户身份指南将 Gatekeeper 描述为非 OpenShift Kubernetes 上实现集群级控制的一种选择。它不能证明每个 Run:ai 安装都附带一套完整且配置正确的 OPA 策略。 [阅读文档中 OpenShift 与 Gatekeeper 的控制范围。](https://github.com/dsx-ai-factory/run-ai/blob/45a0a23a8460dbe4d9789d88b3924d41237a537f/docs/installation-and-configuration/configuration/security/user-identity-in-containers.md) 提交工作负载的权限，不应顺带变成修改自身验证策略的权限。基础设施管理、模型凭证、仓库写入和发布审批应相互分离。除了浏览器登录，也要测试 API 和自动化身份：一个漂亮的 SSO 页面不能证明其他路径同样受限。 | 决定 | 负责层 | 应要求的证据 | | --- | --- | --- | | 谁获得 GPU 容量？ | Run:ai 与已配置的调度器。 | 队列、配额、分配和回收记录。 | | 请求发给哪个模型？ | 推理端点与由运维方控制的路由。 | 模型版本、目标地址和请求身份。 | | 智能体可以修改什么？ | 任务策略、沙箱和仓库权限。 | 获批的基线提交、写入范围和拒绝操作测试。 | | 补丁是否满足要求？ | 独立验证与评审。 | 补丁摘要、检查规则、测试结果和评审发现。 | | 这个版本可以发布吗？ | 编程智能体之外的发布授权方。 | 与已验证的精确版本绑定的审批。 | 这是我们建议的运行模式，不是在声称 Run:ai 会自动把这五层连接起来。 ## ESF 放在哪一层？已经有现成集成了吗？ **这里的 ESF 指 Engineering Software Factory。**它是从 Machinist 衍生的独立 MIT 许可项目。README 描述了由 Temporal 协调、在 CubeSandbox 微型虚拟机中运行编程智能体、执行确定性验证，以及保留补丁和运行证据的流程。项目也明确表示，ESF 生成供评审的变更，而不决定哪些内容发布。核查时，0.6.2 被标为候选版本，并非无条件通过生产环境验证的版本。 [阅读 ESF 架构及就绪状态说明。](https://github.com/mitkox/esf/blob/d41535d86a13e55fe2357d9e0a108566d68ce1b9/README.md) 因此，Run:ai 与 ESF 可能互补，但不能当成已经验证的开箱即用组合。我们未核实受支持的 Run:ai 与 ESF 适配器，也未将两者共同部署。不能仅因两者都能隔离工作，就把 ESF 的 CubeSandbox 环境与 Run:ai 工作负载直接互换。 一个范围可控的集成试验，是保留 ESF 的流程和沙箱，让智能体调用由 Run:ai 管理 GPU 容量的模型端点。用同一个关联标识连接工厂运行、推理请求和基础设施记录。推理需要在某处使用 GPU，并不代表每个编程智能体都要独占一张 GPU。 在这个建议的设计中，GPU 配额应对应推理服务；每个智能体的请求上限与支出预算则应在网关或应用层执行，并与工厂运行记录关联。共享 GPU 权益不会自动变成每个调用方的智能体预算。 验收契约应绑定任务、基线提交、智能体执行框架版本、模型版本、补丁摘要、受保护的检查规则、结果、评审决定和清理结果。检查规则必须位于智能体的写入权限之外，或经过独立完整性校验。补丁变更后，旧审批不再有效。 我们的 [智能体执行框架工程指南](/zh/blog/agent-harness-engineering/) 讨论更广的工作流层， [Google AX 评估](/zh/blog/google-ax-agent-executor-security-self-hosting/) 讨论智能体执行和恢复。本文专门讨论 Run:ai 的 GPU 容量边界，不重复做一篇通用编排工具比较。 ## Run:ai 软件工厂试点应证明什么？ **从两个测试项目、一个可丢弃的代码仓库和固定工作负载集开始。**修改调度器前先记录基线。评估基础设施时，保持模型质量和验证标准不变。以下是建议的验收测试，不是我们实测得到的基准结果。 | 测试 | 通过条件 | | --- | --- | | 配额与回收 | 团队只能按策略借用空闲容量；原需求恢复后，资源权益得到恢复，且不会形成无上限的重启循环。 | | 份额上限 | 故意超额的分配在预期工作负载中失败，邻近工作负载仍满足约定的服务目标。 | | 成组放置 | 分布式测试不会在必要同伴一直未获调度时，无限占用部分容量。 | | 身份与绕过 | UI、API、CLI 以及已启用的 MCP 路径，都拒绝同一项未经授权的跨项目操作。 | | 抢占与恢复 | 中断的运行根据已记录状态恢复或重试，不重复执行外部写入，也不接受过期结果。 | | 检查规则完整性 | 削弱验证规则的补丁，不能把不合格变更变成合格变更。 | | 证据与审批 | 每个获接受变更都有可导出的证据记录，并绑定精确补丁；智能体不能批准自己的发布。 | | 回滚与成本 | 团队能恢复此前的调度器或分配策略，并同时解释实测容量收益和新增运维投入。 | 跟踪排队时间、尾延迟、已完成工作负载、不合格变更、重复工作以及运维投入。请求无法满足延迟目标，或者评审者收到更多有缺陷的补丁时，GPU 更忙不能算成功。更广泛的成本口径请参考我们的 [AI 智能体每次有效操作成本方法](/zh/blog/ai-agent-cost-per-action-2026/) 。 ## 为了掌握自己的 AI，是否应该采用 Run:ai？ **当共享 GPU 容量确实构成瓶颈，而且有人能够承担运维责任时，才考虑采用。**多个团队在 Kubernetes 上争用训练、推理和开发资源，是合理场景。只调用 API 的编程团队、单台本地工作站，或者被不可靠测试拖慢的流水线，可能更应该先投资其他环节。 我们对市场变化的判断是：开源基础设施提高了仅重新包装调度能力的产品的门槛，但不会消除可靠运维、专业工作流、集成和验证的价值。NVIDIA 自己的公告也列出了合作伙伴服务，而不是宣称周边软件企业都会消失。 “掌握自己的 AI”最好转化为操作层面的检验：能否更换模型、控制数据目的地、撤销凭证、导出证据并迁移工作负载？云端部署可以保留这些选项，自托管部署也可能仍然高度依赖一家厂商。部署地点本身不能保证模型符合你的利益。 购买更多 GPU 之前，先明确瓶颈是容量、推理、权限还是验证。Wavect 的 [AI 工程服务](/zh/services/artificial-intelligence/) 可以帮助拆分这些决策。 [Twinsoft AI 案例](/zh/case-studies/twinsoft-ai/) 展示的是应用交付，不是 Run:ai 部署。可以用我们的 [软件上线前 QA 清单](/zh/software-development-guide/software-qa-checklist-before-launch/) 定义发布标准，或 [与我们讨论你的 GPU 和智能体工作流](/zh/contact/) 。 ## Run:ai 开源与软件工厂常见问题 ### NVIDIA 在2026年10月开源了什么？ NVIDIA 于2026年10月13日宣布开源完整 Run:ai 平台，而不只是此前已开源的 KAI Scheduler。发布内容包括完整平台，以及可独立采用的调度、GPU 显存份额、资源管理和工作负载描述组件。 ### 开源 Run:ai 需要购买许可证吗？ 平台代码采用 Apache-2.0，并为第三方内容提供单独许可说明。NVIDIA 表示 NGC Community Product 不要求付费 Run:ai 订阅，但下载发行包仍需接受适用条款。企业支持不包含在内，基础设施和运维依然有成本。 ### Run:ai 与 KAI Scheduler 有什么区别？ KAI Scheduler 决定工作负载如何取得集群资源。完整 Run:ai 平台另有控制平面、工作负载管理、组织策略、身份、权限和可观测性。团队可以只采用某个组件，而不安装整个平台。 ### GPU fractioning 和 MIG 是同一回事吗？ 不是。MIG 在支持的 GPU 上创建硬件分区实例；CUDA 原生 fractioning 通过驱动执行受支持的显存上限。普通时间切片又是另一种机制，不提供与 MIG 等同的显存隔离或故障隔离。 ### 显存份额能让更大的模型放进更小的 GPU 吗？ 不能。划分显存不会增加物理容量。模型权重、运行时分配和缓存仍须放入可用显存。模型压缩和分布式推理是另外的技术选择。 ### Run:ai 能取代 CI/CD 或软件验证吗？ 不能。GPU 分配和工作负载策略不能证明补丁满足要求。受保护的测试、证据、评审和发布权限仍属于软件交付层。 ### ESF 是什么？与 Run:ai 的集成能直接用于生产吗？ 这里的 ESF 是 Engineering Software Factory，一个采用 MIT 许可证、使用 Temporal 和 CubeSandbox 运行编程智能体并保留证据的独立项目。核查的 README 将0.6.2标为候选版本。我们未核实受支持的 Run:ai 适配器或经过联合验证的部署。 ### 每套 Run:ai 安装都包含 OPA 策略吗？ 不能这样假定。核查的身份指南将 Gatekeeper 作为非 OpenShift Kubernetes 的可选集群级控制。Run:ai 也有自身的工作负载策略和 RBAC。应核实实际安装的控制及其执行路径。 ### 只调用 API 的小团队应该部署 Run:ai 吗？ 通常不应作为第一项投资。当 Kubernetes GPU 共享和组织间资源分配成为实质问题时，Run:ai 才更有意义。仅调用 API 的流程，可能更应先改善任务定义、模型路由和验证。 ### 自托管就能保证掌握自己的 AI 吗？ 不能。应检查能否更换模型、控制数据目的地、撤销凭证、导出证据以及迁移工作负载。云端和自托管系统都可能保留或限制这些选择。 ## 最终思考 用 Run:ai 管理稀缺的 GPU 容量，用独立验证决定哪些生成的变更可以验收。开源让第一层可以被检查，并不让第二层变成可选项。 ## 你可能也喜欢.. [**vLLM 与 Triton：模型推理服务层** 把推理引擎的选择，与为其分配 GPU 的调度器分开评估。](/zh/blog/netflix-vllm-triton-inference-stack/) 架构与平台 ## 接下来读什么 对长期交付产生影响的框架、平台与系统设计选择。 [从这里开始**智慧城市软件架构：MQTT、LoRaWAN、Kubernetes 与 Terraform**](/zh/blog/smart-city-architecture-best-practices-2026/) - [GitButler 并行 AI 智能体：多个分支，一个运行中的应用](/zh/blog/gitbutler-parallel-ai-agents-one-workspace/) - [Vendo SaaS 集成：租户隔离与审批边界](/zh/blog/vendo-saas-tenant-isolation/) - [SaaS 集成 AgentMail：租户隔离与重复邮件恢复](/zh/blog/agentmail-saas-duplicate-sends-recovery/) - [AI 编程时代的软件护城河：谁来维护你构建的系统？](/zh/blog/ai-coding-software-moat-operations/) - [Shopify B2B 订单审批：原生功能、应用还是定制买方门户？](/zh/blog/shopify-b2b-order-approval-workflow/) [下一篇文章**GitButler 并行 AI 智能体：多个分支，一个运行中的应用**](/zh/blog/gitbutler-parallel-ai-agents-one-workspace/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 分钟 阅读 · 2026年10月15日 最近审核 2026年10月15日 [**下一篇**](/zh/blog/netflix-vllm-triton-inference-stack/)