#3140 The `--vram-reserve-mib` value `serve` suggests is computed before the per-window graph captures, so following it lands back under the 512 MiB line

Descripción

## Summary

`serve` warns below 512 MiB free and suggests a `--vram-reserve-mib` value. That suggestion
is derived from the free VRAM at the moment of the warning, and does not account for the
decode-window graph captures that have not happened yet. Each capture costs 16 to 60 MiB and
there is one per speculative window size, so on this machine the full set costs 128 MiB that
arrives after the "N MiB of VRAM free with everything loaded" line is printed.

The practical effect: taking the engine's own suggestion is not enough. It suggested 768, I
set 768, and it then warned again and suggested 832. By the arithmetic below, 832 would also
have ended under 512.

## Environment

- Strata 0.1.45, release build (`strata --version` prints `strata 0.1.45`, no commit)
- Linux Mint 22.3, kernel 7.0.0-31-generic, CUDA 13.0, driver 595.84
- RTX 3090 24 GB (sm_86), single GPU, no layer split
- i9-14900KF (8 P-cores + 16 E-cores, no AVX-512), 123 GB RAM
- Qwen3.8-Flash-Next GSQ-RCO **IQ3_S**, native pack, `iq_pack.py` output
- No vision, no control vectors, no `--batch`, single request at a time

Engine arguments, identical across all three runs except `--vram-reserve-mib`:

```
--pack <packs/iq3_s> --native <IQ3_S-00001-of-00002.gguf> --ple-gguf <IQ3_S-00002-of-00002.gguf>
--expert-profile data/expert-profile.bin --expert-cache auto --prefill auto
--spec 4 --spec-min-p 0.5 --mtp <mtp/rt> --max-context 131072 --kv int8 --kv-resident 32768
--pool-workers 15 [--vram-reserve-mib N]
```

## What happens

Three starts, identical but for the reserve. Each line below is the engine's own output, in
order. `capture N-tok` is `strata verify: capturing the N-token window (X MiB of VRAM free)`.

**No reserve flag (engine default)**

```
expert cache 8690 slots, 16.48 GiB
460 MiB of VRAM free with everything loaded
WARNING: only 460 MiB free (below 512 MiB) ... Add --vram-reserve-mib 768
capture 6-tok -> 460
capture 4-tok -> 442
capture 1-tok -> 426
capture 2-tok -> 410
capture 3-tok -> 392
```

**`--vram-reserve-mib 768`, as the engine asked**

```
expert cache 8656 slots, 16.41 GiB
528 MiB of VRAM free with everything loaded
capture 6-tok -> 528
capture 4-tok -> 510
capture 1-tok -> 494
capture 2-tok -> 478
WARNING: only 460 MiB free (below 512 MiB) ... Add --vram-reserve-mib 832
capture 3-tok -> 412
```

**`--vram-reserve-mib 1024`**

```
expert cache 8524 slots, 16.17 GiB
782 MiB of VRAM free with everything loaded
capture 6-tok -> 782
capture 2-tok -> 764
capture 4-tok -> 748
capture 1-tok -> 732
capture 3-tok -> 714
capture 5-tok -> 654
```

No warning in the third run. Six window sizes captured (1 through 6), total cost 128 MiB,
so the floor is 654 MiB rather than the 782 MiB printed at load. The first two runs never
captured the 5-token window, so their floors were not final either.

## Why the suggested value is structurally short, not just imprecise

Free VRAM at load tracks the reserve almost exactly on this machine:

| reserve | free at load | difference |
|---|---|---|
| default (~700) | 460 MiB | -240 |
| 768 | 528 MiB | -240 |
| 1024 | 782 MiB | -242 |

So the suggestion of 832 would have given about 592 MiB at load, and 592 - 128 = **464 MiB**
after the captures, which is under the 512 MiB the same code warns about. The suggestion
appears to be `current_reserve + (512 - current_free)`, which prices the deficit now and not
the captures still to come. Clearing 512 after captures needs free-at-load of 640, so a
reserve of about 880 on this configuration.

## What I did not observe

I want to be clear about the limits of this report. I saw **no slowdown and no hang**. Decode
measured 94 to 102 tok/s warm at 412 MiB free, with a 97.0% expert cache hit rate and 0.0% of
routed experts over PCIe. So this is a report about the guidance being insufficient, not a
reproduction of #2065.

## Why it seems worth fixing anyway

- #2065 reports the engine hanging at layer 48 when headroom drops below ~500 MiB.
- #1913 section 4(b) reports "389 MiB of VRAM free with everything loaded", a
  `capturing the 5-token window (235 MiB of VRAM free)` line immediately before the first
  slow request, and a decode collapse from 98 to 44 tok/s that never recovers in that
  session. That reporter wrote "Causal or coincidence, I cannot tell". The ledger above is
  the same mechanism measured on a different card: captures are what walk the free VRAM
  down after load, and they are invisible if you only read the load-time number.
- #2477 reports setup's generated config leaving ~420 MiB free on an 8 GB card. This looks
  like the 24 GB version of the same thing. For what it is worth, setup's own IQ3_S config
  on this machine came out as `"gpu": [1, 0]` with `"layer_split": "auto"` rather than the
  single card I measured on. I have not checked whether headroom is what drove that choice,
  but a two-card split does sidestep the problem, and it is not always what the user wants.

All three are easier to reason about if the number printed at load is the floor.

## Suggested fixes, in order of preference

1. **Capture the window graphs during startup**, before printing
   `N MiB of VRAM free with everything loaded`. Then that line is true, the warning fires at
   the right time, and the suggested reserve is computed against the real floor. It also
   makes the first few requests of a session representative, which matters for benchmarking.
2. If capturing at startup is not practical, **add the expected capture cost to the suggested
   value**. The number of window sizes is known from `--spec`, and the per-capture cost
   appears stable within a configuration.
3. At minimum, **say in the warning that the figure will fall further** as windows are
   captured, so the reader knows the suggested value is a lower bound.

## Cost of the workaround

Going from no reserve to 1024 on this configuration costs 166 of 8690 expert cache slots,
1.9%, or 0.31 GiB of 16.48.

I measured no speed penalty, on a small sample: best decode was 101.6 tok/s at reserve 768
and 101.5 tok/s at 1024, over six generations of 40 to 500 tokens each, and the decode expert
cache hit rate was 96.3% at 768 against 97.0% at 1024. That is a short probe rather than a
benchmark, and most likely says the probe's working set fits either cache comfortably. On a
card where it does not fit, the trade would be real, which is another reason to size the
reserve correctly rather than generously.