On 11 November I gave my session “GPUs Take Flight: Multi-Tenant Platform Engineering at Scale” twice at Red Hat Summit: Connect 2026 in Nieuwegein, at 12:30 and at 15:00, fifteen minutes each, in Theater 1, the Dell & ITQ silent theater. The silent theater agenda has the abstract: “Discover real-world platform engineering patterns for managing GPU workloads in multi-tenant Red Hat OpenShift environments. Learn scalable architecture and operations strategies to optimize resource sharing, secure multi-tenancy, and accelerate enterprise AI deployments.”
On screen, the deck was “Multi-tenant GPUs on Bare Metal OpenShift AI: A GitOps Blueprint from the Trenches”, with the Dell Technologies and Intel logos.
“It runs” is not “it’s safe to share”
The opening slide listed what we actually avoided from day one:
- Noisy neighbors hoarding GPU memory, and so latency spikes
- Queue explosions: jobs starving, “random wins” scheduling
- MIG misfit: some workloads thrived, others crawled
- Driver drift: proprietary kernel modules and firmware mismatch
- Network chaos: SR-IOV misconfigured, RDMA failures
Its last line: “We needed guardrails. We needed a GitOps-driven framework.”
Bare metal, no safety net
The environment: a Dell AI Factory bare-metal cluster, PowerEdge R660 control plane, R670 CPU nodes and ESXi, XE7740 GPU workers; PowerScale scale-out NAS with RDMA on OneFS; the latest OpenShift and OpenShift AI with the GPU and Network Operators and Run:AI; air-gapped, with a local Quay mirror and no public registries. “Every layer is ours to manage.”
Three personas, one platform
The rule on the slide: if any one persona loses, adoption collapses.
- End-user: “Give me a GPU fast, keep my latency stable”
- LLMOps: “Repeatable across environments deploys, safe upgrades, full observability”
- Tenant admin: “Enforce my boundaries, show me the bill”
Everything is code, and auditable
Argo CD, OpenShift GitOps, is the single source of truth. One repository: cluster-config/ with base/operators/ (GPU Operator, Network Operator, SR-IOV), base/infra/ (StorageClasses, network) and overlays/prod/ (patches: quotas, OAuth), then applications/ (Helm apps with per-environment values) and argocd/ (root apps and ApplicationSets). Every change goes the same way: Git commit, pull request, Argo CD sync, platform.
From bare metal to GitOps
Ansible does the initial handshake, in four steps: install the GitOps Operator (OLM), register the Git repository in Argo CD, apply the root app and the ApplicationSets, and Argo CD takes over for day 2. Air-gapped, the bootstrap also brings an ImageDigestMirrorSet for the mirrored registries, local CatalogSources (the Red Hat and certified indexes), and the Quay CA trust and pull secrets.
Multi-tenant networking
Keepalived (VRRP, master and backup) in front of HAProxy and its virtual IPs, then a NodePort per tenant, then the OpenShift ingress. SR-IOV virtual functions isolate the NICs, with per-tenant network QoS, and each tenant has its own HAProxy log, /var/log/haproxy-<tenant>.log.
Efficient GPU use at scale
The second part, “Efficient GPU use at Scale with OpenShift”, moved from the slides to the platform’s own screens, and to who it is for. One journey on screen: Mark, a Python developer, who needs an internal coding assistant “so I can be more productive while being compliant with internal policies”. The self-service experience has a lead time of one hour: access granted to the endpoints, self-service, set up the coding assistant. Underneath are the GenAI products (RAG, the coding assistant, custom services, a data scientist IDE with Jupyter notebooks), model serving and inference, model development, training and tuning, a model registry, and the GPU infrastructure.
Seven guardrails you can apply today
| # | Guardrail | How |
|---|---|---|
| 1 | GitOps-first | Argo CD + Kustomize |
| 2 | Tenant template | Namespace + RBAC + NetworkPolicy + VIP |
| 3 | Quotas and limits | GPU, CPU, memory |
| 4 | SR-IOV per vendor | NICs |
| 5 | Open modules | DMA-BUF GPU stack |
| 6 | Observability SLOs | Queue, latency, saturation |
| 7 | Upgrade playbook | Matrix, canary, rollback |
When it works
The last slide: multi-tenant GPUs on bare metal work when safety is provable (enforced by RBAC, NetworkPolicy and quotas, in Git), fairness is explicit (encoded in priorities and preemption, through Argo CD) and efficiency is measured (tracked per tenant, per GPU-hour).
The same experience report went to Red Hat Summit 2026 in Atlanta, KubeCon Europe 2026 and the Platform Engineering Meetup NL. The rest of the day, from the keynote to the breakouts, is in my notes from Red Hat Summit: Connect.
