llm-d 1.0 发布：缓存感知路由统一 TPU 与 GPU 推理

大型语言模型推理正在从单机实验走向集群化生产部署，而调度与路由的复杂度往往是架构成败的关键。Google、Red Hat 与 IBM 联合发布的 llm-d 1.0 正是针对这一痛点：一个 Kubernetes 原生的开源分布式推理栈，支持跨 vLLM、SGLang 以及 TPU/GPU 异构硬件运行，并引入缓存感知路由与多租户流控。

缓存感知路由：让前缀复用真正落地

llm-d 1.0 最具技术含金量的能力是缓存感知路由（cache-aware routing）。在 LLM 推理中，KV Cache 的命中率直接决定首 token 延迟与整体吞吐，而传统负载均衡器往往按请求数或连接数轮询，无法感知哪个后端节点已经缓存了相似前缀。llm-d 通过将缓存状态纳入路由决策，把请求导向已持有相关上下文的后端实例，从而减少重复计算。

这一思路对多轮对话、RAG 检索增强生成、以及共享系统提示词的批量 Agent 场景收益明显。它与 vLLM 的 PagedAttention 与 SGLang 的 RadixAttention 在机制上形成互补——后两者解决单节点内存利用，llm-d 解决跨节点的请求流向。

KV Cache 与 PagedAttention / RadixAttention

KV Cache（键值缓存）是 Transformer 自回归推理中的核心优化：每生成一个 token，模型需要用到此前所有 token 的 Key 和 Value 向量，若不缓存则每一步都要全量重算，代价极高。将已计算的 K/V 保存在显存中，可把生成阶段的计算复杂度从与序列长度平方相关降为线性。但 KV Cache 体积随序列长度和并发数线性增长，显存很快成为瓶颈。

vLLM 的 PagedAttention 借鉴操作系统虚拟内存分页思想，把 KV Cache 切分为固定大小的块并按需分配，消除内存碎片，使单卡可承载更多并发序列。SGLang 的 RadixAttention 则用基数树（radix tree）组织多个请求共享的前缀，自动复用相同系统提示或对话历史对应的缓存块。两者都聚焦单节点内的显存利用效率，而 llm-d 的缓存感知路由把这一视角扩展到集群：它需要知道每个后端实例持有哪些前缀的缓存，才能把新请求导向命中率最高的节点。这要求调度层与推理引擎之间共享缓存元数据，也是其与普通负载均衡器的本质区别。

Agent 感知与多租户流控：为生产环境补齐短板

除路由外，1.0 版本补齐了几项面向生产环境的工程能力。多租户流控让不同团队或应用共享同一推理集群时能够获得隔离的配额与优先级，避免单个高并发任务拖垮全局。零停机升级则回应了长期困扰运维的痛点：推理服务通常承载会话状态，滚动重启容易造成请求丢失，llm-d 在调度层处理灰度与排空，降低了版本迭代风险。

Agent 感知路由是另一个值得关注的设计。多步 Agent 工作流存在明显的调用链依赖与上下文漂移，感知调用图的路由可以减少跨节点状态同步开销。这说明项目定位不止于“推理服务网格”，而是希望覆盖 Agent 时代的编排需求。

多租户流控中的配额与优先级机制

多租户流控在推理集群中通常通过分层令牌桶或加权公平队列实现：为每个租户（团队、应用或 API Key）分配请求速率与并发上限，并在资源紧张时按优先级调度。与普通 Web 服务的限流不同，LLM 推理的计量单位不只是请求数，还包括输入 token 数、输出 token 数以及预估的 KV Cache 占用，因此配额模型需要多维度核算。隔离的目标是防止某个高并发批处理任务占满显存导致其他租户的首 token 延迟飙升，同时保证高优先级在线会话在过载时仍能获得资源。llm-d 将这一能力下沉到调度层，意味着租户策略可以跨 vLLM、SGLang 等不同引擎统一生效，而不必在每个推理实例上重复配置。

一次发布，三方背书：生态信号强于单点功能

Google、Red Hat 与 IBM 的合作本身就构成重要信号。Red Hat 代表 Kubernetes 生态与企业级交付能力，IBM 带来混合云客户场景，Google Cloud 则掌握 TPU 硬件与 GKE 平台。三方共同推动意味着 llm-d 有机会成为跨云、跨芯片的推理调度层事实标准，而非某一家厂商的专属优化工具。

对使用 TPU 的团队而言，llm-d 提供的统一抽象尤其有价值：在 GPU 与 TPU 混合集群间使用同一套调度策略，可以减少为不同加速器维护两套推理基础设施的成本。不过，异构硬件下的性能调优仍需实测验证，统一 API 不等于统一性能表现。

Kubernetes 原生与推理服务网格的区别

“Kubernetes 原生”意味着 llm-d 以自定义资源定义（CRD）和控制器（controller）的形式扩展 K8s API，复用其声明式配置、服务发现、健康检查与弹性伸缩机制，而非在 K8s 之外另建一套控制面。这与早期把推理服务简单包装成 Deployment 的做法不同：llm-d 需要在 Pod 之上感知模型副本、缓存分布与请求路由状态，因此引入了类似 Gateway API Inference Extension 的语义。将其理解为“推理服务网格”有助于把握定位——它处理的是服务间的东西向流量治理（路由、重试、熔断、租户隔离），而非南北向的入口网关。这也解释了为何三方合作中 Red Hat 的角色关键：企业级 K8s 发行版与 Operator 交付经验，是把调度层推向生产环境的必要环节。

采用建议：适合谁，需要留意什么

已有 Kubernetes 基础、且推理负载规模达到多节点级别的团队，是 llm-d 最直接的目标用户。若仍处于单卡或单节点阶段，引入调度层的边际收益有限，反而增加运维复杂度。评估时应重点关注三点：缓存命中率的实际提升幅度、多租户隔离在压力下的表现，以及零停机升级对长连接流式输出的兼容性。

开源推理栈的竞争正在从“单引擎性能”转向“集群级调度与资源效率”。llm-d 1.0 将缓存、租户、升级与 Agent 工作流纳入同一抽象，方向上贴合生产需求；它能否真正成为标准，取决于社区采用速度与各硬件后端的一致性表现。