When teams share a GPU across three pods using time-slicing or multi-process service, NVIDIA's DCGM exporter reports that all three pods are consuming the entire GPU, creating the illusion of 300% utilization on hardware that doesn't exist, according to a technical analysis published by The New Stack. The report examines how GPU workloads on Kubernetes platforms force engineering teams to rebuild nearly all the resource visibility, cost allocation, and guardrails they've relied on for CPU and memory for years. Almost every assumption about tracking what a container requested versus what it used falls apart when the workload runs on a GPU, the analysis finds.

The kernel automatically tracks CPU and memory usage per container, making per-pod metrics essentially free, but GPUs don't provide that data. The DCGM exporter reports at the physical device level by default, which works when one pod has exclusive access to a GPU but becomes misleading the moment multiple pods share the same hardware through time-slicing or multi-process service. The driver exposes a single set of counters for the entire GPU, so DCGM can't distinguish which workload consumed what, and teams end up building dashboards and reports on values that are wrong but difficult to spot. GPU utilization metrics tell teams that a kernel was running on the GPU during some portion of the sample window, but won't reveal how much of the actual compute or memory bandwidth was used, allowing GPUs to sit at 100% utilization while the compute does almost nothing. Memory often runs out first because frameworks like vLLM claim most of the GPU at startup regardless of need.

The report states that the basic rightsizing premise of comparing what a workload requested against what it's using barely exists for GPUs when teams start. Kubernetes treats GPUs as whole-number resources where request and limit must match, with no overcommitting at the scheduler, so the fractional sharing needed for inference happens underneath the scheduler through time-slicing or multi-instance GPU partitioning, and Kubernetes requests don't map cleanly. According to the analysis, NVIDIA's NVML library will report per-process memory usage on a GPU that can be traced back to the pod and team, and those numbers are reliable except that they won't add up to the card's total because the driver reserves memory for itself. Compute attribution falls apart entirely: when jobs run side by side to improve utilization, nothing available today will show which team burned 70% and which burned 30%, so the practical decision is to bill on memory where the data holds up and treat compute as a signal to inform chargeback conversations.

The report explains that GPU costs run far higher per hour than CPU costs and are much harder to split per workload, with cloud providers billing a GPU node as one line item that lumps CPU, memory, and GPU together. On AWS, the cheapest multi-instance GPU compatible A100 costs $22 per hour, roughly $14 per hour on spot instances, while a comparable CPU-only instance of that size runs about $5 per hour, even on spot a significant difference. Teams have to break that line item apart and weight the GPU piece by model because a T4 and an H200 are nowhere near the same price, then split it across whatever workloads were sharing the GPU. Every layer of visibility—the metrics, the accuracy, the guardrails, the attribution, the splitting rules—becomes something teams now have to own and maintain, adding engineering time and toil to rebuild what used to come for free. The report notes that the space is moving quickly, with dynamic resource allocation maturing and adoption growing, hardware partitioning getting easier, and the tooling gap narrowing every release, so teams should be deliberate about which layers they build now versus what they let the ecosystem catch up on.

The gap between cloud billing and workload-level cost visibility will likely widen before vendor tooling narrows it, forcing platform teams to choose between rough fairness and expensive precision. That trade-off becomes a strategic decision about whether GPU economics justify custom instrumentation or whether showback without true attribution is enough to keep teams honest.