Article summary — original
ReplaySSM Accelerates Hybrid-Model Decoding by Caching Inputs Instead of Full State
Developed jointly by NVIDIA and Princeton's Dao AI Lab, ReplaySSM restructures state storage in hybrid SSM-attention models to eliminate decoding latency bottlenecks. By expressing state as an intermittent checkpoint paired with a short input buffer, the method curtails high-bandwidth memory traffic, streamlines speculative decoding rollbacks, and mitigates quantization error accumulation.
At serving batch sizes, conventional state-space model (SSM) layers can become memory-bandwidth bottlenecks up to 100K context tokens due to reading and writing the entire state at every step.
ReplaySSM represents the state as a checkpoint plus a buffer of recent inputs, computing outputs on non-flush steps and only updating the checkpoint to memory once the buffer fills.
Standard decoding with ReplaySSM achieves 1.46× to 1.80× kernel speedups and 1.20× to 1.47× step speedups at batch size 256 across Nemotron 3 and Qwen3.5 models.
In speculative decoding, ReplaySSM commits drafts by advancing a pointer and uses output-only evaluation, delivering up to 2.10× higher serving throughput at batch size 512 compared to vLLM.
Decoupling precision allows low-precision (such as NVFP4) state reads for output calculations alongside higher-precision recurrence updates, halting error compounding across extended generation contexts.
SSM Decoding Bottlenecks in Hybrid Architectures
Hybrid architectures such as Nemotron 3, Qwen3.5, Kimi-K3, and GLM-5.3-Flash interleave SSM layers like Mamba-2, Gated DeltaNet, or Kimi Delta Attention with sparse attention layers. Although SSMs replace growing KV caches with fixed-size states, conventional decoding fuses output calculation with state updates at every step. This makes SSMs memory-bound: a single layer's FP32 state consumes 4 MiB per sequence, roughly matching an attention layer's KV cache for 8K tokens. With high SSM-to-attention layer ratios, loading and storing the state creates heavy high-bandwidth memory (HBM) traffic that bottlenecks latency at serving batch sizes.
State Checkpointing and Buffered Input Formulation
ReplaySSM unrolls the recurrent SSM formulation across a window of tokens, defining the state as an initial checkpoint plus a buffer of input records. During intermediate non-flush steps, the model appends incoming inputs to the buffer and evaluates outputs directly from the checkpoint and buffer without storing a new state. When the buffer reaches capacity, a flush step folds the buffered records into the checkpoint and writes it to HBM once. This design maintains numerical consistency with conventional decoding while cutting write traffic during non-flush steps down to a few input vectors.
Standard Decoding Gains and Bandwidth Relief
Evaluations across 4B dense models on NVIDIA H100 GPUs and 120B-class mixture-of-experts models on Blackwell Ultra B300 GPUs demonstrated substantial improvements when evaluated with a window size of 16. While batch size 1 shows no speedup due to other latency factors, batch size 256 yields 1.46× to 1.80× faster kernel execution and 1.20× to 1.47× faster decode steps across Nemotron 3 and Qwen3.5. Because the share of step latency occupied by SSM layers expands alongside batch size, end-to-end performance scaling improves concurrently.
Streamlined Speculative Verification and Output-Only Evaluation
Under conventional speculative decoding, serving engines save state snapshots per draft token to support rollback, taxing memory bandwidth and capping concurrency. ReplaySSM appends draft token inputs to the buffer and handles rollbacks by adjusting the buffer pointer, eliminating snapshot storage entirely. It also applies output-only evaluation to compute outputs via small matrix products over cached keys, values, and draft queries using Tensor Cores without building intermediate states. On GSM8K benchmarks with draft length 4 at batch size 512, ReplaySSM achieved 1.85× to 2.10× the throughput of vLLM while maintaining verifying performance for 8 tokens in approximately the time of a single standard step.
Decoupled Precision to Prevent Quantization Drift
In recurrent updates, state quantization errors repeatedly feed back into subsequent steps. ReplaySSM decouples precision roles: a high-precision checkpoint (such as FP16 with stochastic rounding or FP32) is preserved for recurrent updates, while a low-precision copy (such as NVFP4) is generated during flushes specifically for non-flush output reads. Because the low-precision copy never recirculates into the recurrence, error does not accumulate over generation length. On 128K generated tokens of PG-19 with Qwen3.5-4B, this separation reduced Kullback–Leibler divergence from 0.136 to 0.0038 against FP32 baselines, protecting downstream benchmark performance across GPQA-Diamond, MMLU-Pro, and Math-L5.
Production Deployment and Open-Source Integration
ReplaySSM is currently deployed in production engines for GLM-5.3-Flash and Kimi-K3's KDA layers. The framework is also merged and available across inference ecosystems, including TensorRT-LLM, vLLM, SGLang, and FlashInfer, alongside public research code.
Saved original article
Hybrid models interleave state-space model (SSM) layers with a few attention layers. NVIDIA
Nemotron 3
,
Qwen3.5 through Qwen3.8
,
Kimi-K3
, and
GLM-5.3-Flash
are all built this way, with
Mamba-2
,
Gated DeltaNet (GDN)
, or
Kimi Delta Attention (KDA)
as the SSM layer.
SSM layers are designed to make decoding fast: they use a fixed-size state in place of a key-value (KV) cache that grows with context length. At serving batch sizes, however, the SSM layers, not attention, can be the latency bottleneck up to 100K tokens of context. SSM layers also complicate two techniques that reliably speed up attention decoding: speculative decoding and quantization.
ReplaySSM makes SSM layers the fast part again. It represents the SSM state as a checkpoint plus a buffer of recent inputs. This separates output computation from state updates and addresses three challenges in current SSM decoding: state traffic, rollback for speculative decoding, and error accumulation in a quantized state.
ReplaySSM is joint work between NVIDIA and the Dao AI Lab at Princeton. The paper,
ReplaySSM: Cache SSM Inputs, Not State
, details all three benefits and presents the full evaluation. It is available on arXiv, with
code on GitHub
. It is integrated into NVIDIA TensorRT-LLM, vLLM, and FlashInfer, and also runs in production in GLM-5.3-Flash and Kimi-K3.
Figure 1. Conventional decoding loads and stores the full state at every step. ReplaySSM caches recent inputs, computes outputs from the checkpoint plus buffer, and writes the checkpoint only when the buffer fills
Why SSM layers can become a decoding bottleneck
Take the Mamba-2 layer used in
NVIDIA Nemotron 3 Ultra
as an example. It decodes one token with the following recurrence:
S
t
=
α
t
S
t
−
1
+
v
t
k
t
⊤
,
o
t
=
S
t
q
t
,
S_t = \alpha_t S_{t-1} + v_t k_t^\top, \qquad o_t = S_t q_t,
where
S
t
S_t
is the state,
α
t
\alpha_t
is a data-dependent decay, and
v
t
v_t
,
k
t
k_t
, and
q
t
q_t
are the token’s inputs. Each step loads
S
t
−
1
S_{t-1}
from high-bandwidth memory (HBM), applies the decay and a rank-1 update, computes the output with
q
t
q_t
, and stores
S
t
S_t
back. GDN and KDA add a delta-rule correction, but their updates can be written in the same outer-product form, so what follows applies to them too.
During decoding, the state does two jobs. It is read to produce this token’s output, and it is updated to become the next token’s state. Conventional decoding does both at once: each step updates the state, reads the output from it, and stores it for the next step. All three challenges come from this fusion.
Figure 2. Three challenges of conventional SSM decoding and the ReplaySSM answer to each. Left: decode-step latency breakdown for Nemotron-3-Super-NVFP4 at batch size 256 on one NVIDIA Blackwell Ultra B300 GPU
State memory traffic
An SSM decoding step loads and stores the full state while performing little arithmetic on it, so the kernel is bound by HBM bandwidth, not compute. At serving batch sizes, that makes the SSM layers, not attention, the largest component of the decode step up to 100K tokens on
Nemotron-3-Super-NVFP4
at batch size 256 on one NVIDIA Blackwell Ultra B300 GPU (Figure 2, left).
Two factors drive this:
Layer count: The model has five times as many SSM layers as attention layers.
State size: One layer’s FP32 state is 4 MiB per sequence, while an FP8 KV entry is 0.5 KiB per token, so an SSM layer’s state is the size of an attention layer’s KV cache for 8K tokens.
Rollback for speculative decoding
Speculative decoding
has a drafter propose
T
tokens, verifies them in one pass through the target model, and rolls back to the last accepted token. Attention naturally supports rollback by moving the KV cache pointer. But once an SSM has summarized the drafts into its state, the update has no easy inverse, so rollback becomes expensive. Serving engines such as vLLM work around this by storing a state snapshot after every draft token and picking the one that matches the accepted prefix. That is one read and T writes per step on a memory-bound path, and the snapshots cap how many requests fit in GPU memory. As a result, speculative decoding, a reliable speedup for Transformers, barely helps SSMs at serving batch sizes.
State quantization
The quantized state produces the output and is the input to the next update, so its rounding error re-enters the recurrence at every step. A KV cache has no such loop: a quantized entry is read many times but never written back into itself, which is why KV caches tolerate lower precision than SSM states. Qwen3.5-122B-A10B-NVFP4, for example, uses the NVIDIA NVFP4 4-bit floating-point format for its weights, with an FP8 KV cache and an FP32 SSM state.
How ReplaySSM represents the state
The SSM recurrence can be unrolled over a window of
h
tokens:
S
t
=
α
t
S
t
−
1
+
v
t
k
t
⊤
=
γ
h
S
c
k
p
t
+
∑
j
=
1
h
γ
j
+
1
:
h
v
j
k
j
⊤
,
S_t = \alpha_t S_{t-1} + v_t k_t^\top = \gamma_h\, S_{\mathrm{ckpt}} + \sum_{j=1}^{h} \gamma_{j+1:h}\, v_j k_j^\top,
where
S
c
k
p
t
S_{\mathrm{ckpt}}
is the state before the window and
γ
\gamma
is the cumulative decay. Conventional decoding follows the left side step by step. ReplaySSM uses the right side: it represents the state as a checkpoint plus a small buffer of recent input records (
α
j
\alpha_j
,
v
j
v_j
,
k
j
k_j
) for Mamba-2.
On most steps, which we call non-flush steps, it appends the current inputs to the buffer and computes the output from the checkpoint and the buffer without storing a state. When the buffer of
L
records fills, a flush step folds the buffered inputs into the checkpoint, writes the new checkpoint to HBM once, and clears the buffer. The outputs match conventional decoding up to floating-point differences. ReplaySSM’s approach can be summarized in three questions:
What does ReplaySSM do?
It caches recent SSM inputs and represents the state as a checkpoint plus those inputs.
What does this change?
It separates output computation from state updates: outputs are computed every step, while the checkpoint is updated once per window.
What does this achieve?
It reduces state memory traffic, simplifies speculative rollback, and supports low-precision state reads without propagating their rounding error through recurrent updates.
How we evaluated ReplaySSM
We evaluate four hybrid models from two families, Nemotron 3 with Mamba-2 layers and Qwen3.5 with GDN layers, from 4B dense models on one NVIDIA H100 Tensor Core GPU to 120B-class mixture-of-experts (MoE) models on one NVIDIA Blackwell Ultra B300 GPU (Table 1). We implemented ReplaySSM in vLLM and compared it with vLLM’s own kernels at their best launch configuration.
Performance runs keep the SSM state in FP32, the default precision for these models, and use a window of
L
= 16, the best-performing window size for all four models. Speculative decoding tests use each model’s multi-token prediction (MTP) head to generate draft tokens.
Model
SSM layer
Weights
GPU
SSM / attention layers
Nemotron-3-Nano-4B
Mamba-2
BF16
1×H100
21 / 4
Nemotron-3-Super-120B-A12B
Mamba-2
NVFP4
1×B300
40 / 8
Qwen3.5-4B
GDN
BF16
1×H100
24 / 8
Qwen3.5-122B-A10B
GDN
NVFP4
1×B300
36 / 12
Table 1. Evaluated models and hardware. Each model runs on one GPU without tensor parallelism
Benefit 1: Reduce state memory traffic
Over a window of
L
tokens, conventional decoding reads the state
L
times and writes it
L
times. ReplaySSM still reads the checkpoint on every step, because the output needs it, but writes it only once, during the flush. A non-flush step has one job—computing the output—and writes only the new input record, a few vectors instead of a full matrix. This roughly halves the dominant state traffic.
At serving batch sizes, memory bandwidth limits the conventional kernel’s performance, so reducing state memory traffic speeds up decoding. At batch size 1, other sources of latency dominate, and ReplaySSM provides no speedup in these tests. At batch size 256, the kernel runs 1.46× to 1.80× faster, and the decode step runs 1.20× to 1.47× faster across the four models (Figure 3). The end-to-end gain grows with batch size because the SSM share of the step grows.
Figure 3. Standard decoding speedup over tuned vLLM at batch size 256. Kernel numbers include flush costs
Benefit 2: Simplify rollback and speed up verification
In speculative decoding, ReplaySSM appends the inputs of all
T
draft tokens to the input buffer before verification and commits the accepted prefix afterward by advancing the buffer pointer. As with a KV cache, records beyond the pointer are ignored, and the next append overwrites them. There is no state snapshot to save for each draft token and no state to restore (Figure 2, middle). A flush folds only committed records into the checkpoint, so it never waits for the accepted length.
This separation offers another benefit. Conventional decoding must produce two things per token, the output and the updated state, because the next token consumes the state. A non-flush step in ReplaySSM produces only the output, and computing only the output opens up a different computation method. For one update from a zero state,
o
=
(
v
k
⊤
)
q
=
v
(
k
⊤
q
)
o = (v k^\top)q = v(k^\top q)
. The expression on the left builds a
d
v
×
d
k
d_v \times d_k
state and reads it. The expression on the right forms a scalar and scales a vector without building the state. For
T
drafts against
h
committed records, the same idea gives the following expression:
O
=
S
c
k
p
t
Q
D
+
V
(
W
⊙
(
K
⊤
Q
)
)
,
O = S_{\mathrm{ckpt}}\, Q D + V \bigl(W \odot (K^\top Q)\bigr),
with
D
holding the cumulative decays of the draft positions and
W
a causally masked matrix of decays. We call this output-only evaluation. The checkpoint is used once for all
T
queries, and everything else is two small matrix products over the cached keys, the cached values, and the draft queries. No intermediate state is formed, which saves on-chip memory and FLOPs, and Tensor Cores can speed up these computations. Also,
K
⊤
Q
K^\top Q
is shared by all value heads in a group. This is the same chunkwise computation that prefill kernels already use, with the buffer and the drafts as the chunk. GDN can also use this form. Output-only evaluation applies to standard decoding too, but it matters most in verification, where
T
multiplies the arithmetic per step.
Figure 4 shows speculative serving throughput on GSM8K prompts with
T
= 4 on the two 120B-class models. At batch size 512, ReplaySSM delivers 1.85× and 2.10× the throughput of vLLM’s speculative decoding, with matched acceptance lengths.
Figure 4. Speculative serving throughput on GSM8K prompts, T = 4, L = 16, FP32 state, one B300 per model
The gain has two sources.
Faster verification: vLLM’s kernel stores one snapshot per token, so its latency grows with
T
and at
T
= 8 is almost five times that of vLLM’s standard decoding step. ReplaySSM writes no state on most steps, so it verifies eight tokens in about the time of one standard step, flushes included (Figure 5).
Higher concurrency: Draft state snapshots consume GPU memory and cap concurrency. Conventional speculation stops gaining beyond batch size 128, and on Qwen3.5-122B-A10B-NVFP4, it falls below standard decoding at batch size 512, while ReplaySSM keeps scaling with batch size.
Figure 5. Verification kernel latency on Nemotron-3-Super-NVFP4 at batch size 256, relative to vLLM’s standard decoding step, flushes included
Benefit 3: Limit error accumulation with separate precisions
A lower-precision state requires fewer bytes, which reduces latency when memory bandwidth limits kernel performance. On Mamba-2, the non-flush kernel runs 3.8× faster when reading NVFP4 state than when reading FP32 state.
ReplaySSM changes quantization in two ways. First, the checkpoint is written once per window instead of once per step, so a single low-precision checkpoint is rounded once every
L
steps. The
Nemotron 3 Ultra report
explores this periodic checkpointing approach. It reduces rounding frequency, but rounding error still enters later updates.
Second, non-flush steps read the state only to compute outputs, while flush steps update the checkpoint used in subsequent state updates. The two jobs can use different precisions. We keep a high-precision checkpoint for the recurrence and a low-precision copy for non-flush reads. A flush starts from the high-precision checkpoint, incorporates the buffered inputs, and casts the result independently into both formats. The low-precision copy is never read back into the recurrence, so its rounding error affects only the outputs of the current window and never propagates across the recurrence. Writing the additional low-precision copy during a flush reduces the amount of data read on every non-flush step. Acceptance, rollback, and buffer management are unchanged (Figure 2, right).
Figure 6 measures the output error as the Kullback–Leibler (KL) divergence from FP32-state decoding under teacher forcing on PG-19 text, out to 128K generated tokens. A shared FP8 or NVFP4 checkpoint accumulates error with length. Keeping the recurrence in FP32 removes most of the growth: at 128K tokens on Qwen3.5-4B, NVFP4 reads with an FP32 recurrence cut the KL from 0.136 to 0.0038. What remains is the read error, which does not grow with length.
An FP16 recurrence with stochastic rounding (SR) tracks FP32 closely, so a half-precision recurrence checkpoint is enough. Better quantization of the read copy, such as separate scales along the state and channel dimensions, could cut the remaining read error further.
Figure 6. Output KL from conventional FP32-state decoding on Qwen3.5-4B, L = 16. Separate precisions for the two jobs, output computation and recurrent update, remove most of the accumulated error
We also checked whether the KL gap shows up in downstream accuracy. Table 2 shows GPQA-Diamond, the benchmark with the longest generations of the three we ran. A shared NVFP4 checkpoint loses 3 to 31 percentage points of accuracy across the four models. NVFP4 reads with an FP16 or FP8 recurrence recover most of that and keep three out of four models within about 2 percentage points of FP32.
GPQA-Diamond, change from FP32 (points)
FP32 accuracy
Shared NVFP4 checkpoint
NVFP4 read, FP16+SR recurrence
NVFP4 read, FP8+SR recurrence
Nemotron-3-Nano-4B
56.7
−31.3
−6.7
−5.6
Nemotron-3-Super-NVFP4
79.3
−12.5
−1.4
−1.4
Qwen3.5-4B
76.3
−3.2
+0.7
+1.5
Qwen3.5-122B-A10B-NVFP4
82.7
−5.2
−2.0
−1.7
Table 2. GPQA-Diamond accuracy with an NVFP4 read checkpoint, expressed as the change from each model’s FP32 reference. The shared checkpoint uses stochastic rounding. Standard decoding, L = 16
Figure 7 shows how accuracy loss varies with generation length on GPQA-Diamond. Across the three benchmarks:
GPQA-Diamond:
On Nemotron-3-Super-NVFP4, the shared checkpoint tracks FP32 accuracy for shorter generations but diverges from it as generation length grows. The separate-precision configuration stays close to FP32 throughout.
MMLU-Pro and Math-L5:
Generations are generally shorter than those in GPQA-Diamond. Three out of four models lose at most 3 percentage points of accuracy with a shared NVFP4 checkpoint, while the separate checkpoint configurations stay within half a percentage point of FP32 on average.
The paper includes results for all three benchmarks and a long-input RULER test.
Figure 7. GPQA-Diamond accuracy by quartile of FP32 reference generation length on Nemotron-3-Super-NVFP4
Get started with ReplaySSM
ReplaySSM is in production.
GLM-5.3-Flash
serves with ReplaySSM, and
Z.ai’s infrastructure report
describes adding it to the KDA decode kernel.
Kimi-K3
caches the SSM inputs of draft tokens for verification in its KDA layers and cites ReplaySSM as a concurrent approach. ReplaySSM is also integrated into open-source inference frameworks such as TensorRT-LLM, vLLM, SGLang, and FlashInfer.
To learn more, check out these resources:
Read the paper:
ReplaySSM: Cache SSM Inputs, Not State
Try the code:
github.com/Johnny-Liou/ReplaySSM
Serve hybrid models with ReplaySSM in TensorRT-LLM:
PR 14203
,
PR 16464
Serve hybrid models with ReplaySSM in vLLM:
PR 48018
,
PR 52506
,
PR 52928
Use the ReplaySSM kernels in FlashInfer:
PR 3975
,
PR 4081
Read the
earlier post from the Dao AI Lab
for a longer walkthrough of standard and speculative decoding