In this piece
NVIDIA Run:ai Open Source: GPU Fleet vs Software Factory
Reviewed 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.
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.
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 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.
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.
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.
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.
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.
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.
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.
| 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. 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.
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.
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.
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 covers the broader workflow layer. Our Google AX review 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.
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 can help separate those decisions. The Twinsoft AI case study illustrates application delivery, not a Run:ai deployment. Use our software QA checklist for release criteria, or discuss your GPU and agent workflow with us.
Open-source Run:ai and software-factory FAQ
What did NVIDIA open-source in October 2026?
Does open-source Run:ai require a paid license?
What is the difference between Run:ai and KAI Scheduler?
Is GPU fractioning the same as MIG?
Can fractioning make a larger model fit on a smaller GPU?
Does Run:ai replace CI/CD or software verification?
What is ESF, and is its Run:ai integration production-ready?
Does every Run:ai installation include OPA policies?
Should a small API-only team deploy Run:ai?
Does self-hosting guarantee that you own your AI?
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.