llm-d 1.0转向生产运维：开源推理栈补上不停机升级

Google Cloud在10月20日的发布说明中称，llm-d 1.0当天在PyTorch Conference发布；现场演示让1000个隔离智能体通过同一端点调用vLLM和SGLang，使用TPU与GPU组成的资源池。这个Kubernetes原生分布式推理栈此次加入多租户流控和协调滚动升级，目标是让共享模型服务在突发请求与计划维护期间持续响应。

IBM Research在同期发布文章中引述项目联合创始人兼维护者Carlos Costa的话：“llm-d is ready for day 2 operations”，并介绍llm-d由Red Hat、IBM、Google Cloud、CoreWeave和NVIDIA共同发起，目前是CNCF沙箱项目。它处在Kubernetes管理的模型服务集群中，协调请求如何分配给副本；vLLM和SGLang仍承担模型推理。对部署团队来说，1.0解决的核心问题是多个推理实例如何共同处理缓存、租户优先级和升级，而不是替换现有模型引擎。

请求如何经过缓存路由与分离的推理池

一次长对话的后续请求，可能再次携带相同的系统指令、代码片段或历史上下文。如果普通负载均衡把它送到没有相关KV缓存的副本，模型就需要重新处理可复用的前缀。llm-d的路由器同时考虑缓存位置与副本负载：已有缓存的副本可以少做重复计算，但副本接近饱和时，继续向它集中请求又会增加等待时间。

在一条典型的请求路径中，入口先接收请求并识别会话；路由器随后查看可用副本、缓存线索和当前负载，选择处理位置。模型引擎执行预填充，读取输入上下文，再执行解码，逐步生成输出。采用分离部署时，这两个阶段可以放在不同资源池，由llm-d协调请求跨阶段流转；后续会话再进入端点时，路由器仍可利用先前留下的上下文信息。这里的缓存命中取决于请求是否真的共享前缀，以及相关缓存是否仍在可用副本上。

分离预填充与解码的意义，是让两类计算按各自压力配置容量。长输入主要增加预填充工作，持续生成则占用解码资源；把它们拆开后，资源池可以分别扩缩。不过，请求必须在两个阶段之间传递状态，路由与版本管理也随之复杂。对输入较短、会话很少返回、只运行少量副本的服务，分离资源池和缓存感知调度未必能抵消新增的运行成本。

租户争用和滚动升级为何连在一起

共享集群要处理的，不只是把请求送到空闲副本。交互式调用通常在意等待时间，智能体任务则可能短时间发起大量并行请求；如果它们都进入后端队列，突发负载会挤占需要快速响应的服务。llm-d 1.0把优先级和公平性放进路由层的流控：不同租户或工作负载可以分别排队，调度先区分优先级，再在同级队列间分配机会。后端繁忙时，请求可以暂留在路由层；需求超过容量时，准入控制还可减少继续涌入的工作。

项目维护者在1.0发布说明中写明，默认流控仍接近先到先服务，多租户策略需要主动配置；同一版本还提供稳定的v1配置API、路由器热备，以及由DisaggregatedSet协调的预填充与解码副本滚动更新。因而，优先级机制提供的是控制拥塞的手段，具体服务质量仍取决于容量和策略如何设置。

升级时，分离部署有一处特别容易被忽略的耦合：一轮请求可能先落在预填充副本，再交给解码副本。如果其中一侧已更新、另一侧尚未完成，路由器必须避免把请求送进不兼容的组合。DisaggregatedSet将两类副本作为逻辑单元管理，依据底层Pod的就绪状态和版本选择可用配对；Endpoint Picker的热备实例则在活动路由器更替时接手调度。这些机制针对计划内滚动更新维持服务，不能推导出运行中请求在任意故障下都能无损迁移；双活路由与请求故障迁移仍在项目后续工作之列。

何时需要在vLLM或SGLang之外增加这一层

单个vLLM或SGLang实例已能加载模型、批处理请求并生成输出。若部署只有一个实例，或者多个副本的请求彼此独立，增加分布式协调层的收益可能有限。边界出现在副本之间需要共同决策时：同一会话多次返回、长前缀值得复用、不同租户争用加速器，或者预填充与解码被拆成独立资源池。此时，单靠模型引擎内部的调度，无法决定整个集群应由哪个副本接收下一次请求。

llm-d与Kubernetes的关系也在这一边界上。Kubernetes管理工作负载和资源，模型引擎执行推理，llm-d在它们之间处理面向推理请求的路由、排队与跨副本协调。这样的平台层可以把不同引擎接在统一端点之后，但也引入路由器、缓存状态和分离资源池的运行负担。PyTorch Conference上的混合资源演示说明这些组件能够组成一个服务入口；它不能代表任意模型、硬件和请求构成都会得到相同的延迟或吞吐结果。

演示中的成本优势有明确边界

厂商公布的成本比较提供了规模参照，却不是自托管部署的通用折扣。IBM与Red Hat曾展示自托管服务同时运行3000个软件工程智能体，估算成本约为以服务形式提供同一开放模型实际价格的五分之一至十分之一。这个结果对应特定的智能体负载、基础设施和价格参照；若请求很少复用上下文，或加速器长期闲置，成本关系就可能不同。

因此，1.0对平台团队最直接的变化，是计划维护不再必然要求切断整条分离推理路径，同时共享端点有了处理租户争用的机制。真正决定这一层是否值得部署的，是实际流量中可复用前缀有多少、突发请求如何影响交互延迟，以及升级时是否确实需要跨预填充和解码资源池保持服务连续。

相关阅读：

• Langfuse自托管别停在Docker：生产环境还缺高可用与备份
• 阿拉巴马州传唤OpenAI：监管焦点从模型能力转向测试失控
• Jalapeño把推理延迟降至三分之一，但没有挑战训练芯片