KV缓存

vLLM V1 功能表里，FP8 KV Cache 已经标为可用。它解决的是推理服务最头疼的问题：长上下文把 KV cache 撑爆 HBM，能同时服务的并发数被迫砍半。 FP8 KV 到底能省下多少显存？ KV cache 的大小约等于「层数 × 序列长度 × KV 头数 × 头维度 × 字节数」。BF16 下每个元素占 2 字节，压到 FP8 的 E4M3 格式后变成 1 字节，同等 HBM 能装下约两倍长的上下文或两倍并发。在 GB300 NVL72 这类靠 HBM 容量决定吞吐的机器上，这直接转化为每百万 token 的成本下降。 省显存的代价藏在哪里？ 权重量化大家已经很熟，KV 量化的特殊之处在于：KV cache 里存的是历史注意力信息，一旦量化误差在长序列里逐步累积，模型对遥远位置的注意力会漂移，出现「长上下文末尾忘事」。所以 FP8 KV 不是免费午餐——短上下文几乎无感，超长上下文要专门评测召回质量。 什么场景该开 FP8 KV、什么场景不该？ 上下文在 32K 以内、并发吃紧，大胆开 FP8 KV；上下文逼近 1M、且任务强依赖远距离检索，先拿你的真实请求集测一遍准确率，再决定是否回退 BF16。vLLM 里通过相关开关开启，灰度切流即可。 FP8 KV 在推理部署里排什么位置？ FP8 KV Cache 会和 prefix caching、PD 分离一起，成为 2026 年推理部署的标准三件套。容量换精度，是这笔账的本质。 ...

在多副本推理集群里，最浪费的一件事是：同一个系统提示被十个副本各算一遍。vLLM 自带 prefix caching 能在单实例内复用 KV，但请求被 round-robin 随机打散后，缓存命中率随副本数上升反而下降。llm-d 要解决的就是这层跨副本的调度。 llm-d 怎么把路由从抽签变成查表？ llm-d 不满足于轮询，而是读取 vLLM 吐出的 KV-cache 事件，知道哪个副本上已经缓存了哪段前缀。新请求进来，路由层直接把它送到已经持有该前缀的那台副本，而不是重新算一遍。这把跨副本的缓存命中从碰运气变成了确定性查表。 分布式 KV 为什么要全局索引加分层卸载？ 光会路由还不够。llm-d 维护一个全局索引，记录每个 token 块住在哪个副本上。当显存吃紧，它还能把冷缓存分层卸载到 CPU 内存乃至本地 SSD，需要时再拉回来。这样 prefix 缓存不再是显存里的易失品，而变成一个可跨层管理的资源池。 开 prefix-aware 路由之前要注意什么？ 开 prefix-aware 路由的前提，是你的请求前缀真的有共享结构——固定系统提示、共享工具描述、长文档多轮问答。如果每次请求前缀都完全不同，路由再聪明也无的放矢。先统计你的缓存命中分布，再决定上不上 llm-d。 推理优化为什么从单实例走向集群调度？ 推理优化正在从「单实例内核调优」走向「集群级缓存调度」。llm-d 代表的方向是：把 KV 缓存当成一个分布式数据库来管，而不是每个实例自己的临时仓库。 这里有一个被忽视的前提你知道吗？ prefix-aware 路由要生效，前缀必须真的可缓存。如果你的系统提示里嵌了时间戳、用户名这类每次都变的字段，前缀哈希立刻失配，路由层再聪明也命不中。所以上 llm-d 之前，先做一件事：把系统提示里的动态内容全部挪到消息后半段，让公共前缀尽可能长。这一步往往不花一分钱，却能把缓存命中率拉高一截。再配合全局索引与分层卸载，你会发现集群总吞吐上去了，而新请求的平均等待反而下降。缓存这门生意，本质是把「重复计算」变成「一次计算到处复用」。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：llm-d路由