sglang chart: add MTP k=4 arm; restore continuous-serving (closed-loop) section with its chart

README.md

@@ -63,6 +63,7 @@ numbers are a floor.
 | DSpark k=6 | 387 | 189 · 3,021 | 58 · 5,606 |
 | DSpark k=4 | 337 | 173 · 2,765 | **59 · 5,702** |
 | MTP (steps 4, k=6) | 290 | 158 · 2,531 | 57 · 5,453 |
+| MTP (steps 3, k=4) | 273 | 161 · 2,579 | 57 · 5,472 |
 | no speculation | 156 | 96 · 1,539 | 43 · 4,128 |
 
 ### vLLM 0.26
@@ -88,6 +89,27 @@ confidence head would pick the verify budget per request per step, so
 the best-k envelope is a floor on what it would deliver (see known
 issues — no engine wires the head yet; all numbers verify blindly).
 
+### Continuous serving (closed loop)
+
+The same GSM8K workload served as a continuous request stream
+(EOS-terminated generations, prompts sampled per request — closer to
+production traffic than the one-batch protocol above; sglang fork,
+radix cache on as in production):
+
+![sglang continuous serving](./frontier_gsm8k.png)
+
+| config | solo (bs1) | bs16 | bs96 |
+| --- | ---: | ---: | ---: |
+| **DSpark k=8** | **443 tok/s** | 128/user · 2,046 agg | 54/user · **5,205 agg** |
+| DSpark k=5 | 369 | 115 · 1,845 | 53 · 5,057 |
+| MTP (steps 4, k=6) | 284 | 103 · 1,647 | 34 · 3,226 |
+| no speculation | 152 | 70 · 1,114 | 28 · 2,681 |
+
+Under sustained load with request churn, DSpark's margin over MTP is
+larger than in the one-batch numbers (+61% aggregate at capacity):
+continuous serving mixes prefill into every decode window, and DSpark's
+faster turnarounds keep queues shorter.
+
 ## Evaluation detail
 
 Serving-faithful rollout on **held-out prompts never seen in training**