The most valuable hardware benchmark I ran ended with a $0 purchase decision.

The 30-day review counted 27,759 completed accelerator jobs and summed 33.01 recorded job-hours. Treating every duration as if the jobs ran serially produced a 4.59% occupancy upper bound.

That number did not support more capacity.

The missing benchmark was demand

Most hardware reviews ask how fast a machine can run a model. That is useful for choosing between machines. It is incomplete for deciding whether to buy another one.

Capacity planning needs a second question: how often is the installed performance actually needed?

A faster node can reduce the duration of one job and still sit idle most of the month. A second node can double theoretical throughput and do nothing for a queue that rarely waits. The product page cannot answer that. The job history can.

The planning review used completed-job count and recorded duration over a 30-day window. Five jobs were classified as interactive. Most of the measured work could tolerate a queue.

That made scheduling the first intervention and hardware the last.

Why 4.59% is an upper bound

The calculation summed 33.01 job-hours and divided by the 720 hours in a 30-day window.

That produces 4.59%.

It is not measured accelerator utilization. It assumes the recorded jobs ran one after another. If some jobs overlapped, the true occupied wall time was lower. The sum also says nothing about instantaneous compute use, memory pressure, queue wait, or utilization inside each job.

The label carries the honesty: serial occupancy upper bound.

Calling it “GPU utilization” would turn a planning approximation into a telemetry claim. The approximation is strong enough for a no-buy decision because even its overcounted form is low. It is not strong enough to describe how busy the chip was during each job.

The decision did not need a price spreadsheet

I could have built a table of workstation GPUs, used servers, cloud rentals, power, cooling, and network gear. That would have produced impressive numbers and a weaker decision.

The demand evidence stopped the analysis earlier. If installed capacity is not under sustained pressure, the exact price of unused expansion does not matter.

This is a useful order of operations:

  1. measure demand;
  2. measure queue pressure and service targets;
  3. improve scheduling;
  4. measure direct utilization;
  5. price expansion only after a capacity gap survives the first four steps.

Starting with vendor options reverses the logic. It turns “what do I need?” into “which thing can I justify?”

What would earn a purchase

The no-buy decision is not permanent. It is evidence-bound.

Expansion would become credible if several signals appeared together:

  • sustained queue wait that violates a written latency target;
  • direct utilization telemetry showing the current accelerator near its practical ceiling;
  • enough interactive work that batching cannot absorb the demand;
  • a memory wall that scheduling cannot solve; or
  • an availability target that requires a second independent machine.

One busy afternoon would not clear that bar. Neither would a model that loads only on a larger box if the model has no accepted production job.

The capacity case needs a workload, a performance target, and a measured shortfall.

The five interactive jobs matter

Only five jobs in the window were classified as interactive.

That small count changes the architecture. Most work can be queued, batched, deferred, or scheduled around other loads. A second accelerator would improve convenience more than capacity unless the interactive share grows.

The classification also needs improvement. A better next pass would define interactive work by a latency requirement instead of a label, then record queue wait and completion time separately. That would show whether the user experience—not only the hardware—needs another lane.

The current evidence leaves that as a residual uncertainty. It does not pretend the job-duration sum answered it.

The public evidence boundary

The capacity aggregate includes the window, completed-job count, summed duration, upper bound, interactive count, and decision. It does not include application records or speculative hardware prices.

The no-buy report keeps the planning limit next to the result. That is important because 4.59% is easy to repeat and easier to mislabel.

The larger rule

Benchmark the queue before the catalog.

Peak tokens per second can tell you whether a machine is capable. Demand, wait time, and accepted outcomes tell you whether another machine is necessary.

In this 30-day window, the installed hardware was capable and the measured demand was thin. The best GPU purchase was the one the benchmark prevented.