OCP2026｜Run:ai全平台开源
AI平台自研应聚焦交付与运营
截至 2026 年 10 月 17 日
OCP 2026 期间，NVIDIA 将完整 Run:ai 平台开源，并为基础设施运营层 DSX OS 增加网络配置、集群验收、机架管理和裸金属交付组件。[1][2] 相较此前已经开放的 GPU 调度器，本届扩大的是企业能够直接采用、修改和交付的软件范围：既可以整体评估一套平台，也可以把组织配额、工作负载描述等能力接入已有系统。
这组发布改变了 AI 工厂的平台建设起点。对经营 GPU 云、模型服务或企业 AI 平台的公司，关键选择变成了采用哪些现成能力、保留哪些自有控制，以及谁为持续交付负责。开放底座越完整，越需要把组件能力与客户承诺分清。
完整平台开放扩大了可以直接采用的范围
2025 年 4 月 1 日，NVIDIA 已发布 Apache 2.0 许可的 GPU 调度器 KAI Scheduler。公平共享、层级队列，以及为必须一起启动的任务整体分配资源的 gang scheduling 等机制，当时就属于开放能力。[13] 因而，本次讨论应以此前能获得什么为起点：团队已经能够采用调度引擎，却仍需自行连接组织权限、工作负载入口、生命周期管理和平台运维。
完整 Run:ai 仓库把控制平面、集群服务、安装器、客户端等放到一起，形成可检查和构建的平台实现。[4] 这扩大了开放的范围，也降低了厂商或云服务商从组件拼出产品的重复劳动。对于已有 Kubernetes 平台的企业，更重要的是可以只引入缺少的部分；对于尚未形成平台的新经营者，则多了一个能够整体评估的起点。两种采用路径对应不同的迁移风险，不能仅凭“完整开源”就认为必须整体替换现有系统。
本次独立组件覆盖四类职责：决定任务如何放置的 KAI Scheduler，表达部门、项目、资源配额与节点池的 KAI Resource Management，描述不同框架工作负载结构的 Workload Map，以及把 CUDA 原生 GPU 分片接到 Kubernetes 的 GPU Fractioning Operator。[1] 这些属于开源软件和接口契约。跨厂商治理、兼容性测试及长期版本承诺，还需分别核对，不能仅因在 OCP 期间发布就视为统一行业标准。
另一个更具体的变化发生在 GPU 共享路径。Run:ai 原本已有专有分片实现，本次公告说明其转向 CUDA 13.4 原生能力，由驱动落实显存限制，再由 Operator 提供 Kubernetes 集成和分片指标。[1][10] 对平台负责人，这意味着需要重新验证驱动、运行时、调度器和计量之间的接口。已有“分片”产品名称，并不能代替新实现的兼容性、干扰和恢复测试。
两组发布覆盖了投产与运行两段流程
完整 Run:ai 管理共享资源上的工作负载，DSX OS 的这次增补则覆盖更靠前的集群投产流程。自动配置交换网络的是 Config Manager；运行压力负载、检查集群健康的是 Cluster Readiness Engine；管理机架硬件和固件的是 Rack Management Service；按标准集群生命周期交付裸金属环境的是 Cluster API Provider for NVIDIA Infrastructure Controller。[2] 它们在10月12日公布，Run:ai 全平台开源公告则发表于10月13日。
这组组件的价值在于减少交付过程中难以复现的人工步骤。一个集群能启动，不代表它已经通过高负载验收；交换机配置看起来相同，也不代表所有节点在真实通信压力下表现一致。把配置、压力测试和硬件状态变为可重复执行的流程，才有机会区分设备故障、软件漂移和工作负载自身问题。这里的效率提升需要在自己的环境测量，不能把厂商的部署时间描述直接变成对客户的服务承诺。
把这两段流程连接起来，平台团队才能继续追问：设备经过了什么验收，当前有哪些资源可以承诺，工作负载又由谁管理。前段减少重复部署中的人工差异，后段把共享资源交给具体团队与服务。组件之间仍需集成，但本届发布让更多环节有了可以检查和采用的实现。
组织配额和工作负载描述是两处关键集成点
资源分配首先是权利问题，然后才是放置问题。一个部门有多少保底额度，闲置额度能否借给另一个部门，借用后多久必须归还，都会影响平台可以向谁作出什么承诺。KAI Resource Management 将组织层级、配额与节点池单独表达，使平台团队能够把这层逻辑接入已有门户和审批流程。[8] 这不自动等于合同计费，也不意味着每个配额百分比都能转换为同等比例的在线推理吞吐。
在工作负载一侧，平台面对的也不只是 Deployment 或 Job。同一个 AI 服务可能由前端、处理输入的预填充组件（prefill）、逐 Token 生成组件（decode）和辅助组件组成，不同框架使用不同的自定义资源。Workload Map 提供统一结构，帮助工具理解组件、角色和状态；其边界是描述工作负载，而不是自己完成排队、自动扩缩容或跨集群传播。[9] 如果把“统一描述”误解为“统一执行”，就会低估平台真正需要补上的控制逻辑。
采用边界应在建设之初确定。已有平台可以保留客户入口、产品目录和成本规则，接入所缺的组织管理或调度能力；新建平台可以把完整栈作为起点，再逐项验证身份、网络、存储和运维依赖。前一种路径主要评估接口与迁移，后一种路径主要评估整栈维护及服务责任。两条路径都需要测试从扩容决定到真正接单的完整时间，不能把组件运行状态直接当成交付结果。
建设选择要落到持续交付和支持责任
这次发布的影响，首先会出现在软件采购与平台建设路径上。已有 Kubernetes 和推理平台的企业可以按缺口集成，避免大规模迁移；新建服务商可以评估完整平台，但应先在有限租户、有限模型和明确服务目标（SLO）下验证。选择开源底座并不要求重写所有算法，企业真正需要掌握的是产品目录、准入规则、成本口径、隔离等级和服务责任。
成熟度也要按对象分别判断。KAI Scheduler 有更长的开放使用历史；完整 Run:ai 的公开分发方式刚刚推出；DSX 新组件各自有不同依赖与运行边界。源码可获取、代码来自既有产品和企业提供生产支持，是三件应分别核对的事。官方说明 NGC Community Product 无需付费 Run:ai 订阅，但不包含 NVIDIA 企业支持，下载仍适用相应条款。[1]
完整源码及独立组件应分别按其适用许可采用。[1][4] 开源许可决定代码可以如何使用，分发条款决定软件包怎样取得，支持合同决定生产事故由谁响应。把这三项分开比较，才能看清软件预算和运营预算是否真的下降。对企业来说，值得购买的可能是长期维护、兼容性验证和事故支持；值得自有掌握的则是客户承诺及其验收依据。
本届软件新闻的方向由此更清楚：AI 工厂正在获得从基础设施交付到工作负载管理的更多开放组件，厂商和运营者可以围绕共同底座组合产品。对 CTO，决策重点是用这些开放能力缩短哪一段交付流程，以及谁持续为版本、安全、兼容和事故负责。只有把这些问题落实，开放的软件范围扩大，才会转化为稳定可售的 Token 产能。
技术附页
以下保留采用这些组件时需要验证的调度、隔离、计量与故障细节。它们用于界定平台的交付边界，并非本届新增功能清单。
一 三层调度与服务目标如何对齐
资源调度决定租户与工作负载得到哪些 GPU；请求调度决定一次推理进入哪个副本；引擎内部调度决定副本如何执行批处理与计算。三个层次面对的时间尺度和状态不同。KAI 的公平共享、gang scheduling 和拓扑感知，解决资源层的一组问题；Dynamo 感知上下文缓存的请求路由（KV-aware routing）则在请求层同时考虑缓存复用与已分配负载。[5][6] 缓存命中更多的副本如果已经拥塞，未必是当前请求更好的选择。
把这三层连接起来，需要明确在线服务的约束。GPU 利用率回答设备在采样窗口内有多忙；用户关心的是请求成功、首 Token 到达、后续输出速度，以及任务是否在截止时间前完成。增大批次或延长排队可以提高设备忙碌程度，也可能把用户体验推过边界。性能工具 AIPerf 的有效吞吐指标 goodput 统计满足指定服务目标的完成请求，并通过达标比例保留另一层观察。[3] 经营看板应把有效吞吐、达标比例和失败率放在一起。
用一组假设说明区别：同一种模型、相同请求长度分布与统计窗口，方案甲每秒完成 100 个请求，其中 95% 达标；方案乙完成 120 个，只有 70% 达标。对应有效吞吐分别为每秒 95 与 84 个请求。这不是产品实测。若失败请求没有进入达标比例分母，还需重新核算。乙的总吞吐更高，能够承接的同等级订单却可能更少。
对于多租户服务，入口限流、路由、资源回收和扩容必须使用相容的目标。资源层刚回收一个副本，请求层仍把流量送过去，会形成交付故障；入口持续接单、底层却没有能及时启动的容量，也会如此。开放的组件可以降低实现成本，真正需要经营者掌握的，是这些控制之间的优先级与退化规则。
Grove 可以作为背景说明这种分工。它把多角色推理负载表达为一个有依赖关系的整体，再交由调度器落实放置；相关项目和 2025 年文档并非本届首次发布。[7] Prefill 与 decode 分离后，扩容也必须判断各角色是否协调。只增加输入处理能力，可能更快地制造生成阶段的积压；为装满 GPU 而跨越更远距离，可能把节省的计算时间消耗在 KV 搬运上。共同的工作负载描述让这些问题更容易被工具理解，但比例和放置策略仍要由真实请求分布决定。
服务交付因此多出一个值得测量的时间：从平台决定扩容，到新增能力能够稳定接单。Pod 运行、权重加载、通信连接建立、缓存准备和入口流量切换，并不总在同一时刻完成。采购团队关心 GPU 到货速度，产品团队则必须继续追踪这段软件交付时间，否则硬件规模扩张不会等比例变成可售能力。
二 GPU 分片与租户隔离的验证范围
显存边界是共享资源的重要基础，却不能单独回答不同租户之间的时延干扰、网络权限、存储访问和密钥管理。GPU Fractioning 的指标有助于看到底层资源分配；能否把这部分资源出售为保底服务，还要测试邻近工作负载、突发、回收和重启的影响。[10] 开发环境、小模型与严格时延服务，未必适合共用同一套共享策略。
Run:ai 原有文档包含身份、按角色控制访问（RBAC）、项目隔离与审计能力。[11] 本次开源后，企业更容易检查这些能力如何衔接现有身份和容器环境，但仍需按照自己的威胁模型评估。内部研发团队与外部不可信租户，对隔离边界、故障影响范围和取证能力的要求可能差异很大。
产品合同也要说清保底对象。专属设备、预留副本和保证请求表现，是三种不同承诺。低峰能够借用的容量，不应直接按随时可用的保底能力出售；回收耗时、恢复耗时与预热需求应进入内部容量模型。当资源分配百分比无法映射到可验证的服务结果，单靠调度器显示的配额很难支撑定价。
三 计量事件怎样进入成本和账单
监控记录运行事实，计费执行合同。输入和输出 Token 怎样计数，缓存命中如何折算，取消、重试和部分返回如何收费，都需要可追溯的规则。模型与 tokenizer 版本改变时，也应保留对应依据。分片指标可以帮助归集资源成本，但不能直接替代按 Token、预留吞吐或任务结果签订的计费规则。
平台应把请求标识、租户、模型版本、执行尝试、返回状态与计费事件连接起来。监控可以采样，账单需要去重、可重放和可对账。成本也不能只计成功请求的 GPU 秒：为承诺保留的空闲容量、模型预热、失败重试、存储、网络和运维，都应归入相应服务等级。否则每百万 Token 的表面成本下降，可能只是排队更激进或共享更多，并未改善经营结果。
四 从集群验收走到故障处置
Cluster Readiness Engine 的仓库也给出了关键边界：它可以运行分布式负载、识别异常节点并报告原因，但不会自行禁止节点接收新调度任务或添加调度限制标记（cordon 或 taint）。[12] 因此，“检查工具已安装”与“故障节点不会继续接单”之间，还需要上层平台接入准入、容量台账和维修流程。更准确的产品分工，是下层提供观测与执行能力，上层决定何时停止接单、怎样处置在途任务、何时重新释放容量。
机架管理同样不能独立于调度策略。固件升级、节点维修和整架维护都会改变可用容量；平台若只看到设备总数，便可能把正在维护的资源继续计入承诺。对服务商而言，软件开放提供了连接这些环节的材料，能否形成可靠交付仍取决于状态传播、责任划分与故障演练。
故障闭环同样需要完整责任。从发现异常、停止新增流量、处置在途请求，到隔离、修复验证和恢复销售，每一步都应留下证据。重试需要预算与幂等边界，避免同一业务请求重复收费，或把故障期间的剩余容量压垮。DSX 的健康检查和 Run:ai 的工作负载管理提供了可连接的环节，用户服务能否按约定退化与恢复，仍必须由端到端演练证明。
参考资料
[1] NVIDIA Run:ai 全平台开源公告，2026-10-13。
https://developer.nvidia.com/blog/nvidia-runai-is-now-open-source-as-part-of-nvidia-dsx-ai-factory-platform/
[2] NVIDIA OCP 2026 公告及 DSX OS 新组件，2026-10-12。
https://blogs.nvidia.com/blog/ocp-global-summit-vera-rubin-scale-ai-factories/
[3] AIPerf Goodput 定义与达标比例，读取于 2026-10-17。
https://docs.nvidia.com/aiperf/tutorials/metrics-analysis/benchmark-goodput-with-ai-perf
[4] Run:ai 官方代码仓库，读取于 2026-10-17。
https://github.com/dsx-ai-factory/run-ai
[5] KAI Scheduler 官方仓库，读取于 2026-10-17。
https://github.com/kai-scheduler/KAI-Scheduler
[6] Dynamo KV-aware routing 官方说明，读取于 2026-10-17。
https://docs.dynamo.nvidia.com/dynamo/knowledge-base/concepts/system-architecture/kv-aware-routing
[7] Grove 多组件推理编排说明，2025-11-10；架构背景，不列作本届新发布。
https://developer.nvidia.com/blog/streamline-complex-ai-inference-on-kubernetes-with-nvidia-grove/
[8] KAI Resource Management 官方仓库，读取于 2026-10-17。
https://github.com/kai-scheduler/kai-resource-management
[9] Workload Map 官方仓库，读取于 2026-10-17。
https://github.com/dsx-ai-factory/workload-map
[10] GPU Fractioning 官方仓库，读取于 2026-10-17。
https://github.com/kai-scheduler/gpu-fractioning
[11] Run:ai 架构与组件官方文档，读取于 2026-10-17。
https://docs.nvidia.com/run-ai/self-hosted/documentation/getting-started/architecture
[12] Cluster Readiness Engine 官方仓库，读取于 2026-10-17。
https://github.com/NVIDIA/cluster-readiness-engine
[13] NVIDIA 首次开源 KAI Scheduler，2025-04-01；用于核对本次开放的历史基线。
https://developer.nvidia.com/blog/?p=98094