Block drafting
A parallel drafter proposes a whole block of tokens in one forward pass, instead of one token at a time.
An optimised DSpark speculator that predicts how your outputs continue, and a custom KV backend that remembers what your traffic reuses. Both tuned on your workload, both measured against standard serving on the same GPUs.
DSpark, published by DeepSeek in July 2026, drafts a block of tokens in one pass and predicts how much of it will survive verification. We start from there and optimise it for your workload.
A parallel drafter proposes a whole block of tokens in one forward pass, instead of one token at a time.
The target model checks the block in a single pass and keeps the longest accepted prefix. It is lossless: outputs follow the target model’s distribution exactly.
Every deployment runs a DSpark optimised for its own workload, so your formats, phrasing and code conventions are predicted more often.
Per-position confidence and your live concurrency decide how many tokens to verify, so the speed-up holds when the GPUs are busy.
Standard decoding: about 1 tokens per forward pass. Stock DSpark: about 2.4 tokens per forward pass. Our DSpark: about 6.2 tokens per forward pass.
| Concurrent requests | Our DSpark | DFlash | EAGLE-3 |
|---|---|---|---|
| 1 | 5.9 | 5.1 | 1.6 |
| 4 | 5.6 | 4.5 | — |
| 8 | 5.3 | 4.5 | — |
| 16 | 4.9 | 3.9 | — |
| 32 | 4.3 | 2.8 | 1 |
EAGLE-3, DFlash and stock DSpark acceptance from the DSpark paper, compared in the same harness. DFlash and EAGLE-3 concurrency curves from the DFlash paper on B200 with SGLang. At 32 concurrent requests our DSpark runs 4.3× faster than standard decoding.
Prefill is the most expensive way to reread a prompt you have already seen. Our KV backend makes reuse the default path, across every tier of memory in the server.
Hot blocks stay in GPU memory, warm blocks move to host DRAM, cold blocks to local NVMe. Reuse promotes them back in milliseconds.
We keep what your traffic will reuse: system prompts, tool schemas and live sessions, rather than whatever was used most recently.
Sliding-window, linear and sparse-attention layers need their own cache layouts. Stock engines often miss on these models; ours is built for them.
Each request goes to the worker that already holds its context, so reuse becomes the default path instead of a lucky hit.
6K-token system and tool prefix · about 5K tokens added per turn · 12K tokens/s prefill · 400K tokens/s KV load from the cache tiers.
Average time to first token across 32 concurrent coding-agent sessions with 100K-token contexts. Baselines as published by LMCache, May 2026.
Share of prompt tokens served from cache on a creative writing workload, next to hit rates reported across the industry.
Every result compares our stack with standard serving on identical hardware, at the same latency target, on replayed traffic.
A representative sample with your real mix of prompt lengths, reuse and output formats.
Standard serving runs on identical hardware at the same per-user speed and time-to-first-token target.
DSpark is lossless, so outputs match standard decoding. Where precision changes, quality is evaluated too.
Throughput per GPU, TTFT and inter-token latency at p50 and p99, cache hit rate, acceptance and cost per token.
Creative writing defeats generic speculative decoding and prefix caching: every reply is new prose, and readers pause long enough between turns for ordinary caches to forget the story. It is also where optimising for the workload pays off most.
Long stories and character dialogue at high temperature. Every reply is new prose, and readers pause long enough between turns for ordinary caches to forget the story.
Baselines come from papers, engineering blogs and public price lists, accessed 24 September 2026.
One benchmark.
A whole new cost curve.