Run:ai manages shared GPUs; our run covered its MCP server
NVIDIA Run:ai puts a management layer around shared Kubernetes GPU infrastructure. Its README describes quotas across departments and projects, workload scheduling and centralized monitoring. Those capabilities are relevant when several teams share capacity and administrators need organizational resource policies.
Our successful sandbox result concerns a narrower part of that system: the Go project in runai-mcp-server/. This component exposes Run:ai control-plane operations to AI assistants through Model Context Protocol. Passing its recorded checks provides a starting point for evaluating the adapter. It does not establish that the Kubernetes platform was deployed or that GPU resources were shared correctly.
A platform team has two separate decisions: whether it needs Run:ai's management model and, if it already uses Run:ai, whether to connect an assistant to its operations. Assistant access introduces credentials and tool permissions that a successful Go build cannot settle.
What happened when we ran it
Our November 10, 2026 sandbox run installed the Run:ai MCP server project in 25 seconds, built it in 148 seconds and completed its test step in 72 seconds. At commit 036acf6, the recorded Go summary reported 20 passed and zero failed out of 20. Installation recorded 165 dependencies.
The measured project lived in ./runai-mcp-server/. The checkout around it was much larger: 29,075 files, approximately 3,461,975 source lines and 310 MB. Those checkout figures describe the monorepo, not the adapter's own implementation or installed dependencies.
The sandbox configuration listed 3 CPUs, 8 GB RAM and image golang:1.24-bookworm. Raw toolchain logs were not supplied to establish the actual Go or operating-system version. The record also contains no live control-plane request, deployed cluster, GPU allocation exercise or throughput benchmark. The passing summary provides no test-by-test inventory from which to infer those checks.
The scan found 32 CI workflow files and a Dockerfile, with no tests directory detected. That directory signal does not contradict the recorded passing Go tests. No vulnerability-audit result accompanies the supplied measurements.
The platform requires Kubernetes and separate operating components
The README divides Run:ai into a control plane and cluster services, both installed on Kubernetes. The control plane manages organizational resources and connected clusters. Cluster services handle scheduling and workload management where jobs run. Platform evaluation therefore requires a team that operates Kubernetes or intends to take on that responsibility.
The root documentation offers guided installation through a configuration YAML file and manual Helm deployment. It also describes a local Kind environment that builds services in containers. None of those paths was exercised by our MCP-server run. For a single team's jobs on dedicated GPUs, the README says native Kubernetes scheduling may be sufficient.
The repository warns that root Makefile targets are placeholders and directs developers into individual service directories. To reproduce component checks, identify the service first: a root-level command does not establish that the intended service was checked.
The MCP adapter needs a control plane and an authentication choice
The component README requires a Run:ai control-plane base URL. Its default stdio transport uses a service-account client ID and secret through environment variables. The documentation says credentials are not accepted on the command line. Obtaining an appropriately scoped account remains an operational prerequisite outside our sandbox evidence.
For HTTP mode, the README says the MCP client obtains a Bearer token from the Run:ai identity manager and presents it on each request; the server validates the token and forwards it downstream. HTTP therefore leaves the client responsible for obtaining and presenting the token. Our run did not verify identity discovery, token validation or authorization against a real deployment.
Write tools are disabled by default in the documented configuration. Evaluate inspection access before enabling tools that mutate Run:ai state. Our recorded checks do not establish which production permissions a particular account receives.
The README includes Claude Code and Cursor configuration examples, but their container image names use registry.example.com. Those examples require a verified replacement artifact. They do not establish client compatibility, and our run did not test those configurations.
KAI Scheduler and Kueue offer other evaluation paths
KAI Scheduler documents GPU sharing and hierarchical queues. Its README describes quotas, limits, priorities and fairness policies across multi-level queue hierarchies. Evaluate it when scheduling policy is the requirement and the broader Run:ai management layer is unnecessary. Run:ai's own README says it ships KAI Scheduler, so this is partly a component-versus-platform choice.
Kueue documents queueing and scheduling alongside kube-scheduler and job controllers. Consider it when admission, quotas and job integration fit the problem you need to solve. These are infrastructure evaluation paths; this record contains no comparative setup or scheduling-performance measurements.
What remains unassessed
GitHub metadata records a November 11, 2026 push; the supplied issues listing shows issues opened on November 10. This does not establish support responsiveness. Community support and production maturity remain unassessed, alongside setup ease for the full platform.
Documentation receives 3/5 on our editorial scale: 1 means missing basic instructions, 3 means a usable documented path with material gaps and 5 means detailed guidance verified in operation; 2 and 4 fall between. The component map and authentication instructions support the rating, while placeholder client artifacts require resolution and live operation remains unverified. This rating assesses the supplied documentation, not deployment success.
For an existing operator, the next useful check is an authenticated read through the MCP adapter against a nonproduction control plane. A team selecting the full platform needs a separate cluster trial of its quota and workload policies.