#3496 [Engine] Windows Strix Halo: the expert arena registration leaves no VRAM for the expert cache

说明

### Area

Engine

### Desktop app, Terminal or source?

Terminal: source checkout, started with `START-HERE.bat`; the engine comes from the v0.1.45 release package.

### What happened

I run Strata on a Beelink GTR9 Pro (Ryzen AI Max+ 395 with the Radeon 8060S, gfx1151, 128 GB of unified memory). I installed from a source checkout at v0.1.45, because `setup.py` still asks for the old engine asset name `strata-windows-x64-hip.zip` and 0.2.0-beta no longer publishes it (404 from `releases/latest`); I pointed `--prebuilt` at the v0.1.45 release folder instead. The engine that landed reports gfx1151 in its `BUILD.json` and does run here.

The model is IQ3_S at 131072 context with int8 KV. On startup the engine registers its 46.84 GiB expert arena with the driver, and afterwards almost no free VRAM is left: `--expert-cache auto` settles on 161 slots and `serve` exits with code 1. With an explicit `--expert-cache` it clamps to those same 161 slots and does start, so the failure is easy to miss.

This is the situation `dea6920` ("0.2.1.2") describes ("91 GiB before, 0 after"), and it is the same memory-reporting problem as #2837; #3398 already measures `--mmap-experts` as the fastest decode path on this APU. I am adding a second machine, IQ3_S numbers, and the "clamps to 161 slots then exits" detail, so the fix can be checked on real Strix Halo + Windows hardware when a package exists - the docs say nobody has run one yet.

### Reproduction status

Measured locally on this machine; it happens on every start of this configuration.

### Strata version

Engine 0.1.45, installed from the v0.1.45 release; the checkout itself is the current 0.2.0-beta line.

### Graphics card, memory and system

Radeon 8060S iGPU in a Ryzen AI Max+ 395 (gfx1151), 128 GB LPDDR5X with a 32 GB BIOS carve-out, Windows 11 build 26300, Adrenalin 32.0.31041.1004.

### Model, size and settings

IQ3_S, 131072 context, int8 KV, MTP on; `--mmap-experts --expert-cache 24576 --vram-reserve-mib 0`.

### Logs

```
expert cache auto: 0.31 GiB free, 2560 MiB reserved (+218 MiB for the draft head) -> 0 slots
no VRAM is left for the expert cache: it needs at least 326 slots (827 MiB), about 1026 MiB more than this card has free
serve: verify: needs the profile-filled VRAM expert tier (--expert-profile and --expert-cache)
```

### What the machine can actually do

With nothing else running, HIP reports 104 GiB free, and a plain ctypes loop of 4 GiB `hipMalloc` blocks reached 64 GiB without a failure. So the driver is not the limit by itself; the arena registration is what takes it.

The BIOS carve-out is not the knob either: 4 GB gives 0.00 GiB free for the cache, 32 GB gives 0.31 GiB. That matches the ROCm report in ROCm/TheRock#8922, where raising the Windows "Variable Graphics Memory" slider actually lowered the HIP allocation ceiling (1 GB VGM -> 100 GiB allocatable, 96 GB -> about 32 GiB). I left it at 32 GB.

### Workaround that works here

`--mmap-experts --expert-cache 24576 --vram-reserve-mib 0` puts all 24,576 experts in VRAM (46.84 GiB) and leaves about 45 GiB free; it serves normally in that configuration.

Speeds with a 2.8K-token prompt, same machine:

- default (pinned arena, 161 slots): 33 tok/s decode, about 300 tok/s prefill
- `--mmap-experts` with 10,452 slots (19.8 GiB): 24 tok/s - slower, because the CPU-side experts then come from the file cache instead of a pinned arena
- `--mmap-experts` with all 24,576 slots: 36 tok/s, 446 tok/s prefill
- the same, plus the opt-in gfx1151 prompt switches and `--prefill auto:32768`: 38.6 tok/s, 636 tok/s prefill

For comparison, STRIX_HALO.md lists 59 tok/s and about 1,250 tok/s prefill for IQ3_S on Linux, so Windows HIP is still behind even with every expert in VRAM.

### Two smaller things

`--expert-vram` is not an accepted flag in 0.1.45: passing it prints the usage and exits with code 2, although an engine string mentions it ("--expert-vram GiB sets the experts' budget instead").

llama.cpp with Vulkan on the same box is unaffected by the carve-out (pp512 308-319 t/s, tg128 12.3-12.7 t/s), which is how I convinced myself this was not a machine-wide memory problem.