sgl-project/sglang · error · ValueError

--enable-linear-replayssm requires Triton, or Helion for KDA

Error message

--enable-linear-replayssm requires Triton, or Helion for KDA, as the linear-attn decode backend; got --linear-attn-decode-backend={decode!r}.

What it means

The ReplaySSM buffered-decode feature (--enable-linear-replayssm) only works when the linear-attention decode backend is Triton, or Helion for KDA models. Any other --linear-attn-decode-backend (e.g. flashinfer) is rejected because the ReplaySSM ring replay is only implemented for those kernels.

Source

Thrown at python/sglang/srt/server_args.py:6935

            )

        # ReplaySSM buffered decode guards. Runs on Triton, or Helion for KDA.
        # cuda-graph is supported (slice 1b: CUDA-graph-safe static
        # write-cursor buffers). The RADIX prefix cache is now supported (slice
        # 2b: the decode kernel force-flushes the ring into temporal[slot] on
        # the radix track boundary `seq_lens % mamba_track_interval == 0`, and
        # the COW copy-into-slot path resets the ring cursor) -- so the
        # --disable-radix-cache requirement is dropped.
        #
        # Slice 2b only wires the no_buffer mamba scheduler strategy (the
        # default). The extra_buffer strategy donates the track snapshot via
        # `donate_mamba_ping_pong_slot` with a separate ping-pong slot swap that
        # does NOT route through MambaPool.copy_from, so the ReplaySSM ring
        # cursor of the donated/kept slot would not be reset there. Handling
        # that donation path is a follow-up; for now require no_buffer.
        if cfg.enable_linear_replayssm:
            if decode not in {"triton", "helion"}:
                raise ValueError(
                    "--enable-linear-replayssm requires Triton, or Helion for "
                    "KDA, as the linear-attn decode backend; got "
                    f"--linear-attn-decode-backend={decode!r}."
                )
            from sglang.srt.arg_groups.overrides import (
                mamba_extra_buffer_of,
            )

            if mamba_extra_buffer_of(resolved_view(self)):
                raise ValueError(
                    "--enable-linear-replayssm requires --mamba-radix-cache-strategy "
                    "no_buffer (the default); the extra_buffer ping-pong "
                    "donation path is not yet supported (follow-up). Got "
                    f"--mamba-radix-cache-strategy={cfg.mamba_radix_cache_strategy!r}."
                )
            if cfg.disaggregation_mode != "null":
                # The disaggregated decode pool (HybridMambaDecodeReqToTokenPool)
                # is not wired for the ReplaySSM ring, so the flag would silently

View on GitHub (pinned to 0132848349)

Solutions

Set --linear-attn-decode-backend triton (or helion for KDA models)
Or drop --enable-linear-replayssm if you must keep flashinfer decode

Example fix

# before
--enable-linear-replayssm --linear-attn-decode-backend flashinfer
# after
--enable-linear-replayssm --linear-attn-decode-backend triton

Defensive patterns

Strategy: validation

Validate before calling

REPLAYSSM_DECODE_OK = {"triton", "helion"}
def validate(decode_backend, enable_replayssm):
    return not enable_replayssm or decode_backend in REPLAYSSM_DECODE_OK

Type guard

def replayssm_compatible_decode(b: str) -> bool: return b in {"triton", "helion"}

Prevention

Keep a compatibility matrix of experimental flags vs backends
Prefer removing flags rather than overriding backends when enabling ReplaySSM

When it happens

Trigger: Passing --enable-linear-replayssm together with --linear-attn-decode-backend flashinfer (or any value outside {triton, helion}).

Common situations: Enabling ReplaySSM for throughput on a config that already selected flashinfer decode for GDN; mixing newer experimental flags with older tuned backend choices.

Related errors

AI-assisted analysis of sgl-project/sglang@0132848349 (2026-08-28). Data as JSON: /api/errors/22ed354b559bf1d4. Report an issue: GitHub.