智能体请求让轮询式负载均衡失灵

Google 团队发布了 llm-d 1.0，这是一个开源、Kubernetes 原生的分布式推理栈，目标是把 vLLM 或 SGLang 模型服务器组织成协同工作的服务池。它面向自托管智能体和强化学习等负载，试图解决一个具体问题：当请求之间共享上下文、流量又突然变得不均匀时，普通的轮询式负载均衡并不知道该把请求送到哪里。

智能体不是只提交一次提示词就结束。它会连续发起多轮请求，前一轮留下的上下文可能仍在某个副本的 KV cache 中；如果下一轮被随机送往别处，系统就可能重复处理已有上下文。与此同时，突发的智能体循环会占用队列和加速器资源，让交互式请求等待。llm-d 1.0 值得技术负责人读的地方，是它把这两类问题——上下文复用和不同租户之间的资源公平——都当作服务层需要处理的调度问题。

路由器开始关心请求带着什么上下文

llm-d 的路由器建立在 Kubernetes Gateway API Inference Extension 之上，会跟踪哪些副本持有特定前缀的缓存，再结合负载和预测延迟选择目标副本。对调用方来说，智能体仍然访问一个服务入口；对系统来说，每一轮请求则有机会落到已经保存相关上下文的位置。这与只看当前请求数量的负载均衡不同，调度依据包含了“已有工作能否复用”。

上下文也不必永远挤在加速器显存里。材料描述的缓存路径可以在显存不足时把 KV cache 转移到主机内存，再到 SSD 或 Managed Lustre，相关实现包括 vLLM 的 OffloadingConnector、Mooncake 和 SGLang 的 HiCache。部署能力的边界也比较清楚：llm-d 1.0 覆盖 vLLM 与 SGLang，可运行在 NVIDIA、AMD、Intel GPU 或 Google TPU 上，缓存层级从 HBM 延伸到 CPU 内存、SSD 和 Lustre。实际能否利用这些层级，仍取决于团队的模型服务、硬件和存储配置。

把服务池做大，还要拆开计算路径

llm-d 还把 prefill 和 decode 放在不同的资源池里运行。前者主要消耗计算，后者更受内存带宽和状态访问影响；分开部署后，团队可以分别扩缩两类资源，而不是让一类阶段的压力直接拖住另一类。它不是一个全新的模型执行引擎，而是在 vLLM、SGLang 之上增加面向集群的路由、缓存和部署协调能力。

1.0 的重点因此不只是多支持几种硬件，而是让这些分布式路径更接近生产运维要求。材料列出的能力包括 v1 API、经过加固的请求路径、路由器热备和热更新，以及通过 DisaggregatedSet 协同滚动升级 prefill 与 decode 池，避免版本不匹配时丢失会话。项目由 Red Hat、IBM 和 Google 牵头维护，基于 Kubernetes 生态构建，并以 Apache 2.0 发布；这些信息说明它试图成为可组合的基础设施层，而不只是某个模型服务器的专用插件。

公平调度与空闲算力瞄准两种浪费

多租户控制针对的是服务质量冲突：突发的智能体请求不应挤占延迟敏感的交互流量。llm-d 1.0 加入优先级与公平性感知的流量控制，也提供会话感知路由、轮次优先级调度和原生 Responses API 状态支持。这些机制的价值不在于让所有请求都更快，而在于给系统一个区分请求重要性、延续会话状态的调度入口。

另一条路径是把异步任务送进暂时空闲的算力。llm-d-async-processor 可以从 Google Cloud Pub/Sub 或 Redis 拉取作业，在空闲容量上执行推理；材料还描述了把推理插入强化学习空档的用法。Google 报告称，这类 RL 时间切片把加速器 duty cycle 从约 40% 提高到 70% 以上。这个结果同时暴露了边界：利用率明显上升仍意味着大约三成时间没有被占用，而且异步任务能否填补空档取决于任务是否允许延迟、队列是否有积压以及资源是否真的空闲。

公布的提速需要放回测试条件里读

材料给出的性能数字来自 Google 和 llm-d 采用者的自报结果，适合作为待验证的线索，而不是可直接套用的容量规划参数。在 Ironwood TPU（TPU 7x）编码工作负载中，Google 报告称，前缀感知路由加主机内存卸载让中位 TTFT 降低超过 85%，吞吐量达到普通 Kubernetes Service 的 2.4 倍。Gemini 平台报告的前缀缓存命中率从 35% 提高到 70%，编码智能体的 TTFT 降低超过 35%；突发聊天负载下，P95 TTFT 降低超过 50%。

这些结果不能简单归结为“换上 llm-d 就能提速”：缓存命中、卸载和 prefill/decode 分离都依赖负载特征与系统配置，比较基线也会影响结果。材料还提到一项在 17,000 节点、多区域 GKE 部署上的已发布基准，但提供的摘录没有给出足以复现该测试的完整方法。对技术负责人更稳妥的判断是，先确认自身流量是否有可复用前缀、突发多租户或闲置周期，再用同一硬件和服务目标比较端到端延迟、吞吐与利用率。若这些问题并不存在，增加一层分布式调度也可能只是增加运维面，而不是减少成本。