[Bug]: OffloadingConnector stores but never serves when MTP/EAGLE speculative decoding is enabled (hybrid GDN model, XPU)

快速结论：该报错发生在 vLLM XPU 环境启用 EAGLE/MTP 推测解码并配合混合 GDN（门控延迟网络）模型使用 OffloadingConnector 时，表现为 KV 缓存只存不取、检索命中率为 0。优先排查 `offloading/scheduler.py` 中 `is_eagle_group` 的误分类问题。

适用环境：Ubuntu 24.04.4 LTS、Python 3.12.3、PyTorch 2.13.0+xpu、Intel Arc Pro B70 Graphics、XPU runtime 20260000、vLLM XPU kernels 0.1.dev1。

最快修复方案：目前尚无已验证的一步修复方案，但社区维护者正在推进 PR #52771。可优先尝试将 `is_eagle_group` 强制设为 `False` 以进行临时验证（仅为定位手段，非正式修复）。

注意事项：该问题根因已定位但修复尚未合入主线；强制改动 `is_eagle_group` 仅用于复现验证，不建议用于生产环境；PR #52771 中提到的其他修复点尚未经过完整的端到端 XPU 硬件验证。

问题场景

用户在 vLLM XPU 环境运行混合 GDN 模型（如 Mamba 对齐结构 + full-attention），启用 EAGLE/MTP 推测解码并开启 KV offload 后，发现 OffloadingConnector 能够存储 KV 条目，但在检索时无法命中任何缓存。复现流程为：max_tokens=1 触发 A→完成→A 的请求流程，第二次 A 请求从 offload 层读取 token 数为 0。

报错原文

[Bug]: OffloadingConnector stores but never serves when MTP/EAGLE speculative decoding is enabled (hybrid GDN model, XPU)

原因分析

根据维护者的定位分析，根因不在存储/保留路径，而在检索（lookup）路径。问题链条如下：

误分类触发点：scheduler.py 第 227-231 行的 fallback 逻辑将所有 group 都标记为 eagle 类型；
级联失效：第 797-799 行的 unconditional volatile-tail pop 对 full-attention group 执行 num_hit_chunks -= 1；
补偿缺失：第 762-768 行没有对应的查询加宽机制（加宽仅限 sliding-window 路径）；
最终归零：第 749-751 行，pop 后边界低于 mamba/GDN group 的粗粒度 chunk 划分，导致 _lookup_complete_chunks 对整个请求返回 0——尚未查询 mamba group 就已经失败。

此外，_sliding_window_lookup 的 consecutive-window 要求（第 145 行的 reachable_tail = window + int(is_eagle)）存在同源的 sibling 零路由问题。

环境排查

确认 Python 版本：3.12.3
确认 PyTorch 版本：2.13.0+xpu（CUDA used to build PyTorch: None，非 CUDA 构建）
确认 XPU 可用及 Intel GPU 型号（如 Intel Arc Pro B70 Graphics）
确认 XPU runtime 版本：20260000
确认 vLLM XPU kernels 版本：0.1.dev1+g4509e9f97
确认复现时使用的 EAGLE/MTP 模型拓扑为 full-attention + mamba-align 混合结构
确认 speculative_config 是否启用及具体 eagle-family 配置

解决步骤

临时定位验证（可优先尝试）：在 offloading/scheduler.py 中，将所有 group 的 is_eagle_group 强制设为 False，保持 speculative 开启状态，观察第二次 A 请求是否恢复 offload 命中（预期可从 0 恢复到 16/28 token）。此步骤仅用于确认根因，不应作为生产修复。
关注并测试 PR #52771：该 PR 计划修复三个层面：对所有 group 类型加宽 eagle 查询（防止 pop 操作饿死 sibling group）；在请求完成时保存 final chunk；可能收窄 all-groups fallback 逻辑。
配合维护者进行端到端验证：维护者建议在 PR 构建上运行 3 分钟确定性复现测试，并观察指标：kv_offload_total_bytes_total{transfer_type="CPU_to_GPU"} 和 kv_offload_load_bytes_total 应为非零值。
关注关联 Issue #52047：该 Issue 涉及 drafter group 的 attention spec 标记为 non_causal_multi_token_decode 的情况，与当前问题的 shared-KV 路径可能相关，需协调避免重复修复。

验证方法

问题是否已解决，应通过以下两个指标确认：

运行确定性复现测试时，第二次 A 请求不再返回 0 命中，而是能正常从 offload tier 读取已存储的 KV chunk（在作者环境中预期恢复为 16/28 token）。
监控 kv_offload_total_bytes_total{transfer_type="CPU_to_GPU"} 指标，确认在合理延迟内变为非零，且步骤 4（即第二次 A 请求）的延迟应下降至接近步骤 2 的水平。