在实际的大语言模型推理场景中每一次生成新 Token 都需要重复计算之前所有 Token 的注意力这带来了巨大的计算开销。为了优化这一过程KV Cache 技术应运而生它通过缓存注意力机制中的 Key 和 Value 矩阵避免了重复计算是当前主流推理框架如 vLLM、TGI实现高性能吞吐的核心技术。然而当用户输入包含大量重复或相似的前缀时例如系统提示词、长文档的固定开头即使有 KV Cache每次请求仍需重新计算并存储这些前缀的 KV 值造成了内存和计算资源的浪费。Prompt Cache前缀缓存正是为了解决这一问题而设计的进阶优化技术。其核心思想是将高频使用的、固定的文本前缀如系统指令、文档模板预先计算其 KV 值并持久化存储。当新的请求包含此前缀时直接复用缓存的结果从而跳过这部分 Token 的计算显著降低首次 Token 的生成延迟Time To First Token, TTFT并减少内存占用。这对于需要频繁调用相同系统提示的聊天应用、批量处理相似格式文档的场景能带来可观的成本节约和性能提升。本文将深入解析 KV Cache 的工作原理及其带来的资源挑战然后详细阐述 Prompt Cache 如何在此基础上进行优化。我们将通过一个概念性的“DSH能力小验证”环节模拟并分析 Prompt Cache 的潜在收益。本文适合正在使用或计划使用大语言模型进行应用开发的工程师、架构师以及对模型推理优化感兴趣的研究者。通过阅读你将理解这两种缓存机制的原理、差异并能在技术选型和架构设计时评估引入 Prompt Cache 的必要性与可行性。1. 理解 KV Cache从重复计算到状态复用的飞跃要理解 Prompt Cache 的价值必须先厘清其优化对象——KV Cache 的工作原理及其局限性。1.1 注意力机制中的计算瓶颈在 Transformer 的解码器Decoder-Only架构中生成每一个新 Token 时都需要计算该 Token 的 Query 向量与之前所有已生成 Token 的 Key 向量的注意力分数再与这些 Token 的 Value 向量加权求和。这个过程是自回归的。如果没有缓存每次生成新 Tokent时都需要从输入的第一个 Token 开始重新计算所有1到t个 Token 的 Key 和 Value 矩阵。假设模型有L层隐藏层维度为H那么生成一个长度为N的序列其计算复杂度约为O(L * H * N^2)。这在实际推理中是无法接受的。1.2 KV Cache 的工作原理与实现KV Cache 的核心思想是空间换时间。在生成过程中将每一层注意力模块计算出的 Key 和 Value 张量缓存下来。当生成下一个 Token 时只需计算当前新 Token 的 Query、Key、Value并从缓存中读取之前所有 Token 的 Key 和 Value拼接后进行注意力计算。一个简化的伪代码过程如下# 假设batch_size1, num_headsh, head_dimd, seq_len 逐步增长 # k_cache, v_cache: 形状为 [layer, batch, seq_len, h, d] 的缓存 def generate_with_kv_cache(model, input_ids, max_length): past_key_values None # 初始缓存为空 generated_ids input_ids.clone() for step in range(max_length): # 前向传播传入过去的 KV 缓存 outputs model(input_idsgenerated_ids[:, -1:], # 只输入最后一个token past_key_valuespast_key_values, use_cacheTrue) # 获取当前步的 logits 和更新后的 KV 缓存 next_token_logits outputs.logits past_key_values outputs.past_key_values # 更新后的缓存包含了新token的KV # 采样下一个token (例如贪婪采样) next_token_id torch.argmax(next_token_logits[:, -1, :], dim-1, keepdimTrue) generated_ids torch.cat([generated_ids, next_token_id], dim-1) return generated_ids在实际框架中如 Hugging Face Transformerspast_key_values是一个包含每一层 K 和 V 缓存的元组。启用use_cacheTrue后模型会自动管理这个状态。1.3 KV Cache 的内存挑战与成本KV Cache 虽然极大提升了计算效率但它将计算负担转移到了内存或显存上。缓存的大小与以下因素成正比批处理大小Batch Size序列长度Sequence Length模型层数Number of Layers注意力头数Number of Heads每个注意力头的维度Head Dimension对于一个典型的模型如 LLaMA-7B层数L32头数h32头维度d128缓存一个 Token 的 KV 值所需的内存约为2K和V * L * h * d * dtype_size例如 fp16为2字节。 计算得2 * 32 * 32 * 128 * 2 bytes ≈ 524,288 bytes ≈ 512 KB per token。这意味着处理一个 1024 个 Token 的序列仅 KV Cache 就可能占用1024 * 512 KB ≈ 0.5 GB的显存。在批处理或长上下文场景下这成为制约吞吐量和可处理序列长度的主要瓶颈。因此出现了 PagedAttentionvLLM、Continuous BatchingTGI等技术来更高效地管理这块内存。注意KV Cache 优化的是同一序列内Token 的重复计算问题。但对于不同请求之间的重复前缀它无能为力。每个新请求都需要独立计算并存储其前缀的 KV 值这正是 Prompt Cache 要解决的痛点。2. Prompt Cache前缀缓存跨请求的共享优化Prompt Cache 将优化的粒度从单个请求内部提升到了多个请求之间。它的目标是将公共的、不变的前缀计算一次多次复用。2.1 核心概念与适用场景核心概念预先计算并存储一段固定文本称为“提示前缀”或“系统提示”经过模型处理后的 KV 状态。当新的用户请求以该前缀开头时直接加载缓存的 KV 状态作为模型past_key_values的初始状态然后从前缀结束的位置开始进行自回归生成。适用场景聊天机器人每个对话轮次前都有一段固定的系统指令用于设定助手的行为、身份和回复格式。文档处理流水线处理成千上万份结构相似的文档如新闻稿、财报摘要它们拥有相同的指令前缀和模板。代码补全在相同的项目上下文或文件头部注释下进行多次补全请求。批量任务使用相同的复杂提示词Few-Shot示例、思维链模板处理多个不同的问题。2.2 技术实现原理实现一个基本的 Prompt Cache 系统通常包含以下组件和步骤1. 缓存创建预热阶段将固定的提示前缀文本进行 Tokenize。以该文本作为输入运行一次完整的模型前向传播不生成后续Token并收集模型所有层输出的最终past_key_values。将此 KV 状态序列化并存储到高速存储中如内存数据库 Redis、或本地文件系统。存储时需要关联一个唯一的cache_key如提示前缀的哈希值。import torch from transformers import AutoTokenizer, AutoModelForCausalLM import pickle import hashlib def create_prompt_cache(prompt_text, model, tokenizer, cache_save_path): 创建并保存提示前缀的KV缓存 inputs tokenizer(prompt_text, return_tensorspt).to(model.device) # 前向传播获取最后一个位置的隐藏状态和KV缓存 with torch.no_grad(): outputs model(**inputs, use_cacheTrue) # outputs.past_key_values 包含了所有层的KV缓存 cached_kv outputs.past_key_values # 生成缓存键例如使用提示文本的哈希 cache_key hashlib.md5(prompt_text.encode()).hexdigest() # 序列化并保存实际生产环境可能用数据库 cache_data { cache_key: cache_key, prompt_length: inputs[input_ids].shape[1], past_key_values: cached_kv # 注意实际存储可能需要特殊处理张量 } with open(f{cache_save_path}/{cache_key}.pkl, wb) as f: pickle.dump(cache_data, f) print(fCache created for prompt (key: {cache_key}), length: {cache_data[prompt_length]} tokens) return cache_key2. 缓存查询与加载推理阶段收到用户请求后提取或识别其包含的提示前缀。根据前缀生成cache_key查询缓存。如果命中则加载对应的 KV 状态和前缀长度信息。将用户请求中前缀之后的部分进行 Tokenize。将加载的 KV 缓存作为past_key_values初始状态输入模型并从前缀后的第一个位置开始进行自回归生成。def generate_with_prompt_cache(user_input, model, tokenizer, cache_key, cache_load_path): 使用缓存的KV状态进行生成 # 1. 加载缓存 try: with open(f{cache_load_path}/{cache_key}.pkl, rb) as f: cache_data pickle.load(f) cached_kv cache_data[past_key_values] prompt_len cache_data[prompt_length] except FileNotFoundError: print(Cache miss, falling back to normal generation.) return generate_with_kv_cache(model, tokenizer, user_input) # 2. 处理用户输入假设user_input已包含完整前缀我们只取后缀 # 在实际应用中需要更精确地分离前缀和后缀。 full_input_ids tokenizer(user_input, return_tensorspt).input_ids.to(model.device) # 假设我们知道前缀长度获取后续的输入ID suffix_input_ids full_input_ids[:, prompt_len:] # 3. 使用缓存进行生成 past_key_values cached_kv generated_ids suffix_input_ids.clone() # 从后缀的最后一个token开始生成如果后缀不为空 # 这里简化处理假设后缀是完整的我们直接在其后生成。 # 更复杂的逻辑需要处理suffix_input_ids的逐步生成。 input_for_gen suffix_input_ids if suffix_input_ids.shape[1] 0: # 如果用户输入就是纯前缀则从/s开始生成 input_for_gen torch.tensor([[tokenizer.eos_token_id]]).to(model.device) # 此处应调用一个类似generate_with_kv_cache的函数但初始past_key_values是加载的缓存。 # 为简化示例我们展示关键步骤 outputs model(input_idsinput_for_gen, past_key_valuespast_key_values, use_cacheTrue) # ... 后续的自回归生成循环与之前类似但初始缓存已就绪 # 注意需要将cached_kv与后续新生成的token的KV缓存正确拼接 # Transformers库的generate()函数在传入past_key_values时内部会处理拼接。 # 实际中更推荐使用模型的.generate()方法并传入past_key_values和attention_mask attention_mask torch.ones_like(full_input_ids) generated model.generate( input_idsfull_input_ids, # 传入完整ID模型内部会根据past_key_values跳过计算 past_key_valuescached_kv, attention_maskattention_mask, max_new_tokens50, use_cacheTrue ) return tokenizer.decode(generated[0], skip_special_tokensTrue)2.3 潜在收益与权衡分析收益降低延迟TTFT跳过前缀计算首次 Token 生成时间显著缩短尤其对于长前缀如 1000 Token 的系统提示效果明显。节省计算资源减少 GPU/CPU 的计算量在批量处理时能服务更多并发请求。降低成本对于按计算资源或 API 调用 Token 数计费的场景能直接减少开销。挑战与权衡缓存管理需要设计缓存的存储、加载、更新和淘汰策略如 LRU。缓存过多会占用大量内存。前缀匹配如何准确、高效地识别请求是否命中缓存前缀。简单的哈希匹配要求前缀完全一致而实际场景可能需要支持模糊匹配或分层缓存。模型更新如果模型权重更新微调所有相关的 Prompt Cache 可能失效需要重新预热。实现复杂度需要深度集成到推理服务中可能涉及修改模型封装或推理引擎。特性KV CachePrompt Cache优化维度单个请求内部序列生成过程跨多个请求共享公共前缀主要目标避免自回归生成中的重复计算避免跨请求的重复前缀计算存储内容单个序列已生成部分的 K, V 张量固定前缀文本对应的完整 KV 状态生命周期请求开始到结束长期存储直到被淘汰或失效节省资源计算时间计算时间 内存跨请求聚合典型应用所有自回归语言模型推理固定系统提示、批量文档处理、聊天会话3. DSH能力小验证模拟分析与实践考量“DSH”在此上下文中很可能指的是DeepSeek Harness一个用于部署和测试大语言模型的工具或框架。我们可以设计一个概念性的“小验证”实验来量化 Prompt Cache 的潜在收益。3.1 验证目标与实验设计目标在模拟的 DSH/推理服务环境中对比使用 Prompt Cache 前后处理一批包含相同长前缀请求的延迟和资源消耗。实验设计构造数据准备 100 个用户查询每个查询前附加相同的 500 Token 的系统指令。基准测试无缓存在 DSH 服务中顺序或并发发送这 100 个请求记录总耗时、平均 TTFT 和峰值显存占用。预热缓存将 500 Token 的系统指令预先计算 KV 缓存并存储。优化测试有缓存再次发送相同的 100 个请求服务端先进行缓存查询和加载然后处理。记录相同的指标。对比分析计算延迟降低比例和显存节约量。3.2 关键指标与估算公式时间节省估算假设模型计算 500 个 Token 的前向传播时间为T_prefixms。启用 Prompt Cache 后每个请求节省了T_prefixms 的 TTFT。总时间节省100 * T_prefixms。对于计算密集的模型T_prefix可能占 TTFT 的很大比重。显存节省估算根据之前的公式每个 Token 的 KV Cache 大小约为CBytes。500 个 Token 的缓存大小S_cache 500 * CBytes。无缓存时100 个请求在并发或峰值时可能需要在内存中同时保存多个请求的前缀 KV假设平均并发为M则前缀部分占用显存M * S_cache。有缓存时全局只需保存一份S_cache。显存节省约为(M - 1) * S_cache。这对于长上下文、大 batch 的场景非常可观。3.3 实践考量与伪代码示例在实际的 DSH 或类似服务中集成 Prompt Cache需要考虑服务架构。以下是一个简化的服务端处理逻辑伪代码# 伪代码集成Prompt Cache的推理服务端点 class OptimizedInferenceService: def __init__(self, model, tokenizer, cache_backend): self.model model self.tokenizer tokenizer self.cache cache_backend # 例如 RedisClient 或 Dict async def generate(self, request: GenerateRequest): request 包含 - prompt: 完整提示词 - system_prompt_id: 可选标识使用的系统提示模板ID - max_tokens: 等参数 full_prompt request.prompt cache_key None # 1. 尝试提取前缀并查询缓存 if request.system_prompt_id: # 方式一通过预设ID获取缓存 cache_key fsys_prompt:{request.system_prompt_id} else: # 方式二从prompt中动态识别固定前缀更复杂 # 例如提取前N个token作为前缀进行哈希 prefix_tokens self.tokenizer.encode(full_prompt[:500]) # 简单截取 cache_key fprefix_hash:{hashlib.md5(str(prefix_tokens).encode()).hexdigest()} cached_data await self.cache.get(cache_key) past_key_values None input_ids_for_gen None if cached_data: # 2. 缓存命中加载KV并准备后续输入的token ids past_key_values cached_data[kv_state] prefix_len cached_data[length] # 只对前缀之后的部分进行tokenize suffix_prompt full_prompt[prefix_len:] # 注意这需要根据字符长度近似处理精确做法需用tokenizer suffix_ids self.tokenizer.encode(suffix_prompt, return_tensorspt) input_ids_for_gen suffix_ids # 需要调整attention_mask以匹配past_key_values的序列长度 else: # 3. 缓存未命中正常处理并可选地异步创建缓存如果识别出是公共前缀 input_ids_for_gen self.tokenizer.encode(full_prompt, return_tensorspt) # 异步任务判断是否应为该前缀创建缓存 # if self.should_cache(full_prompt): # asyncio.create_task(self._warmup_cache(full_prompt)) # 4. 调用模型生成 outputs self.model.generate( input_idsinput_ids_for_gen, past_key_valuespast_key_values, max_new_tokensrequest.max_tokens, # ... 其他参数 ) return self.tokenizer.decode(outputs[0], skip_special_tokensTrue) async def _warmup_cache(self, prompt_text): 异步预热缓存 inputs self.tokenizer(prompt_text, return_tensorspt).to(self.model.device) with torch.no_grad(): outputs self.model(**inputs, use_cacheTrue, output_hidden_statesFalse, output_attentionsFalse) cache_key fprefix_hash:{hashlib.md5(prompt_text.encode()).hexdigest()} cache_data { kv_state: outputs.past_key_values, length: inputs[input_ids].shape[1] } # 注意需要将张量移到CPU或序列化后才能存储到分布式缓存 await self.cache.set(cache_key, cache_data, ex3600) # 设置过期时间4. 常见问题、排查与最佳实践4.1 常见问题与排查路径问题现象可能原因检查与排查步骤处理建议启用 Prompt Cache 后生成结果异常或乱码1. 缓存的前缀与当前请求的实际前缀不匹配Tokenization 差异。2. 缓存创建和加载时的模型状态不一致如是否在训练模式。3. Attention Mask 未正确配置。1. 对比缓存创建时和加载时的输入 ID 序列是否完全一致。2. 确保模型在缓存创建和推理时均处于eval()模式。3. 检查并确保传递给generate()函数的attention_mask正确反映了完整序列长度前缀长度后缀长度。实现一个验证函数对比使用缓存和不使用缓存对同一提示的生成结果是否一致。确保 Tokenizer 的配置如是否添加特殊标记完全相同。缓存命中率低1. 前缀提取策略不合理过度细化导致无法匹配。2. 用户请求的前缀确实变化很大。1. 分析请求日志统计公共前缀的长度和频率。2. 检查缓存键的生成逻辑是否因大小写、空格、标点导致哈希不同。考虑分层缓存策略对固定模板使用 ID 匹配对动态内容使用模糊匹配或更长的公共子序列检测。调整缓存粒度。服务内存显存使用反而上升1. 缓存数量无限增长没有淘汰策略。2. 缓存的张量未及时从 GPU 移出长期占用显存。1. 监控缓存后端如 Redis的内存使用量。2. 检查 GPU 显存中是否残留了缓存张量的引用。实现 LRU 或 TTL 缓存淘汰机制。在将 KV 状态存入共享缓存前将其移至 CPU 内存或进行序列化。首次请求缓存未命中延迟极高缓存预热在请求线程中同步进行阻塞了正常响应。检查代码逻辑确认缓存创建是否是同步的、耗时的操作。必须将缓存预热改为异步任务。对于可预知的公共前缀应在服务启动后或低峰期主动预热。4.2 生产环境最佳实践缓存存储与序列化不要将 PyTorch/TensorFlow 张量直接存入分布式缓存如 Redis应先序列化如使用pickle或转换为numpy数组/字节流。考虑使用 GPU 内存、CPU 内存、SSD 的多级缓存架构将高频使用的热缓存放在最快的位置。缓存键设计对于明确的系统提示使用业务 ID如template_v1作为键。对于动态提取的前缀使用 Token ID 序列的哈希值比原始文本哈希更可靠能避免 Tokenizer 前后处理不一致的问题。在键中包含模型版本和配置信息如model_name:revision:precision防止模型更新导致缓存误用。缓存更新与失效建立模型版本与缓存版本的映射关系。当模型更新时使旧版本的所有缓存失效。为缓存设置合理的过期时间TTL即使没有模型更新也能定期刷新。降级与熔断缓存服务如 Redis应具备高可用性。当缓存服务不可用时推理服务应能自动降级为常规的 KV Cache 模式保证核心功能可用。实现缓存操作的超时和熔断机制防止因缓存访问慢而拖垮整个推理服务。监控与度量监控关键指标缓存命中率、平均 TTFT区分缓存命中/未命中、缓存内存使用量、缓存加载耗时。这些指标是评估优化效果、调整缓存策略如容量、TTL的根本依据。4.3 扩展方向动态前缀检测与缓存不仅缓存固定的系统提示还可以通过在线学习动态识别高频出现的请求前缀模式并进行缓存。分层与共享缓存在微服务架构中可以设计一个中心化的 Prompt Cache 服务供多个模型实例或推理节点共享进一步提高资源利用率。与现有推理引擎集成研究如何将 Prompt Cache 深度集成到 vLLM、TGI 等高性能推理引擎中利用其已有的内存管理PagedAttention和批处理调度能力实现更底层的优化。量化与压缩对缓存的 KV 状态进行量化如 INT8或压缩进一步减少存储空间和加载时间以空间换时间。Prompt Cache 是在 KV Cache 基础上针对实际应用模式的一次重要优化。它并非适用于所有场景但在前缀高度重复的批处理、聊天会话等场景下其带来的延迟降低和成本节约是实实在在的。在决定引入此项技术前务必通过类似“DSH能力小验证”的模拟或压测评估其在特定业务场景下的收益成本比。从架构上需要谨慎设计缓存管理、前缀匹配和故障降级策略确保优化在提升性能的同时不引入新的系统复杂性和稳定性风险。 Prompt Cache：大模型推理中跨请求前缀复用的性能优化技术
在实际的大语言模型推理场景中每一次生成新 Token 都需要重复计算之前所有 Token 的注意力这带来了巨大的计算开销。为了优化这一过程KV Cache 技术应运而生它通过缓存注意力机制中的 Key 和 Value 矩阵避免了重复计算是当前主流推理框架如 vLLM、TGI实现高性能吞吐的核心技术。然而当用户输入包含大量重复或相似的前缀时例如系统提示词、长文档的固定开头即使有 KV Cache每次请求仍需重新计算并存储这些前缀的 KV 值造成了内存和计算资源的浪费。Prompt Cache前缀缓存正是为了解决这一问题而设计的进阶优化技术。其核心思想是将高频使用的、固定的文本前缀如系统指令、文档模板预先计算其 KV 值并持久化存储。当新的请求包含此前缀时直接复用缓存的结果从而跳过这部分 Token 的计算显著降低首次 Token 的生成延迟Time To First Token, TTFT并减少内存占用。这对于需要频繁调用相同系统提示的聊天应用、批量处理相似格式文档的场景能带来可观的成本节约和性能提升。本文将深入解析 KV Cache 的工作原理及其带来的资源挑战然后详细阐述 Prompt Cache 如何在此基础上进行优化。我们将通过一个概念性的“DSH能力小验证”环节模拟并分析 Prompt Cache 的潜在收益。本文适合正在使用或计划使用大语言模型进行应用开发的工程师、架构师以及对模型推理优化感兴趣的研究者。通过阅读你将理解这两种缓存机制的原理、差异并能在技术选型和架构设计时评估引入 Prompt Cache 的必要性与可行性。1. 理解 KV Cache从重复计算到状态复用的飞跃要理解 Prompt Cache 的价值必须先厘清其优化对象——KV Cache 的工作原理及其局限性。1.1 注意力机制中的计算瓶颈在 Transformer 的解码器Decoder-Only架构中生成每一个新 Token 时都需要计算该 Token 的 Query 向量与之前所有已生成 Token 的 Key 向量的注意力分数再与这些 Token 的 Value 向量加权求和。这个过程是自回归的。如果没有缓存每次生成新 Tokent时都需要从输入的第一个 Token 开始重新计算所有1到t个 Token 的 Key 和 Value 矩阵。假设模型有L层隐藏层维度为H那么生成一个长度为N的序列其计算复杂度约为O(L * H * N^2)。这在实际推理中是无法接受的。1.2 KV Cache 的工作原理与实现KV Cache 的核心思想是空间换时间。在生成过程中将每一层注意力模块计算出的 Key 和 Value 张量缓存下来。当生成下一个 Token 时只需计算当前新 Token 的 Query、Key、Value并从缓存中读取之前所有 Token 的 Key 和 Value拼接后进行注意力计算。一个简化的伪代码过程如下# 假设batch_size1, num_headsh, head_dimd, seq_len 逐步增长 # k_cache, v_cache: 形状为 [layer, batch, seq_len, h, d] 的缓存 def generate_with_kv_cache(model, input_ids, max_length): past_key_values None # 初始缓存为空 generated_ids input_ids.clone() for step in range(max_length): # 前向传播传入过去的 KV 缓存 outputs model(input_idsgenerated_ids[:, -1:], # 只输入最后一个token past_key_valuespast_key_values, use_cacheTrue) # 获取当前步的 logits 和更新后的 KV 缓存 next_token_logits outputs.logits past_key_values outputs.past_key_values # 更新后的缓存包含了新token的KV # 采样下一个token (例如贪婪采样) next_token_id torch.argmax(next_token_logits[:, -1, :], dim-1, keepdimTrue) generated_ids torch.cat([generated_ids, next_token_id], dim-1) return generated_ids在实际框架中如 Hugging Face Transformerspast_key_values是一个包含每一层 K 和 V 缓存的元组。启用use_cacheTrue后模型会自动管理这个状态。1.3 KV Cache 的内存挑战与成本KV Cache 虽然极大提升了计算效率但它将计算负担转移到了内存或显存上。缓存的大小与以下因素成正比批处理大小Batch Size序列长度Sequence Length模型层数Number of Layers注意力头数Number of Heads每个注意力头的维度Head Dimension对于一个典型的模型如 LLaMA-7B层数L32头数h32头维度d128缓存一个 Token 的 KV 值所需的内存约为2K和V * L * h * d * dtype_size例如 fp16为2字节。 计算得2 * 32 * 32 * 128 * 2 bytes ≈ 524,288 bytes ≈ 512 KB per token。这意味着处理一个 1024 个 Token 的序列仅 KV Cache 就可能占用1024 * 512 KB ≈ 0.5 GB的显存。在批处理或长上下文场景下这成为制约吞吐量和可处理序列长度的主要瓶颈。因此出现了 PagedAttentionvLLM、Continuous BatchingTGI等技术来更高效地管理这块内存。注意KV Cache 优化的是同一序列内Token 的重复计算问题。但对于不同请求之间的重复前缀它无能为力。每个新请求都需要独立计算并存储其前缀的 KV 值这正是 Prompt Cache 要解决的痛点。2. Prompt Cache前缀缓存跨请求的共享优化Prompt Cache 将优化的粒度从单个请求内部提升到了多个请求之间。它的目标是将公共的、不变的前缀计算一次多次复用。2.1 核心概念与适用场景核心概念预先计算并存储一段固定文本称为“提示前缀”或“系统提示”经过模型处理后的 KV 状态。当新的用户请求以该前缀开头时直接加载缓存的 KV 状态作为模型past_key_values的初始状态然后从前缀结束的位置开始进行自回归生成。适用场景聊天机器人每个对话轮次前都有一段固定的系统指令用于设定助手的行为、身份和回复格式。文档处理流水线处理成千上万份结构相似的文档如新闻稿、财报摘要它们拥有相同的指令前缀和模板。代码补全在相同的项目上下文或文件头部注释下进行多次补全请求。批量任务使用相同的复杂提示词Few-Shot示例、思维链模板处理多个不同的问题。2.2 技术实现原理实现一个基本的 Prompt Cache 系统通常包含以下组件和步骤1. 缓存创建预热阶段将固定的提示前缀文本进行 Tokenize。以该文本作为输入运行一次完整的模型前向传播不生成后续Token并收集模型所有层输出的最终past_key_values。将此 KV 状态序列化并存储到高速存储中如内存数据库 Redis、或本地文件系统。存储时需要关联一个唯一的cache_key如提示前缀的哈希值。import torch from transformers import AutoTokenizer, AutoModelForCausalLM import pickle import hashlib def create_prompt_cache(prompt_text, model, tokenizer, cache_save_path): 创建并保存提示前缀的KV缓存 inputs tokenizer(prompt_text, return_tensorspt).to(model.device) # 前向传播获取最后一个位置的隐藏状态和KV缓存 with torch.no_grad(): outputs model(**inputs, use_cacheTrue) # outputs.past_key_values 包含了所有层的KV缓存 cached_kv outputs.past_key_values # 生成缓存键例如使用提示文本的哈希 cache_key hashlib.md5(prompt_text.encode()).hexdigest() # 序列化并保存实际生产环境可能用数据库 cache_data { cache_key: cache_key, prompt_length: inputs[input_ids].shape[1], past_key_values: cached_kv # 注意实际存储可能需要特殊处理张量 } with open(f{cache_save_path}/{cache_key}.pkl, wb) as f: pickle.dump(cache_data, f) print(fCache created for prompt (key: {cache_key}), length: {cache_data[prompt_length]} tokens) return cache_key2. 缓存查询与加载推理阶段收到用户请求后提取或识别其包含的提示前缀。根据前缀生成cache_key查询缓存。如果命中则加载对应的 KV 状态和前缀长度信息。将用户请求中前缀之后的部分进行 Tokenize。将加载的 KV 缓存作为past_key_values初始状态输入模型并从前缀后的第一个位置开始进行自回归生成。def generate_with_prompt_cache(user_input, model, tokenizer, cache_key, cache_load_path): 使用缓存的KV状态进行生成 # 1. 加载缓存 try: with open(f{cache_load_path}/{cache_key}.pkl, rb) as f: cache_data pickle.load(f) cached_kv cache_data[past_key_values] prompt_len cache_data[prompt_length] except FileNotFoundError: print(Cache miss, falling back to normal generation.) return generate_with_kv_cache(model, tokenizer, user_input) # 2. 处理用户输入假设user_input已包含完整前缀我们只取后缀 # 在实际应用中需要更精确地分离前缀和后缀。 full_input_ids tokenizer(user_input, return_tensorspt).input_ids.to(model.device) # 假设我们知道前缀长度获取后续的输入ID suffix_input_ids full_input_ids[:, prompt_len:] # 3. 使用缓存进行生成 past_key_values cached_kv generated_ids suffix_input_ids.clone() # 从后缀的最后一个token开始生成如果后缀不为空 # 这里简化处理假设后缀是完整的我们直接在其后生成。 # 更复杂的逻辑需要处理suffix_input_ids的逐步生成。 input_for_gen suffix_input_ids if suffix_input_ids.shape[1] 0: # 如果用户输入就是纯前缀则从/s开始生成 input_for_gen torch.tensor([[tokenizer.eos_token_id]]).to(model.device) # 此处应调用一个类似generate_with_kv_cache的函数但初始past_key_values是加载的缓存。 # 为简化示例我们展示关键步骤 outputs model(input_idsinput_for_gen, past_key_valuespast_key_values, use_cacheTrue) # ... 后续的自回归生成循环与之前类似但初始缓存已就绪 # 注意需要将cached_kv与后续新生成的token的KV缓存正确拼接 # Transformers库的generate()函数在传入past_key_values时内部会处理拼接。 # 实际中更推荐使用模型的.generate()方法并传入past_key_values和attention_mask attention_mask torch.ones_like(full_input_ids) generated model.generate( input_idsfull_input_ids, # 传入完整ID模型内部会根据past_key_values跳过计算 past_key_valuescached_kv, attention_maskattention_mask, max_new_tokens50, use_cacheTrue ) return tokenizer.decode(generated[0], skip_special_tokensTrue)2.3 潜在收益与权衡分析收益降低延迟TTFT跳过前缀计算首次 Token 生成时间显著缩短尤其对于长前缀如 1000 Token 的系统提示效果明显。节省计算资源减少 GPU/CPU 的计算量在批量处理时能服务更多并发请求。降低成本对于按计算资源或 API 调用 Token 数计费的场景能直接减少开销。挑战与权衡缓存管理需要设计缓存的存储、加载、更新和淘汰策略如 LRU。缓存过多会占用大量内存。前缀匹配如何准确、高效地识别请求是否命中缓存前缀。简单的哈希匹配要求前缀完全一致而实际场景可能需要支持模糊匹配或分层缓存。模型更新如果模型权重更新微调所有相关的 Prompt Cache 可能失效需要重新预热。实现复杂度需要深度集成到推理服务中可能涉及修改模型封装或推理引擎。特性KV CachePrompt Cache优化维度单个请求内部序列生成过程跨多个请求共享公共前缀主要目标避免自回归生成中的重复计算避免跨请求的重复前缀计算存储内容单个序列已生成部分的 K, V 张量固定前缀文本对应的完整 KV 状态生命周期请求开始到结束长期存储直到被淘汰或失效节省资源计算时间计算时间 内存跨请求聚合典型应用所有自回归语言模型推理固定系统提示、批量文档处理、聊天会话3. DSH能力小验证模拟分析与实践考量“DSH”在此上下文中很可能指的是DeepSeek Harness一个用于部署和测试大语言模型的工具或框架。我们可以设计一个概念性的“小验证”实验来量化 Prompt Cache 的潜在收益。3.1 验证目标与实验设计目标在模拟的 DSH/推理服务环境中对比使用 Prompt Cache 前后处理一批包含相同长前缀请求的延迟和资源消耗。实验设计构造数据准备 100 个用户查询每个查询前附加相同的 500 Token 的系统指令。基准测试无缓存在 DSH 服务中顺序或并发发送这 100 个请求记录总耗时、平均 TTFT 和峰值显存占用。预热缓存将 500 Token 的系统指令预先计算 KV 缓存并存储。优化测试有缓存再次发送相同的 100 个请求服务端先进行缓存查询和加载然后处理。记录相同的指标。对比分析计算延迟降低比例和显存节约量。3.2 关键指标与估算公式时间节省估算假设模型计算 500 个 Token 的前向传播时间为T_prefixms。启用 Prompt Cache 后每个请求节省了T_prefixms 的 TTFT。总时间节省100 * T_prefixms。对于计算密集的模型T_prefix可能占 TTFT 的很大比重。显存节省估算根据之前的公式每个 Token 的 KV Cache 大小约为CBytes。500 个 Token 的缓存大小S_cache 500 * CBytes。无缓存时100 个请求在并发或峰值时可能需要在内存中同时保存多个请求的前缀 KV假设平均并发为M则前缀部分占用显存M * S_cache。有缓存时全局只需保存一份S_cache。显存节省约为(M - 1) * S_cache。这对于长上下文、大 batch 的场景非常可观。3.3 实践考量与伪代码示例在实际的 DSH 或类似服务中集成 Prompt Cache需要考虑服务架构。以下是一个简化的服务端处理逻辑伪代码# 伪代码集成Prompt Cache的推理服务端点 class OptimizedInferenceService: def __init__(self, model, tokenizer, cache_backend): self.model model self.tokenizer tokenizer self.cache cache_backend # 例如 RedisClient 或 Dict async def generate(self, request: GenerateRequest): request 包含 - prompt: 完整提示词 - system_prompt_id: 可选标识使用的系统提示模板ID - max_tokens: 等参数 full_prompt request.prompt cache_key None # 1. 尝试提取前缀并查询缓存 if request.system_prompt_id: # 方式一通过预设ID获取缓存 cache_key fsys_prompt:{request.system_prompt_id} else: # 方式二从prompt中动态识别固定前缀更复杂 # 例如提取前N个token作为前缀进行哈希 prefix_tokens self.tokenizer.encode(full_prompt[:500]) # 简单截取 cache_key fprefix_hash:{hashlib.md5(str(prefix_tokens).encode()).hexdigest()} cached_data await self.cache.get(cache_key) past_key_values None input_ids_for_gen None if cached_data: # 2. 缓存命中加载KV并准备后续输入的token ids past_key_values cached_data[kv_state] prefix_len cached_data[length] # 只对前缀之后的部分进行tokenize suffix_prompt full_prompt[prefix_len:] # 注意这需要根据字符长度近似处理精确做法需用tokenizer suffix_ids self.tokenizer.encode(suffix_prompt, return_tensorspt) input_ids_for_gen suffix_ids # 需要调整attention_mask以匹配past_key_values的序列长度 else: # 3. 缓存未命中正常处理并可选地异步创建缓存如果识别出是公共前缀 input_ids_for_gen self.tokenizer.encode(full_prompt, return_tensorspt) # 异步任务判断是否应为该前缀创建缓存 # if self.should_cache(full_prompt): # asyncio.create_task(self._warmup_cache(full_prompt)) # 4. 调用模型生成 outputs self.model.generate( input_idsinput_ids_for_gen, past_key_valuespast_key_values, max_new_tokensrequest.max_tokens, # ... 其他参数 ) return self.tokenizer.decode(outputs[0], skip_special_tokensTrue) async def _warmup_cache(self, prompt_text): 异步预热缓存 inputs self.tokenizer(prompt_text, return_tensorspt).to(self.model.device) with torch.no_grad(): outputs self.model(**inputs, use_cacheTrue, output_hidden_statesFalse, output_attentionsFalse) cache_key fprefix_hash:{hashlib.md5(prompt_text.encode()).hexdigest()} cache_data { kv_state: outputs.past_key_values, length: inputs[input_ids].shape[1] } # 注意需要将张量移到CPU或序列化后才能存储到分布式缓存 await self.cache.set(cache_key, cache_data, ex3600) # 设置过期时间4. 常见问题、排查与最佳实践4.1 常见问题与排查路径问题现象可能原因检查与排查步骤处理建议启用 Prompt Cache 后生成结果异常或乱码1. 缓存的前缀与当前请求的实际前缀不匹配Tokenization 差异。2. 缓存创建和加载时的模型状态不一致如是否在训练模式。3. Attention Mask 未正确配置。1. 对比缓存创建时和加载时的输入 ID 序列是否完全一致。2. 确保模型在缓存创建和推理时均处于eval()模式。3. 检查并确保传递给generate()函数的attention_mask正确反映了完整序列长度前缀长度后缀长度。实现一个验证函数对比使用缓存和不使用缓存对同一提示的生成结果是否一致。确保 Tokenizer 的配置如是否添加特殊标记完全相同。缓存命中率低1. 前缀提取策略不合理过度细化导致无法匹配。2. 用户请求的前缀确实变化很大。1. 分析请求日志统计公共前缀的长度和频率。2. 检查缓存键的生成逻辑是否因大小写、空格、标点导致哈希不同。考虑分层缓存策略对固定模板使用 ID 匹配对动态内容使用模糊匹配或更长的公共子序列检测。调整缓存粒度。服务内存显存使用反而上升1. 缓存数量无限增长没有淘汰策略。2. 缓存的张量未及时从 GPU 移出长期占用显存。1. 监控缓存后端如 Redis的内存使用量。2. 检查 GPU 显存中是否残留了缓存张量的引用。实现 LRU 或 TTL 缓存淘汰机制。在将 KV 状态存入共享缓存前将其移至 CPU 内存或进行序列化。首次请求缓存未命中延迟极高缓存预热在请求线程中同步进行阻塞了正常响应。检查代码逻辑确认缓存创建是否是同步的、耗时的操作。必须将缓存预热改为异步任务。对于可预知的公共前缀应在服务启动后或低峰期主动预热。4.2 生产环境最佳实践缓存存储与序列化不要将 PyTorch/TensorFlow 张量直接存入分布式缓存如 Redis应先序列化如使用pickle或转换为numpy数组/字节流。考虑使用 GPU 内存、CPU 内存、SSD 的多级缓存架构将高频使用的热缓存放在最快的位置。缓存键设计对于明确的系统提示使用业务 ID如template_v1作为键。对于动态提取的前缀使用 Token ID 序列的哈希值比原始文本哈希更可靠能避免 Tokenizer 前后处理不一致的问题。在键中包含模型版本和配置信息如model_name:revision:precision防止模型更新导致缓存误用。缓存更新与失效建立模型版本与缓存版本的映射关系。当模型更新时使旧版本的所有缓存失效。为缓存设置合理的过期时间TTL即使没有模型更新也能定期刷新。降级与熔断缓存服务如 Redis应具备高可用性。当缓存服务不可用时推理服务应能自动降级为常规的 KV Cache 模式保证核心功能可用。实现缓存操作的超时和熔断机制防止因缓存访问慢而拖垮整个推理服务。监控与度量监控关键指标缓存命中率、平均 TTFT区分缓存命中/未命中、缓存内存使用量、缓存加载耗时。这些指标是评估优化效果、调整缓存策略如容量、TTL的根本依据。4.3 扩展方向动态前缀检测与缓存不仅缓存固定的系统提示还可以通过在线学习动态识别高频出现的请求前缀模式并进行缓存。分层与共享缓存在微服务架构中可以设计一个中心化的 Prompt Cache 服务供多个模型实例或推理节点共享进一步提高资源利用率。与现有推理引擎集成研究如何将 Prompt Cache 深度集成到 vLLM、TGI 等高性能推理引擎中利用其已有的内存管理PagedAttention和批处理调度能力实现更底层的优化。量化与压缩对缓存的 KV 状态进行量化如 INT8或压缩进一步减少存储空间和加载时间以空间换时间。Prompt Cache 是在 KV Cache 基础上针对实际应用模式的一次重要优化。它并非适用于所有场景但在前缀高度重复的批处理、聊天会话等场景下其带来的延迟降低和成本节约是实实在在的。在决定引入此项技术前务必通过类似“DSH能力小验证”的模拟或压测评估其在特定业务场景下的收益成本比。从架构上需要谨慎设计缓存管理、前缀匹配和故障降级策略确保优化在提升性能的同时不引入新的系统复杂性和稳定性风险。