Silent Inflation: When Your Capacity Math Lies
Two incidents this week, on two different systems, from two totally different domains. Same failure.
Incident one: a quantized model checkpoint. 21GB on disk, running on hardware with 6x headroom. It "loaded successfully" — then OOMed at first compute.
Incident two: a 20GB container image, pushed to a server with 121GB of RAM. The import didn't just fail — it took the entire node down, including SSH.
The common thread isn't Docker or AI or quantization. It's a failure class I've started calling silent inflation: an operation whose real resource cost is many times its advertised size, invisible until the moment it breaks your capacity math.
The Three Inflation Vectors
Hidden expansion shows up in three places, over and over:
- Decompression. A 20GB compressed container image becomes 28GB on disk — and the decompression itself burns CPU and memory on the destination node. Push a big image to a busy server and you've scheduled a resource storm on a box you don't control the pace of. In our case: memory compaction stalled, the kernel's compaction thread soft-locked for 15 minutes, and sshd starved. The node answered ping and nothing else.
- Dequantization. A 4-bit model silently falls back to computing in bf16 when no native kernel exists for your silicon. The checkpoint is "supported" — but every tensor inflates 4-8x at compute time. Your 21GB model now needs 100GB of working memory.
- Deserialization. That "small" config or snapshot file that becomes a gigantic in-memory object graph. Everyone who's loaded a 3MB JSON into 3GB of Java objects knows this one.
Notice what all three share: the size you measured at rest is not the size at rest-in-motion. Capacity planning based on artifact size is planning on a lie of omission.
Why "It Fits" Isn't a Number — It's a Question
Every capacity conversation I've been in goes: "the artifact is X GB, the machine has Y GB, X < Y, ship it." That arithmetic is only valid if resource cost at use time equals size at rest time. Silent inflation breaks exactly that assumption — and it always breaks it in the direction of "more."
The fix isn't more headroom (inflation doesn't scale with headroom, it explodes past it). The fix is changing what you measure:
- Measure at first contact with the expensive operation — the first matmul, the first import, the first deserialization. Not at load. "Model loaded" and "container started" are the cheapest moments of a process's life; measuring there is measuring the lobby, not the furnace room.
- Make the destination pull, never push. When a host pulls an artifact itself, the transfer happens at the pace the host can absorb. When you push, you've decided the pace for it. Big artifacts to busy machines: pull, always.
- Treat silent fallback as a louder failure than an error. A dequant fallback that "works" is operationally worse than a crash — it converts a deployment decision into a production incident with a delay fuse. Prefer systems that refuse over systems that cope.
The General Rule
Before any "it fits" claim, audit the operation for hidden expansion. Ask: between the bytes at rest and the bytes at work, what transformation happens, where does it happen, and who pays for it?
Decompress, dequantize, deserialize, duplicate — the four horsemen of capacity planning. If any of them ride, your GB-per-GB arithmetic is fiction, and the incident is already scheduled. The only question is whether you find out in a planning review or a 3 AM console session.
We built VibeComputing around this class of problem: infrastructure that tells you what it's actually doing — at the layer where the cost is really incurred — instead of what the checklist said it would do.
Measure the furnace, not the lobby.
Stop planning on advertised sizes
VibeComputing gives you ground-truth visibility into what your infrastructure actually consumes — at the moment it matters.
Get Started Free