Can trim(n) drop the last n tokens? (Ring caches lose trimability
once wrapped.)
Decode: one new position per row (S = 1), with no prefill padding in
effect.
Window: S positions per row, for prefill chunks and tails, speculative
verify windows and committed spans. Padding prepared through
PaddedPrefillCache holds: padded positions change neither state, each
row's convolution tail ends at its last real position, and each row's offset
advances by its real count. Outputs at padded positions are unspecified.
Training-only adapter; never admitted, merged, or persisted.
Drop the last n tokens (future writes overwrite them). bypass (default
false → unchanged behavior) skips the isTrimmable guard for the
speculative-decode rollback case (trim the last n ≤ γ tips right after a
1 concat write); rotating caches then physically shrink the buffer tail.
Stateless DeltaNet stand-in (same re-runnability contract as TrainingCache): state WRITES are discarded immediately, so a gradient- checkpoint recompute re-enters with the identical null-state conditions; reads always yield null (zeros inside the kernel) — a full-sequence forward from t=0, exactly the training/perplexity semantics. Before this existed, qwen3_5 routed its DeltaNet layers into plain TrainingCache and threw on the missing conv/recurrent/advance surface (the recorded "mlx-bun perplexity cannot score qwen3_5" gap).
Its
recurDecodeandrecurWindowrun the recurrence with a backward attached (gatedDeltaUpdate'sdifferentiable), since the inference kernel has no gradient; the DeltaNet block hands them its projections as it does to any recurrent cache.