Card: defaults failures reproduced on our box; meta-device overlay revision shipped, sysctl now only for the BF16 disk path

README.md

@@ -46,9 +46,9 @@ docker run --gpus all --ipc=host -p 8000:8000 \
 
 Drop `-e VLLM_GDN_DECODE_KERNEL=triton` when serving the plain NVFP4 build. No container
 memory cap needed: unlike the BF16 disk path, the quantized tables fit the page cache next to
-checkpoint streaming. Two flags were added to the block on 2026-09-06 after a field report: the image's default `--max-num-seqs` exceeds the Mamba state blocks left at 0.92 utilization and CUDA graph capture aborts, and at the native 262,144 context with MTP the KV cache no longer fits after the draft head. 32,768 / 36 is what the table below was measured with; the report ran 135,168 / 64 with MTP.
+checkpoint streaming. Two flags were added to the block on 2026-09-06 after a field report, and both failures reproduce on our box: the image's default `--max-num-seqs` (1024) exceeds the Mamba state blocks left at 0.92 utilization (598) and CUDA graph capture aborts, and at the native 262,144 context with MTP the KV cache needs 7.57 GiB where 5.95 GiB is left after the draft head. 32,768 / 36 is what the table below was measured with; the report ran 135,168 / 64 with MTP.
 
-On a host with less than about 100 GB of RAM plus swap, set `sysctl vm.overcommit_memory=1` as well. The offload worker constructs the 95 GB BF16 table parameter before this overlay stubs it and points gathers at the sidecar, and the kernel's default heuristic refuses a single allocation larger than RAM + swap (`DefaultCPUAllocator: can't allocate memory`). A revised `ple_layer_quant.py` that builds the parameter on the meta device instead is in test and will replace the sysctl requirement.
+Hosts with less than about 100 GB of RAM plus swap: the `ple_layer_quant.py` in this repo since 2026-09-06 builds the 95 GB table parameter on the meta device, so the offload worker no longer requests that allocation and `vm.overcommit_memory` can stay at its default. Before that revision the worker constructed the BF16 parameter first and the kernel's heuristic refused it (`DefaultCPUAllocator: can't allocate memory: you tried to allocate 102400491520 bytes`), which a 64 GB host reported and we reproduced under an emulated 67 GiB commit limit; the revised file boots under the same limit and scores 77.0 (three runs: 76.0, 76.0, 79.0, against 78.2 for the same table with the previous overlay) on the tool-calling suite. Re-download the overlay if yours predates that date. The BF16 disk overlay on the model cards still needs `sysctl vm.overcommit_memory=1` on such hosts.
 
 ## Measured
 
@@ -69,7 +69,7 @@ formats sit in one band). Generation-sanity gates passed on every configuration.
 
 Validated end to end inside a **48 GB container** (INT4 table): sanity PASS, tool-calling
 80.5, 79.4 tok/s @ 1 and 486 @ 32 — within noise of uncapped. The cap was a cgroup limit on a
-176 GB host; a real 64 GB host additionally needs the `vm.overcommit_memory` setting from the serve section.
+176 GB host; a real 64 GB host also needs the current overlay revision (or the `vm.overcommit_memory` setting) from the serve section.
 
 **Field report, 64 GB host.** [Marzero](https://github.com/MarcoPizeta/flash-next-rtxpro6000-bench) ran this INT4 table with the mixed checkpoint on one RTX PRO
 6000 and 64 GB of DDR5 (60.9 GiB usable), MTP 3, `--max-model-len 135168 --max-num-seqs 64`: decode with MTP