根据Issue #19332，当启用L3 KV缓存（HiCache）时，SGLang在TCP环境下显示内存使用持续增加，甚至导致OOM。PR body指出，HiCache存储alloc()视图时保留了旧host-pool backing storage的引用，导致内存泄漏，复现步骤显示内存从77g增长到102g。
建议工程师阅读此PR以理解内存泄漏的根本原因和修复方法，特别是在缓存和长期引用场景中。对于维护HiCache或类似系统的开发者，这是一个值得关注的内存管理案例。
Review中只有gemini-code-assist[bot]的评论，指出克隆host indices以防止共享引用副作用，xiezhq-hermann批准了变更。Issue评论中，dcosmos确认修复有效。没有争议点，讨论简洁。
实现方案是在两个HiCache相关文件的备份函数中，将host indices克隆后再存储到节点中。具体修改：在hi_mamba_radix_cache.py的write_backup和mamba_backup_commit函数中，添加.clone()；在hiradix_cache.py的write_backup函数中同样添加.clone()。这确保节点持有独立副本，避免共享引用导致的泄漏。
| 文件 | 模块 | 状态 | 重要度 |
|---|---|---|---|
python/sglang/srt/mem_cache/hi_mamba_radix_cache.py |
缓存子系统 | modified | 8.0 |
python/sglang/srt/mem_cache/hiradix_cache.py |
缓存子系统 | modified | 8.0 |
分析完成后，这里会展示 LLM 生成的相对完整源码片段和详细注释。
gemini-code-assist[bot] 指出克隆防止共享引用副作用，避免内存泄漏。
结论：变更被批准，修复有效，无争议。 · 已解决
主要风险是.clone()可能引入额外的内存分配和拷贝开销，轻微影响性能，但权衡修复内存泄漏是合理的。变更仅涉及两处代码，回归风险低，但需在部署后监控内存使用和性能。
该修复直接影响启用HiCache的用户，消除内存泄漏，提升系统稳定性和可靠性，减少OOM风险。对性能影响可能微小，但改善了长时间运行工作负载的资源管理。影响范围限于使用分层缓存的场景。
本PR修复了SGLang中HiCache模块的内存泄漏问题，通过克隆host indices避免长期引用旧存储。变更仅涉及两处代码修改，但显著提升了系统在启用分层缓存时的稳定性和资源管理能力。
动机：根据Issue #19332，当启用L3 KV缓存（HiCache）时，SGLang在TCP环境下显示内存使用持续增加，甚至导致OOM。根本原因是HiCache在存储alloc()视图时，保留了旧host-pool backing storage的引用，导致内存泄漏。PR body中提供了复现步骤，显示内存从77g增长到102g。
核心修改点：
python/sglang/srt/mem_cache/hi_mamba_radix_cache.py：write_backup函数中，将node.host_value = host_indices改为node.host_value = host_indices.clone()。mamba_backup_commit函数中，同样添加.clone()。python/sglang/srt/mem_cache/hiradix_cache.py：write_backup函数中，将node.host_value = host_indices改为node.host_value = host_indices.clone()。关键逻辑：通过克隆host indices，确保缓存节点持有独立副本，避免共享引用导致的长期内存占用。
review讨论：
Issue反馈：dcosmos确认修复有效，解决了#19332中的问题。
风险分析：
.clone()可能引入额外内存分配和拷贝，轻微影响性能，但权衡修复内存泄漏是必要的。影响评估：
相关PR：
演进趋势：近期HiCache相关PR频繁，显示团队在持续优化缓存性能和可靠性，本PR是解决内存泄漏的关键一环。
参与讨论