缓存命中率做到 96%成本降 3.2 倍这个数字放在大模型推理服务里不是口号而是一个可以拆开算清楚的目标。先说结论在 vLLM、vllm-ascend 这类推理引擎里缓存命中率直接决定了一次请求里有多少 prompt 前缀不需要重新计算命中率越高GPU 或 NPU 的算力耗费越低单 token 成本自然就下来了。这篇文章适合正在跑 vLLM 或 vllm-ascend 服务的人看尤其是已经接了 Prometheus Grafana 但不知道应该盯哪几个指标以及遇到命中率突然下降却不知道怎么排查的情况。我会把命中率提升链路、监控采集步骤、排查顺序和成本估算方式完整拆一遍。1. 先搞清楚LLM 服务里的缓存命中率到底省的是什么很多人第一次听说“缓存命中率”第一反应是 Redis、HTTP 缓存那一套以为就是热点数据多存几份。LLM 推理里的缓存完全不同它省的不是“重复查询”而是重复计算。大模型生成回答时有两个阶段Prefill 阶段把用户输入的全部 token 过一遍模型生成每个 token 对应的中间状态。Decode 阶段根据中间状态逐个生成新 token。中间状态里最关键的部分叫 KV Cache也就是 Key-Value 缓存。它的特点是只要输入序列前缀相同前面那段计算出来的 KV Cache 就可以复用。比如系统提示词 历史对话 用户问题整个前置长文本每次都一样那这一段就没有必要每次都重算。缓存命中的含义就是这次请求的前缀和之前请求的前缀重叠了一部分引擎直接把已经算好的 KV Cache 拿出来用跳过对应的 Prefill 计算。没命中就只能老老实实把完整输入重新跑一遍。这里要注意一个关键点缓存命中要求的是字符串级别的完全一致不是语义相似。你加了一个空格、改了一个标点、把顺序调了一下前缀就算不上了。所以提升命中率本质上是在管理提示词的稳定性而不是在做语义匹配。在实际服务里命中率对成本的影响非常大。因为 Prefill 是计算密集阶段长 prompt 的 Prefill 往往占用大量加速器算力而 Decode 阶段相对轻一些。如果每次请求都要把同样的长前缀重新 Prefill 一遍算力就是在做重复劳动。96% 的命中率意味着什么意味着 100 个前缀 token 里有 96 个可以从缓存里直接复用只有 4 个需要新算。这个数字放在长上下文场景里节省的算力非常可观。我之前接触过的一个服务prompt 平均 5000 token命中率从 60% 提到 90% 以上之后同样一批请求占用的加速器时间直接少了一大截。所以这一节的核心判断是缓存命中率不是一个“优化指标”而是一个直接和钱挂钩的工程指标。它高单位时间能处理的请求变多需要的实例变少它低算力全部浪费在重复 Prefill 上成本直线上升。2. 96% 命中率是怎么来的KV Cache 与前缀复用的核心链路想提升命中率得先理解缓存是从哪个维度被标记和查找的。vLLM 系引擎的前缀缓存会按 token 序列的哈希值去匹配。命中条件有三个输入文本经过分词后token 列表前面一段和某一历史请求完全一致。这些 token 对应的 KV Cache 还在缓存区里没有被淘汰。产生缓存的模型版本和当前部署版本一致模型一变旧缓存全部失效。2.1 Prefill 和缓存命中的实际关系假设一个请求是“系统提示词 用户上传的文档 问题”系统提示词固定 1000 token文档固定 3000 token问题平均 100 token。如果每次请求前面 4000 token 都完全一样那第一次请求算完这 4000 token 的 KV Cache 后后续请求就只需要算最后那 100 token 的增量以及 Decode 阶段的新输出。这就是命中率高的典型场景。但现实里有两个问题会把命中率拉下来文档或系统提示词里有动态字段比如时间戳、用户 ID、随机数、日期。用户把同一份文档以不同方式粘贴进来格式、换行、编码不一样。这两个问题一出现前缀就对不上了前面 4000 token 全部重算命中率直接归零。2.2 提升命中率的实操手段要把命中率做到 90% 以上甚至逼近 96%通常要做这几件事第一固定系统提示词模板。凡是公共前缀统一从配置中心读取不要由前端拼接。尤其是时间、会话 ID 这类动态内容要么移到开头之前要么移到用户问题之后避免插在公共前缀中间。第二开启 prefix caching 相关功能。vLLM 较新版本默认开启 prefix caching但旧版本或部分 fork 分支可能需要显式加启动参数比如--enable-prefix-caching。在 vllm-ascend 上也要先确认这个开关是否存在以及默认值是什么。第三控制前缀长度和缓存容量。缓存区不是无限的--max-model-len越大能缓存的完整序列越少。如果你既要长上下文又要高命中率就需要在显存或 NPU 内存允许范围内把缓存块数量调够。第四避免同一实例混跑多种 prompt 范式。如果系统里同时存在三四种差异很大的 prompt 模板缓存会被切得很碎命中率反而不高。更合理的做法是把不同模板拆到不同服务或不同模型实例上。第五让请求结构保持稳定。用户上传的内容尽量做标准化预处理比如统一换行符、去除多余空格、固定编码格式。这些看起来是小事对缓存命中率的影响是决定性的。注意命中率不是配好参数就自动变高的。它高度依赖业务请求的稳定性。先让小流量测试一段时间观察命中率和耗时变化再逐步放开。3. 落地监控Prometheus Grafana 采集 vllm-ascend 缓存命中率指标命中率提升之后接下来的问题就是怎么持续看到这个数字怎么在它下降的时候第一时间发现答案就是 Prometheus Grafana 这套标准组合。vllm-ascend 服务和原生 vLLM 一样会通过 Prometheus 格式暴露指标默认可以在服务的/metrics路径拉到。你需要做的有三件事让服务导出指标、让 Prometheus 抓取指标、让 Grafana 把指标画成面板。3.1 环境准备我建议按这个顺序准备一台或一组部署 vllm-ascend 的推理节点确认服务端口已开放。一台 Prometheus 服务器版本 2.x 即可资源要求不高。一台 Grafana 服务器和 Prometheus 可以同一台机器。网络层面要保证 Prometheus 能访问到推理节点的/metrics接口。如果推理节点有多个副本我一般会先在单个节点上手动 curl 一下指标接口确认能返回数据再配置 Prometheus。3.2 采集配置Prometheus 的 prometheus.yml 里加一个 job 记录推理服务的抓取目标scrape_configs: - job_name: vllm-ascend metrics_path: /metrics static_configs: - targets: - 10.0.0.11:8000 - 10.0.0.12:8000 labels: instance_group: llm-serving重点确认两个字段metrics_path如果服务通过 nginx 反代要确认路径没有被改写。targets端口要和 vllm 的--port参数一致默认常见的是 8000。配置好之后重启 Prometheus在 Targets 页面能看到两个实例状态为 UP就说明抓取正常。3.3 在 Grafana 里画出命中率导入 Prometheus 数据源之后新建一个 Dashboard用 PromQL 查询缓存命中相关指标。不同版本的指标名会有差异常见的有vllm:num_cached_tokens缓存命中的 token 数量。vllm:num_prefix_cached_tokens前缀缓存命中的 token 数量。vllm:prefix_cache_hit_rate前缀缓存命中率这是最直接的面板指标。一个常用查询方式是把命中 token 和总 token 放在一起算比例rate(vllm:num_prefix_cached_tokens_total[5m]) / ( rate(vllm:num_prefix_cached_tokens_total[5m]) rate(vllm:num_prompt_tokens_total[5m]) )不过这里要提醒一句不同 vLLM 版本的指标命名并不统一。有的版本把num_prompt_tokens_total记成vllm:prompt_tokens_total有的版本已经把prefix_cache_hit_rate作为独立 gauge 输出。建议你部署完后先去/metrics里搜一下prefix、cache相关字段再用真实指标名去画面板不要照抄网上旧版本的查询语句。除了命中率本身我还会在同一个面板上放四个辅助指标指标作用判断标准TTFT 延迟首个 token 生成时间命中率高时 TTFT 会明显下降请求排队数当前排队请求量命中率提升后排队数应下降每分钟请求数服务吞吐观察命中率与吞吐是否同步变化KV Cache 使用率缓存区占用情况接近上限时说明可能要扩容或调淘汰策略这四个指标和命中率一起看才能判断命中率变化到底是好现象还是坏现象。比如命中率上升但 TTFT 没有下降说明命中的都是短前缀节省的计算量有限命中率下降但请求量也变少可能只是流量结构变化不一定是故障。4. 命中率突然下降怎么排查版本升级是头号诱因命中率掉下来的时候很多人第一反应是改参数、清缓存、重启服务。但这类问题的根因往往和参数无关。我建议按下面的排查顺序走先看现象再看输入最后看环境。4.1 第一步确认是整体下降还是局部下降打开 Grafana把命中率面板的时间范围拉长到 24 小时或 7 天。先看下降是不是从某个时间点开始的这个时间点和服务变更是否吻合。最常见的诱因就是模型版本或推理引擎版本升级。最近社区里反馈比较多的一个现象是某次模型或服务更新之后缓存命中率明显下滑。原因其实不复杂模型权重变了、prompt 模板变了、tokenizer 版本变了都会让旧的缓存哈希对不上之前积累的缓存等于全部作废。更新后命中率会先跌一波等新请求逐渐把新缓存填起来再慢慢回升。如果你的命中率下降时间点和发布窗口完全重合先不要改任何参数等 1 到 2 小时观察曲线是否自动恢复。如果恢复缓慢再检查是不是模型版本升级后 prompt 前缀也发生了变化。4.2 第二步检查输入前缀是否发生了变化这个最容易被忽略。命中率下降不一定在服务端很可能在客户端。常见情况上游应用改了系统提示词文案哪怕只改了一个字。请求里多了时间戳、trace ID、用户 ID 等动态字段。文档格式从统一模板改成了用户原始上传格式。分词器对同一段文本的处理方式发生了变化。排查方法是抓一批命中率低时的请求样本对 prompt 前几百个 token 做比较看前缀一致性是否变差。如果发现大量请求的前缀都不一样问题在调用方不在推理服务。4.3 第三步检查缓存容量和淘汰策略如果前缀没有变化服务也没升级那就看缓存容量。缓存区满的时候新请求会淘汰旧缓存如果流量突然增长或者长请求变多缓存会被快速冲掉命中率会呈现周期性波动。这时候看 KV Cache 使用率指标。如果长时间接近上限考虑增加缓存 block 数量。降低--max-model-len让单条请求占用更少缓存空间。把流量拆分到更多实例上减少单实例缓存压力。4.4 第四步检查多实例一致性多副本部署时缓存默认是每实例独立的。如果负载均衡把相同前缀的请求分散到多个实例每个实例只能缓存一小部分整体命中率就会很低。更糟的情况是请求带 session 亲和性配置不当同一个用户的前后缀请求落到不同实例前缀缓存完全用不上。这种情况下的排查方法是按实例维度看命中率。如果 A 实例命中率 90%B 实例命中率 30%负载均衡策略大概率有问题。修复手段通常是让相同前缀的请求尽量路由到同一实例或者改用共享缓存方案。注意多实例环境下不能只看集群汇总命中率。每个实例单独画一条线能帮你快速定位是缓存淘汰问题、路由问题还是输入变化问题。5. 成本降 3.2 倍怎么算命中率、延迟和吞吐的关系标题里“成本降 3.2 倍”这个数字很多人的第一反应是命中率 96%所以成本降到原来的 4%那不是 25 倍吗这个理解是错的。成本降低是多个因素叠加的结果不能拿命中率直接反推。5.1 命中率如何影响单请求耗时一次请求的总耗时可以粗略拆成三部分Prefill 耗时和需要从头计算的 prompt token 数成正比。Decode 耗时和输出 token 数成正比基本固定。排队耗时受算力占用情况影响。假设请求的 prompt 固定 4000 token输出固定 500 token。不命中时每次都要算 4000 token 的 Prefill。命中率 96% 时平均每次只有 4% 的前缀需要重算也就是大约 160 token 的 Prefill。单请求的 Prefill 耗时理论上会大幅下降。实际服务里Prefill 和 Decode 是混合调度、流水线并行的单请求耗时不会严格按比例下降但单位时间能处理的请求量会显著上升。吞吐上来之后同样的请求量需要的实例数就可以减少。5.2 成本公式的正确拆法合理估算方式是把总成本拆成三个因子总成本 实例数量 × 单实例单位时间成本 × 运行时长命中率提升 → 单实例吞吐上升 → 相同请求量下需要的实例数减少。实例数减少 → 总运行时长、电费、运维成本同步下降。排队时间缩短 → 同样的业务体验可以接受更小的资源冗余。所以 3.2 倍的成本优化大概率是把实例数降下来了、单位 token 算力开销降下来了、以及运维和容灾冗余减少之后综合得到的结果。它和命中率有关但不是线性关系。5.3 判断成本优化是否达标的参考口径不要只看一两个数字建议用这几个口径做前后对比口径优化前优化后说明每千 token 的加速器耗时按日志统计按日志统计核心降本指标单实例同时处理请求数看 vllm 日志看 vllm 日志吞吐变化平均 TTFT看监控看监控体验指标每百万 token 成本按账单算按账单算业务口径如果命中率提升到 96%但每千 token 的耗时没有明显下降那说明你的请求结构可能没有从缓存中受益或者命中率统计口径里包含了大量极短前缀。这时候不要急着宣传降本成果先把请求样本拆开看命中到底发生在哪些 token 上。5.4 降本不是唯一的收益命中率提升还有一个容易被忽略的收益长上下文请求的稳定性。长 prompt 每次全量 Prefill不仅耗时高还容易触发显存峰值。命中率高了以后长请求的峰值显存占用也会更平缓这在大并发场景下能降低 OOM 风险。所以我的建议是把命中率、TTFT、KV Cache 使用率和每千 token 耗时放在同一张 Dashboard 上。降本是否成立看的是这一组指标的综合变化而不是单个数字。6. 边界与避坑命中率不是越高越好监控要盯住细节最后聊几个容易踩的坑。很多团队把命中率当成 KPI追到 99%结果发现延迟反而变差了成本也没有继续降。原因往往出在下面几点。6.1 命中率统计口径不一致不同引擎、不同版本对“命中率”的定义不完全一样。有的是按请求数算有的是按 token 数算有的是只算前缀命中有的把部分命中也算进去。统计口径不同数字差距会很大。我一般用 token 维度来评估成本用请求维度来观察用户覆盖情况。两个口径都要看但决策时以 token 维度为准。6.2 高命中率不等于低延迟如果命中命中的只是很短的公共前缀比如几个固定的系统词那节省的计算量非常有限TTFT 不会有明显变化。这种情况下命中率数字漂亮但业务收益不大。反过来如果命中率稳定但请求量很低说明缓存区被大量不常复用的内容占着命中率指标有欺骗性。要结合每分钟请求数和命中 token 的绝对量一起判断。6.3 别为了命中率去做危险优化有一种做法是把所有请求的 prompt 强行截断成固定前缀保证前缀一致。这在某些场景可行但如果截断掉了用户真正关心的上下文输出质量会明显下降。缓存省下来的成本可能还不够弥补效果变差带来的损失。更稳妥的做法是模板统一动态信息后置。用户内容标准化预处理干净。实例路由尽量保持会话亲和。版本升级时提前评估缓存清空的影响。6.4 监控面板不是搭完就结束Prometheus Grafana 采集配置完成后最重要的一件事是设置告警。命中率本身不建议设固定阈值告警因为不同业务差异太大。我更建议对命中率变化率做告警比如“5 分钟内命中率下降超过 20 个百分点”或者对 TTFT 的异常上升做告警再通过命中率辅助定位。我自己的习惯是在 Grafana 里建三个面板区实时命中率 TTFT 趋势。缓存容量与淘汰情况。按实例维度的命中率对比。三个面板配合基本可以覆盖日常运维和版本升级后的回归验证。6.5 如果你的场景不适合做前缀缓存前缀缓存不是所有场景都有效。如果业务请求的 prompt 几乎每次都不一样比如用户随意输入、没有固定模板、也没有历史对话那前缀缓存能命中的部分非常有限命中率低是正常的。这时候与其纠结怎么提命中率不如优化请求结构把公共部分尽可能提取出来。判断标准很简单随机抽 100 条真实请求比较它们在分词后的前 200 个 token。如果有 80 条以上高度一致缓存优化空间很大如果前 200 个 token 就各不相同那命中率天花板就在那里不要强行追求。最后留几个我排查时优先看的点如果你的 vllm-ascend 服务命中率一直上不去或者掉下来之后找不到原因先按这个顺序做打开/metrics接口确认当前版本实际暴露的指标名不要凭经验写 PromQL。拉出命中率最低和最高的两台实例对比请求样本的 prompt 前缀差异。看版本发布记录把命中率掉点和服务更新、模型更新对齐。看 KV Cache 使用率确认是不是缓存区被长请求挤爆。最后才去调并发、batch 大小和缓存 block 数量。这个方案真正落地时最该盯住的不是命中率这一个数字而是输入格式、缓存容量和版本变更这三个前置条件。输入不稳定命中率就是空中楼阁缓存容量不够命中率撑不住版本一变旧缓存全部作废。把这三件事处理好再配上 Prometheus Grafana 的持续监控96% 命中率、3.2 倍成本优化这些结果才会真的出现在你的 Dashboard 上。