前缀缓存与缓存感知路由：公共提示词为什么只需算一次

01 · 一个请求会缓存，多个请求仍可能重复算

一家企业把1024个 token 的规则文档放在每次请求开头，后面接128个 token 的具体问题。即使每个请求在 Decode 时已经复用了自己的历史 KV，10个请求的 Prefill 仍可能把相同文档重新算10遍。

前缀缓存把已处理的公共起始部分留下来。第二个兼容请求找到这份缓存后，可以从公共前缀之后继续计算自己的后缀。最终生成的答案仍由模型针对当前问题产生。

依据：vLLM · Automatic Prefix Caching 使用与边界 ↗

02 · 为什么必须是兼容的“前缀”

一个位置的高层 K/V 依赖它之前的上下文。句子“请总结”出现在一篇合同之后，和出现在一个故事之后，即使 token 一样，也可能有不同的 K/V。匹配任意中间段落是不够的，必须确认从序列起点到共享边界的条件相容。

缓存匹配应基于实际送入模型的 token 序列和计算身份。肉眼看起来相同的文字，经过不同聊天模板、特殊 token、分词器或适配器后，不一定可共享。多模态输入还需确认对应输入内容，而不能只比较图片占位符。

03 · 用“前块身份 + 当前块内容”定位缓存

一种实现方法是把前缀按块建立索引。假设每块4个 token，第一块是 [A,B,C,D]，第二块是 [E,F,G,H]。第二块的身份不仅包含 E 到 H，也包含第一块的身份；第三块再接上第二块身份。这条链记录了此前完整上下文。

parent_key = identity(model, adapter, position_config, cache_namespace)
for full_block in prompt_blocks:
    key = hash(parent_key, exact_token_ids(full_block), extra_input_identity)
    if cache_index.contains(key):
        attach_readonly_block(request, cache_index[key])
    else:
        stop_matching_and_prefill_remaining_tokens()
        break
    parent_key = key

vLLM 的设计文档给出了包含父块、块内 token 和额外身份的哈希方案，并说明其普通前缀块缓存的完整块条件。具体边界、混合模型状态与命中粒度要按引擎核对，不宜把一种实现说成所有前缀缓存的定义。

依据：vLLM · 前缀缓存哈希、块引用与生命周期设计 ↗

04 · 十个请求的工作量，怎样算才不夸大

仍用1024个公共前缀 token、128个独立后缀 token、10个请求的例子。理想情况下，首次计算1152个位置，后续九个请求各计算128个新位置：1152 + 9×128 = 2304。逐请求从头 Prefill 则处理10×1152 = 11520个位置，减少9216个重复位置，占原数量的80%。

本例有128个未命中后缀，最终后缀输出可产生首 token。如果请求的整个提示词都命中，缓存只保存 K/V 时未必保存了产生首 token 所需的最后 logits；有的实现仍计算末尾 token 或尾块，不能笼统承诺“全命中意味着零计算”。

05 · 共享之后，谁能写、何时能释放

请求A和B可以引用同一组完整前缀块，各自的后缀使用自己的空间。共享部分应按引擎约定保持只读；需要改变共享尾部时，通常要采用复制后写入或分配私有块。请求结束是减少引用，并不意味着立刻销毁仍被别的请求使用的块。

• 引用计数：确认还有哪些请求或缓存索引保留块。
• 淘汰策略：容量有限时，在收益与占用之间选择保留哪些可复用内容。
• 缓存分层：从 CPU、远端或其他实例取回内容，需要计入传输和格式转换成本。
• 共享尾块处理：未满块是否可命中、是否复制，由具体实现决定。

前缀缓存与分页 KV 是互补关系：前者回答“哪些结果可再次使用”，后者回答“结果怎样分配、寻址和共享”。结果缓存则直接返回以前的答案，三者不要混为一谈。

06 · 缓存感知路由：命中最多的实例一定最快吗

