当推理成本成为大模型落地的主要约束，调度层的竞争开始从单机框架转向集群编排。
发生了什么
Google、Red Hat 与 IBM 联合发布了 llm-d 1.0。按 MarkTechPost 的报道，这是一个 Kubernetes 原生的开源栈，目标是分布式 LLM 推理的部署与调度。1.0 版本带来三类能力：多租户流控（multi-tenant flow control）、零停机升级，以及缓存感知（cache-aware）与 Agent 感知（agent-aware）的路由。运行时层面同时支持 vLLM 与 SGLang，硬件层面同时覆盖 TPU 与 GPU 集群。
值得注意的是发布方的组合：Google 提供 TPU 与云侧经验，Red Hat 带来 Kubernetes 与企业级交付，IBM 则对应企业客户与混合云场景。
为什么重要
过去两年，推理优化的焦点集中在单机推理引擎——连续批处理、PagedAttention、投机解码等，vLLM 与 SGLang 是代表。但当模型规模、并发量和多模型共存成为常态，单机效率的边际收益在收窄，真正的浪费发生在集群层：请求被随机打散到没有对应 KV 缓存的副本上，前缀缓存被反复重建；多租户之间互相抢占算力，缺乏隔离与配额；升级一次推理服务往往意味着请求中断或整批迁移。
llm-d 的定位正是补上这一层。缓存感知路由的核心思路，是让调度器知道哪个副本已经持有相关上下文，把请求送到"热"的地方，减少重复的 prefill 计算；Agent 感知路由则针对多轮、工具调用的 Agent 负载，让同一会话尽量落在同一副本上。多租户流控解决的是公平性与隔离，零停机升级解决的是运维连续性。
另一个信号是异构。同一套栈同时面向 TPU 与 GPU，意味着 Google 希望把 TPU 纳入主流开源推理生态，而不是让它只存在于自家托管服务里。
影响与看点
对开发者而言，最直接的变化是：分布式推理的复杂度被下沉到 Kubernetes 层，应用侧不必自己实现路由与副本管理。对平台团队而言，缓存感知路由的实际收益高度依赖负载特征——长系统提示、共享前缀、多轮对话场景收益明显，短请求、高多样性的负载则可能有限。
需要观察的点包括：路由决策与 vLLM、SGLang 内部调度如何协同，是否会出现两层调度打架；多租户流控在真实混部下的隔离效果；以及 TPU 与 GPU 混合集群的运维成熟度。开源栈的成败往往不取决于首个版本的功能清单，而取决于社区是否愿意围绕它形成部署惯例。
一个克制的判断：llm-d 1.0 更像是在为"推理集群操作系统"占位，而非立刻替代现有方案；它的价值会在多模型、多租户、异构硬件同时出现的规模下才真正显现。
