Add Performance-under-load section (concurrency sweep, GuideLLM real-data)

README.md

@@ -141,6 +141,28 @@ context length, batch size, and backend. Notes from the serving campaign:
   `VLLM_ATTENTION_BACKEND=TRITON_ATTN` lifted spec-off short-form decode a
   further +13% in my follow-up runs.
 
+
+## Performance under load (GuideLLM, real articles, eagle3 head)
+
+Concurrency sweep of the production config (FP8 + EAGLE-3 draft, TRITON_ATTN,
+k=3) on real article prompts. Aggregate throughput scales with concurrency;
+inter-token latency stays essentially flat under load.
+
+![Concurrency scaling](https://huggingface.co/NullSense/Nanbeige4.2-3B-FP8-Dynamic/resolve/main/assets/chart_concurrency.png)
+
+| concurrent streams | aggregate output tok/s | TTFT p50 (ms) | ITL p50 (ms) |
+|---|---|---|---|
+| 4 | 435 | 56 | 7.7 |
+| 8 | 750 | 187 | 8.2 |
+| 16 | 993 | 303 | 8.5 |
+
+Measured with [GuideLLM](https://github.com/vllm-project/guidellm) on an RTX 5090,
+vLLM v0.25.1, real multi-kB article prompts. Single-stream decode is the 154-244
+tok/s in the Speed table; this shows the same server saturating to ~1000 tok/s
+aggregate at concurrency 16 with per-token latency near-constant, i.e. it batches
+well for multi-user / parallel-agent workloads. Spec acceptance held over the run
+(165k accepted / 502k drafted).
+
 ## Serving (vLLM)
 
 The architecture is not yet in upstream vLLM