GPU Operator, Kueue, multi-tenant
GPUs shared cleanly across your teams, with zero waste
A GPU at 30% utilization is an expense, not an investment. A well-designed Kubernetes farm isolates teams, enforces quotas and pushes real fleet utilization to the maximum.
Use cases
- Internal AI platform shared across data science and product teams
- Production inference: autoscaling, rolling updates, high availability
- On-demand GPU development environments (notebooks, jobs)
- Multi-customer platform for SaaS vendors and AI service providers
Reference architecture
- GPU
- NVIDIA GPU Operator: drivers, device plugin, DCGM monitoring and time-slicing / MIG for fine-grained sharing.
- Scheduling
- Kueue or Volcano for batch queues, team quotas and controlled preemption.
- Multi-tenant
- Namespaces, RBAC, network policies and, if needed, virtualized control planes per tenant.
- Platform
- GitOps (Argo CD), private registry, ingress, cert-manager and Prometheus / Grafana observability.
What you receive
- 01
Hardened GPU Kubernetes cluster, versioned with GitOps
- 02
Quotas, queues and per-team isolation configured
- 03
GPU utilization dashboards per team and per project
- 04
Runbook, training and full handover
FAQ
- Can Kubernetes replace Slurm for training?
- For inference and single-node jobs, yes, without reservation. For large-scale multi-node training, Slurm keeps the native gang scheduling advantage; Kueue and Volcano close the gap at intermediate scales. We size it based on your jobs.
- Do you handle strict multi-tenancy between customers?
- Yes: network isolation, dedicated control planes per tenant when necessary, hard quotas and consumption-based billing. That is the foundation of the multi-customer AI platforms we deploy.