执行摘要
此PR为SGLang的HiCache文件后端添加了对流水线并行（PP）维度的基本支持，通过扩展存储配置命名空间以包含PP秩和大小信息。这是一个为后续完整兼容性解决方案做准备的增量变更，影响范围限于内部存储后端实现，风险较低但需关注配置格式变更可能带来的缓存兼容性问题。
功能与动机
根据PR描述，主要动机是"在FileBackend中添加流水线并行（PP）所需的键支持"，并明确指出"HiCache与PP之间的兼容性问题将在后续PR中解决"。这表明这是一个分步实施策略的第一步：先扩展存储后端的键空间以容纳PP维度，为后续的完整兼容性功能奠定基础。
实现拆解
变更集中在python/sglang/srt/mem_cache/hicache_storage.py文件的FileBackend.__init__方法中：
-
参数提取扩展：从storage_config中新增提取pp_rank和pp_size参数
tp_rank, tp_size, pp_rank, pp_size, model_name, is_mla_model = (
storage_config.tp_rank,
storage_config.tp_size,
storage_config.pp_rank, # 新增
storage_config.pp_size, # 新增
storage_config.model_name,
storage_config.is_mla_model,
)
-
配置后缀逻辑更新：
- 新增
enable_pp = pp_size > 1条件判断
- 当PP启用时，在原有后缀基础上追加
_{pp_size}_{pp_rank}
- 保持原有MLA模型和非MLA模型的后缀生成逻辑不变
-
目录创建逻辑：维持原有的tp_rank == 0时创建目录的逻辑不变
评论区精华
review讨论非常有限，主要价值点来自关联Issue的评论：
stmatengss: "'compatibility issues between HiCache and PP will be addressed in a follow-up PR' => I'm unsure whether this PR is related (https://github.com/sgl-project/sglang/pull/15175). FYI @hzh0425"
这揭示了两个重要信息：1）存在专门处理HiCache与PP兼容性问题的PR #15175；2）社区成员关注此PR与那个更大范围解决方案的协调关系。作者未直接回应此问题，仅展示了测试运行成功的截图。
风险与影响
技术风险：
- 配置格式变更风险：新的后缀格式
_{pp_size}_{pp_rank}可能使现有缓存文件无法被识别，如果系统中有使用旧格式的缓存，可能导致缓存失效或需要迁移
- 边界条件处理：
enable_pp = pp_size > 1的逻辑简单，但未考虑pp_size=0或负值等异常情况
- 测试覆盖不足：变更缺少针对PP参数各种组合的单元测试
影响分析：
- 用户影响：无直接用户影响，这是内部实现细节
- 系统影响：为流水线并行场景下的HiCache使用创造了条件，但完整功能需等待后续PR
- 团队影响：需要确保后续的兼容性PR与此变更保持接口一致性
关联脉络
从近期历史PR分析可见，HiCache是SGLang持续优化的重点模块之一：
- PR #21842 添加了Mooncake transfer engine的手动初始化测试，同样涉及HiCache
- 多个PR（如#21920、#21225）关注推测解码（speculative-decoding）优化，这是HiCache可能服务的场景之一
特别值得注意的是stmatengss提及的PR #15175，虽然不在提供的近期PR列表中，但根据评论推断，那可能是处理HiCache与PP完整兼容性的大规模变更。本PR应被视为那个更大解决方案的技术铺垫——先解决存储键空间的基础问题，再处理更复杂的兼容性逻辑。
这种分步实施策略在大型系统中常见：先建立基本的数据结构支持，再逐步完善功能逻辑。团队在推进HiCache对流水线并行的支持时，采取了这种渐进式演进路径。
参与讨论