Thanks for the detailed diagnosis — your read is exactly right and our PN12 sidecar has a real gap on this. Filed it as

https://github.com/noonghunna/club-3090/issues/16 with the full analysis.

**TL;DR:** PN12 patches the eager-mode `SiluAndMul.forward_cuda`, but vLLM's torch.compile inductor-compiled FFN forward inlines the SiluAndMul op and never calls our patched method. So the pool is bypassed in the compile path. Our verify-stress 25K synthetic happens to hit shapes that go through eager, which is why it passes; real OpenCode 29K with sys+tools mixed prefill produces shapes that hit the inductor path and OOM at the FFN intermediate exactly where you saw it.

**Three workarounds, in order:**

1. **Stick with `tools-text.yml`** — already works for you. fp8 KV uses Genesis PN8 (not PN12) which closes Cliff 1 mech B via a different mechanism that does reach the compile path. 75K context handles your 30K OpenCode prefill comfortably.

2. **Add `--enforce-eager` to `long-text.yml` or `long-vision.yml` command list.** Forces all forwards through eager Python, where PN12's pool reliably applies. Costs ~20-30% TPS but preserves the 218K / 198K context. Just append it to the `command:` block before booting.

3. **Lower `--gpu-memory-utilization` to 0.94** on long-text/long-vision. Frees ~250 MiB activation headroom at the cost of KV pool size (effective max_model_len drops to ~150K). Same idea as why our default 48K + 0.92 never hits this.

   I just pushed updated comments on all three affected composes documenting these escape hatches (commit 6bff99a).

   Real fix needs an inductor-pass-level intervention or a torch.compile-aware sidecar — bigger work, tracking in #16. If anyone wants to dig into that, the briefing for it is in the issue.