之前负责的一个大模型推理服务因为一次模型版本升级缓存命中率从 90% 掉到了 60% 左右。首字时延从 0.3 秒涨到 0.8 秒接口错误率也明显上升。当时第一反应是“模型变慢了”后来查了一圈才发现真正原因是缓存前缀全部失效所有请求都要从头开始计算。这个事故之后团队里聊得最多的指标就变成了缓存命中率。后来我整理了一套完整的缓存命中率监控和优化流程用 Prometheus Grafana 采集 vllm-ascend 推理服务的缓存指标再通过系统提示词动静分离、tokenizer 模板统一、版本升级前后预热等手段把缓存命中率稳定到了 96% 左右整体推理成本下降了约 3.2 倍。这篇文章就把这套思路完整拆开从缓存原理、监控部署到命中率优化、成本验证、常见问题排查一步步说清楚。如果你是做大模型推理服务、推理成本优化或者正在用 vLLM / vllm-ascend 做部署这篇文章会比较适合你。1. 缓存命中率为什么直接决定推理成本1.1 什么是缓存命中率缓存命中率这个概念在不同技术栈里含义略有不同但在大模型推理场景下通常指的是在一次推理请求中系统可以直接复用上一次计算结果的 token 数量占请求总 token 数量的比例。用大白话说用户每次请求都会带着一段比较长的输入比如系统提示词、历史对话、知识库片段。这些内容如果每次都被模型“重新读一遍”计算量会非常大。如果能把前一次计算好的中间结果缓存下来下一次遇到完全相同的 token 前缀时直接复用就能省掉大量重复计算。命中率的计算公式很简单缓存命中率 命中的缓存 token 数 / 请求输入总 token 数假设一次请求输入了 1000 个 token其中 960 个 token 是从缓存里直接拿到的只有 40 个 token 是需要重新计算的那么这次请求的缓存命中率就是 96%。1.2 命中率如何影响成本和时延大模型推理过程可以粗略分成两个阶段预填充阶段和解码阶段。预填充阶段模型先把用户输入的整个 prompt 完整处理一遍生成 KV Cache这个过程计算量很大。解码阶段模型逐 token 生成回复内容每一步都依赖前面已经生成的 KV Cache。如果不做缓存那么每个请求进来模型都会完整执行一遍预填充。即使两个请求的 prompt 有 90% 完全相同也要重复计算两遍。缓存命中率较高时模型可以直接跳过大部分预填充计算这带来的收益非常明显首字时延下降。命中之后不需要完整预填充第一个 token 能更快生成。吞吐量提升。同样的 GPU 或 NPU 资源单位时间内能处理的请求数更多。成本下降。无论是商用模型 API 按 token 计费还是自建集群按资源计费省下来的预填充计算都会反映在账单上。1.3 96% 和 3.2 倍是怎么来的很多人看到“缓存命中率 96%成本降 3.2 倍”会觉得有点夸张其实这是特定业务场景下的结果。假设每天有 10 万次请求每个请求的输入包含 4000 个 token其中 3500 个 token 是稳定的系统提示词和工具定义只有 500 个 token 是动态的用户输入。当命中率只有 80% 时每天大约有 2800 万 token 命中缓存700 万 token 需要重新预填充。当命中率提升到 96% 时每天大约有 3360 万 token 命中缓存只有 140 万 token 需要重新预填充。两者的未命中 token 数量相差 5 倍。如果复用缓存的成本只有重新计算的十分之一那么整体输入成本大约能降到原来的三分之一左右再叠加实例数缩减和时延下降带来的收益成本降低 3.2 倍是完全合理的。需要强调一点这个数字不是普适的只适用于有大量稳定前缀、动态内容占比不高的业务。如果业务请求完全没有公共前缀缓存命中率天然不会高强行追求 96% 是不现实的。2. 大模型推理缓存的核心原理与失效原因2.1 KV Cache、Prefix Cache 与提示词缓存很多初学者容易把几个概念混在一起这里先做一个简单区分。KV CacheTransformer 在解码过程中保存的历史 Key 和 Value 向量是推理加速的基础组件。Prefix Cache按请求前缀维度缓存 KV Cache。如果新请求的前缀和之前某个请求的前缀完全一致就可以直接复用这一段的 KV Cache。提示词缓存云厂商或商业模型 API 公开开放的缓存能力本质上是服务端前缀缓存只是在计费上单独做了优惠。在 vLLM 和 vllm-ascend 这类推理框架中Prefix Cache是缓存命中率的核心。它要求命中的部分在 token 维度上完全一致而不是语义一致。2.2 命中率下降的典型场景缓存命中率不会平白无故一直保持在高位。下面这几种情况都会导致命中率突然下跌模型版本升级新的模型权重导致缓存 key 变化。Tokenizer 版本变化同一句话切分出来的 token id 不同。系统提示词模板被改动比如增加了一个时间戳。请求网关层做了 prompt 改写或者消息拼接顺序调整。服务重启或缓存容量不足缓存被淘汰。这里特别想说一下版本升级。很多人升级模型版本后会感觉“模型变慢、成本变高”其实很可能是缓存失效导致的。只要模型版本变了之前所有按旧版本前缀缓存的 KV Cache 都不能再复用必须重新计算。这不是模型本身性能劣化而是缓存体系被重置了。2.3 动态前缀为什么是头号敌人Prefix Cache 的核心要求是“前缀完全一致”。只要前缀里混入一个会变化的元素它后面的所有内容都会跟着失效。最常见的错误做法是把动态信息塞进系统提示词里。比如下面这段系统提示词你是某平台的客服助手。 当前时间2025-06-01 10:00:00 用户所在城市杭州 你的任务是帮助用户解决问题。如果每次请求都重新拼一遍当前时间那么当秒数变化之后整个 prompt 前缀就变了。缓存命中率会随之大幅下降。正确的做法是“动静分离”把时间、城市这类动态信息放到用户消息里系统提示词只保留完全静态的内容。3. 部署 Prometheus Grafana 收集 vllm-ascend 缓存指标前面讲了很多原理下面进入实战环节。监控是缓存优化中最关键的一步只有先看清当前命中率才知道从哪里下手。3.1 监控体系架构整体架构比较简单vllm-ascend 推理服务 | | 暴露指标 v Prometheus 采集指标 | | 查询 v Grafana 展示面板vllm-ascend 推理服务负责接收请求生成缓存。Prometheus 每个周期去拉取指标。Grafana 负责把指标转换成可视化面板和趋势图。在正式接入 Prometheus 之前先要确认 vllm-ascend 服务是否暴露了缓存相关指标。vllm-ascend 是 vLLM 在昇腾硬件上的适配层指标设计整体延续 vLLM 的风格但不同版本可能会存在差异这一步必须在自己的环境里实际验证。3.2 启动带缓存的推理服务以 vLLM 兼容命令为例启动服务时添加以下参数vllm serve /model/llama-3-8b \ --host 0.0.0.0 \ --port 8000 \ --metrics-port 8001 \ --enable-prefix-caching \ --max-model-len 8192这里解释几个关键参数--port 8000OpenAI 兼容接口的访问端口。--metrics-port 8001Prometheus 指标抓取端口。--enable-prefix-caching开启前缀缓存功能。注意较新的 vLLM 版本可能默认开启具体以版本文档和启动日志为准。--max-model-len 8192允许的最大上下文长度需要根据你的显存和实际业务调整。如果你是使用 vllm-ascend 部署启动方式可能涉及 NPU 设备和 CANN 环境的配置不同硬件、不同驱动版本差异比较大。建议参考官方 README 和版本兼容矩阵这里只强调缓存相关的通用参数思路。3.3 采集指标并接入 Prometheus服务启动后先用curl看一下实际暴露的指标curl -s http://127.0.0.1:8001/metrics | grep -i cache执行后你会看到很多带缓存关键字的指标。这里需要注意不同 vLLM 版本的指标名称不完全一样vllm-ascend 适配层也可能调整指标命名。最好的做法是把当前环境的指标输出保存一份。从中找到与 cache、hit、miss、prefix 相关的指标名。根据实际指标名编写 PromQL 查询。不要直接照搬网上任意一篇教程里的指标名一定要以自己环境中的/metrics输出为准。如果你的服务没有直接暴露缓存命中率还有一个通用做法自己写一个小型 exporter从服务日志或业务日志里解析命中 token 数和未命中 token 数再转换为 Prometheus 指标。下面是一个简单示例# cache_hit_exporter.py import os import re import time from prometheus_client import start_http_server, Counter, Gauge HIT_TOKENS Counter(llm_cache_hit_tokens_total, 累计命中的前缀 token 数) MISS_TOKENS Counter(llm_cache_miss_tokens_total, 累计未命中的输入 token 数) CURRENT_HIT_RATE Gauge(llm_cache_hit_rate, 当前缓存命中率) def parse_log_line(line: str): # 示例日志格式cache_hit960 cache_miss40 m re.search(rcache_hit(\d)\scache_miss(\d), line) if not m: return None return int(m.group(1)), int(m.group(2)) def tail_log(): log_file /var/log/vllm/vllm.log with open(log_file, r, encodingutf-8) as f: f.seek(0, os.SEEK_END) while True: line f.readline() if line: parsed parse_log_line(line) if parsed: hit, miss parsed HIT_TOKENS.inc(hit) MISS_TOKENS.inc(miss) total HIT_TOKENS._value.get() MISS_TOKENS._value.get() if total 0: CURRENT_HIT_RATE.set(HIT_TOKENS._value.get() / total) else: time.sleep(1) if __name__ __main__: start_http_server(9101) tail_log()这个脚本只做一件事读取推理服务日志从缓存命中日志行中提取命中数和未命中数然后以 Prometheus 指标格式暴露在 9101 端口。日志格式和正则表达式需要根据你的服务实际输出调整。3.4 Prometheus 配置示例Prometheus 的采集配置如下global: scrape_interval: 15s scrape_configs: - job_name: vllm-ascend metrics_path: /metrics static_configs: - targets: [10.0.0.10:8001] - job_name: cache-hit-exporter metrics_path: /metrics static_configs: - targets: [10.0.0.11:9101]配置好之后重启 Prometheus在 Prometheus 的 Targets 页面确认两个 target 都是 UP 状态。需要注意如果 Prometheus 和推理服务不在同一台机器上必须确保服务端口对 Prometheus 所在主机开放并且网络策略允许访问。3.5 用 Grafana 展示命中率曲线Grafana 里需要做两步第一步添加 Prometheus 数据源。在 Grafana 的 Data Sources 页面选择 Prometheus填写地址比如http://10.0.0.20:9090然后点击 Save Test显示连接成功即可。第二步新建 dashboard添加一个 Graph 或 Timeseries 面板用 PromQL 查询命中率。假设你从/metrics中找到的指标名是vllm_cache_hit_tokens_total和vllm_cache_miss_tokens_total那么命中率可以用下面的 PromQL 计算sum(rate(vllm_cache_hit_tokens_total[5m])) / ( sum(rate(vllm_cache_hit_tokens_total[5m])) sum(rate(vllm_cache_miss_tokens_total[5m])) )这段查询会计算过去 5 分钟内命中 token 数占命中加未命中 token 总数的比例。图表类型可以选择 Time series 来观察命中率变化趋势也可以加一个 Stat 面板直接显示当前值。建议再配合一个阈值比如命中率低于 85% 时标红。4. 实战把缓存命中率从 80% 优化到 96%监控搭好之后接下来就是调优的核心环节。下面以我曾经遇到的一个业务场景为例整个问题的定位和解决过程可以分成几步。4.1 第一步用监控定位真凶当时业务方的诉求很简单最近接口变慢了成本也在上升希望排查一下。通过 Grafana 面板观察发现缓存命中率只有 70% 左右而且呈周期性波动。进一步看请求日志发现系统提示词里被接入了“当前时间”字段每次请求的时间戳都在变化导致前缀缓存几乎无法命中。这就是一个非常典型的动态前缀问题。4.2 第二步系统提示词动静分离修复方式是把动态内容从系统提示词中移除放到用户消息中。修改前system你是知识库助手。当前时间2025-06-01 10:23:45。用户所在城市杭州。修改后system你是知识库助手。请结合用户提供的上下文回答问题。 user当前时间2025-06-01 10:23:45用户所在城市杭州我的问题是……这样系统提示词部分就变成了完全静态的前缀。只要用户的会话前缀稳定这部分的 KV Cache 就可以被后续请求复用。除了时间字段常见的动态元素还包括用户 IP 或用户 ID。随机生成的一次性 ID。根据用户画像动态拼接的推荐内容。每次请求重新排序的工具列表。这些内容只要不是必备前缀都应该尽量放到后缀位置。4.3 第三步统一模板与 tokenizer除了动态前缀另一个容易忽略的问题是 tokenizer 和聊天模板不一致。同一个系统提示词如果服务端用不同的 chat template 拼接或者在不同节点上对换行符、空格、角色名的处理不一致最终切分出来的 token 序列就会不同缓存照样无法命中。实际操作中需要做到几点多副本实例使用完全相同的 chat template 配置。不要在网关层对消息体做随意格式化。固定模型服务的 tokenizer 版本不随意升级。排查时可以直接把请求体的 token id 打印出来对比两个请求的前缀是否完全一致。这里分享一个小技巧如果怀疑是 token 序列不一致可以在服务端临时打印请求 token id 的前 100 个然后对比正常请求和异常请求很快就能定位到是哪一段被改动了。4.4 第四步新版上线前后缓存预热模型版本升级导致的缓存命中率下跌是一个很难完全避免的问题。既然无法避免就要做好提前量。建议的流程是上线前用线上典型的请求样本执行一次推理请求。让系统提示词和常见用户前缀进入缓存。发布新版本后先观察命中率是否恢复到升级前的水平。发一个预热请求的示例curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: your-model, messages: [ {role: system, content: 你是知识库助手。请结合用户提供的上下文回答问题。}, {role: user, content: 预热请求} ] }预热请求只需要调用一次真实用户请求进来后稳定前缀就可以复用了。4.5 成本验证与效果分析当命中率稳定到 96% 之后需要把效果量化成业务指标这样才能判断优化是否有价值。可以从三个维度进行对比命中率从 80% 提升到 96%。时延首字时延 P95 从 500ms 下降到 180ms。成本在同样业务量的情况下有效输入的重复计算大幅减少实例数缩减了约 1/3综合成本下降约 3.2 倍。为什么成本下降比命中率提升更明显因为缓存命中带来的收益不是线性的。命中率从 80% 提升到 96%未命中 token 数量从 20% 降低到 4%相当于需要重新计算的部分减少了 80%。前面介绍过额外再叠加缓存 token 的单价优势和实例数量的减少成本下降自然远超命中率的提升幅度。5. 常见问题与排查思路缓存优化过程中会遇到不少问题下面整理几个高频问题。问题现象可能原因解决思路模型版本升级后命中率骤降缓存 key 包含模型版本或权重复核信息重新预热缓存观察是否恢复到升级前水平命中率曲线周期性暴跌服务重启导致缓存清空或缓存容量不足调整缓存容量制定重启后预热方案命中率很高但成本没有下降输出 token 仍然占大部分成本成本结构属于解码主导需要优化回复长度和并发策略多个副本实例命中率差异大多副本没有共享缓存请求路由不固定使用一致性路由或分布式缓存方案同一个请求前缀有时命中有时不命中chat template 或 tokenizer 版本不一致统一模板和 tokenizer 版本对比 token idGrafana 面板没有数据Prometheus 抓取失败或指标名写错先确认 target 状态为 UP再确认指标名下面展开几个容易踩坑的细节。关于版本升级很多团队只记录了模型版本没有记录 tokenizer 版本。实际上即使模型权重没变tokenizer 变化也会导致 token 序列不同缓存同样会失效。建议上线前把 tokenizer 的 hash 值一起记录下来便于排查。关于缓存预热不建议在业务高峰期做预热请求本身也会消耗计算资源。踩过坑的同学应该都能体会到那种感觉明明是想降成本结果预热时把整台机器的资源占满了。关于成本核算要明确缓存命中率下降带来的是“预填充计算成本”上升并不等于“总成本”一定上升。如果你的业务输出 token 远多于输入 token那缓存优化对成本的影响不会那么明显。这种情况下建议先优化输出长度再回头优化缓存。6. 最佳实践与工程建议6.1 缓存优化必须在监控之后进行这也是全文最想强调的一点。没有监控数据就做优化相当于盲调。缓存命中率是一个多因素共同作用的结果只有先记录基线、再修改变量、最后对比效果才能形成稳定的优化循环。建议在生产环境上线之前就把缓存命中率监控搭建好至少保留一个月的历史数据基线。6.2 前缀稳定性设计是第一优先级在大模型应用设计阶段就要考虑缓存友好性。系统提示词只放稳定内容。用户身份、时间、地理位置全部放到动态消息中。工具描述和 few-shot 示例不要频繁调整顺序。对话历史截断策略保持一致。如果应用层在开发阶段就能注意这些后续的缓存命中率优化会轻松很多。6.3 设置命中率告警Grafana 安装了 Prometheus 数据源之后建议再加上告警规则。比如命中率低于 80% 持续 5 分钟触发 Warning。命中率低于 60% 持续 5 分钟触发 Critical。这样任何一次模型升级、模板变更、缓存清空都能第一时间被发现而不是等到用户反馈接口变慢之后才去排查。6.4 缓存不是越久越好缓存可以降低计算成本但缓存本身也要占用显存或内存。并非所有请求都值得长期缓存。建议根据业务特点设置合理的缓存淘汰策略高频请求的稳定前缀优先保留。长时间没有访问的旧缓存及时淘汰。敏感数据不要在缓存中保留过长的时间。这里要特别提醒缓存中可能包含用户上传的文本如果涉及隐私数据或合规要求需要提前评估缓存策略是否合规而不是一味追求高命中率。6.5 版本升级前做好缓存失效预案版本升级造成命中率下降有时是不可避免的。真正关键的问题是你能不能快速识别出这是缓存问题并快速恢复。建议在版本发布规范中增加一条模型或 tokenizer 变更后必须检查缓存命中率趋势。如果命中率没有恢复到预期水平需要回看系统提示词是否被改动。6.6 关注“有效命中率”而不是“总命中率”有些请求的缓存命中率虽然高但只有很少的 token 被复用对成本优化的贡献很有限。更合理的做法是同时关注两个指标平均命中率整体 token 层面的缓存命中比例。命中 token 总量每天实际复用了多少 token。命中 token 总量更能反映缓存优化带来的实际收益如果你的团队要向上汇报优化成果建议同时展示这两组数据。7. 收尾从一个事故到一套流程回到文章开头那个版本升级后命中率暴跌的问题。经过这次优化团队把缓存命中率监控做成了例行巡检项系统提示词模板变更必须走评审模型升级也补充了缓存预热流程。现在遇到类似问题我们不再做无头苍蝇式的排查而是先打开 Grafana 看命中率曲线再按模板、tokenizer、缓存预热、路由策略的顺序逐项确认。缓存命中率优化不是一次性的动作更像是一套持续改进的流程。你可以先从监控做起摸清当前命中率基线再逐个排除动态前缀问题最后把版本升级、模板变更等流程规范化。只要缓存命中率稳住了成本下降就是顺水推舟的事情。如果你也在做 vllm-ascend 的推理服务建议先把监控搭起来再对着今天讲的几个优化点逐一检查。有更好的缓存优化思路也欢迎在评论区一起交流。 大模型推理缓存命中率优化实战：从80%到96%的监控与调优
之前负责的一个大模型推理服务因为一次模型版本升级缓存命中率从 90% 掉到了 60% 左右。首字时延从 0.3 秒涨到 0.8 秒接口错误率也明显上升。当时第一反应是“模型变慢了”后来查了一圈才发现真正原因是缓存前缀全部失效所有请求都要从头开始计算。这个事故之后团队里聊得最多的指标就变成了缓存命中率。后来我整理了一套完整的缓存命中率监控和优化流程用 Prometheus Grafana 采集 vllm-ascend 推理服务的缓存指标再通过系统提示词动静分离、tokenizer 模板统一、版本升级前后预热等手段把缓存命中率稳定到了 96% 左右整体推理成本下降了约 3.2 倍。这篇文章就把这套思路完整拆开从缓存原理、监控部署到命中率优化、成本验证、常见问题排查一步步说清楚。如果你是做大模型推理服务、推理成本优化或者正在用 vLLM / vllm-ascend 做部署这篇文章会比较适合你。1. 缓存命中率为什么直接决定推理成本1.1 什么是缓存命中率缓存命中率这个概念在不同技术栈里含义略有不同但在大模型推理场景下通常指的是在一次推理请求中系统可以直接复用上一次计算结果的 token 数量占请求总 token 数量的比例。用大白话说用户每次请求都会带着一段比较长的输入比如系统提示词、历史对话、知识库片段。这些内容如果每次都被模型“重新读一遍”计算量会非常大。如果能把前一次计算好的中间结果缓存下来下一次遇到完全相同的 token 前缀时直接复用就能省掉大量重复计算。命中率的计算公式很简单缓存命中率 命中的缓存 token 数 / 请求输入总 token 数假设一次请求输入了 1000 个 token其中 960 个 token 是从缓存里直接拿到的只有 40 个 token 是需要重新计算的那么这次请求的缓存命中率就是 96%。1.2 命中率如何影响成本和时延大模型推理过程可以粗略分成两个阶段预填充阶段和解码阶段。预填充阶段模型先把用户输入的整个 prompt 完整处理一遍生成 KV Cache这个过程计算量很大。解码阶段模型逐 token 生成回复内容每一步都依赖前面已经生成的 KV Cache。如果不做缓存那么每个请求进来模型都会完整执行一遍预填充。即使两个请求的 prompt 有 90% 完全相同也要重复计算两遍。缓存命中率较高时模型可以直接跳过大部分预填充计算这带来的收益非常明显首字时延下降。命中之后不需要完整预填充第一个 token 能更快生成。吞吐量提升。同样的 GPU 或 NPU 资源单位时间内能处理的请求数更多。成本下降。无论是商用模型 API 按 token 计费还是自建集群按资源计费省下来的预填充计算都会反映在账单上。1.3 96% 和 3.2 倍是怎么来的很多人看到“缓存命中率 96%成本降 3.2 倍”会觉得有点夸张其实这是特定业务场景下的结果。假设每天有 10 万次请求每个请求的输入包含 4000 个 token其中 3500 个 token 是稳定的系统提示词和工具定义只有 500 个 token 是动态的用户输入。当命中率只有 80% 时每天大约有 2800 万 token 命中缓存700 万 token 需要重新预填充。当命中率提升到 96% 时每天大约有 3360 万 token 命中缓存只有 140 万 token 需要重新预填充。两者的未命中 token 数量相差 5 倍。如果复用缓存的成本只有重新计算的十分之一那么整体输入成本大约能降到原来的三分之一左右再叠加实例数缩减和时延下降带来的收益成本降低 3.2 倍是完全合理的。需要强调一点这个数字不是普适的只适用于有大量稳定前缀、动态内容占比不高的业务。如果业务请求完全没有公共前缀缓存命中率天然不会高强行追求 96% 是不现实的。2. 大模型推理缓存的核心原理与失效原因2.1 KV Cache、Prefix Cache 与提示词缓存很多初学者容易把几个概念混在一起这里先做一个简单区分。KV CacheTransformer 在解码过程中保存的历史 Key 和 Value 向量是推理加速的基础组件。Prefix Cache按请求前缀维度缓存 KV Cache。如果新请求的前缀和之前某个请求的前缀完全一致就可以直接复用这一段的 KV Cache。提示词缓存云厂商或商业模型 API 公开开放的缓存能力本质上是服务端前缀缓存只是在计费上单独做了优惠。在 vLLM 和 vllm-ascend 这类推理框架中Prefix Cache是缓存命中率的核心。它要求命中的部分在 token 维度上完全一致而不是语义一致。2.2 命中率下降的典型场景缓存命中率不会平白无故一直保持在高位。下面这几种情况都会导致命中率突然下跌模型版本升级新的模型权重导致缓存 key 变化。Tokenizer 版本变化同一句话切分出来的 token id 不同。系统提示词模板被改动比如增加了一个时间戳。请求网关层做了 prompt 改写或者消息拼接顺序调整。服务重启或缓存容量不足缓存被淘汰。这里特别想说一下版本升级。很多人升级模型版本后会感觉“模型变慢、成本变高”其实很可能是缓存失效导致的。只要模型版本变了之前所有按旧版本前缀缓存的 KV Cache 都不能再复用必须重新计算。这不是模型本身性能劣化而是缓存体系被重置了。2.3 动态前缀为什么是头号敌人Prefix Cache 的核心要求是“前缀完全一致”。只要前缀里混入一个会变化的元素它后面的所有内容都会跟着失效。最常见的错误做法是把动态信息塞进系统提示词里。比如下面这段系统提示词你是某平台的客服助手。 当前时间2025-06-01 10:00:00 用户所在城市杭州 你的任务是帮助用户解决问题。如果每次请求都重新拼一遍当前时间那么当秒数变化之后整个 prompt 前缀就变了。缓存命中率会随之大幅下降。正确的做法是“动静分离”把时间、城市这类动态信息放到用户消息里系统提示词只保留完全静态的内容。3. 部署 Prometheus Grafana 收集 vllm-ascend 缓存指标前面讲了很多原理下面进入实战环节。监控是缓存优化中最关键的一步只有先看清当前命中率才知道从哪里下手。3.1 监控体系架构整体架构比较简单vllm-ascend 推理服务 | | 暴露指标 v Prometheus 采集指标 | | 查询 v Grafana 展示面板vllm-ascend 推理服务负责接收请求生成缓存。Prometheus 每个周期去拉取指标。Grafana 负责把指标转换成可视化面板和趋势图。在正式接入 Prometheus 之前先要确认 vllm-ascend 服务是否暴露了缓存相关指标。vllm-ascend 是 vLLM 在昇腾硬件上的适配层指标设计整体延续 vLLM 的风格但不同版本可能会存在差异这一步必须在自己的环境里实际验证。3.2 启动带缓存的推理服务以 vLLM 兼容命令为例启动服务时添加以下参数vllm serve /model/llama-3-8b \ --host 0.0.0.0 \ --port 8000 \ --metrics-port 8001 \ --enable-prefix-caching \ --max-model-len 8192这里解释几个关键参数--port 8000OpenAI 兼容接口的访问端口。--metrics-port 8001Prometheus 指标抓取端口。--enable-prefix-caching开启前缀缓存功能。注意较新的 vLLM 版本可能默认开启具体以版本文档和启动日志为准。--max-model-len 8192允许的最大上下文长度需要根据你的显存和实际业务调整。如果你是使用 vllm-ascend 部署启动方式可能涉及 NPU 设备和 CANN 环境的配置不同硬件、不同驱动版本差异比较大。建议参考官方 README 和版本兼容矩阵这里只强调缓存相关的通用参数思路。3.3 采集指标并接入 Prometheus服务启动后先用curl看一下实际暴露的指标curl -s http://127.0.0.1:8001/metrics | grep -i cache执行后你会看到很多带缓存关键字的指标。这里需要注意不同 vLLM 版本的指标名称不完全一样vllm-ascend 适配层也可能调整指标命名。最好的做法是把当前环境的指标输出保存一份。从中找到与 cache、hit、miss、prefix 相关的指标名。根据实际指标名编写 PromQL 查询。不要直接照搬网上任意一篇教程里的指标名一定要以自己环境中的/metrics输出为准。如果你的服务没有直接暴露缓存命中率还有一个通用做法自己写一个小型 exporter从服务日志或业务日志里解析命中 token 数和未命中 token 数再转换为 Prometheus 指标。下面是一个简单示例# cache_hit_exporter.py import os import re import time from prometheus_client import start_http_server, Counter, Gauge HIT_TOKENS Counter(llm_cache_hit_tokens_total, 累计命中的前缀 token 数) MISS_TOKENS Counter(llm_cache_miss_tokens_total, 累计未命中的输入 token 数) CURRENT_HIT_RATE Gauge(llm_cache_hit_rate, 当前缓存命中率) def parse_log_line(line: str): # 示例日志格式cache_hit960 cache_miss40 m re.search(rcache_hit(\d)\scache_miss(\d), line) if not m: return None return int(m.group(1)), int(m.group(2)) def tail_log(): log_file /var/log/vllm/vllm.log with open(log_file, r, encodingutf-8) as f: f.seek(0, os.SEEK_END) while True: line f.readline() if line: parsed parse_log_line(line) if parsed: hit, miss parsed HIT_TOKENS.inc(hit) MISS_TOKENS.inc(miss) total HIT_TOKENS._value.get() MISS_TOKENS._value.get() if total 0: CURRENT_HIT_RATE.set(HIT_TOKENS._value.get() / total) else: time.sleep(1) if __name__ __main__: start_http_server(9101) tail_log()这个脚本只做一件事读取推理服务日志从缓存命中日志行中提取命中数和未命中数然后以 Prometheus 指标格式暴露在 9101 端口。日志格式和正则表达式需要根据你的服务实际输出调整。3.4 Prometheus 配置示例Prometheus 的采集配置如下global: scrape_interval: 15s scrape_configs: - job_name: vllm-ascend metrics_path: /metrics static_configs: - targets: [10.0.0.10:8001] - job_name: cache-hit-exporter metrics_path: /metrics static_configs: - targets: [10.0.0.11:9101]配置好之后重启 Prometheus在 Prometheus 的 Targets 页面确认两个 target 都是 UP 状态。需要注意如果 Prometheus 和推理服务不在同一台机器上必须确保服务端口对 Prometheus 所在主机开放并且网络策略允许访问。3.5 用 Grafana 展示命中率曲线Grafana 里需要做两步第一步添加 Prometheus 数据源。在 Grafana 的 Data Sources 页面选择 Prometheus填写地址比如http://10.0.0.20:9090然后点击 Save Test显示连接成功即可。第二步新建 dashboard添加一个 Graph 或 Timeseries 面板用 PromQL 查询命中率。假设你从/metrics中找到的指标名是vllm_cache_hit_tokens_total和vllm_cache_miss_tokens_total那么命中率可以用下面的 PromQL 计算sum(rate(vllm_cache_hit_tokens_total[5m])) / ( sum(rate(vllm_cache_hit_tokens_total[5m])) sum(rate(vllm_cache_miss_tokens_total[5m])) )这段查询会计算过去 5 分钟内命中 token 数占命中加未命中 token 总数的比例。图表类型可以选择 Time series 来观察命中率变化趋势也可以加一个 Stat 面板直接显示当前值。建议再配合一个阈值比如命中率低于 85% 时标红。4. 实战把缓存命中率从 80% 优化到 96%监控搭好之后接下来就是调优的核心环节。下面以我曾经遇到的一个业务场景为例整个问题的定位和解决过程可以分成几步。4.1 第一步用监控定位真凶当时业务方的诉求很简单最近接口变慢了成本也在上升希望排查一下。通过 Grafana 面板观察发现缓存命中率只有 70% 左右而且呈周期性波动。进一步看请求日志发现系统提示词里被接入了“当前时间”字段每次请求的时间戳都在变化导致前缀缓存几乎无法命中。这就是一个非常典型的动态前缀问题。4.2 第二步系统提示词动静分离修复方式是把动态内容从系统提示词中移除放到用户消息中。修改前system你是知识库助手。当前时间2025-06-01 10:23:45。用户所在城市杭州。修改后system你是知识库助手。请结合用户提供的上下文回答问题。 user当前时间2025-06-01 10:23:45用户所在城市杭州我的问题是……这样系统提示词部分就变成了完全静态的前缀。只要用户的会话前缀稳定这部分的 KV Cache 就可以被后续请求复用。除了时间字段常见的动态元素还包括用户 IP 或用户 ID。随机生成的一次性 ID。根据用户画像动态拼接的推荐内容。每次请求重新排序的工具列表。这些内容只要不是必备前缀都应该尽量放到后缀位置。4.3 第三步统一模板与 tokenizer除了动态前缀另一个容易忽略的问题是 tokenizer 和聊天模板不一致。同一个系统提示词如果服务端用不同的 chat template 拼接或者在不同节点上对换行符、空格、角色名的处理不一致最终切分出来的 token 序列就会不同缓存照样无法命中。实际操作中需要做到几点多副本实例使用完全相同的 chat template 配置。不要在网关层对消息体做随意格式化。固定模型服务的 tokenizer 版本不随意升级。排查时可以直接把请求体的 token id 打印出来对比两个请求的前缀是否完全一致。这里分享一个小技巧如果怀疑是 token 序列不一致可以在服务端临时打印请求 token id 的前 100 个然后对比正常请求和异常请求很快就能定位到是哪一段被改动了。4.4 第四步新版上线前后缓存预热模型版本升级导致的缓存命中率下跌是一个很难完全避免的问题。既然无法避免就要做好提前量。建议的流程是上线前用线上典型的请求样本执行一次推理请求。让系统提示词和常见用户前缀进入缓存。发布新版本后先观察命中率是否恢复到升级前的水平。发一个预热请求的示例curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: your-model, messages: [ {role: system, content: 你是知识库助手。请结合用户提供的上下文回答问题。}, {role: user, content: 预热请求} ] }预热请求只需要调用一次真实用户请求进来后稳定前缀就可以复用了。4.5 成本验证与效果分析当命中率稳定到 96% 之后需要把效果量化成业务指标这样才能判断优化是否有价值。可以从三个维度进行对比命中率从 80% 提升到 96%。时延首字时延 P95 从 500ms 下降到 180ms。成本在同样业务量的情况下有效输入的重复计算大幅减少实例数缩减了约 1/3综合成本下降约 3.2 倍。为什么成本下降比命中率提升更明显因为缓存命中带来的收益不是线性的。命中率从 80% 提升到 96%未命中 token 数量从 20% 降低到 4%相当于需要重新计算的部分减少了 80%。前面介绍过额外再叠加缓存 token 的单价优势和实例数量的减少成本下降自然远超命中率的提升幅度。5. 常见问题与排查思路缓存优化过程中会遇到不少问题下面整理几个高频问题。问题现象可能原因解决思路模型版本升级后命中率骤降缓存 key 包含模型版本或权重复核信息重新预热缓存观察是否恢复到升级前水平命中率曲线周期性暴跌服务重启导致缓存清空或缓存容量不足调整缓存容量制定重启后预热方案命中率很高但成本没有下降输出 token 仍然占大部分成本成本结构属于解码主导需要优化回复长度和并发策略多个副本实例命中率差异大多副本没有共享缓存请求路由不固定使用一致性路由或分布式缓存方案同一个请求前缀有时命中有时不命中chat template 或 tokenizer 版本不一致统一模板和 tokenizer 版本对比 token idGrafana 面板没有数据Prometheus 抓取失败或指标名写错先确认 target 状态为 UP再确认指标名下面展开几个容易踩坑的细节。关于版本升级很多团队只记录了模型版本没有记录 tokenizer 版本。实际上即使模型权重没变tokenizer 变化也会导致 token 序列不同缓存同样会失效。建议上线前把 tokenizer 的 hash 值一起记录下来便于排查。关于缓存预热不建议在业务高峰期做预热请求本身也会消耗计算资源。踩过坑的同学应该都能体会到那种感觉明明是想降成本结果预热时把整台机器的资源占满了。关于成本核算要明确缓存命中率下降带来的是“预填充计算成本”上升并不等于“总成本”一定上升。如果你的业务输出 token 远多于输入 token那缓存优化对成本的影响不会那么明显。这种情况下建议先优化输出长度再回头优化缓存。6. 最佳实践与工程建议6.1 缓存优化必须在监控之后进行这也是全文最想强调的一点。没有监控数据就做优化相当于盲调。缓存命中率是一个多因素共同作用的结果只有先记录基线、再修改变量、最后对比效果才能形成稳定的优化循环。建议在生产环境上线之前就把缓存命中率监控搭建好至少保留一个月的历史数据基线。6.2 前缀稳定性设计是第一优先级在大模型应用设计阶段就要考虑缓存友好性。系统提示词只放稳定内容。用户身份、时间、地理位置全部放到动态消息中。工具描述和 few-shot 示例不要频繁调整顺序。对话历史截断策略保持一致。如果应用层在开发阶段就能注意这些后续的缓存命中率优化会轻松很多。6.3 设置命中率告警Grafana 安装了 Prometheus 数据源之后建议再加上告警规则。比如命中率低于 80% 持续 5 分钟触发 Warning。命中率低于 60% 持续 5 分钟触发 Critical。这样任何一次模型升级、模板变更、缓存清空都能第一时间被发现而不是等到用户反馈接口变慢之后才去排查。6.4 缓存不是越久越好缓存可以降低计算成本但缓存本身也要占用显存或内存。并非所有请求都值得长期缓存。建议根据业务特点设置合理的缓存淘汰策略高频请求的稳定前缀优先保留。长时间没有访问的旧缓存及时淘汰。敏感数据不要在缓存中保留过长的时间。这里要特别提醒缓存中可能包含用户上传的文本如果涉及隐私数据或合规要求需要提前评估缓存策略是否合规而不是一味追求高命中率。6.5 版本升级前做好缓存失效预案版本升级造成命中率下降有时是不可避免的。真正关键的问题是你能不能快速识别出这是缓存问题并快速恢复。建议在版本发布规范中增加一条模型或 tokenizer 变更后必须检查缓存命中率趋势。如果命中率没有恢复到预期水平需要回看系统提示词是否被改动。6.6 关注“有效命中率”而不是“总命中率”有些请求的缓存命中率虽然高但只有很少的 token 被复用对成本优化的贡献很有限。更合理的做法是同时关注两个指标平均命中率整体 token 层面的缓存命中比例。命中 token 总量每天实际复用了多少 token。命中 token 总量更能反映缓存优化带来的实际收益如果你的团队要向上汇报优化成果建议同时展示这两组数据。7. 收尾从一个事故到一套流程回到文章开头那个版本升级后命中率暴跌的问题。经过这次优化团队把缓存命中率监控做成了例行巡检项系统提示词模板变更必须走评审模型升级也补充了缓存预热流程。现在遇到类似问题我们不再做无头苍蝇式的排查而是先打开 Grafana 看命中率曲线再按模板、tokenizer、缓存预热、路由策略的顺序逐项确认。缓存命中率优化不是一次性的动作更像是一套持续改进的流程。你可以先从监控做起摸清当前命中率基线再逐个排除动态前缀问题最后把版本升级、模板变更等流程规范化。只要缓存命中率稳住了成本下降就是顺水推舟的事情。如果你也在做 vllm-ascend 的推理服务建议先把监控搭起来再对着今天讲的几个优化点逐一检查。有更好的缓存优化思路也欢迎在评论区一起交流。