各位做 LLM 推理服务的朋友或多或少都遇到过这样的场景线上 GPU 资源吃紧每次请求都在重新计算历史 token显存带宽被反复消耗响应延迟也居高不下但翻遍监控面板却找不到一个能精准定位问题的指标。直到我们把缓存命中率这一项纳入核心指标才发现问题远比想象中严重某些路径的缓存命中率长期在 50% 以下大量重复计算白白烧掉了 GPU 算力。这篇文章不打算泛泛聊缓存理论而是围绕一个核心结果——缓存命中率提升到 96%推理成本降到原来的约 1/3.2——完整拆解三个问题缓存命中率到底在衡量什么为什么它和成本强相关如何在 vllm-ascend 推理服务中采集缓存指标并用 Prometheus Grafana 做可视化监控命中率下降时如何系统化定位根因而不是盲目加显存、加机器如果你正在做 vLLM 推理服务的性能调优或者刚接触华为昇腾 NPU 上的推理部署这篇文章可以当作一份可落地的参考笔记。基础概念、部署命令、配置片段、告警规则都会覆盖到。1. 背景为什么缓存命中率直接决定推理成本1.1 先理解 LLM 推理中的“重复计算”大语言模型LLM服务于对话、代码生成、文档总结等场景时请求往往带有大量共享前缀或重复上下文。典型场景包括多轮对话中历史消息会在每一轮重新出现在上下文里一批文档问答请求共享同一份长文档前缀系统提示词System Prompt占比高且内容基本固定。在没有缓存的情况下服务端对每个请求都从零开始计算注意力Attention所需的 Key 和 Value 张量即使这些内容上一秒刚算过。这种重复计算不仅抬高了首 token 延迟TTFT也浪费了宝贵的显存带宽和算力。1.2 缓存命中率是“重复计算浪费”的度量尺缓存命中率简单说就是请求命中了已经缓存的计算结果的比例。在 LLM 推理场景中它通常指的是KV Cache 的命中率即 PagedAttention 或类似机制在处理请求时有多少 KV 块是直接复用而无需重新计算的。当命中率为 96% 时意味着大量前缀和上下文无需重新走一遍前向计算GPU 只需要计算新增的那一小部分 token。反过来如果命中率掉到 50% 以下相当于一半的算力都在做无意义的重复劳动资源利用率自然上不去单次请求成本也就水涨船高。1.3 成本降低 3.2 倍是个什么概念“成本降 3.2 倍”这类表述在工程语境里容易被误读。更严谨的说法是优化前单次请求的推理成本若为 1优化后约为 1/3.2即下降约 68%。这部分的收益主要来自算力不再浪费在重复计算上单位时间能处理的请求数吞吐提升显存占用得到释放可以容纳更大的 Batch 或更长的上下文因为不再频繁触发显存不足系统稳定性提升重试和扩容次数减少。一句话总结缓存命中率是 LLM 推理成本结构的“杠杆点”。命中率每提升一档GPU 资源的利用率、吞吐和成本都会出现非线性改善。2. 核心概念vLLM、KV Cache 与 vllm-ascend2.1 vLLM 是什么vLLM 是一个高性能 LLM 推理服务框架核心卖点是通过PagedAttention机制管理 KV Cache把显存利用率做到接近上限同时支持 Continuous Batching、Prefix Caching 等优化能力。它对外提供 OpenAI 兼容的 HTTP API也内置了 Prometheus 指标暴露接口方便接入监控体系。2.2 KV Cache 与命中率的关系在 Transformer 解码阶段模型需要计算每个 token 的 KKey和 VValue向量。如果这两个向量被缓存下来后续生成过程中只需做注意力查询不必重新计算。缓存命中率的计算方式可以简化为命中率 命中的缓存块数 / 请求需要的总缓存块数vLLM 在内部会为每个请求维护一个 KV Cache 块表同时通过哈希或前缀树等方式实现共享前缀的检测。命中率越高意味着复用越多。2.3 vllm-ascend 是什么vllm-ascend 是 vLLM 针对华为昇腾AscendNPU 的适配版本基于昇腾 CANN 算子库实现推理加速。它继承了 vLLM 的接口风格与监控能力同时适配了昇腾设备上的内存管理、算子融合和图编译逻辑。如果团队内部在用 Atlas 系列加速卡或昇腾云服务通常就需要使用 vllm-ascend 来跑推理服务。它的指标暴露方式和标准 vLLM 类似但部分指标名称和采集路径可能略有区别需要以实际部署版本输出为准。2.4 为什么要用 Prometheus GrafanaPrometheus 是目前最主流的开源监控时序数据库通过 HTTP 拉取Pull指标Grafana 负责可视化面板和告警展示。两者组合几乎成了云原生监控的事实标准。对于 vllm-ascend 来说服务本身暴露/metrics端点Prometheus 只需要配置一个抓取任务Grafana 负责把指标画成面板。整套链路轻量、易扩展也便于后续接入更多业务监控指标。3. 环境准备与版本说明3.1 硬件与系统环境本文示例以昇腾 NPU 推理节点为基础环境同时需要一台可以访问该节点的监控服务器也可以是同一台机器。实际硬件型号不做限制关键点是操作系统能正常驱动 NPU并已安装好 CANN 工具链。具体环境如下示例值请按实际环境调整操作系统Ubuntu 22.04 LTS NPU 驱动CANN 7.x以厂商文档为准 Python3.10 推理框架vllm-ascend版本以项目 release 为准 监控端Prometheus GrafanaDocker Compose 部署3.2 推理服务部署方式vllm-ascend 支持多种部署方式直接源码运行python -m vllm.entrypoints.openai.api_server通过 Docker 容器运行通过 Kubernetes Helm 部署本文以“裸机进程方式启动 监控端 Docker 方式部署”为例便于理解每一步在做什么。如果你们是 K8s 环境只需要把 Prometheus 的抓取地址换成 Service 的 DNS 即可原理一致。3.3 版本说明需要注意vLLM 和 vllm-ascend 的版本更新非常快不同版本暴露的指标名称可能存在差异。本文仅以通用指标名称为例进行讲解如果你在环境中发现某些指标不存在请优先查看服务启动日志以及/metrics端点实际输出的指标列表。4. 实战部署 Prometheus Grafana 收集 vllm-ascend 缓存命中率指标这一节是全文核心。我们的目标是启动 vllm-ascend 推理服务确认/metrics端点可访问部署 Prometheus 抓取推理服务指标在 Grafana 中绘制缓存命中率面板配置告警规则命中率异常下降时及时通知。4.1 启动 vllm-ascend 并确认指标端点假设我们已经准备好模型权重目录/data/models/Qwen-14B-Chat使用以下命令启动推理服务python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen-14B-Chat \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --host 0.0.0.0 \ --port 8000 \ --enable-prefix-caching这里有几个关键参数需要解释--enable-prefix-caching开启前缀缓存这是命中率优化的基础开关。如果不开启前缀复用的能力会大打折扣。--gpu-memory-utilization控制 NPU 显存中 KV Cache 的可用比例。比例太小会导致缓存容量不足命中率上不去比例太大会挤压模型权重和激活内存。--max-model-len限制最大上下文长度。越长的上下文越容易暴露缓存管理问题。启动后访问指标端点curl -s http://127.0.0.1:8000/metrics | grep -i cache如果一切正常你会在输出中看到类似下面的指标名称实际以版本为准vllm:cache_hit_rate vllm:cache_hit_tokens_total vllm:cache_miss_tokens_total这些指标就是我们接下来监控的核心数据。4.2 用 Prometheus 采集指标4.2.1 准备 Prometheus 配置文件创建目录和配置文件mkdir -p /opt/monitoring/prometheus编辑 Prometheus 抓取配置# 文件路径/opt/monitoring/prometheus/prometheus.yml global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: vllm-ascend static_configs: - targets: [192.168.1.100:8000]解释一下配置项scrape_intervalPrometheus 每隔 15 秒拉取一次指标。对于缓存命中率这种慢变指标15 秒足够用如果希望更灵敏可以改成 5s但会稍微增加端点压力。targets指向 vllm-ascend 服务所在节点的 IP 和端口。这里用192.168.1.100作为示例请替换为真实地址。4.2.2 启动 Prometheus用 Docker 启动 Prometheusdocker run -d \ --name prometheus \ --restartalways \ -p 9090:9090 \ -v /opt/monitoring/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \ prom/prometheus:latest启动后检查状态curl -s http://127.0.0.1:9090/api/v1/targets | head -n 50如果看到health: up说明 Prometheus 已经成功从 vllm-ascend 拉取指标。4.3 在 Grafana 中绘制命中率面板4.3.1 启动 Grafana创建 Grafana 数据目录并启动容器mkdir -p /opt/monitoring/grafana/data docker run -d \ --name grafana \ --restartalways \ -p 3000:3000 \ -e GF_SECURITY_ADMIN_USERadmin \ -e GF_SECURITY_ADMIN_PASSWORDadmin123 \ -v /opt/monitoring/grafana/data:/var/lib/grafana \ grafana/grafana:latest浏览器访问http://127.0.0.1:3000使用admin / admin123登录。4.3.2 添加 Prometheus 数据源在 Grafana 左侧菜单点击Connections - Data sources - Add data source选择 Prometheus填写URL: http://192.168.1.100:9090点击Save test提示成功即可。4.3.3 新建命中率面板点击Dashboards - New dashboard - Add visualization选择刚才配置的 Prometheus 数据源在查询编辑器中输入vllm:cache_hit_rate如果指标名称不是这个可以先用下面的查询确认实际指标{__name__~.*cache.*}面板推荐配置图表类型Time series单位Percent0-100阈值低于 80% 时标记为红色标题缓存命中率如果命中率指标本身计算的是 0~1 的小数可以在查询后用* 100转换成百分比vllm:cache_hit_rate * 1004.3.4 添加请求量与缓存块分布面板除了命中率本身还要同时监控两个辅助指标否则单块面板很难定位问题。第一个是请求吞吐量sum(rate(vllm:num_requests_total[5m]))第二个是缓存块使用量vllm:num_blocks_used / vllm:num_blocks_total这两个指标能帮你判断“命中率下降是因为流量形态变化还是因为缓存容量不足”。4.4 配置命中率告警缓存命中率不能等跌到谷底再人工介入。建议在 Grafana 中配置告警规则。在面板编辑页进入Alert标签创建告警规则条件vllm:cache_hit_rate 0.80持续时间5 分钟通知渠道钉钉 / 企业微信 / 邮件根据团队实际情况告警规则的目的是在命中率出现“悬崖式下跌”时第一时间感知。持续 5 分钟是为了过滤偶发波动避免告警轰炸。4.5 验证整套监控链路启动服务后可以手动打一些请求验证命中率变化。最简单的做法是用 curl 连续发送带相同前缀的对话请求curl -s http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /data/models/Qwen-14B-Chat, messages: [ {role: system, content: 你是一个智能助手。}, {role: user, content: 请用一段话介绍缓存命中率的含义。} ], max_tokens: 128 }连续执行两次后到 Grafana 面板观察。正常情况下第一次请求会触发缓存构建第二次请求命中率会明显上升。如果两次都没有变化说明前缀缓存可能没有真正生效需要检查启动参数。5. 从监控到优化缓存命中率为什么是 96%5.1 优化前的基线在优化之前我们先建立基线。假设当前命中率只有 60%此时每次请求大约有 40% 的 KV 块需要重新计算。如果把一次请求的 token 消耗想象成账单那么 40% 就是白花的钱。5.2 影响命中率的三个杠杆要把命中率从 60% 提升到 96%核心是放大缓存复用的比例。常用的杠杆有三个。杠杆一开启并调优 Prefix Caching--enable-prefix-caching是 vLLM 生态中提升命中率最直接的手段。开启后服务端会通过哈希匹配请求前缀如果前缀相同直接复用已有的 KV 块。实际业务中大多数请求的 System Prompt 都是固定的这部分 token 占比高且重复率极高。只要这个开关正确开启命中率就能出现大幅提升。杠杆二提高 KV Cache 容量上限--gpu-memory-utilization参数决定有多少显存用于 KV Cache。如果这个参数设置得太小缓存块很快被淘汰即使业务流量具有可复用的前缀也无法在缓存中保留足够时间。建议根据模型权重大小逐步调高该参数并通过监控面板观察num_blocks_used / num_blocks_total的比例。如果长期接近 100%说明缓存容量吃紧需要调整参数或减少并发。杠杆三规范请求前缀设计这一点在业务侧容易被忽略。如果每一次请求都往 System Prompt 里塞入时间戳、随机字符串或用户无关的临时信息那么前缀的哈希值每次都不同前缀缓存就无法生效。要形成规则固定的系统提示词放在最前面会话级的动态信息放在相对靠后的位置随机参数使用请求级字段不要污染公共前缀。5.3 命中率 96% 时的现象优化后在监控面板上你会看到命中率稳定在 95%~97% 之间GPU 算力不再被重复计算拖累相同显存和算力下并发能力明显提升单请求平均延迟下降尤其是长 Prompt 场景的首 token 延迟单位 token 的推理成本降到原来的约 1/3.2。这里需要说明96% 并不是一个“万能最优值”。命中率的极限取决于业务流量中真正的重复比例如果业务 90% 都是完全不同的私有内容命中率的上限自然不会太高。我们不能脱离业务形态谈命中率目标。6. 常见问题与排查思路6.1 服务升级后缓存命中率突然下降这是很多团队都会踩的坑——升级了 vLLM 或 vllm-ascend 版本后缓存命中率出现明显滑坡。可能的原因有新版本修改了缓存哈希算法导致旧缓存全部失效新版本修改了指标计算逻辑看起来数据下降了模型配置变化导致上下文窗口变小缓存块提前被淘汰。排查步骤先确认是否真的“业务命中率下降”还是“指标计算口径变化”查看模型服务启动日志看是否有缓存相关 warning对比升级前后请求的 KV Cache 块命中分布如果是哈希算法变化导致的缓存重建通常会在几分钟到几小时内自然恢复无需过度处理。6.2 命中率低但显存占用很高看到这个现象第一反应是“缓存不够用了”但实际可能是另一回事。常见原因如下问题现象常见原因解决思路命中率低但显存占用高缓存容量被大 Batch 请求挤占降低--max-num-seqs或调整调度策略命中率低但显存占用高前缀哈希不匹配缓存空占内存检查请求前缀中是否存在动态内容命中率低但显存占用高缓存淘汰策略过于激进调高--gpu-memory-utilization建议先用 Grafana 将“缓存块使用率”和“命中率”叠加在一个面板里观察。如果块使用率接近 100% 但命中率依然低优先排查请求前缀设计如果块使用率低但命中率低优先检查--enable-prefix-caching是否生效。6.3 指标端点在 Grafana 中显示 No Data如果 Prometheus 已经显示up但 Grafana 面板仍然无数据通常是查询语句里指标名不对。建议先在 Prometheus 的 Graph 页面执行{jobvllm-ascend}把所有指标刷出来找到带cache关键字的指标名称再回 Grafana 调整查询。6.4 长上下文场景命中率起伏剧烈长上下文请求的特点是前缀很长但后续生成内容分散。在这种情况下命中率可能在请求开始阶段很高在生成阶段逐渐下降。这种情况下可以采用分段观察vllm:cache_hit_rate按请求阶段拆分比较困难实际操作中可以用“最近 5 分钟平均命中率”来观察趋势避免因单次长请求造成整条曲线剧烈震荡。7. 最佳实践与工程建议7.1 让缓存命中率成为团队的核心指标很多团队只看QPS、P99 延迟和显存利用率却忽略了一个事实——这三个指标都受缓存命中率的间接影响。建议把缓存命中率提升到核心监控面板的第一屏与 QPS 并列展示。当业务上线新功能、调整 Prompt 模板或升级推理框架时先看命中率是否变化再决定是否继续操作。7.2 命中率变化要有“成本视角”命中率不是越高越好而是要从成本角度综合看待。命中率提升后释放的 GPU 算力可以用来提升 Batch Size 和吞吐也可以选择不换机器让单卡服务更多请求如果命中率提升并没有带来吞吐变化需要回头检查是不是其他瓶颈比如 CPU 调度、磁盘 I/O掩盖了收益。7.3 缓存监控要结合日志和链路追踪Prometheus 指标能告诉你“命中率是多少”但没法告诉你“哪个业务方的请求导致命中率下降”。实践中建议在请求的日志中记录请求前缀哈希值在链路追踪中埋点记录 KV Cache 命中情况命中率异常时结合业务方信息快速定位“谁在制造大量不重复前缀”。这一点在多人协作的中大型团队里尤其重要否则排查命中率问题会变成从监控曲线“猜凶手”。7.4 谨慎对待公共前缀长度很多团队为了提升命中率会把大量上下文挪到 System Prompt 中。这确实能提高命中率但也带来两个隐患过长的公共前缀会占用大量 KV Cache挤压其他请求的缓存空间某些场景下公共前缀过长反而拉低了上限——因为重复内容不是业务实际需要计算的。建议通过实验数据决定公共前缀长度而不是“越多越好”。7.5 告警规则要分级不要把缓存命中率的所有异常都设置为同一个级别的告警。推荐参考严重命中率 50%持续 10 分钟 警告命中率 70%持续 15 分钟 提示命中率低于基线 10%持续 30 分钟分级可以避免“同一时间所有值班人员都收到告警”的麻木效应。8. 总结与下一步本文从缓存命中率的基本概念出发解释了为什么命中率是 LLM 推理成本的关键杠杆然后完整演示了如何用 Prometheus Grafana 收集 vllm-ascend 的缓存命中率指标最后给出了从 60% 到 96% 的优化路径和常见问题排查思路。实际操作时建议按下面的顺序推进先确认 vllm-ascend 的/metrics端点有缓存指标输出搭建 Prometheus Grafana把命中率、缓存块使用率、请求量画在同一块面板开启--enable-prefix-caching观察命中率变化结合业务流量形态调整--gpu-memory-utilization和前缀设计配置分级告警把命中率纳入团队稳定性指标体系。下一步可以继续研究的方向包括多轮对话场景下的语义缓存、KV Cache 压缩技术、长上下文场景中的缓存调度策略以及推理服务自动扩缩容策略。每一块都值得单独开一篇实践笔记展开写。如果你也在 vllm-ascend 或类似推理栈上做性能优化可以把这套监控方案先搭起来。数据到位了优化方向自然会浮现。