NVIDIA opened Run:ai. The source code needs an independence test

THE SIGNAL IN ONE SENTENCE

Opening the hood is useful. It is not the same as handing over the keys. On October 13, NVIDIA released the full Run:ai platform as open source. The company also published four pieces that can be used separately: KAI Scheduler, GPU Fractioning Operator, KAI Resource Management and Workload Map. Run:ai is the control layer that decides how scarce accelerator capacity gets shared across teams and jobs. It sits around Kubernetes and OpenShift clusters, where it can schedule workloads, enforce quotas, divide GPU capacity, coordinate multiple clusters and show administrators what is running. That is consequential infrastructure. A queueing rule can decide which research project starts today and which waits until Friday. A quota can protect one team from a noisy neighbor or quietly preserve an old organizational hierarchy. An upgrade can improve utilization or turn the cluster into an expensive sculpture garden. NVIDIA calls the release an open foundation for AI factories. The code is now visible in a public monorepo under Apache 2.0, with additional licenses for some nested material. The repository includes the control plane, in-cluster operators and controllers, shared libraries, clients, an installer and local development tooling. NVIDIA also offers a community product through its NGC catalog as a Helm chart. This is a real improvement over a closed control plane. Developers can inspect implementation choices, report bugs, study interfaces, propose changes and build a fork. Security teams can review more of the machinery that allocates valuable compute. Operators can adopt individual components instead of swallowing the entire platform. But the plain signal is that visible source is the beginning of independence, not proof of it. An operator is independent only when it can build the system from source, deploy it in a clean environment, understand every required binary and service, operate it without an undisclosed vendor dependency, export its policies and history, upgrade on its own schedule, recover from failure and migrate away without rebuilding the organization from memory. That is a much harder test than opening a repository. Start with the clean-room build. Take a fresh machine with no NVIDIA account state, no internal company network and no cached artifacts. Follow the public instructions exactly. Record every package, container image, chart, registry, license prompt, token and manual intervention. Hash the outputs. Compare them with the published artifacts. The root repository currently explains that the monorepo contains many services and that the top-level Makefile exposes placeholders while real build targets live within individual services. It also says the complete continuous-integration gate runs remotely. That is not a scandal. Large projects often take time to make a friendly public build path. It is a useful independence test because it shows where a fork may still depend on institutional knowledge, remote automation or artifacts maintained elsewhere. Next, draw the dependency map. The source repository is Apache 2.0, but operators should inspect every nested license and artifact. The README notes that some bundled material carries other licenses and that the license does not grant trademark rights. The NGC community product requires acceptance of NVIDIA's software agreement and product-specific terms. It does not require a paid subscription or support entitlement, but it also does not include enterprise support. Those are different layers of freedom. The source license governs what people can do with code. Registry terms govern access to packaged artifacts. Trademark rules govern naming. A support contract governs who answers at 3 a.m. None should be smuggled into the word open as if it were one switch. Build the source-only path and the packaged path separately. If the source path fails without an NGC artifact, say so plainly. If a team can replace that artifact, document how. If the community build depends on a proprietary driver, service or control endpoint, put it on the architecture diagram. Then test portability without pretending that all portability is the same. Run:ai targets Kubernetes and OpenShift, including connected and air-gapped environments. That is platform portability within a defined world. Key components are also designed around NVIDIA GPUs, CUDA and NVIDIA's device-management stack. GPU Fractioning, for example, uses CUDA 13.4 native fractioning to let workloads share a GPU with enforced memory boundaries. Open source does not magically turn hardware-specific engineering into hardware neutrality. Teams should ask two separate questions. Can this control plane move between supported Kubernetes environments? Can its policies, workload definitions and operational history move to a different accelerator stack? The first may work well. The second needs evidence, adapters and honest documentation. Do not mark a check box called portable after moving a Helm release from one NVIDIA cluster to another. The scheduling layer deserves its own test. KAI Scheduler is an Apache 2.0 project in the Cloud Native Computing Foundation Sandbox. NVIDIA says it supports gang scheduling, quotas, fair-share allocation, topology-aware placement, bin packing, GPU sharing and Kubernetes Dynamic Resource Allocation. Those features sound technical, but they encode policy. Create synthetic tenants with unequal demand. Give one team urgent work, another a guaranteed quota and a third a bursty queue. Measure wait time, preemption, starvation, utilization and recovery. Change the priority policy while jobs are running. Confirm that an administrator can explain why one workload moved ahead of another. Fair share needs receipts. A scheduler can reach high utilization while repeatedly delaying the same users. It can honor quotas while wasting fragmented capacity. It can look fair on average and remain unfair during the hours that matter. Publish workload traces, policy files and results so another operator can reproduce the behavior. Isolation needs sharper evidence than a diagram. If several jobs share one GPU, test memory boundaries, process crashes, denial-of-service behavior, observability and cleanup. Try incompatible frameworks and long-running jobs. Kill a workload during allocation. Exhaust memory on purpose. Verify what one tenant can infer about another tenant's usage. Repeat after upgrades. NVIDIA's October 13 post describes capabilities and ecosystem integrations. It does not provide independent evidence that every configuration preserves security, performance or isolation. That is normal for a launch post. It is also why deployment teams should not treat the post as a validation report. Next comes the exit drill. Export queues, quota definitions, access policies, projects, users, audit history, utilization records and workload metadata in documented formats. Restore them into a fresh instance. Then translate the important parts into a competing scheduler or a plain Kubernetes setup. Time the work. Count the records that lose meaning. Note any policy that exists only in a vendor-specific object. Record how many scripts or manual fixes are required. An exit path that works only after three engineers reverse-engineer an undocumented database is not an exit path. It is an archaeological dig. Upgrades need the same discipline. Pin every component version. Publish compatibility matrices for Kubernetes, OpenShift, drivers, CUDA, GPU Operator and Helm charts. Test a version jump, a failed migration and a rollback with live queues. Verify whether community maintainers can produce security patches without waiting for an internal release process. Governance may be the hardest independence test. Apache 2.0 permits forks, but legal permission does not create a functioning community. Track who can merge code, publish releases, rotate credentials, manage security reports and decide the roadmap. Count maintainers by employer. Measure how long outside pull requests and vulnerability reports wait. Look for public design discussions, release criteria and a process for disagreements. The public monorepo says issues, releases and support status are tracked in the open, while a long-range roadmap is not yet published. That is a reasonable starting point. The next signal will be whether outside participants can shape the project rather than merely observe NVIDIA shaping it. There is a practical way to adopt the release without betting the cluster. Choose one noncritical pool and one representative workload mix. Build from source. Run the packaged community product separately. Apply identical scheduling policies. Compare utilization, wait time, failed jobs, operator effort and recovery time with the current system. Preserve a rollback path. Keep the existing scheduler ready until the new stack survives a failure, an upgrade and an export. Use the modular release as intended. A team may need the scheduler but not the full control plane. Another may want Workload Map for visibility. A third may test resource-management APIs without adopting GPU fractioning. Smaller adoption surfaces are easier to understand, secure and replace. The open-source release gives infrastructure teams something valuable: the right to look, test, change and fork. Now the community has to exercise those rights. Build it without secret knowledge. Run it without hidden services. Break it under realistic load. Patch it without waiting for permission. Move the data out. Replace a component. Let an outside maintainer influence a release. If those tests pass, Run:ai will be more than source available for inspection. It will be infrastructure that operators can genuinely own. The hood is open. Now ask who still holds the keys.