Back to blog

Large-model reload stability and B200 controls

Fixes a GPU memory leak during reload fallback, hardens B200 scripts, and adds practical controls for acceptance ranges and overhead measurement.

2 min readInvarLock Team
A returning coil stays inside fixed bounds and settles back onto its reference, evoking stable reloads without growing resource use.

Release: InvarLock 0.3.1 - Memory cleanup, scheduling fixes, and acceptance controls

Highlights

  • GPU memory is freed before reload fallback (reducing OOM risk on big runs).
  • B200 scripts hardened (paths, size detection, error propagation).
  • New controls for overhead skipping, primary metric acceptance ranges, and large-run evidence-pack guidance.

0.3.1 is a large-run stability release. The memory leak fix is the kind of thing you only appreciate after you have watched a reload fallback fail repeatedly at scale: freeing GPU memory before reloading keeps 70B+ runs from turning one recovery path into a second failure.

The B200 updates are in that same category. Preset path resolution, model-size detection, worker error propagation, cleanup traps, and progress monitoring all become less brittle. The added controls (INVARLOCK_SKIP_OVERHEAD_CHECK plus configurable primary-metric acceptance ranges) give CI/release profiles a cleaner way to handle oversized models without editing code or relying on the older tiny-relax escape hatch.

The release also adds the first comprehensive evidence-pack guide, which matters because these larger runs are not just about getting to the end: they need to leave behind enough context for someone else to understand what happened.

Sources

Website documentation explains the maintained workflow. The changes described here belong to InvarLock v0.3.1; the tagged release record preserves that historical scope.

More in Release

Explore nearby related posts.