tenantplaneBook a demo
Menu

GPU orchestration for Kubernetes

Your GPUs.
Easy to share.

One console for training jobs and model serving, on the Kubernetes scheduler you already run. Kueue handles quotas, llm-d routes inference, and every team sees exactly what is happening.

Book a demo Try the interactive demo
Native kube-schedulerKueue quotasllm-d serving
A light console window, a translucent glass cluster, and a dark GPU panel connected by one path.
Your
teamsYour Kubernetes cluster(cloud or on-premises)Your GPUs(jobs and models)
Native Kubernetes scheduling

No replacement scheduler

Fair-share GPU quotas

Guaranteed, borrowable, preemptible

LLM serving built in

vLLM behind llm-d’s router

Nothing to rip out

Standard Kubernetes objects

Why platform teams switch

The scheduler is solved.
Using it isn’t.

Kueue and the Kubernetes scheduler are becoming the standard way to share GPUs. The experience around them is still kubectl, YAML and dashboards that say a pod is Pending without saying why.

01

Pending, with no reason.

Researchers wait on jobs nobody can explain, and platform engineers become the help desk for every quota question.

02

Quotas in spreadsheets.

Borrowing is invisible, so teams hold on to GPUs. Expensive hardware sits idle while work waits in line.

03

Serving as a side project.

Every model needs its own deployment, routing and dashboards before anyone can call it.

The console

Built so nobody has to
ask the platform team.

Four pages: Overview, Jobs, Models and GPUs. Every status is one sentence that says what is happening and what would change it.

Open the interactive demo
The Tenantplane overview: 40 of 48 GPUs in use, a map of every GPU by what it is doing, utilization over 24 hours, team quotas, running work and recent activity.
Queues you can read

Every pending job explains itself.

Not “Pending”. Instead: “Waiting: needs 16 GPUs, 8 free for research right now. #1 in line.” Kueue’s admission state, translated into the one thing that would unstick it.

  • Place in line, per team
  • What it’s waiting for, in GPUs
  • Placement problems called out separately from quota
A waiting job in the Tenantplane console showing it needs 16 GPUs, 8 are free for its team, and it is first in line.
No surprises

Know the outcome before you submit.

An image, a command and a GPU count. Before you click, the console predicts whether the job starts now, waits in line or can never fit, using the same quota rules Kueue enforces. Then it shows exactly what will happen, step by step.

  • Impossible jobs blocked up front
  • Sensible defaults with the reason shown
  • The exact API call behind every action
The new job form with a forecast that the job starts right away and a panel explaining each step from access check to Kueue, the Kubernetes scheduler and completion.
Model serving

A model endpoint from one field.

Name a model. vLLM serves it, llm-d’s router sends each request to the replica with the best cache hit and the shortest queue, and you get an OpenAI-compatible endpoint with latency, cache and live logs.

  • Scale replicas with one click
  • Multi-node models on LeaderWorkerSet
  • Optionally queue serving under team quotas
A model served on two replicas with request count, latency, time to first token, KV cache use, a prompt box and live vLLM logs.
Capacity

See where every GPU goes.

Each team has a guaranteed share and can borrow what others leave idle. Borrowed GPUs go back when their owner needs them. One page shows who has what, who is using it and what is free.

  • Guaranteed and borrowed GPUs per team
  • Priorities that can preempt
  • Utilization history from your cluster’s metrics
The GPUs page showing physical capacity and per-team guaranteed, used and borrowed GPUs.

Ask in plain language

“Why is pretrain-3b waiting?” is answered from live cluster state, by the same rules the pages use. Nothing is guessed.

Your access rules apply

Run:ai’s role-based access control decides who can view, submit or serve. Tokens stay on the server, never in the browser.

Distributed training

PyTorch, TensorFlow, XGBoost and MPI jobs are gang-admitted, so a job’s workers start together or not at all.

Every click is an API call

Each action shows the request it makes. Anything done in the console can be scripted or run from CI.

Architecture

Open standards underneath.
A console on top.

Tenantplane doesn’t sit in the scheduling path. It reads and writes the same Kubernetes and Run:ai objects your platform already uses, so you keep every upstream improvement and nothing gets locked in.

Questions platform teams ask
  1. 01
    Tenantplane consoleJobs, models, GPUs and activity, in plain language.
  2. 02
    NVIDIA Run:ai control planeOpen source. Projects, access control, audit and the workload APIs.
  3. 03
    KueueQuotas, borrowing, priorities and all-or-nothing admission.
  4. 04
    kube-schedulerThe default Kubernetes scheduler places every pod. Unchanged.
  5. 05
    llm-d and vLLMInference routing and model serving.
  6. 06
    Your GPUsAny cloud or on-premises Kubernetes cluster with NVIDIA GPUs.
Tested, not assumed

Verified against
a live cluster.

An end-to-end suite runs against a real Kubernetes cluster with Kueue, llm-d and the Run:ai control plane installed, and browser tests drive every screen of the console.

End-to-end checks on a live cluster
72
Replacement schedulers installed
0
Workload kinds gang-admitted
5
Lines of YAML to submit a job
0

Covered: quota admission and borrowing, preemption by priority, all-or-nothing admission of distributed PyTorch jobs, jobs that can never fit, llm-d request routing, multi-node serving on LeaderWorkerSet, and role-based access for every write.

For platform and infrastructure leads

Questions we get asked.

Still deciding? We’re happy to walk through your cluster and how it would map onto teams and quotas.

Do we have to replace our scheduler?

No. Pods are placed by the default Kubernetes scheduler. Kueue decides when work is admitted, based on quotas and priority, and is a Kubernetes SIG project. No KAI, Volcano or other replacement scheduler is installed.

What happens to our workloads if we stop using Tenantplane?

They keep running. Everything the console creates is a standard object: Jobs, PyTorchJobs, LeaderWorkerSets, Kueue ClusterQueues and LocalQueues. You can inspect and manage all of it with kubectl.

Where does our data go?

Nowhere new. Tenantplane runs in your cluster, next to your workloads. Sign-in tokens are kept server-side in an encrypted session, and every request is checked against your existing access rules.

Which workloads does it handle?

Batch and training jobs; distributed PyTorch, TensorFlow, XGBoost and MPI training with gang admission; and LLM serving with vLLM behind llm-d, including models that span several machines.

Which hardware is supported?

NVIDIA GPUs exposed through the NVIDIA device plugin or GPU Operator, on any conformant Kubernetes cluster in the cloud or on-premises. Quotas are defined per GPU type, so mixed fleets get separate shares.

How do you know it works?

An end-to-end suite runs 72 checks against a live Kubernetes cluster: quota admission, borrowing, preemption, gang-scheduled distributed training, llm-d routing and multi-node serving. Browser tests drive every screen.

How do we get started?

Book a walkthrough. We look at your cluster, teams and workloads, then install Tenantplane alongside your existing setup and hand it over with your quotas configured.

See it on your cluster

Let your teams share GPUs
without the help desk.

Book a 30-minute walkthrough. We’ll look at your GPUs, teams and workloads,
and show how Tenantplane would run them.

Book a demo Or try the interactive demo