In this article
An idle GPU reading does not reveal whether the resource was available, reserved or unable to serve the intended task.
A GPU idle report should separate waiting for work from owner reservations, maintenance and genuine unavailability. Low GPU utilisation alone cannot identify which of those states applied. Start with a non-overlapping timeline, then explain causes with supporting observations.
This produces a useful operating record without treating every unused hour as lost revenue. Offered availability and actual commercial work remain separate measures.
Define mutually exclusive states
Choose definitions that fit the resource and reporting period. For example, ready means the required environment and access were available for the agreed task. An owner reservation means external work was not intended, even if the machine was technically healthy.
The following invented day illustrates the classification:
| State | Duration | Meaning |
|---|---|---|
| External work | 8 hours | A defined workload ran |
| Ready without a task | 10 hours | Resource was available |
| Owner reservation | 2 hours | Outside work was excluded |
| Maintenance | 2 hours | Agreed changes were performed |
| Unavailable | 2 hours | Required resource was not ready |
The total is 24 hours because the example’s intervals do not overlap. Real reports need that reconciliation before percentages are calculated.
Combine different observations
NVIDIA DCGM health monitoring and vLLM serving metrics describe different parts of the system. Hardware observations can help investigate a device problem; application metrics can describe request activity. Neither should automatically replace the owner’s schedule or maintenance record.
Record the time zone and measurement interval for each source. A short sample showing no GPU work does not establish an entire hour of unavailability. Similarly, a healthy device does not prove that the API or network was ready.
Keep causes separate from conclusions
Write the observed event first: no queued request, connection failure or a scheduled reservation. Add the confirmed cause when evidence supports it. If the cause remains uncertain, preserve that uncertainty rather than guessing about market demand or a hardware defect.
For overlapping events, apply the agreed classification rule once. Do not count the same interval under maintenance and outage and then report both as separate lost capacity.
Use the report to improve operation
Reconcile the period total, explain missing intervals and identify a specific improvement. That might be a clearer reservation calendar, a missing application check or a revised support contact. The action should follow the evidence rather than a target utilisation percentage.
A realistic history of waiting, reservations and interruptions helps define a pilot more clearly than one average utilisation figure.
Continue with Calculate the Cost of Making Your GPU Available and Keep a Network Outage Log for a GPU Node.