Prompt Cache：别再为同样的 System Prompt 重算一遍

多轮对话里 System Prompt 每次都一样——500 Token 的固定前缀每轮推理都要重跑一遍 Prefill。等于把同一段文字反复读几十上百遍。Prompt Cache 就是来省掉这件重复劳动的。正常推理流程下一个新请求进来先跑 Prefill全 Prompt 的 K/V 全部算一次然后进入 Decode每步算一个新 Token。如果 System Prompt 有 500 Token、用户输入 100 TokenPrefill 跑了 600 Token。第二次对话 System Prompt 一样、用户输入变成 80 Token——Prefill 又跑了 580 Token其中 500 Token 跟上一轮完全一样。Prefix Cache 的原理Prompt Cache也叫 Prefix Cache不存完整的 KV Cache——它只存 Prompt 前缀部分的 K/V。新请求进来时先拿 Prompt 的前 N 个 Token 去 Cache 里查——有没有匹配的前缀。有的话这 N 个 Token 的 K/V 直接复用Prefill 只算新增的部分。Prefix Cache 的命中流程 请求 1Prompt [SYS_500] [USER_100] → Prefill 全部 600 Token → 缓存 [SYS_500] 的 KV → hash(SYS_500) → Cache 条目 请求 2Prompt [SYS_500] [USER_80] → hash(SYS_500) 命中 → 跳过 500 Token 的 Prefill → 只 Prefill USER_80 部分80 Token → 500 Token Prefill 时间直接省掉多轮对话里第一轮是冷启动全量 Prefill第二轮起 Cache 命中率接近 100%。一个客服机器人一天 10 万请求90% 是第二轮及以后的对话——Prefill 节省的总时间非常可观。Runtime 如何管理 Prompt CacheCANN 的 Prompt Cache 实现在 Runtime 层不在应用层。好处是跟 NPU 显存管理和 HCCL 通信直接打通不用在 Host 和 Device 之间搬 Cache 数据。Cache 维护逻辑每个 Prefix 用 Token 序列的 hash 做键存在 NPU 显存里不搬回 CPU。新请求查 Cache——有命中就跳过对应 Prefill未命中就完整 Prefill 后把 Prefix 写入 Cache。Cache 满了走 LRU 淘汰——最久没被命中的条目被清除释放显存。# Prompt Cache 管理——Runtime 侧简化逻辑classPromptCache:def__init__(self,max_gb2):self.poolacl.rt.malloc(max_gb*1024**3)self.entries{}# {hash: {kv_offset, size, last_access}}deflookup(self,prefix_tokens):keyhash(tuple(prefix_tokens))ifkeyinself.entries:self.entries[key][last_access]now()returnself.entries[key][kv_offset]# NPU 显存地址returnNonedefinsert(self,prefix_tokens,kv_data):keyhash(tuple(prefix_tokens))offsetself.pool_alloc(kv_data.nbytes)acl.rt.memcpy(offset,kv_data)# 存进 Poolself.entries[key]{offset:offset,size:kv_data.nbytes,last_access:now()}ifself.pool_free256*1024**2:# 不足 256MB 时淘汰self.evict_lru()收益量化一个 AI 客服System Prompt 500 Token每轮用户输入平均 100 Token。1000 并发每个用户 10 轮对话。不使用 Prompt Cache每轮 Prefill 600 Token总 Prefill Token 数 1000 × 10 × 600 6M Token。每次 Prefill 约 12ms500100 Token每用户 10 轮 120ms Prefill 总时间。使用 Prompt Cache第一轮 600 Token Prefill12ms后 9 轮只有 100 Token Prefill约 2ms。每用户 10 轮 12 9×2 30ms。省了 90ms/用户——1000 用户省了 90 秒 NPU 时间。什么场景不适合每个请求 Prefix 都不一样——Cache 命中率接近零。Batch 小导致 Cache 插入即淘汰——Cache 没热起来就被清空。真正的收益集中在大 Prefix、高频重复的场景客服机器人、代码助手Tool 描述固定、RAG 的 System Prompt。参考仓库cann-recipes-infer 推理 RecipesRuntime 运行时ATB Transformer 加速库CANN 学习中心