dsx-ai-factory/run-ai

What it does

NVIDIA Run:ai is an open-source AI workload and GPU orchestration layer that runs on Kubernetes or OpenShift. It adds GPU-aware scheduling, fractional GPU allocation, quota hierarchies, multi-cluster management, and observability on top of native cluster scheduling, aimed at organizations that share a GPU estate across teams and projects. It sits above Kubernetes rather than replacing it, and complements tools such as the NVIDIA GPU Operator, Kubeflow, Ray, and Argo Workflows; it ships the KAI Scheduler for fair-share, preemption, and topology-aware placement (architecture overview).

The monorepo holds the control plane, the per-cluster services, the installer CLI, generated clients and shared Go libraries, a load-test suite, documentation, an MCP server, and a local development environment (repository map). If you only need one team's jobs on dedicated GPUs, native Kubernetes scheduling may already be enough.

Try it locally

The local environment builds the control plane and cluster services from source and deploys them into a self-contained Kind cluster with a local image registry. Prerequisites are Docker or Podman, make, git, curl, python3, openssl, plus minimum CPU/RAM/disk; kind, kubectl, and helm are installed automatically, and Go, Node, and Java are not required on the host because builds run in containers (local development guide).

From the repository root:

./local-dev.sh

This performs the full build, cluster creation, and deploy. Subsequent cycles can reuse the build and cluster:

./local-dev.sh --skip-build --skip-cluster   # re-deploy only
./local-dev.sh --teardown                    # tear the environment down

To change a single service, use its own directory's Makefile targets (make build, make test, make lint, make validate) as described in the service reference.

Production installation

NVIDIA Run:ai deploys on Kubernetes or OpenShift, connected or air-gapped. Check the support matrix and system requirements first. The recommended path is guided installation using the runai-installer CLI with a configuration YAML file; it runs preflight checks, installs dependencies, and deploys both the control plane and cluster. Teams managing deployments through their own tooling such as Argo CD can use the manual Helm path instead. Released images are published on nvcr.io/nvidia/runai-oss and Helm charts at https://helm.ngc.nvidia.com/nvidia/runai-oss, which are the default sources used by the installer and charts.

Constraints

• The root Makefile targets are placeholders; build, test, and lint targets live in each service directory.
• The full CI gate runs remotely and is reported on pull requests as the Validate Successful Run check, so local validation differs from the merge gate.
• Production deployment requires a supported Kubernetes/OpenShift version, GPU and network operator setup, and networking/access preparation; air-gapped installs need a reachable image and chart source.
• Code is Apache-2.0, but the license does not grant rights to NVIDIA or Run:ai trademarks, logos, or brand assets; some vendored subdirectories carry separate licenses.

HotRepo's take

The project's only recorded appearance here is on the 2026-11-10 Go daily list at position 14, with 5 stars gained that day and 728 stars total. That is a single snapshot of the Go language ranking, not a trend, and the all-language daily rank is unknown, so there is not enough same-basis history to say anything about momentum. What the data does show is a large, structured monorepo with a real control plane, cluster controllers, installer, and load-test suite rather than a thin wrapper — the kind of infrastructure project whose value depends on cluster scale and team governance needs rather than on star velocity.