执行摘要

• 一句话：修复 ReplaySSM 在请求结束时缓存长度计算
• 推荐动作：建议后续跟进处理 review 中提出的两个边界情况：增加 req.mamba_pool_idx 的 None 检查以及 cache_len 的下限截断。同时，建议为 ReplaySSM 的缓存修正添加专门的单元测试，覆盖各种 write_pos 值和边界条件。

功能与动机

ReplaySSM 模式下，无额外缓冲时，temporal[slot] 中保存的 SSM 状态并非最新，而是滞后于当前活跃状态的回绕缓冲区内容。若直接按 token_ids_len 或 mamba_last_track_seqlen 缓存，会导致 key 长度与实际状态不匹配，从而在缓存命中时恢复出错误的状态。PR body 未提供 issue 链接，但从代码注释“ReplaySSM (no_buffer): temporal[slot] lags the live state by the slot's unflushed ring depth”可见其设计背景。

实现拆解

变更仅涉及 python/sglang/srt/mem_cache/unified_cache_components/mamba_component.py 中的 prepare_for_caching_req 方法，共 +18/-5 行。

1. 重构分支逻辑：将原来的三元表达式拆分为 if self.enable_mamba_extra_buffer 分支，使逻辑更清晰，并为后续的 ReplaySSM 修正腾出空间。

2. 新增 ReplaySSM 缓存长度修正：在 is_finished 为 True 且 enable_mamba_extra_buffer 为 False 时，通过 self.cache.req_to_token_pool.mamba_pool.replayssm_write_pos 获取当前 slot 的未冲刷回绕深度 write_pos，然后执行 cache_len -= int(write_pos_buf[req.mamba_pool_idx].item()) 并清零 write_pos_buf[req.mamba_pool_idx] = 0。这确保了捐赠给 radix cache 的检查点与 key 长度一致。

3. 保留原始逻辑：当 enable_mamba_extra_buffer 为 True 时，行为不变，仍然使用 req.mamba_last_track_seqlen 作为 cache_len。

4. 测试配套：本次提交未包含新增的单元测试。但作者在 PR 合并后触发了 /rerun-group radix_cache/unified_radix_tree 和单文件重跑，CI 结果均为绿色（Passed），说明该修正通过了已有的回归测试。

关键文件：

• python/sglang/srt/mem_cache/unified_cache_components/mamba_component.py（模块 缓存层；类别 source；类型 core-logic）: 核心变更文件，修改了 prepare_for_caching_req 方法，为 ReplaySSM 添加了缓存长度修正逻辑。

关键符号：prepare_for_caching_req

关键源码片段

python/sglang/srt/mem_cache/unified_cache_components/mamba_component.py

核心变更文件，修改了 prepare_for_caching_req 方法，为 ReplaySSM 添加了缓存长度修正逻辑。

def prepare_for_caching_req(
    self,
    req: Req,
    insert_params: InsertParams,
    token_ids_len: int,
    is_finished: bool,
) -> Optional[int]:
    # 根据是否启用额外缓冲区决定 cache_len 基准
    if self.enable_mamba_extra_buffer:
        cache_len = req.mamba_last_track_seqlen
    else:
        cache_len = token_ids_len
        # ReplaySSM 模式（无额外缓冲）：temporal[slot] 实际上滞后于
        # 活跃状态的写入进度，滞后深度由 write_pos 记录。
        # 当请求结束时，需将 cache_len 减去滞后深度，使得捐赠给
        # radix cache 的 checkpoint 与 key 长度一致。
        # 同时将 write_pos 清零，以便后续重用。
        # page_size 被断言为 1，因此无需重新对齐。
        if is_finished:
            write_pos_buf = (
                self.cache.req_to_token_pool.mamba_pool.replayssm_write_pos
            )
            if write_pos_buf is not None:
                # 减去未冲刷的环深度，确保长度匹配
                cache_len -= int(write_pos_buf[req.mamba_pool_idx].item())
                # 重置写入位置
                write_pos_buf[req.mamba_pool_idx] = 0
​
    if is_finished:
        if cache_len is None:
            cache_len = 0
        # ... 后续逻辑：根据需要设置 mamba_value 等（未改动）

评论区精华

唯一一条 review 评论来自 gemini-code-assist[bot]，指出两点潜在问题：

• TypeError 风险：如果 req.mamba_pool_idx 为 None（例如请求在分配 slot 前失败），索引 write_pos_buf 会抛出 TypeError。
• 负值风险：如果 write_pos_buf[req.mamba_pool_idx] 大于 cache_len，减法后 cache_len 可能变为负数，导致后续切片行为异常。

该评论建议增加判空保护和 cache_len 下限截断。然而，作者没有回复或采纳建议，最终 PR 以当前状态合并。

• 边界安全：req.mamba_pool_idx 可能为 None 且 cache_len 可能为负 (correctness): 未采纳建议，PR 按原样合并。作者未回复此评论。

风险与影响

• 风险：
  1. 空指针访问风险：req.mamba_pool_idx 可能为 None，若在分配 slot 前调用此方法，将导致 TypeError（如上 review 评论所述）。
  2. 负值风险：同样来自 review 评论，cache_len 可能变为负数，后续使用 cache_len 作为切片长度时可能导致意外行为。
  3. 回归风险：该修改位于共享缓存路径，影响所有使用 UnifiedTree 且未启用 mamba extra buffer 的请求。鉴于 CI 已通过，回归概率较低。
  4. 缺少单元测试：新增的 ReplaySSM 逻辑没有对应的单元测试覆盖边界情况。
     - 影响：影响范围仅限于 experimental_use_mamba 场景下的 UnifiedTree 缓存组件。受益于该修复，ReplaySSM 模式在请求结束时的缓存一致性得到保障，避免了因 key 长度不匹配导致的 cache miss 或错误状态恢复。后续可能需要对 gemini-code-assist 指出的风险做进一步防御。
     - 风险标记：缺少错误处理, 边界条件未覆盖, 缺少单元测试

关联脉络

• 暂无明显关联 PR