--- title: "NVIDIA Run:ai Open Source: GPU Fleet vs Software Factory" canonical: https://wavect.io/blog/nvidia-runai-open-source-gpu-software-factory/ language: en description: "What open-source Run:ai includes, how MIG differs from GPU fractioning, and what an ESF software factory still needs: protected checks, evidence and review." 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 Open Source: GPU Fleet vs Software Factory [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min read · 15 Oct 2026 Last reviewed October 15, 2026 [**Next**](/blog/netflix-vllm-triton-inference-stack/) TL;DR NVIDIA announced the full Run:ai platform as open source on 13 October 2026. Its own code is Apache-2.0; the NGC Community Product has separate distribution terms and no included enterprise support. Run:ai manages GPU capacity, workloads and access. MIG, time-slicing and CUDA-native fractioning have different isolation boundaries. A software factory such as ESF addresses a separate task-to-patch workflow. Test both capacity allocation and independent verification before treating the combination as a production system. *Reviewed 15 October 2026 against NVIDIA documentation and public source repositories. This is a source-based assessment, not a Run:ai deployment, ESF integration test or GPU benchmark.* Your GPUs are busy. Your software is still not ready to ship. That is the gap behind NVIDIA's Run:ai announcement. Allocating compute and accepting a software change are different jobs. Open-source GPU orchestration can improve the first. It does not remove the second. The useful question is not whether Run:ai replaces every AI platform. It is **which part of your stack you no longer need to build, and which decisions must stay under your control**. ## What did NVIDIA actually open-source? **On 13 October 2026, NVIDIA announced the complete Run:ai platform as open source, not just its KAI scheduling engine.** The announcement places Run:ai within the NVIDIA DSX AI Factory Platform and offers both an integrated platform and separately adoptable components. [Read NVIDIA's release announcement.](https://developer.nvidia.com/blog/nvidia-runai-is-now-open-source-as-part-of-nvidia-dsx-ai-factory-platform/) The Run:ai repository includes the control plane, cluster services, installer, CLI, MCP server and development environment. It identifies Apache-2.0 as the code license, with separate notices for bundled third-party material and brand assets. “Everything is Apache-2.0” is therefore less precise than “the platform's own code is Apache-2.0; check the accompanying licenses.” [Inspect the repository scope and licensing notes.](https://github.com/dsx-ai-factory/run-ai/blob/45a0a23a8460dbe4d9789d88b3924d41237a537f/README.md) This changes the build-versus-buy calculation. Teams can inspect and adapt infrastructure capabilities that previously required a commercial platform decision. It does not make every dependency, model weight, support service or GPU free. ## Is open-source Run:ai free to use? **The announcement says the NGC Community Product requires no paid Run:ai subscription or NVIDIA support entitlement. NVIDIA enterprise support is not included.** Downloading that distribution still requires accepting its applicable NVIDIA software and AI-product terms. Keep the source-code license, packaged distribution terms and support contract separate. There is a practical access caveat. During this review, the NGC collection linked by the announcement still displayed subscription language and a 23 September 2026 update date. That older catalog page does not cancel the newer announcement, but we did not authenticate or complete a Community Product download. Confirm the exact chart, image versions and access path before planning a rollout. [Check the linked NGC collection and its displayed terms.](https://catalog.ngc.nvidia.com/orgs/nvidia/runai/collections/run-ai-self-hosted/-) A zero license line leaves hardware or cloud rental, electricity, storage, networking, upgrades, incident response and engineering time. Better utilization becomes cash savings only when it lets you reduce a bill or avoid additional capacity. Filling a GPU you already pay for is useful capacity recovery, not automatically money returned. ## Run:ai versus KAI Scheduler: which layer do you need? **Choose the smallest layer that solves a measured problem.** An existing Kubernetes platform may need a scheduler or GPU-sharing mechanism, not another complete management stack. | Component | Primary job | Not a substitute for | | --- | --- | --- | | Run:ai platform | Coordinate workloads, organizational policies, access and visibility across connected clusters. | Your software acceptance criteria and release approvals. | | KAI Scheduler | Place workloads using queues, quotas, fairness, priorities and gang scheduling. | A model-serving engine or an agent's reasoning loop. | | GPU Fractioning Operator | Enforce supported fractional GPU-memory allocations on nodes and expose metrics. | Additional physical memory or universal hardware-level isolation. | | KAI Resource Management | Represent projects, departments, node pools and resource entitlements. | Product priorities or authorization to merge code. | | Workload Map | Describe the structure of different Kubernetes workload types consistently. | A task-to-patch verification pipeline. | KAI documents hierarchical quotas, over-quota weights, resource reclamation, time-based fair-share and all-or-nothing placement for grouped workloads. These address different problems: a quota defines an entitlement, fairness governs contention, and gang scheduling helps a distributed job obtain its required group of resources. None says that the job's output is correct. [Review KAI's scheduling capabilities.](https://github.com/kai-scheduler/KAI-Scheduler) KAI Resource Management adds the organizational vocabulary above those queues. This is useful when several teams share heterogeneous GPU capacity. It is less compelling when one team already runs predictable jobs on dedicated hardware. [Inspect the resource-management layer.](https://github.com/kai-scheduler/kai-resource-management) Run:ai is not “without semantics.” Workload Map understands workload structure, roles and status; it can help other tools manage different resource types consistently. What it does not encode is whether a generated patch satisfies a customer's requirement. That is the narrower, important distinction. [Read Workload Map's scope.](https://github.com/dsx-ai-factory/workload-map) ## Are MIG, time-slicing and GPU fractioning the same? **No. They share hardware in different ways and offer different boundaries.** “Slicing GPUs like pizza” is memorable, but it hides the details that matter for tenant isolation and latency. MIG creates hardware-partitioned GPU instances on supported devices. NVIDIA describes dedicated compute and memory resources with isolation between instances. Available profiles and compatibility depend on the GPU. [Read NVIDIA's MIG introduction.](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/introduction.html) Time-slicing lets multiple workloads take turns using a GPU. NVIDIA explicitly distinguishes it from MIG: ordinary time-slicing does not provide memory or fault isolation between replicas. More advertised resource slots do not create more physical GPU capacity. [Compare GPU Operator's time-slicing guarantees.](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-sharing.html) The new GPU Fractioning Operator integrates CUDA-native memory limits. Its documentation describes limits injected before a container starts, enforced by the driver, plus per-pod metrics. Its prerequisites include CUDA 13.4/r615 or newer, a compatible container runtime with NRI, and matching GPU Operator, toolkit and device-plugin versions. These are requirements for that fractioning path, not blanket minimums for every Run:ai deployment. [Check fractioning behavior and the full compatibility requirements.](https://github.com/kai-scheduler/gpu-fractioning) | Approach | Useful boundary | What to test | | --- | --- | --- | | MIG | Hardware-partitioned instances on compatible GPUs. | Whether a supported profile fits model memory, cache and latency needs. | | Time-slicing | Shared access over time, without MIG-equivalent isolation. | Contention, failure impact and whether the tenants can safely share. | | CUDA-native fractioning | Driver-enforced GPU-memory limits with compatible software. | Actual limit enforcement, out-of-memory behavior and interference under load. | A hard memory limit is not a promise of constant tokens per second, equal compute time, or a complete hostile-tenant security boundary. Size for weights, runtime allocations, context cache and concurrency. Giving a model less memory cannot make an oversized model fit; model compression or distributed inference is a separate decision. For the serving layer rather than GPU allocation, see our [vLLM and Triton production analysis](/blog/netflix-vllm-triton-inference-stack/). Run:ai can govern the capacity an inference server uses. The inference server still has to serve the model correctly. ## Do RBAC, SSO and OPA make coding agents safe? **They govern particular permissions and policies. They do not establish software correctness.** Run:ai's service reference documents identity-provider integration, role-based access control, workload policy enforcement, audit services and runtime limits. Those are real capabilities, not features to dismiss because they sit below an agent. [Inspect the platform's identity, policy and audit services.](https://github.com/dsx-ai-factory/run-ai/blob/45a0a23a8460dbe4d9789d88b3924d41237a537f/docs/developer/services.md) The OPA claim needs a narrower reading. The reviewed user-identity guide describes Gatekeeper as an option for cluster-level controls on non-OpenShift Kubernetes. It does not establish that every Run:ai installation ships with a complete, correctly configured OPA policy set. [Read the documented OpenShift and Gatekeeper boundaries.](https://github.com/dsx-ai-factory/run-ai/blob/45a0a23a8460dbe4d9789d88b3924d41237a537f/docs/installation-and-configuration/configuration/security/user-identity-in-containers.md) A permission to submit a workload must not become a permission to rewrite its own verification policy. Keep infrastructure administration, model credentials, repository writes and release approval separate. Test the API and automation identities as well as the browser login: an attractive SSO screen does not prove that every other path is restricted. | Decision | Responsible layer | Evidence to require | | --- | --- | --- | | Who gets GPU capacity? | Run:ai and the configured scheduler. | Queue, quota, allocation and reclamation records. | | Which model receives a request? | Serving endpoint and operator-controlled routing. | Model revision, destination and request identity. | | What may the agent change? | Task policy, sandbox and repository permissions. | Approved base commit, write scope and denied-action tests. | | Does the patch satisfy requirements? | Independent verification and review. | Patch digest, gate definitions, test results and review findings. | | May this version ship? | Release authority outside the coding agent. | Approval bound to the exact verified revision. | This is our proposed operating model, not a claim that Run:ai automatically wires all five layers together. ## Where does ESF fit, and is there a ready-made integration? **ESF means Engineering Software Factory in the referenced project.** It is an independent, MIT-licensed project derived from Machinist. Its README describes Temporal coordinating coding agents in CubeSandbox microVMs, deterministic verification, and preserved patches and execution evidence. It also says ESF produces changes for review, not decisions about what ships. At review time, version 0.6.2 is described as a release candidate, not an unconditional production qualification. [Read ESF's architecture and readiness caveats.](https://github.com/mitkox/esf/blob/d41535d86a13e55fe2357d9e0a108566d68ce1b9/README.md) That makes Run:ai and ESF potentially complementary, not a verified turnkey bundle. We did not verify a supported Run:ai-to-ESF adapter or deploy them together. ESF's CubeSandbox execution environment is not interchangeable with a Run:ai workload simply because both isolate work. A bounded integration experiment would keep ESF's workflow and sandbox intact while its agents call a model endpoint whose GPU capacity is managed by Run:ai. Add a correlation ID across the factory run, inference request and infrastructure records. Do not allocate a dedicated GPU to every coding agent merely because inference needs GPUs somewhere. For this proposed design, map GPU quotas to inference services and enforce per-agent request limits and spending budgets at the gateway or application layer. Correlate those records with factory runs. A shared GPU entitlement is not automatically a budget for each agent that calls the endpoint. The acceptance contract should bind the task, base commit, harness version, model revision, patch digest, protected gate definitions, results, reviewer decision and cleanup outcome. Gate definitions must live outside the agent's writable authority or be independently integrity-checked. A new patch invalidates the old approval. Our [agent harness engineering guide](/blog/agent-harness-engineering/) covers the broader workflow layer. Our [Google AX review](/blog/google-ax-agent-executor-security-self-hosting/) covers agent execution and recovery. This article's job is the Run:ai GPU-capacity boundary, not another general orchestration comparison. ## What should a Run:ai software-factory pilot prove? **Start with two test projects, a disposable repository and a fixed workload set.** Record the baseline before changing the scheduler. Keep model quality and verification criteria unchanged while evaluating the infrastructure. The following are proposed acceptance tests, not benchmark results we measured. | Test | Pass condition | | --- | --- | | Quota and reclaim | A team can borrow idle capacity only as policy permits; returning demand restores the intended entitlement without unbounded restart loops. | | Fraction limit | A deliberately oversized allocation fails in the intended workload; a neighboring workload stays within its agreed service objective. | | Grouped placement | A distributed test does not consume partial capacity indefinitely while required peers remain unscheduled. | | Identity and bypass | UI, API, CLI and enabled MCP paths deny the same unauthorized cross-project action. | | Preemption and recovery | An interrupted run resumes or retries from recorded state without duplicating an external write or accepting stale results. | | Gate integrity | A patch that weakens verification cannot turn a failing change into an accepted one. | | Evidence and approval | Each accepted change has an exportable evidence record tied to the exact patch; agents cannot approve their own release. | | Rollback and cost | The team can restore the prior scheduler or allocation policy and explain the measured capacity gain alongside added operating effort. | Track queue delay, tail latency, completed workloads, rejected changes, repeated work and operator effort. A busier GPU is not a success when requests miss their latency objective or reviewers receive more defective patches. For the broader financial denominator, use our [AI agent cost-per-action methodology](/blog/ai-agent-cost-per-action-2026/). ## Should you adopt Run:ai to own your AI? **Adopt it when shared GPU capacity is a material constraint and someone can own the operating burden.** A multi-team Kubernetes environment with competing training, inference and development workloads is a plausible fit. An API-only coding team, one local workstation, or a pipeline blocked by unreliable tests may need a different first investment. Our interpretation of the market shift: open-source infrastructure raises the bar for products that mainly repackage scheduling. It does not eliminate the value of reliable operations, specialized workflows, integrations or verification. NVIDIA's own announcement includes an ecosystem of partner offerings, not a claim that all surrounding software businesses disappear. “Own your AI” is most useful as an operational test: can you change the model, control data destinations, revoke credentials, export evidence and move the workload? A cloud deployment can preserve those options. A self-hosted deployment can still depend heavily on one vendor. Neither location guarantees that a model follows your interests. Before buying more GPUs, identify whether the bottleneck is capacity, inference, permissions or verification. Wavect's [AI engineering work](/services/artificial-intelligence/) can help separate those decisions. The [Twinsoft AI case study](/case-studies/twinsoft-ai/) illustrates application delivery, not a Run:ai deployment. Use our [software QA checklist](/software-development-guide/software-qa-checklist-before-launch/) for release criteria, or [discuss your GPU and agent workflow](/contact/) with us. ## Open-source Run:ai and software-factory FAQ ### What did NVIDIA open-source in October 2026? On 13 October 2026 NVIDIA announced the full Run:ai platform, beyond the previously open KAI Scheduler. The release includes an integrated platform and independently adoptable scheduling, GPU fractioning, resource-management and workload-description components. ### Does open-source Run:ai require a paid license? The platform code is published under Apache-2.0 with separate third-party notices. NVIDIA says its NGC Community Product needs no paid Run:ai subscription, but downloading that distribution requires its applicable terms. Enterprise support is not included, and infrastructure and operations still cost money. ### What is the difference between Run:ai and KAI Scheduler? KAI Scheduler decides how workloads receive cluster resources. The complete Run:ai platform adds control-plane services, workload management, organizational policies, identity, access and observability. A team can adopt a component without adopting the entire platform. ### Is GPU fractioning the same as MIG? No. MIG creates hardware-partitioned instances on supported GPUs. CUDA-native fractioning enforces supported GPU-memory limits through the driver. Ordinary time-slicing is different again and does not provide MIG-equivalent memory or fault isolation. ### Can fractioning make a larger model fit on a smaller GPU? No. Dividing GPU memory does not add physical capacity. Model weights, runtime allocations and cache still need to fit the available memory. Compression and distributed inference are separate techniques. ### Does Run:ai replace CI/CD or software verification? No. GPU allocation and workload governance do not prove that a patch satisfies requirements. Keep protected tests, evidence, review and release authority in the software-delivery layer. ### What is ESF, and is its Run:ai integration production-ready? The referenced ESF is Engineering Software Factory, an independent MIT-licensed project using Temporal and CubeSandbox for coding-agent workflows and evidence. Its reviewed README describes 0.6.2 as a release candidate. We did not verify a supported Run:ai adapter or a jointly qualified deployment. ### Does every Run:ai installation include OPA policies? Do not assume so. The reviewed identity guide describes Gatekeeper as an optional cluster-level control for non-OpenShift Kubernetes. Run:ai also has its own workload policies and RBAC. Verify the controls actually installed and their enforcement paths. ### Should a small API-only team deploy Run:ai? Usually not as its first investment. Run:ai is relevant when shared Kubernetes GPU capacity and organizational allocation are material problems. An API-only workflow may benefit more from better task scoping, model routing and verification. ### Does self-hosting guarantee that you own your AI? No. Evaluate whether you can change models, control data destinations, revoke credentials, export evidence and move workloads. Either cloud or self-hosted systems can preserve or restrict those options. ## Final thoughts Use Run:ai to govern scarce GPU capacity. Use independent gates to decide whether generated changes deserve acceptance. Open source makes the first layer inspectable; it does not make the second layer optional. ## You may also like.. [**vLLM and Triton: the model-serving layer** Choose the inference runtime separately from the scheduler that allocates its GPUs.](/blog/netflix-vllm-triton-inference-stack/) Architecture and platforms ## Read next Framework, platform and system-design choices that affect delivery over the long term. [Start here**Smart City Architecture Best Practices: MQTT, LoRaWAN, Kubernetes and Terraform**](/blog/smart-city-architecture-best-practices-2026/) - [GitButler for Parallel AI Agents: Multiple Branches, One Build](/blog/gitbutler-parallel-ai-agents-one-workspace/) - [Vendo for SaaS: Tenant Isolation and Approval Boundaries](/blog/vendo-saas-tenant-isolation/) - [AgentMail for SaaS: Tenant Isolation and Duplicate-Send Recovery](/blog/agentmail-saas-duplicate-sends-recovery/) - [AI Coding and the Software Moat: Who Runs What You Build?](/blog/ai-coding-software-moat-operations/) - [Shopify B2B Order Approvals: Native Features, Apps, or a Custom Buyer Portal?](/blog/shopify-b2b-order-approval-workflow/) [Next article**GitButler for Parallel AI Agents: Multiple Branches, One Build**](/blog/gitbutler-parallel-ai-agents-one-workspace/) [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min read · 15 Oct 2026 Last reviewed October 15, 2026 [**Next**](/blog/netflix-vllm-triton-inference-stack/)