本文内容
NVIDIA Run:ai 开源：GPU 编排不等于软件工厂
核查日期：。依据为 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 的发布公告。
Run:ai 仓库包含控制平面、集群服务、安装器、CLI、MCP 服务器以及开发环境。仓库将自身代码的许可证标为 Apache-2.0，同时单独说明第三方内容和品牌资产的许可。因此，更准确的表述是“平台自身代码采用 Apache-2.0，附带内容需分别查看许可证”，而不是“一切都采用 Apache-2.0”。核对仓库范围与许可说明。
这改变了自建与采购之间的选择。原本需要采购商业平台才能获得的基础能力，如今可以检查、修改和复用。但依赖组件、模型权重、技术支持和 GPU 并不会因此全部免费。
开源 Run:ai 可以免费使用吗？
公告明确表示，NGC Community Product 不要求付费的 Run:ai 订阅，也不要求 NVIDIA 支持权益，但不包含 NVIDIA 企业支持。下载该发行包仍需接受适用的 NVIDIA 软件协议和 AI 产品条款。源代码许可证、发行包条款以及支持合同，应当分开核对。
实际获取还有一个需要注意的细节。在本次核查时，公告链接到的 NGC 集合页面仍显示订阅提示，页面更新日期为。较旧的目录页面不能推翻较新的公告，但我们没有登录，也没有完成 Community Product 下载。部署前应确认具体 Helm chart、镜像版本和获取路径。查看 NGC 集合及其当前显示的条款。
许可证费用归零，不代表硬件或云租赁、电力、存储、网络、升级、故障处理和工程时间归零。只有当利用率提升帮助你减少实际账单，或避免购买额外容量时，它才转化为现金节省。用好已付费的 GPU 是收回闲置容量，不一定意味着账单随之下降。
Run:ai 与 KAI Scheduler：你需要哪一层？
选择能够解决已测量问题的最小组件。已有 Kubernetes 平台可能只缺调度器或 GPU 共享机制，而不是另一套完整管理系统。
| 组件 | 主要职责 | 不能取代什么 |
|---|---|---|
| Run:ai 平台 | 跨已连接集群协调工作负载、组织策略、权限和可观测性。 | 软件验收标准与发布审批。 |
| KAI Scheduler | 根据队列、配额、公平共享、优先级和成组调度来放置工作负载。 | 模型推理服务引擎或智能体的推理循环。 |
| GPU Fractioning Operator | 在节点上执行受支持的 GPU 显存份额分配，并提供指标。 | 额外的物理显存或通用硬件级隔离。 |
| KAI Resource Management | 管理项目、部门、节点池以及资源使用权益。 | 产品优先级或合并代码的授权。 |
| Workload Map | 以一致方式描述不同 Kubernetes 工作负载类型的结构。 | 从任务到补丁的验证流水线。 |
KAI 文档列出了分层配额、超额使用权重、资源回收、基于时间的公平共享，以及整组工作负载全部就绪才分配的机制。这些能力解决不同问题：配额定义权益，公平共享协调资源争用，成组调度帮助分布式任务取得所需的一整组资源。它们都不负责证明任务输出正确。查看 KAI 的调度能力。
KAI Resource Management 在队列之上增加组织层定义。多个团队共享不同型号的 GPU 时，这很有价值。如果一个团队已经在专用硬件上运行可预测任务，收益就可能有限。了解资源管理层。
说 Run:ai“没有语义”并不准确。Workload Map 理解工作负载的结构、角色和状态，让其他工具能够以一致方式管理不同资源类型。它不表达的是：生成的补丁是否满足客户要求。这个更具体的区别才重要。阅读 Workload Map 的职责范围。
MIG、时间切片和 GPU fractioning 是同一回事吗？
不是。它们以不同方式共享硬件，提供的边界也不同。“像切披萨一样切 GPU”很好记，却掩盖了租户隔离和延迟表现中最关键的细节。
MIG 在支持的设备上创建硬件分区 GPU 实例。NVIDIA 将其描述为具有专用计算和显存资源、实例间相互隔离的机制。可用配置和兼容性取决于具体 GPU。阅读 NVIDIA 的 MIG 介绍。
时间切片让多个工作负载轮流使用 GPU。NVIDIA 明确将它与 MIG 区分：普通时间切片不提供副本之间的显存隔离或故障隔离。向调度器报告更多资源槽位，不会产生更多物理 GPU 容量。比较 GPU Operator 对时间切片的保证。
新的 GPU Fractioning Operator 接入 CUDA 原生显存限制。文档描述了在容器启动前注入限制、由驱动强制执行，并提供每个 Pod 的指标。其前提包括 CUDA 13.4/r615 或更新版本、支持 NRI 的兼容容器运行时，以及相互匹配的 GPU Operator、工具包和设备插件版本。这些是该 fractioning 路径的要求，不能当成所有 Run:ai 部署的统一最低配置。核对 fractioning 行为及完整兼容性要求。
| 方式 | 主要边界 | 应测试什么 |
|---|---|---|
| MIG | 兼容 GPU 上的硬件分区实例。 | 受支持的配置能否满足模型显存、缓存和延迟要求。 |
| 时间切片 | 按时间共享访问，不具备与 MIG 等同的隔离。 | 争用、故障影响，以及租户是否适合共享硬件。 |
| CUDA 原生 fractioning | 在兼容软件栈中，由驱动执行显存上限。 | 实际限额执行、显存不足行为以及负载下的相互干扰。 |
显存硬上限不等于恒定的每秒 token 数、平均分配的计算时间，也不等于面向恶意租户的完整安全边界。容量规划仍需包含权重、运行时分配、上下文缓存和并发。给模型更少显存，不能让原本放不下的模型自动装进去；模型压缩或分布式推理属于另一项决策。
如果问题在推理服务层而非 GPU 分配层，请看我们的vLLM 与 Triton 生产架构分析。Run:ai 可以管理推理服务器所用的容量，推理服务器仍需正确提供模型服务。
RBAC、SSO 和 OPA 能让编程智能体安全吗？
它们约束特定权限和策略，并不能证明软件正确。Run:ai 的服务参考文档列出了身份提供方集成、基于角色的访问控制、工作负载策略执行、审计服务以及运行时限制。这些都是真实能力，不应因为它们位于智能体之下就被忽略。检查平台的身份、策略和审计服务。
OPA 的说法需要更精确。我们核查的用户身份指南将 Gatekeeper 描述为非 OpenShift Kubernetes 上实现集群级控制的一种选择。它不能证明每个 Run:ai 安装都附带一套完整且配置正确的 OPA 策略。阅读文档中 OpenShift 与 Gatekeeper 的控制范围。
提交工作负载的权限，不应顺带变成修改自身验证策略的权限。基础设施管理、模型凭证、仓库写入和发布审批应相互分离。除了浏览器登录，也要测试 API 和自动化身份：一个漂亮的 SSO 页面不能证明其他路径同样受限。
| 决定 | 负责层 | 应要求的证据 |
|---|---|---|
| 谁获得 GPU 容量？ | Run:ai 与已配置的调度器。 | 队列、配额、分配和回收记录。 |
| 请求发给哪个模型？ | 推理端点与由运维方控制的路由。 | 模型版本、目标地址和请求身份。 |
| 智能体可以修改什么？ | 任务策略、沙箱和仓库权限。 | 获批的基线提交、写入范围和拒绝操作测试。 |
| 补丁是否满足要求？ | 独立验证与评审。 | 补丁摘要、检查规则、测试结果和评审发现。 |
| 这个版本可以发布吗？ | 编程智能体之外的发布授权方。 | 与已验证的精确版本绑定的审批。 |
这是我们建议的运行模式，不是在声称 Run:ai 会自动把这五层连接起来。
ESF 放在哪一层？已经有现成集成了吗？
这里的 ESF 指 Engineering Software Factory。它是从 Machinist 衍生的独立 MIT 许可项目。README 描述了由 Temporal 协调、在 CubeSandbox 微型虚拟机中运行编程智能体、执行确定性验证，以及保留补丁和运行证据的流程。项目也明确表示，ESF 生成供评审的变更，而不决定哪些内容发布。核查时，0.6.2 被标为候选版本，并非无条件通过生产环境验证的版本。阅读 ESF 架构及就绪状态说明。
因此，Run:ai 与 ESF 可能互补，但不能当成已经验证的开箱即用组合。我们未核实受支持的 Run:ai 与 ESF 适配器，也未将两者共同部署。不能仅因两者都能隔离工作，就把 ESF 的 CubeSandbox 环境与 Run:ai 工作负载直接互换。
一个范围可控的集成试验，是保留 ESF 的流程和沙箱，让智能体调用由 Run:ai 管理 GPU 容量的模型端点。用同一个关联标识连接工厂运行、推理请求和基础设施记录。推理需要在某处使用 GPU，并不代表每个编程智能体都要独占一张 GPU。
在这个建议的设计中，GPU 配额应对应推理服务；每个智能体的请求上限与支出预算则应在网关或应用层执行，并与工厂运行记录关联。共享 GPU 权益不会自动变成每个调用方的智能体预算。
验收契约应绑定任务、基线提交、智能体执行框架版本、模型版本、补丁摘要、受保护的检查规则、结果、评审决定和清理结果。检查规则必须位于智能体的写入权限之外，或经过独立完整性校验。补丁变更后，旧审批不再有效。
我们的智能体执行框架工程指南讨论更广的工作流层，Google AX 评估讨论智能体执行和恢复。本文专门讨论 Run:ai 的 GPU 容量边界，不重复做一篇通用编排工具比较。
Run:ai 软件工厂试点应证明什么？
从两个测试项目、一个可丢弃的代码仓库和固定工作负载集开始。修改调度器前先记录基线。评估基础设施时，保持模型质量和验证标准不变。以下是建议的验收测试，不是我们实测得到的基准结果。
| 测试 | 通过条件 |
|---|---|
| 配额与回收 | 团队只能按策略借用空闲容量；原需求恢复后，资源权益得到恢复，且不会形成无上限的重启循环。 |
| 份额上限 | 故意超额的分配在预期工作负载中失败，邻近工作负载仍满足约定的服务目标。 |
| 成组放置 | 分布式测试不会在必要同伴一直未获调度时，无限占用部分容量。 |
| 身份与绕过 | UI、API、CLI 以及已启用的 MCP 路径，都拒绝同一项未经授权的跨项目操作。 |
| 抢占与恢复 | 中断的运行根据已记录状态恢复或重试，不重复执行外部写入，也不接受过期结果。 |
| 检查规则完整性 | 削弱验证规则的补丁，不能把不合格变更变成合格变更。 |
| 证据与审批 | 每个获接受变更都有可导出的证据记录，并绑定精确补丁；智能体不能批准自己的发布。 |
| 回滚与成本 | 团队能恢复此前的调度器或分配策略，并同时解释实测容量收益和新增运维投入。 |
跟踪排队时间、尾延迟、已完成工作负载、不合格变更、重复工作以及运维投入。请求无法满足延迟目标，或者评审者收到更多有缺陷的补丁时，GPU 更忙不能算成功。更广泛的成本口径请参考我们的AI 智能体每次有效操作成本方法。
为了掌握自己的 AI，是否应该采用 Run:ai？
当共享 GPU 容量确实构成瓶颈，而且有人能够承担运维责任时，才考虑采用。多个团队在 Kubernetes 上争用训练、推理和开发资源，是合理场景。只调用 API 的编程团队、单台本地工作站，或者被不可靠测试拖慢的流水线，可能更应该先投资其他环节。
我们对市场变化的判断是：开源基础设施提高了仅重新包装调度能力的产品的门槛，但不会消除可靠运维、专业工作流、集成和验证的价值。NVIDIA 自己的公告也列出了合作伙伴服务，而不是宣称周边软件企业都会消失。
“掌握自己的 AI”最好转化为操作层面的检验：能否更换模型、控制数据目的地、撤销凭证、导出证据并迁移工作负载？云端部署可以保留这些选项，自托管部署也可能仍然高度依赖一家厂商。部署地点本身不能保证模型符合你的利益。
购买更多 GPU 之前，先明确瓶颈是容量、推理、权限还是验证。Wavect 的AI 工程服务可以帮助拆分这些决策。Twinsoft AI 案例展示的是应用交付，不是 Run:ai 部署。可以用我们的软件上线前 QA 清单定义发布标准，或与我们讨论你的 GPU 和智能体工作流。
Run:ai 开源与软件工厂常见问题
NVIDIA 在2026年10月开源了什么？
开源 Run:ai 需要购买许可证吗？
Run:ai 与 KAI Scheduler 有什么区别？
GPU fractioning 和 MIG 是同一回事吗？
显存份额能让更大的模型放进更小的 GPU 吗？
Run:ai 能取代 CI/CD 或软件验证吗？
ESF 是什么？与 Run:ai 的集成能直接用于生产吗？
每套 Run:ai 安装都包含 OPA 策略吗？
只调用 API 的小团队应该部署 Run:ai 吗？
自托管就能保证掌握自己的 AI 吗？
最终思考
用 Run:ai 管理稀缺的 GPU 容量，用独立验证决定哪些生成的变更可以验收。开源让第一层可以被检查，并不让第二层变成可选项。