[Bug]: [SpecDecode] Hybrid Mamba (align) corrupts under speculative decoding when a KV connector is attached — even with zero retrieved toke

快速结论：该报错发生在 vLLM 使用 Mamba 混合架构模型（如 Qwen3-8B、Qwen3-27B 的 Hybrid Mamba 版本）启用投机解码（SpecDecode）并挂载 KV Connector（如 LMCacheMPConnector）时，即使检索 token 数为 0 也会出现生成内容损坏。优先排查方向：确认 vLLM 版本是否包含 #50344 修复，并检查是否仍在使用 0.27.1 或更早版本。

适用环境：vLLM v0.27.1（已验证）、vLLM main 分支（待验证）；Ubuntu 24.04.4 LTS、Python 3.12.3、CUDA 12.8.61（PyTorch 构建于 CUDA 13.0）；NVIDIA GeForce RTX 3090（双卡）与 RTX 5090（SM120）；模型涉及 Qwen3-8B 及 Qwen3-27B（Qwen-GDN hybrid，mamba_cache_mode=align，block_size=1600），启用 MTP 投机解码时 num_speculative_tokens=2。

最快修复方案：暂无确认的一步修复方案。Issue 作者在面对相同损坏时已退回“关闭投机解码 + 仅启用 LMCache”的稳定组合用于生产环境。若仍希望保留投机解码，请优先尝试升级到包含 #50344（commit d6941300fc）的 vLLM nightly 或更新正式版，但这仅是维护者推测的针对性修复，作者在 0.27.1 上手动回移该补丁后实测 损坏依然存在。

注意事项：即使确认 connector 走的是 get_computed_blocks()（与无 connector 路径相同的定点查找），损坏仍会发生，说明问题不限于查找分支本身，可能涉及投机解码回滚与 connector 每步调用的状态同步（如 update_state_after_alloc、build_connector_meta、GetStoreMetadata）冲突，或 D2H store 读取与 spec-verify 写入的竞争。此外，在“检索禁用”实验中，lookup 仍会增加 tracker.num_stored_tokens，导致 store 窗口前移、部分数据未写入，这会干扰后续日志分析，但不属于核心正确性问题。

问题场景

用户在 vLLM 中运行 Qwen-GDN 等 Hybrid Mamba 模型（mamba_cache_mode=align），同时启用了投机解码（speculative decoding）和 KV connector（例如连接 LMCache 的 LMCacheMPConnector）。即使在“已禁用检索”（retrieve 到 0 个 token）的实验配置下，模型在长时间运行（约 40 分钟后）或特定硬件（RTX 5090）上仍会生成损坏文本。典型表现为生成流中出现 U+FFFD 替换字符（即字节级乱码）或输出循环重复。

报错原文

[Bug]: [SpecDecode] Hybrid Mamba (align) corrupts under speculative decoding when a KV connector is attached — even with zero retrieved tokens

（实际运行环境中未看到明确的 Python traceback，主要表现为输出质量损坏，例如：）

byte-level garbage in the reasoning stream (U+FFFD replacement-char fragments)

原因分析

维护者提出的补丁（#50344）将“per-group divergent local hits”仅用于显式声明支持该能力的 connector（如 NIXL），而默认 connector 与 LMCacheMPConnector 不支持，因此应当回退到 HybridKVCacheCoordinator 的定点查找路径。但 Issue 作者将补丁回移到 v0.27.1 后，问题依旧存在，因此该分支选择并非唯一根因。

可能原因：在投机解码的 spec-verify 回滚路径中，connector 存在这一事实引入了额外的单步调用（update_state_after_alloc 等）或 D2H store 读取与 spec-verify 写入产生竞争，导致 Mamba 状态迁移时共享状态损坏。另一个可能方向是 tracker.num_stored_tokens 被检索命中量推进后导致 store 窗口偏移，虽然作者认为这不构成正确性问题，但它与状态同步的关系尚未完全撇清。

环境排查

vLLM 版本：确认是 0.27.1 tag、包含 #50344 的 main 分支，还是 nightly 构建；#50344 的 commit d6941300fc 虽早于 0.27.1 发布，但不是该 tag 的祖先，因此 0.27.1 仍会进入旧分支。
connector 类型：确认是否使用 LMCacheMPConnector，它不会将 supports_divergent_local_hybrid_hits 置为 True；只有 NIXL 会显式开启该能力。
模型与缓存参数：确认是否使用 Hybrid Mamba（如 Qwen-GDN）且 mamba_cache_mode=align，并记录 block_size（如 1600）。
投机解码配置：确认 num_speculative_tokens（如 2）与 MTP 配置。
记录调度器启动日志中的 connector.supports_divergent_local_hybrid_hits 值，以判断实际选用了哪条 lookup 分支。

解决步骤

首选回归对照：在相同工作负载下，先尝试关闭投机解码（--speculative-model 相关配置不启用），保留 KV connector，确认是否出现损坏。Issue 作者通过此组合恢复了生产稳定性。
升级 vLLM：升级到包含 #50344 的 main/nightly 构建或更新正式版（0.27.1 不含该修复），然后重跑相同压力场景（长时间多会话、共享工具前缀、compaction、部分命中），观察约 40 分钟后是否仍然损坏。
如在旧版验证，可参考 Issue 作者经验，可优先尝试将 #50344（commit d6941300fc）作反向移植：在 KVConnectorBase_V1 增加默认 False 的 supports_divergent_local_hybrid_hits 标志，并在 Scheduler.schedule() 增加 _get_local_prefix_cache_hit() 分发，替换原先的无条件 get_computed_blocks_for_connector() 调用；运行中需确认 incapable connector 实际走了固定点查找路径。
如果升级后仍损坏，可优先尝试在运行时打印 supports_divergent_local_hybrid_hits 以便确认策略，并观察“检索 token 为 0 时是否仍会推进 tracker.num_stored_tokens”——Issue 指出这会导致 store 窗口前移，虽未定性为直接根因，但有助于缩小排查范围。
若涉及 RTX 5090（SM120），请在回复中附上同样的失效现象，作者确认在 SM120 上同样存在该损坏类别。

验证方法

通过长时间压力测试（多次长会话 agent 场景、共享工具前缀、compaction、部分命中）验证是否持续运行超过约 40 分钟仍未出现输出乱码或循环。检查生成流中是否出现 U+FFFD 或重复片段。若手动补丁有效，可在调度器日志中确认 connector 实际走了 get_computed_blocks() 且无 get_computed_blocks_for_connector() 路径，并检查 retrieve/store 区间是否自洽。