SGLang 安全更新：改进请求隔离
内容提要
2026年9月，Cloudflare报告其Workers AI上GLM-5.3部署存在跨请求KV缓存泄露：预填充缓存池容量小于配置上下文长度，被拒请求仍进入分离式预填充/解码交接，解码读到未填充的缓存页，可能返回他人会话内容。SGLang修复了准入路径，并引入延迟释放机制：中止时保留槽位，待各预填充节点排空在途RDMA写并确认或超时后再释放，防止迟到写入污染其他请求。建议升级至v0.5.21以上并监控释放指标。
延伸解读
问题根源：配置容量与缓存池不匹配
Cloudflare 部署的 GLM-5.3 配置上下文长度为 1,048,576 tokens，但预填充 KV 缓存池仅能容纳 681,280 tokens。请求可能符合配置窗口却超出实际内存，触发拒绝路径。在分离式预填充/解码架构中，被标记拒绝的请求仍进入交接，解码读到未填充的缓存页，导致跨请求内容泄露。这提醒运营者需核对池容量与上下文长度是否一致。
修复核心：延迟释放与排空确认
SGLang 引入延迟释放机制：中止时保留槽位，向各预填充节点发送 ABORT 通知，节点排空在途 RDMA 写后回复 ABORT_ACK，解码收到所有确认或超时后才释放槽位。这防止迟到写入污染其他请求。同时准入路径修复确保被拒请求在进入分离式交接前返回错误。运营者应升级至 v0.5.21 以上，并监控释放指标。
影响范围与升级建议
该竞态影响启用 PD 分离且使用 Mooncake、NIXL 或 MORI 等传输后端的部署，默认配置从 v0.4.x 到 v0.5.21（MORI 需 v0.5.22）均受影响。单实例部署不受此特定竞态影响。建议升级至 v0.5.21 以上，MORI 用户需 v0.5.22；并运行能配对中止的路由器，作为第一层防御。
运营监控与性能权衡
升级后应关注 sglang:decode_deferred_kv_release_total{outcome} 指标，健康部署应几乎全部通过 drained 释放；超时比例高说明确认路径需检查。性能测试显示该功能对吞吐影响在 ±2% 内，不显著。中止路径上，确认快速路径正常时释放仅毫秒级；若确认丢失，每次中止需等待完整超时（默认 30 秒），可通过调整超时和批大小平衡安全与资源占用。
Q&A
SGLang 这次安全更新修复了什么问题？
修复了分离式预填充/解码（PD）服务中跨请求 KV 缓存泄露与污染问题：被拒绝或中止的请求仍可能进入交接流程，或其在途 RDMA 写迟到落盘，导致解码读到他人会话的缓存内容。
Cloudflare 报告的 GLM-5.3 事件是怎么发生的？
其部署配置上下文长度为 1,048,576 tokens，但预填充 KV 缓存池只能容纳 681,280 tokens；超限请求本应被拒，却仍进入分离式预填充/解码交接，解码读取了未为该请求填充的缓存页，可能返回其他用户会话内容。
延迟释放机制是如何防止迟到写入污染其他请求的？
中止时解码端不立即释放槽位，而是保留 KV 缓存槽、请求池行和元数据缓冲；同时通知所有预填充 rank 丢弃未入队块，各 rank 排空在途写后回复 ABORT_ACK，解码端在全部确认或超时后才释放，且释放的槽位不进入 radix 树、直接隔离丢弃。
哪些部署会受这个中止传输竞态影响？
需同时满足：启用 PD 分离并使用 KVCache 传输后端（Mooncake、NIXL、MORI 或自定义 CommonKVManager）；请求在传输中途终止且至少一个写已发出未落盘；分配器在写落盘前把槽位重新分配给其他请求。单实例无跨引擎传输的部署不受此特定竞态影响。
运维者应该升级到哪个版本，升级后要监控什么？
建议升级到 v0.5.21 及以上（Mooncake、NIXL 默认受保护）；MORI 及带代际标签的确认需 v0.5.22，并建议构建包含 #41128。升级后监控 sglang:decode_deferred_kv_release_total{outcome}，健康部署绝大多数释放应走 drained，超时占比高说明确认路径需排查。
这个修复对推理性能有影响吗？
在 2×H100 上 21 组测试（1024 请求、并发 256）显示吞吐差异在 ±2% 内且置信区间跨零；2×H200 上默认开启成本约 −0.38%（不显著）。仅在池接近耗尽时，中止路径的保留会表现为短暂准入延迟。
PD 校验和是什么，默认开启吗？
是可选的传输完整性检查（#39500），预填充在 GPU 上计算 Adler-32 校验和随最后一块发送，解码在请求加入运行批次前校验，可捕获该时点前的迟到写。默认关闭，需在预填充和解码引擎同时传 --disaggregation-enable-kv-checksum，且两者 KVCache 布局需一致。
