Clarify that 64k context and 8-9 streams are not simultaneous

README.md

@@ -111,12 +111,16 @@ an answer is always produced: see
   `gcc --version` still succeeds, and the failure surfaces ~40 s in as a `gcc`
   `CalledProcessError` inside `cuda_graph_runner.py` — which reads like a runtime bug and is not.
   Preflight in [`sglang/INSTALL.md`](sglang/INSTALL.md#requirements).
-- **24 GB VRAM** for the shipped defaults (65,536-token context, ~8–9 concurrent streams) with a
-  ~10.15 GB model. Note the stream ceiling: `MAMBA_RATIO=0.3` sizes the recurrent-state pool, which
-  clamps `max_running_requests` to 8–9 on a 24 GB card, so the `12`/`16` entries in the default
-  `CUDA_GRAPH_BS` are **dropped and never captured**. To serve more streams raise
-  `MAXREQ`/`MAXMAMBA` with `MEM` — the throughput recipe is in the
-  [model card](https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#verified-configurations).
+- **24 GB VRAM** for the shipped defaults (65,536-token context, ~8–9 concurrent streams *at short
+  prompts*) with a ~10.15 GB model. Those two figures are **not simultaneous**: the default pool is
+  68,686 tokens, which is one full-length 64k request or ~8 requests of ~8k. Note also the stream
+  ceiling: `MAMBA_RATIO=0.3` sizes the recurrent-state pool, which clamps `max_running_requests` to
+  8–9 on a 24 GB card, so the `12`/`16` entries in the default `CUDA_GRAPH_BS` are **dropped and
+  never captured**. To serve more streams raise `MAXREQ`/`MAXMAMBA` with `MEM` — the throughput
+  recipe is in the
+  [model card](https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#verified-configurations); for
+  long context (128k measured on a 24 GB card) see
+  [By VRAM](sglang/INSTALL.md#by-vram).
   16 GB should fit at a reduced context — the cookbook has a recipe, but we have not run it.
 
 ## Changelog