分层缓存、存储后端与更深的运行时故障面#

这章解决什么问题#

当书已经走到维护层时，还会剩下一类更深、更不适合塞进前面主线章节的问题：如果系统启用了更复杂的分层缓存、storage backend 或远端缓存路径，很多异常就不再只是 scheduler、KV cache 或单机 observability 可以解释的了。

这一章的目标，就是把这些“更深层但仍属于主线延伸”的故障面单独拉出来。这样一来，整本书就不会只覆盖常见路径，而会开始触及更复杂运行时配置下的维护现实。

为什么 HiCache / storage backend 值得单独收口#

从 docs/advanced_features/hicache_best_practices.md、hicache_design.md、runtime attach/detach 文档以及 model_runner.py 中与 Mooncake / storage backend 相关路径看，分层缓存不是一个简单插件，而是会显著改变系统对“缓存命中、预取、写回、存储后端”的理解方式。

这意味着一旦系统进入分层缓存和存储后端路径，前面关于 cache 的理解就要再多一层：不仅要看本地 reuse 和 eviction，还要看远端状态是否存在、是否被预取、是否已经写回，以及控制面和数据面是否对这些状态有一致认识。

本章对应哪些代码路径#

这一章的锚点主要包括 docs/advanced_features/hicache_best_practices.md、docs/advanced_features/hicache_design.md、docs/advanced_features/hicache_storage_runtime_attach_detach.md、python/sglang/srt/model_executor/model_runner.py 中与 Mooncake / storage backend 相关路径，以及 python/sglang/srt/managers/schedule_batch.py 中与 storage hit / cached token 统计相关的字段。

小结#

把这一章补进来之后，扩展与调试这一大节就不再只覆盖“普通主线问题”，而开始触及更深层、更复杂部署形态下的运行时故障面。这正是一本更厚技术书该有的延展能力。