A GPU Pod Can Be Short of CPU While Its Node Looks Idle

GPU eligibility leaves the host CPU question open

A GPU application can still contain CPU work. NVIDIA's CUDA 13.0 programming model separates the CPU host program from GPU kernels. Its matrix-multiplication example has host code allocate device memory, arrange transfers and launch a kernel. GPU execution is one part of that program.

Consider an application whose next GPU operation depends on a host task completing. If that task waits for CPU time, the dependency can delay the next operation. This is a possible mechanism, not a diagnosis of a real workload. A quiet GPU graph cannot identify the host task, its demand or the reason it waited.

For a buyer, the useful question is therefore more specific than whether the offer includes a GPU: what CPU resources are declared for the application and its companion containers, what can constrain them at runtime, and what evidence connects those settings to the intended work?

References: [CU1]

Put requests, limits and usage on the same unit basis

Kubernetes expresses CPU as an absolute quantity. 1000m equals 1 CPU; 500m equals 0.5 CPU. The unit corresponds to the node's CPU execution capacity, such as a virtual CPU or a hardware thread on a hyperthreaded Intel host. A milliCPU value describes CPU time capacity, not a percentage of the whole node or GPU. It does not identify a dedicated physical core or make different processors equally fast.

A request enters placement accounting. A Linux CPU limit sets a runtime CPU-time ceiling. The request typically also supplies a relative weight when containers compete for CPU. Usage is a separate observation, expressed in compatible units rather than inferred from either setting.

Node allocatable is the resource amount available to Pods, accounting for the node's applicable reservations. Use that amount for the placement budget rather than substituting a processor count from a server specification.

This comparison uses the Kubernetes v1.34 documentation and ordinary container-level resources on a stipulated Linux node. Its arithmetic excludes init containers, Pod overhead and Pod-level resource budgets.

References: [KC1][KC2][KC3]

CPU-221: existing usage of 1 CPU does not make a 2.5 CPU Pod fit

Original hypothetical CPU-221 starts with 8 CPU allocatable. Existing Pods already scheduled on that node account for 6 CPU in requests. Stipulate that those workloads' measured usage is only 1 CPU during the selected observation interval. One new GPU-eligible Pod has an application-container request of 2000m and an ordinary companion-container request of 500m.

The new Pod requests 2000m + 500m = 2500m, or 2.5 CPU. The remaining request budget is 8 − 6 = 2 CPU. Adding the new Pod would produce 6 + 2.5 = 8.5 CPU of requests against 8 CPU allocatable: a 0.5 CPU excess. It fails this node's CPU request check.

Subtracting the measured 1 CPU from 8 would instead suggest 7 CPU. That calculation mixes an observed consumption value with the placement budget. The existing workloads have not surrendered 5 CPU of their requests merely because they used less during that interval. Kubernetes explicitly documents that low usage does not override a failed request-capacity check.

Counting only the application's 2 CPU would also produce the wrong answer. It would appear to fit exactly into the remaining 2 CPU, but omit the companion's 0.5 CPU request. The submitted Pod is the application and companion together.

No other node or constraint is stipulated. This establishes a CPU placement failure on this node, not a cluster-wide capacity verdict, a queue-admission result or a performance observation. The 1 CPU usage figure is supplied for the fictional case; no deployment was measured.

References: [KC1][KC2][KC3]

Two app offers can share a ceiling and make different promises

Move to a separate feasible node and compare two hypothetical offers for the same application container. Offer A declares a 500m CPU request and a 2 CPU limit. Offer B declares a 1500m CPU request and the same 2 CPU limit. Hold the companion resources and all other conditions equal, and stipulate that either offer fits.

A accounts for 0.5 CPU of app requests; B accounts for 1.5 CPU. B therefore commits 1 CPU more of the node's request budget. Their equal limit does not make their placement accounting equal.

On ordinary Linux shared CPU scheduling, the larger request typically gives greater CPU-time weight during contention. B's request is three times A's, but that ratio does not establish three times the application throughput or a fixed share of the whole node. Other competing work, available CPU time and the common limit still matter.

Conversely, A's smaller request is not a 0.5 CPU ceiling: a container can use CPU above its request when resources are available, subject to its limit. Neither offer declares exclusive cores. Neither request measures how much CPU the application needs.

References: [KC1][KC2]

A running container can meet a ceiling on a quiet node

Placement success leaves a different question: can the app obtain the CPU time it wants while running? In the documented Linux model, CPU-limit enforcement can make a container wait after it exhausts its permitted CPU time. Unused capacity elsewhere on the node does not by itself remove that container's limit.

For either hypothetical offer, stipulate an interval in which the app has runnable work seeking more CPU time than its 2 CPU limit permits. The limit can constrain that work even though the node is not fully busy. This is a separate hypothetical from CPU-221's unscheduled Pod.

It would still be wrong to label every slow GPU workload CPU-starved. The common 2 CPU limit establishes the same ceiling for these offers. It supplies neither evidence that either app reached it nor a prediction of GPU utilization, completed work or response time.

References: [KC1][KC2]

Measured CPU usage records consumption, not unmet demand

The Kubernetes Metrics API reports CPU as average core usage, derived from a rate over a cumulative CPU-time counter. Its window field identifies the measurement interval. A usage value therefore needs an object and time window before it can support a comparison.

A node average and an application-container average cover different sets of workloads. A short busy phase and a longer quiet interval also answer different questions. Ask what was measured, which containers were included and whether the interval covers the workload condition being evaluated.

Consumption alone cannot reveal all runnable work that waited without receiving CPU time. Low usage could accompany little CPU work to do or work waiting on another dependency; a limiting policy can also separate wanted CPU time from consumed CPU time. Those are explanations to distinguish with workload evidence, not conclusions to draw from the graph.

For the two offers, useful observations would connect the actual app and companion settings, CPU consumption, any reported CPU-limit throttling and useful application output over matching intervals. Request that evidence from the responsible platform team.

References: [KM1][KC2]

Decide which part of the CPU promise the evidence supports

For CPU-221, an offer showing only the quiet graph has not answered the placement question. The complete app-plus-companion request and the node's existing request total supply the decisive comparison. For the separate feasible-node offers, a shared 2 CPU limit leaves their different request commitments visible. Runtime evidence is then needed to judge whether those differences matter for the intended application.

Keep the proposed workload unchanged while comparing offers. If a supplier omits a companion, changes the input workload or demonstrates the app during a different operating phase, identify that difference before attributing the result to CPU resources. Ask the platform owner to explain the placement outcome and the observed application result separately.

The related Kueue article addresses quota admission versus Pod placement. The replica-versus-node-autoscaling article addresses demand targets versus worker provisioning. Use those guides when the purchasing question reaches those boundaries; neither aggregate GPU availability nor another desired replica substitutes for this CPU comparison.

Take a confirmed equipment requirement to physical deployment

CPU evidence may inform the platform team's equipment decision, but CPU request arithmetic alone does not establish a need to buy or install another server. First identify whether the chosen plan actually requires a physical equipment or connection change.

Leviathan's Complete Physical Infrastructure Deployment service can combine agreed receiving, rack integration, onsite installation, cabling and physical handoff records. Kubernetes resource selection, administration and application performance assessment remain with the appointed platform team.

If physical work follows from that team's capacity plan, use the related service and project inquiry. Share a nonconfidential outline of the equipment, quantity, site, rack and connection requirements, required physical stages and team receiving the handoff so the scope and availability can be discussed.

References: [L1]