命中率明明变高了为什么延迟还是越来越抖很多团队把 Prefix Cache 接进推理服务后的第一反应是“命中率终于上来了”。⚠️ 在系统提示词和工具说明高度重复的场景里缓存复用确实能省掉不少 Prefill 算力。可流量一旦进入多租户混跑最常见的异常不是命中率下降而是热点前缀长期占住显存块冷租户持续回收重建结果是总命中更漂亮P99 却更差。问题的根子在于很多实现只看“前缀像不像”不看“这块缓存该不该继续留”。 当 Agent 框架统一了 system prompt热门租户天然更容易复用如果缓存池又按全局 LRU 回收冷流量在高峰期几乎拿不到稳定窗口。 这类抖动往往不会先体现在 GPU 利用率而是先出现在prefill_miss_burst、reclaim_count和首包波动上。图 1全局命中率上升不代表每个租户都从 Prefix Cache 中稳定受益 真正被拖垮的不是复用能力而是共享粒度和回收策略在一组 8B 指令模型的压测里基线是 350 并发、单请求平均输入 2.4k token其中 1.6k token 来自公共前缀。 只开全局 Prefix Cache 时整体命中率从 31% 升到 78%看起来相当成功但把流量按租户切开后会发现头部租户命中率接近 92%长尾租户却只有 28%而且回收风暴几乎总在热点租户扩容后出现。策略整体命中率冷租户命中率P99 延迟典型问题全局 LRU78%28%2.4 s热租户长期占块回收风暴明显租户块预算71%54%1.7 s吞吐略降但长尾更稳Prefix 分片 TTL69%61%1.5 s命中率更保守公平性最好这说明 Prefix Cache 的核心矛盾已经不是“要不要复用”而是“谁在复用、谁在为复用付成本”。 如果不同 prompt 版本、检索模板甚至工具 schema 共用了同一个前缀键短期可能抬高命中率长期却会带来语义错配和冷热不均。✅ 更稳的实现需要把 prefix hash、schema version 和 tenant budget 一起纳入 key 与 admission control。图 2Prefix Cache 的优化目标不能只剩整体命中率还要看长尾延迟和冷租户命中️ 更稳的做法是让 Prefix Cache 带着预算和版本号工作工程上更稳的策略通常是三层门禁同时生效。️ 第一层把prompt_id schema_version prefix_hash作为最小复用单元避免不同模板误共用第二层给每个租户设置可借用块数和预填充预算防止头部流量把缓存池抽空第三层用短 TTL 清理低频块并把 reclaim 成本回写到调度器让高抖动租户主动降级到部分复用。️defshould_admit(cache_key,tenant,state):ifcache_key.schema_version!tenant.schema_version:returnFalseifstate.borrowed_blocks(tenant.id)tenant.block_budget:returnFalseifstate.reclaim_rate(tenant.id)0.18andstate.tail_wait_ms(tenant.id)120:returnFalsereturnstate.pool_free_ratio()0.12andstate.ttl_seconds(cache_key)5这段逻辑的关键不是把预算值写死成 128 个块或 5 秒 TTL而是让缓存治理和服务公平性联动。 一旦监控发现某个租户的miss_burst和tail_wait_ms同时抬升就该优先限制新块准入而不是继续用全局命中率给系统“粉饰太平”。 Prefix Cache 只有从“算子优化”升级为“资源治理组件”才不会在高峰时段把长尾请求牺牲掉。图 3Prefix Cache 真正稳定的前提是复用键、租户预算和淘汰规则同时收敛 接下来 3 到 6 个月Prefix Cache 的竞争会转向租户级治理未来更值得看的不会只是哪个框架把 Prefix Cache 命中率做得更高而是谁能把租户级公平性、版本隔离和回收成本做成默认能力。 对企业场景来说统一 prompt 模板越来越多缓存一定会更热但只要租户差异、RAG 模板差异和工具上下文差异还在全局共享就不可能天然正确。笔者认为真正成熟的推理平台会同时盯住租户命中率、冷租户成功率和回收风暴频次而不是只展示一条整体命中率曲线。 你们线上更常见的问题是热点租户吃光缓存还是 prompt 版本更新后命中失真欢迎交流后续还会继续拆 Prefix Cache 预热和多模型共享缓存的工程细节。图 4Prefix Cache 是否健康要看租户级指标而不是只看一条全局命中率曲线