推理不再是“一台机器的事”：llm-d 1.0 把 Agent 时代的 LLM 服务搬上 Kubernetes

当请求从“一问一答”变成“Agent 连续调用几十轮”，推理集群面对的是突发、长前缀反复复用、还要与交互请求抢资源的流量。10 月 20 日，由 Red Hat、IBM、Google Cloud、CoreWeave 与 NVIDIA 发起、现归属 CNCF 的开源项目 llm-d 发布 1.0；10 月 29 日 Google 又公布了配套介绍与基准数据。

一、问题：普通负载均衡器不懂 KV Cache

传统做法是把 vLLM 或 SGLang 放在 Kubernetes Service 后面轮询。但会话的上下文缓存只存在于某个副本的显存里，轮询会把下一轮请求发到“冷”节点，重复 prefill，拉高首 token 延迟（TTFT）。llm-d 让路由“看见”缓存：按前缀命中与节点负载综合打分再选择副本。

二、三块基石

• 前缀缓存感知 + 负载感知路由
• 分层 KV Cache 卸载：主机内存、SSD、Google Cloud Managed Lustre
• 流量控制与优先级：池子饱和时可挂起或丢弃低优先级请求

同一入口可路由 vLLM 与 SGLang，支持 GPU/TPU 混合集群。

三、Prefill/Decode 分离与 DisaggregatedSet

Prefill 计算密集，decode 受并发与带宽限制，拆成两个池可分别扩缩，prefill 通过 KV 传输连接器（默认 NIXL）把缓存交给 decode。痛点是升级时版本不匹配。1.0 新增 DisaggregatedSet，让两个池按配套版本一起滚动升级。社区报道提醒：多数指南需要 LeaderWorkerSet v0.11.1 及以上，分离部署还需开启 DisaggregatedSet API。

另一篇 llm-d 博客显示拓扑的影响：GKE 上未约束放置的平均 TTFT 为 2.15 秒；确保 RDMA 通道后为 1.157 秒；加入拓扑打分配对后为 0.33 秒。

四、批处理与强化学习

1.0 加入异步处理器，可从 Pub/Sub 或 Redis 取请求，用严格优先级与配额和实时流量共存；并支持 TPU/GPU 时间片，让 RL rollout 间隙跑异步推理。Google 称测试场景中利用率从约 40% 升至 70% 以上。

五、数据怎么看：多数来自厂商自测

• Ironwood TPU 编码负载：中位 TTFT 降低 85% 以上，吞吐 2.4 倍（对比标准 Kubernetes Service）
• Gemini 平台：前缀缓存命中率 35% → 70%，编码 Agent TTFT 降低 35% 以上
• 17,000 节点跨区域 MoE：吞吐 2.9 倍，成功率 99.9%，路由开销低于 1%
• Snap 称命中率最高 75–80%，ZenteiQ 称吞吐 4 倍以上

均为厂商或用户自报，负载偏向高前缀复用；前缀复用低的业务收益会小得多。

对开发者意味着什么

• 先测命中率再上马：长会话、长系统提示词、多轮 Agent 收益大，单轮短请求不必折腾。
• 运维同样重要：1.0 强调稳定 API、高可用路由、不断会话升级。
• 留意依赖与镜像：LeaderWorkerSet 版本要求；llm-d 自建镜像（如 llm-d-rocm）已弃用。
• 自测数据要复测：用自己的流量回放，看 P95 TTFT 与命中率。
• 网络拓扑是一等公民：做 P/D 分离必须考虑 RDMA 与放置策略。

结语

llm-d 1.0 的意义不在某个惊人数字，而在于把缓存、分离、优先级与升级这些生产细节收敛成一套开放、可组合的标准件。当 Agent 成为主流流量，会路由、懂缓存的服务层，可能比多一张 GPU 更值钱。