Skip to content
Skip to content
● ENGINE LIVESign inCreate an account

wubbery://ai-infrastructure — training fleets, inference platforms, neoclouds

Your decode workload reaches 2.2% of the compute you installed. Buying more returns nothing.

Not a claim about your team — arithmetic about the workload. Autoregressive decode moves more bytes than it does maths, so the accelerator waits on memory and the utilisation graph reports a machine that is busy doing nothing. WUBBERY measures which resource actually binds, and names the configuration that reaches the silicon you have already paid for.

0.0%
Return on doubling compute for a memory-bound decode workload
90×
More reachable compute after retuning, with no hardware purchased
1 / 18 hr
Uncorrectable HBM interruptions on a published 16,384-GPU run
01

What actually binds

Utilisation is not the number you think it is

A GPU reported at 95% can be stalled on memory for most of that time. Arithmetic intensity — FLOPs per byte moved — has a ridge point equal to peak FLOPs over peak bandwidth, and decode sits far below it on every modern part. Below the ridge, additional compute returns exactly nothing, and the commercial pressure of the entire industry runs the other way.

A GPU count is not a placement

Forty free GPUs across twenty nodes cannot run an eight-GPU job, and the dashboard shows five times the capacity needed while the queue does not move. An allreduce-heavy job split across NVLink domains runs at cross-domain bandwidth throughout, and the shortfall gets attributed to the model rather than the placement.

At fleet scale, memory failure is routine rather than exceptional

A published frontier run recorded 72 interruptions from uncorrectable memory errors across 54 days on 16,384 accelerators. On a synchronous job every one of those stops the entire run, so one device's memory health is a property of the whole cluster's throughput — and devices signal before they fail.

Speculative prefetch and VRAM pruning across the memory hierarchy
Memory hierarchy and VRAM pruning - from the master deck
02

Measured, on a named alternative

Guards are reported blocked-of-attempted, never as a percentage — “zero violations” without the attempt count is a claim about nothing. Each is posed against a case that passes the check the industry already runs, because a guard that only catches obvious mistakes measures nothing.

The problem

Throughput is low, so the plan is more accelerators. At an arithmetic intensity of 2 against an 89.3 ridge point, that purchase returns nothing.

What WUBBERY does

Declines the purchase that returns nothing on this workload, and names the one that does.

2/2 blocked · +100% from bandwidth instead
The problem

'Do not buy compute' is a diagnosis. It does not get anyone a faster cluster on Monday.

What WUBBERY does

Returns a runnable configuration that reaches far more of the silicon you already own, with nothing bought.

2/2 blocked · +9,000.8% reachable compute
The problem

The fleet reports forty free GPUs. No node holds eight. The queue does not move and the capacity is real, paid for and unplaceable.

What WUBBERY does

Quantifies the capacity that is paid for and unplaceable, and names the single node to act on.

3/3 blocked · +1,900% stranded surfaced
The problem

Two training jobs each hold half the fleet, each waiting for the other, neither taking a step. Utilisation reads 100%.

What WUBBERY does

Prevents the deadlock outright, and when one has already formed, names the eviction that costs least.

3/3 blocked
The problem

A long-context request fits at admission and not at completion. It dies near the end of a generation the customer has already paid for and waited through.

What WUBBERY does

Refuses the request that would die mid-generation, and returns the largest context that will complete.

2/2 blocked
The problem

Eight GPUs are free, so eight are allocated. Split across NVLink domains, every gradient exchange runs at cross-domain speed.

What WUBBERY does

Places a collective-heavy job where it runs at full speed, and refuses to split it rather than silently halving throughput.

3/3 blocked
The problem

A device is degrading. Draining costs capacity now; not draining costs the entire synchronous run at an unknown moment.

What WUBBERY does

Returns a drain-or-hold decision for that device on that job, with the cost of being wrong either way.

3/3 blocked
The problem

Prefill/decode disaggregation is the industry default, so it gets adopted. On sparse traffic it makes the workload slower.

What WUBBERY does

Says whether disaggregation helps or hurts your traffic, and gives the threshold at which the answer flips.

3/3 blocked
The problem

Least-loaded routing sends a 32k prompt with a 30k cached prefix to an idle cold node, and recomputes the lot.

What WUBBERY does

Routes each request to the node that starts generating soonest, congestion included.

2/2 blocked · +220% faster start
03

Reproduce every number above

One command, one seed, the same answer — on your hardware, in front of you. Almost no infrastructure vendor can do that, and it is the only reason to believe any of the figures on this page.

POST https://api.wubbery.com/v1/bench/all-modules
{ "seed": 1 }

What we will not claim: the bounding analysis is first-order: it assumes bandwidth and compute are the only limits and that both reach peak, and it ignores cache reuse, launch overhead, and the fact that sustained bandwidth is typically 70–90% of specification. Use it to decide WHICH resource binds, not to predict absolute throughput. The scheduling analysis takes reuse distances and failure rates as supplied — a wrong input produces a confidently wrong placement, and every module states that in its own output.

Figures measured at seed 1 on the WUBBERY substrate engine and reproducible with the command above. WUBBERY is independent; company and product names are used for identification only and imply no endorsement.