[original-el8]

Warmup retention exhausts device memory on 96 GB GPUs

Compiled-forward warmup retains the physical backing of every retired transient allocation until the catalog completes, so peak preparation memory grows by the sum of all warmup forwards' transient footprints instead of the largest concurrent footprint. Qwen3.8 Flash Next TP1 export at the recipe default concurrency of 32 exhausts a 96 GB RTX PRO 6000 during compiled warmup (~1 GiB retained per forward, OOM by forward ~51), as reported by @mark-yong for Qwen3.8-27B and Qwen3.8-Flash-Next TP1 on 96 GB GPUs (#187), with matching reports from Johannes Bertens (model-card documentation) and local-inference-lab Discord users (TP1 allocation shortfalls of 20–128 MiB). @mark-yong's diagnostic with retention disabled (exports completing without CUDA errors on driver 615.71.09) confirmed retention as the sole accumulation source. DGX Spark (128 GB unified) fits the accumulated backing and does not observe the failure.

Fix

Donate retained physical backing to allocation: flare_package_allocate maps a retained handle of the exact requested size instead of creating fresh physical storage, and a failed map returns the handle to the retained set. Retained memory is then bounded by distinct transient sizes rather than the warmup count, while physical allocations still survive the retention scope (preserving the CUDA_ERROR_ILLEGAL_INSTRUCTION workaround) and release completely at finish(). Aborted scopes donate nothing.

Package and serving contracts are unchanged; Heliopause must be rebuilt.

Validation

• 7 allocator unit tests pass, covering donation take, failed-map return, and complete-drain release.
• An RTX PRO 6000 (SM120, 96 GB) probe allocating and freeing two repeating 1 GiB transients twelve times inside a retention scope held retained backing at 1 GiB and released all of it at finish().
• Full-catalog TP1 export of nvidia/Qwen3.8-Flash-Next-FP4-Local at recipe defaults completed on a 96 GB RTX PRO 6000 (112 graphs, peak 87 GiB with 10 GiB free), where retention without reuse exhausts device memory; the resulting package serves at concurrency 32 with a 17.8 GiB KV cache (1,069,056 tokens).
• SM103 and Windows execution are untested; the allocator change is hardware-agnostic and the retention contract is unchanged.

Closes #187's export-failure case for Qwen3.8 Flash Next TP1 and Qwen3.8-27B: --max-concurrency 8 and tmpfs staging are no longer needed to export at recipe defaults. Credit to @mark-yong for the root-cause diagnosis (retention disabled → export completes) and to Johannes Bertens and the Discord reporters for the corroborating deployment data.

[original-el8]

Closing in favor of #154, which fixes the same retained-warmup accumulation with a more complete mechanism: pooled whole mappings instead of exact-size handle remaps, explicit handling of the SM120 sub-range remap constraint (CUDA_ERROR_NOT_SUPPORTED), failed-unmap recovery, and snapshot accounting for reused references. It is also validated on more hardware (four 96 GB RTX PRO 6000 cards, DeepSeek V4.1 Flash TP4). I have posted this PR's independent validation on #154 — Qwen3.8 Flash Next TP1 export at recipe defaults completing on a 96 GB card with the fix class, tying it to #187.