当模型有多个服务实例，实例A可能已经持有公共文档，实例B还没有。路由器知道各实例的缓存位置，就能尽量减少重复 Prefill。但它也需要考虑已经分配过去的工作，否则请求不断涌向A，热缓存会变成排队热点。

这些毫秒数是自设条件，不是 Dynamo 的实测或内部固定公式。它说明路由要综合缓存收益与负载；跨设备或远程缓存还要加入取回成本。缓存位置事件也可能滞后，需要处理淘汰、失败和迁移。

NVIDIA Dynamo 的官方路由说明把前缀重叠与已分配负载一起用于选择执行实例。这是系统执行线上的分布式服务能力，不能由单个 Attention 算子自动完成。

依据：NVIDIA Dynamo · KV-Aware Routing ↗

07 · 怎样做一个可验证的实验

# 固定模型、模板、采样设置；两组试验使用独立的缓存初始状态
cold_run = run_requests(prompts, prefix_cache=False)
warm_run = run_requests(prompts, prefix_cache=True)
record(cache_hit_tokens, uncached_prefill_tokens, TTFT_p50_p95, throughput)
# 再加入前缀不同、并发增加、缓存受限与模型/适配器切换的用例

vLLM 官方文档提供 enable_prefix_caching=True 的接入入口；执行时仍应核对所用模型和引擎版本。先检查兼容请求命中，再检查后缀输出与无缓存运行是否在误差范围内一致，最后测服务指标。只测第一个冷请求，看不到复用收益；只测热请求，又会高估真实负载收益。

下方纯 Python 教学例子用两个不同后缀复用同一份前缀 K/V，验证两者分别与完整前向一致。它复制状态来模拟隔离，没有实现哈希索引、块池或分布式路由。

依据：vLLM · Automatic Prefix Caching 使用与边界 ↗

08 · 适用范围与平台检查

长公共 system prompt、重复文档问答、多轮对话已有历史等场景更容易产生收益。前缀不断变化、主要时间耗在生成很长答案、缓存容量不足或取回很慢时，收益可能很小。多轮对话只有已经计算且仍兼容的部分可共享，刚生成而尚未前向的末尾 token 不能凭空已有 K/V。

比较 NVIDIA 与昇腾路径时，要分别核对执行引擎的前缀匹配、缓存事件、共享块、路由与传输支持。通用复用原理可以相同，特定 Dynamo 组件和配置不代表另一平台自动具备同等接入能力。

作为昇腾的具体阅读入口，vLLM Ascend 的 main 功能矩阵把 Automatic Prefix Caching 列为可用功能。功能矩阵说明有实现入口；它不证明所有模型、其他并行功能与每种缓存精度都能任意组合。

依据：vLLM Ascend · 支持功能矩阵（main） ↗

• 确认复用覆盖了公共前缀，而不只是每请求内部 Decode 缓存。
• 确认共享条件包含模型、实际 token、位置、适配器等身份。
• 把缓存驻留容量与新增请求容量一起测量。
• 同时报告冷/热混合负载、命中率、首 token 时间和吞吐。

09 · 读完应该能回答

• 为什么相同段落放在不同开场白之后，不能直接共享高层 KV？
• 前缀缓存与返回旧答案的缓存有何区别？
• A的命中率更高，为什么路由仍可能选择B？
• 缓存提示词100%命中，为什么仍可能做末尾计算？

流程位置与关联方法

这个方法可能出现在多个位置；计算线包含模型计算与算子实现，执行线包含运行时、内存和通信。

资料与核查范围

原理依据以原始论文和官方文档为主；算例与时间线是教学推导。文档核查日期：2026-10-08。引用 main / latest 文档时，实际接口以安装版本为准。

• vLLM · Automatic Prefix Caching 使用与边界 ↗
• vLLM · 前缀缓存哈希、块引用与生命周期设计 ↗
• NVIDIA Dynamo · KV-Aware Routing ↗
• TensorRT-LLM · KV Cache System ↗
• vLLM Ascend · 支持功能矩阵（main） ↗

代码为接入片段或教学伪代码；本页没有声称完成 NVIDIA / 昇腾硬件实测。