llm-d：让路由层「认识」KV 缓存，prefix 命中不再靠运气
在多副本推理集群里，最浪费的一件事是：同一个系统提示被十个副本各算一遍。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路由