Run against the real weights for the first time, it exhausted all 54 GB of RAM
and all 4 GB of swap. MemAvailable reached 0 and I killed it to keep the server
alive — the production container was two minutes from being the thing the OOM
killer chose.

It had loaded all six fp32 shards (13m42s) and reached "quantising every Linear to
INT8". The peak is not the bf16 model alone: the INT8 copies are built while the
originals are still referenced, and save_quantized_state_dict then materialises a
full state dict on top. Roughly 2x bf16, not 1x.

Three changes:

- It now REFUSES when the host cannot take it, with the numbers: "~42 GB needed,
  34 GB available". Estimated from the shards on disk (fp32, so bf16 is half)
  times 1.5, plus 4 GB for the interpreter and torch. min_free_gb overrides it for
  someone who knows better. A job that can kill the server should not be reachable
  from a button without this.
- The load streams through a meta-device skeleton (low_cpu_mem_usage=True) instead
  of building a second full copy while loading.
- gc.collect() between the phases, and the model is dropped before the save
  returns — the replaced bf16 weights are ~13 GB of garbage at exactly the moment
  the save wants to allocate.

What this means on THIS host, honestly: 42 GB needed against 54 GB total with the
server using ~20 GB. It will now refuse rather than try. Quantising here needs the
server stopped, or a lower-peak implementation that never materialises the whole
model (quantise shard by shard, write as it goes) — which is the real fix and is
not in this commit.

22 tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY