GPUs are usually the most expensive line on an AI platform's bill, and for a long time Kubernetes managed them crudely. A pod asked for one GPU, got a whole one, and nobody could easily say "an H100 if you have one, otherwise an A100" or "a slice of a GPU is enough". Dynamic Resource Allocation, or DRA, fixes that, and the last two Kubernetes releases moved it from interesting to usable.
From counters to devices
The old model exposed accelerators as extended resources: a count per node. DRA replaces that with ResourceClaims. Drivers publish devices with attributes, and workloads request devices that match criteria. The Kubernetes project describes DRA as fundamentally changing how administrators handle accelerators and specialised resources1.
The features that matter for AI platforms
| Feature | Status | Why it matters |
|---|---|---|
| Prioritised list | Stable in v1.36 | Request a preferred GPU with fallbacks, so jobs run on what is available instead of queueing1 |
| Partitionable devices | Beta in v1.36 | Carve one physical accelerator into smaller logical instances, such as multi-instance GPUs, and share it safely1 |
| Device taints and tolerations | Stable in v1.37 | Keep faulty devices out of use, or reserve hardware for specific teams12 |
| Extended resource support | Stable in v1.37 | Existing workloads keep working while the cluster moves to DRA2 |
| ResourceClaims for workloads | Beta in v1.37, off by default | One claim shared across a whole group of pods, useful for distributed training2 |
Version 1.37 also brings a standard NUMA node attribute and, in alpha, derived attributes using CEL expressions, which help pair devices from different vendors, such as a GPU and a network card on the same NUMA node2.
What this means for cost
Three of these features translate directly into money:
- Fallbacks raise utilisation. Jobs that can run on an older GPU don't sit idle waiting for the newest one.
- Partitioning stops over-allocation. An inference service that needs a fraction of a GPU no longer reserves a whole device.
- Taints make reservation explicit. Expensive hardware set aside for training or experiments is visible and enforced, not tribal knowledge.
Combined with HPA scale-to-zero for queue-driven GPU workers, which also arrived in v1.373, this is the toolkit I'd use to bring a GPU bill under control. The broader approach is in my Kubernetes FinOps playbook.
Measure before and after. GPU utilisation per team and cost per thousand inference requests are the two numbers that show whether the change worked.
A gradual adoption path
- Upgrade and install a DRA driver for your accelerators, and confirm which features your driver supports.
- Turn on extended resource support so existing pod specs keep working unchanged2.
- Move one workload class to ResourceClaims, ideally batch inference, and add a prioritised list of acceptable devices.
- Introduce partitioning for small inference services, with load tests to confirm latency holds.
- Taint reserved and suspect hardware, and give the owning teams tolerations.
- Treat beta and alpha features with care. Some are off by default, and their behaviour can change between releases.
Where this fits in an AI platform
DRA is the scheduling layer. Above it you still need an AI gateway for routing and governance, evaluation to decide which model size is good enough, and observability to see cost per request. In practice the biggest savings often come from realising a smaller model on a partitioned GPU does the job, which is a question for your evaluation set, not your scheduler. I've been exploring the same trade-offs on local hardware, as described in my notes on private LLMs.
How I can help
I design AI platforms on Kubernetes, from GPU scheduling and cost controls to gateways and evaluation. See my AI architecture work, or analyse your challenge and bring the result to a call.
- 1Kubernetes v1.36: More Drivers, New Features, and the Next Era of DRAKubernetes blog · 7 May 2026
- 2Kubernetes v1.37: DRA UpdatesKubernetes blog · 3 Sep 2026
- 3Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscalerKubernetes blog · 2 Sep 2026
- 4Kubernetes v1.37 releaseKubernetes blog · 26 Aug 2026