It started with a warning—then silence. The GPU bill climbed as if the accelerator never slept, yet outputs crawled like the lights went out. Dashboards were green. Customers weren’t.The anomaly didn’t fit: near‑zero GPU utilization while latency spiked. No alerts fired, no red lines—just time evaporating. The evidence suggests a single pathology masquerading as normal.Here’s the promise: we’ll trace the artifacts, name the culprit, and fix the pathology. We’ll examine three failure modes—CPU fallback, version mismatch across CUDA and ONNX/TensorRT, and container misconfiguration—and we’ll prove it with latency, throughput, and GPU utilization before and after.Case Setup — The Environment and the Victim Profile (450 words)Every configuration tells a story, and this one begins with an ordinary tenant under pressure. The workload is text‑to‑image diffusion—Stable Diffusion variants running at 512×512 and scaling to 1024×1024. Traffic is bursty. Concurrency pushes between 8 and 32 requests. Batch sizes float from 1 to 8. Service levels are strict on tail latency; P95 breaches translate directly into credits and penalties.The models aren’t exotic, but their choices matter: ONNX‑exported Stable Diffusion pipelines, cross‑attention optimizations like xFormers or Scaled Dot Product Attention, and scheduler selections that trade steps for quality. The ecosystem is supposed to accelerate—when the plumbing is honest.Hardware looks respectable on paper: NVIDIA RTX and A‑series cards in the cloud, 16 to 32 GB of VRAM. PCIe sits between the host and device like a toll gate—fast enough when configured, punishing when IO binds fall back to pageable transfers. In this environment, nothing is accidental.The toolchain stacks in familiar layers. PyTorch is used for export, then ONNX Runtime or TensorRT takes over for inference. CUDA drivers sit under everything. Attention kernels promise speed—if versions align. The deployment is strictly containerized: immutable images, CI‑controlled rollouts, blue/green by policy. That constraint should create safety. It can also freeze defects in amber.The business stakes are not abstract. Cost per request defines margin. GPU reservations price by the hour whether kernels run or not. When latency stretches from seconds to half a minute, throughput collapses. One misconfiguration turns an accelerator into a heater—expensive, silent, and busy doing nothing that helps the queue.Upon closer examination, the victim profile narrows. Concurrency at 16. Batches at 2 to stay under VRAM ceilings on 512×512, stepping to 20–25 for quality. The tenant expects a consistent P95. Instead, the traces show erratic latencies, wide deltas between P50 and P95, and GPU duty cycles oscillating from 5% to 40% without an obvious reason. CPU graphs tell a different truth: cores pegged when no preprocessing justifies it.The evidence suggests three avenues. First, CPU fallback: when the CUDA or TensorRT execution provider fails to load, the engine quietly selects the CPU graph. The model “works,” but at 10–30× the latency. Second, version mismatch: ONNX Runtime compiled against one CUDA, nodes running another; TensorRT engines invalidated and rebuilt with generic kernels. Utilization appears, but the fast paths are gone. Third, container misconfiguration: bloated images, missing GPU device mounts, wrong nvidia‑container‑toolkit settings, and memory arenas hoarding allocations, amplifying tail latency under load.In the end, this isn’t a mystery about models. It’s a case about infrastructure truthfulness. We will trace the artifacts—provider order, capability logs, device mounts—and correlate them to three unblinking metrics: latency, throughput, and GPU utilization.Evidence File A — CPU Fallback: The Quiet SaboteurIt started with a request that should’ve taken seconds and didn’t. The GPU meter was quiet—too quiet. The CPU graph, meanwhile, rose like a fire alarm. Upon closer examination, the engine had made a choice: it ran a GPU‑priced job on the CPU. No alerts fired. The output returned eventually. This is the quiet saboteur—CPU fallback.Why it matters is simple: Stable Diffusion on a CPU is a time sink. The model “works,” but the latency multiplies—10 to 30 times slower—and throughput collapses. In an environment selling milliseconds, that gap is fatal. The bill keeps counting GPU time, but the device doesn’t do the work.The timeline revealed the pattern. Containers that ran locally with CUDA flew; deployed to a cluster node with a slightly different driver stack, the same containers booted, served health probes, and then degraded. The health endpoint only checked “is the server up.” It never checked “is the GPU actually executing.” In this environment, nothing is accidental—silence is an artifact.The core artifact is execution provider order in ONNX Runtime. The engine accepts a list: try TensorRT, then CUDA, then CPU. If CUDA fails to initialize—wrong driver, missing libraries, device not mounted—ORT will quietly bind the CPU Execution Provider. No exception, no crash, just a line in the logs, often below the fold: “CUDAExecutionProvider not available. Falling back to CPU.” That line is the confession most teams never read.Here’s the weird part: utilization charts look deceptively normal at first glance. Requests still complete. A service map shows green. But the GPU duty cycle hovers at –5%, while CPU user time goes high and flat. P50 latency quadruples, and P95 unravels. Bursty traffic makes it worse—queues build, and auto‑scale adds more replicas that all inherit the same flaw.Think of it like a relay team where the sprinter never shows up, so the librarian runs the leg. The baton moves, but not at race speed. In other words, your system delivers correctness at the expense of the entire SLO budget.Artifacts pile up quickly when you trace the boot sequence. Provider load logs show CUDA initialization attempts with driver version checks. If the container was built against CUDA 12.2 but the node only has 12., initialization fails. If nvidia‑container‑toolkit isn’t configured, the device mount never appears inside the container—no /dev/nvidia, no libcuda.so. If the pod spec doesn’t request gpus explicitly, the scheduler never assigns the device. Any one of these triggers the silent downgrade.Reproduction is straightforward. On a misconfigured node, a simple inference prints “Providers: [CPUExecutionProvider]” where you expect “[TensorrtExecutionProvider, CUDAExecutionProvider].” Push a single 512×512 prompt. The GPU remains idle. CPU threads spike. The image returns in 20–40 seconds instead of 2–6. Repeat on a node with proper drivers and mounts—the same prompt completes in a fraction of the time, and the GPU duty cycle jumps into a sustained band.The evidence suggests the current guardrails are theatrical. Health probes return 200 because the server responds. There’s no startup assert that the GPU path is live. Performance probes don’t exist, so orchestration believes replicas are healthy. The system can’t tell the difference between acceleration and emulation.The countermeasure is blunt by design: hard‑fail if the GPU Execution Provider is absent or degraded. Refuse to start with CPU in production. At process launch, enumerate providers, assert that TensorRT or CUDA loaded, and that the device count matches expectations. Log the capability set—cuDNN, tensor cores available, memory limits—and exit non‑zero if anything is missing. Trade availability for integrity; let orchestrators reschedule on a healthy node.To make it stick, enforce IO binding verification. Bind inputs and outputs to device memory and validate a trivial inference at startup—one warm run that exercises the fused attention kernel. If the timing crosses a latency gate, assume a degraded path and fail the pod. Add a canary prompt set with deterministic seeds; compare latency against a baseline window. If drift exceeds your tolerance, page production and stop rollout.This might seem harsh, but the alternative is worse: a cluster that “works” while hemorrhaging time and budget. Lock the provider order, reject CPU fallback, and make the system prove it’s fast before it’s considered alive. Only then does green mean accelerated.Evidence File B — Version Mismatch: CUDA/ONNX/TensorRT IncompatibilityIf the GPU wasn’t used, the next question is whether it could perform at full speed even when present. The evidence suggests a subtler failure: versions align enough to run, but not enough to unlock the fast path. The system looks accelerated—until you watch the clocks.Why this matters is straightforward. Diffusion pipelines live or die on attention performance. When ONNX Runtime and TensorRT can’t load the fused kernels they expect—because CUDA, cuDNN, or TensorRT versions don’t match—they quietly route to generic implementations. The model “works,” utilization hovers around 30–50%, and latency stretches beyond budget. The bill looks the same; the work is slower.Upon closer examination, the artifacts are precise. Provider load logs declare success with a tell: “Falling back to default kernels” or “xFormers disabled.” You’ll see TensorRT plan deserialization fail with “incompatible engine; rebuilding,” which triggers an on‑node compile. Engines built on one minor version of TensorRT won’t deserialize on another. The rebuild completes, but the resulting plan may omit fused attention or FP16 optimizations. The race finishes—without spikes, tensor core duty cycles stay muted.Here’s the counterintuitive part. Teams interpret “it runs” as “it’s optimal.” In this environment, nothing is accidental—if Scaled Dot Product Attention isn’t active, if xFormers is off, if cuDNN reports limited workspace, performance collapses politely. The simple versi
