* [Bugfix][Core] Keep sliding-window runs at retained Mamba checkpoints
With --prefix-cache-retention-interval, aligned Mamba groups keep a state
every interval tokens, so a prompt that shares only an earlier part of a
cached one can resume there. A sliding-window group beside them (the
DFlash2 draft on Qwen3.8-27B) released every block its window had passed
with reuse_first, except the run at the prompt's last alignment boundary.
The prefill itself then reused those blocks, the window run before each
retained checkpoint lost its hash, and the hybrid hit collapsed to zero:
a 32K prompt edited after 90% recomputed from scratch.
Sliding-window managers now also hold the run ending at each retained
checkpoint. The held blocks keep normal eviction priority, as the
last-boundary run already did, so admission reservations are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* [Release] Keep a 27B GDN state every 8K prompt tokens
The 27B recipe kept only the prompt's last Mamba checkpoint, so an edit
anywhere before the last 2K tokens of a long prompt recomputed it all.
With prefix_cache_retention_interval 8192 (and the sliding-window fix
before this commit), a 32K/64K prompt with its last 10% replaced resumes
at 24576/57344 tokens, as 1.5.1 did: TTFT 7.4 -> 2.0 s and 16.3 -> 2.3 s.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* [Release] Keep a Flash-Next GDN state every 8K prompt tokens
The same retention as the 27B recipe for Flash-Next. With the last 10%
of a 32K/64K prompt replaced, prefill resumes at 24576/49152 tokens
(TTFT 1.5/3.1 s against 5.5/11.4 s cold); MTP's lookbehind costs one
alignment block at 64K. Both the bundled launcher and the Docker image.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* [Misc] Fix line length and formatting in the Flash-Next launcher test
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: mac <mac@MacBook-xinyi.local>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
