若qwen多轮对话响应变慢，应启用prompt缓存：一、隐式缓存默认开启，需加x-context-cache: auto头并保持prompt结构一致；二、显式缓存需注册cache_key；三、vllm启用--enable-prefix-caching；四、transformers手动传past_key_values；五、调试时设x-context-cache: disabled禁用缓存。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
如果您在调用千问Qwen模型时发现多轮对话或重复提示（prompt）场景下响应变慢，则可能是由于未启用或未合理配置prompt缓存机制。上下文缓存可复用公共前缀的KV状态，避免重复计算，从而显著降低首Token延迟。以下是针对不同缓存模式的配置方法：
一、启用隐式缓存（自动模式）
隐式缓存无需任何代码修改或显式开关，由服务端自动识别请求中重复的prompt前缀并缓存，适用于通用对话、快速验证等便捷场景。该模式默认开启且不可关闭，命中后仅按输入token标准单价的20%计费。
1、确认所用API服务支持上下文缓存功能，例如阿里云百炼（Model Studio）平台提供的Qwen系列模型接口。
2、在HTTP请求头中添加 X-Context-Cache: auto 字段以显式声明启用隐式缓存策略（部分服务版本需此标识才触发优化逻辑）。
3、保持多轮请求中system prompt与历史user/assistant消息结构一致，确保服务端能准确识别公共前缀。
二、配置显式缓存（主动模式）
显式缓存允许开发者为特定prompt内容创建带有效期的确定性缓存条目，适用于固定模板、高频指令、知识库问答等对延迟敏感且需高命中率的场景。缓存有效期为5分钟，创建时按输入token单价的125%计费，后续命中仅收10%费用。
1、向缓存注册端点（如 POST /v1/cache/prompt）发送JSON请求，包含待缓存的prompt字符串及可选的cache_key。
2、在后续推理请求中，于请求体中加入 "cache_key": "your_predefined_key" 字段，服务端将优先检索并复用对应缓存。
3、若需更新缓存内容，使用相同cache_key重新调用注册接口，旧缓存将被自动覆盖。
三、在vLLM部署中启用PagedAttention KV缓存
vLLM后端通过PagedAttention技术实现高效的KV缓存内存管理，支持跨请求复用已计算的Key/Value张量，尤其适合批量请求和长上下文场景。该机制不依赖外部缓存服务，而是深度集成于推理引擎内部。
1、启动vLLM服务时，在命令行参数中指定 --enable-prefix-caching 开关。
2、确保所有请求使用相同的tokenizer和模型版本，否则prefix caching将因哈希不匹配而失效。
3、在客户端请求中，将重复的system prompt和历史对话作为prefix传入，后续用户输入作为suffix，vLLM会自动分离并复用prefix对应的KV cache。
四、在Transformers框架中手动管理KV缓存
当使用Hugging Face Transformers直接加载Qwen模型时，可通过控制past_key_values参数实现手动缓存复用，适用于自定义调度逻辑或流式生成场景。
1、首次调用model.generate()后，提取输出中的 past_key_values 元组并持久化存储（如内存字典或Redis）。
2、下一次请求时，将该past_key_values作为参数传入generate()函数的 past_key_values 参数位置。
3、确保新输入的attention_mask长度与缓存KV的序列长度连续对齐，否则将触发完整重计算。
五、禁用缓存以排除干扰的调试配置
在性能诊断阶段，有时需临时关闭所有缓存行为以获取原始延迟基线，确认是否为缓存机制本身引入额外开销或冲突。
1、在API请求头中设置 X-Context-Cache: disabled，强制跳过隐式与显式缓存路径。
2、若使用vLLM，启动时移除 --enable-prefix-caching 参数，并添加 --disable-log-requests 避免日志模块干扰。
3、在Transformers调用中，不传递past_key_values参数，并将use_cache设为False。
