llm-d：LLM推理负载均衡

梯形图转SCL | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

扩展LLM推理的方式与传统Web服务不同。在单个vLLM或SGLang实例上，KV缓存能带来巨大的速度提升——但如果在多个副本前放置一个带有轮询请求转发的标准Kubernetes Service，大部分缓存加速效果就会消失。因为每个Pod都从未见过之前请求的前缀，它最终会从头重新计算整个上下文。

轮询调度的工作假设是每个副本对每个请求都提供相同的性能。这对于无状态Web流量来说是成立的，但一旦请求在调用之间共享缓存，这个假设就完全失效了。副本之间的差异取决于它们已经缓存了什么，而默认的路由层完全忽略了这个关键区别。

1、背景：KV缓存从何而来，为什么如此珍贵

LLM响应生成发生在两个不同的阶段：

1. 预填充（Prefill）：并行处理用户的所有输入Token。它是计算密集型的，关键性能指标是首Token时间（TTFT）。
2. 解码（Decode）：逐个生成新的Token。每一步只计算一个新Token的查询，但它必须从内存中移动模型权重和缓存的Key/Value矩阵。它是内存带宽密集型的，关键指标是Token间延迟（ITL）。

KV缓存存储注意力计算过程中生成的Key和Value矩阵。已处理Token的K/V在后续生成步骤中永远不会改变，因此可以保存并重用。一个130亿参数的模型每个Token大约产生1MB缓存；一个具有4K上下文的单个请求仅KV缓存就需要4GB显存。

由于缓存存储成本如此之高，我们希望尽可能多地重用它。当两个请求共享相同的前缀（例如相同的系统提示）时，第二个请求可以跳过整个预填充步骤并立即开始生成。这称为前缀缓存——并且只有当两个请求都被路由到同一个副本时才有效。

2、Kubernetes需要解决的四个关键问题

2.1 哪个副本持有哪个前缀？

每个推理服务器在创建或驱逐缓存块时都会发出事件。路由层使用这些事件来维护实时索引。llm-d的智能路由器使用此索引进行前缀缓存感知调度。

2.2 何时应该忽略索引？

缓存亲和性将流量路由到已经热的副本，一旦热副本超过其负载阈值，它本身就会成为瓶颈。路由器在亲和性路由和纯负载平衡之间切换：在负载低时坚持热副本，在负载高时放弃亲和性。llm-d称此策略为"饱和前保持粘性"。

2.3 GPU满了还能在哪里存储缓存？

显存填充速度极快。llm-d使用分层缓存：它首先将缓存块卸载到CPU内存，然后卸载到磁盘。在支持250个并发用户的4个H100 GPU设置上，这种分层方法比将所有缓存保留在GPU上高出13.9倍的吞吐量。

2.4 我们应该分割预填充和解码工作负载吗？

预填充是计算密集型的，解码是带宽密集型的，在同一个副本上运行两者会造成资源争用。当AWS将它们分成单独的池时，他们在GPT-OSS上测量到每秒Token数增加了70%。代价是KV缓存需要额外的网络跳转，这会在生成第一个Token之前增加一点延迟。

解决所有这四个问题，在相同硬件和相同模型上，您可以获得大约3倍更高的输出吞吐量和50%更低的TTFT。

3、什么是llm-d？

llm-d是一个共同解决所有这四个问题的项目。它运行在vLLM或SGLang之上——不替代它们——并接管路由、缓存索引、分层卸载和预填充/解码分割。它在Apache 2.0下获得许可，作为云原生计算基金会（CNCF）沙箱项目托管，由Red Hat、Google Cloud、IBM Research、CoreWeave和NVIDIA共同创立，还得到了AMD、Cisco、Hugging Face、Intel、Lambda、Mistral AI等的支持。生产用户包括Tesla、Snowflake、Cohere和DigitalOcean。

在架构上，llm-d位于Kubernetes和您的模型服务器之间。它使用Gateway API推理扩展来跟踪每个副本的缓存和负载状态，并将每个请求路由到最佳目的地。

官方性能基准包括：

• 广泛的专家并行在16×16 B200配置上提供约50,000 tokens/s的集群吞吐量，每个GPU约3,100个解码Token/s
• Google的预测延迟调度将TTFT和ITL降低了40%
• Oracle在相同基础设施上的预填充/解码分割提供了10%到30%的吞吐量改进

4、真实案例研究：Tesla + Red Hat

今年4月，Tesla和Red Hat的工程团队发布了一篇关于构建结合KServe、llm-d和vLLM的生产级推理堆栈的事后分析。

Tesla的早期设置使用vLLM + Kubernetes StatefulSet，遇到了三个主要痛点：

1. 模型文件通常有数百GB，从NFS网络存储加载速度极慢
2. 切换到本地LVM存储后，Pod被绑定到特定节点，硬件故障需要在重新调度之前手动删除PVC
3. 带有轮询路由的NGINX Ingress对LLM工作负载完全无效，GPU上的KV缓存被浪费而没有收益

切换到KServe + llm-d后，路由层使用Envoy AI Gateway提供前缀缓存感知转发。在4×MI300X上运行Llama 3.1 70B，设置tensor-parallel=4、gpu-memory-utilization=0.90和max-model-len=65536，团队测量到输出Token/s增加了3倍，TTFT减少了50%。

团队在集成过程中发现的问题也贡献给了上游KServe：他们使storageInitializer成为可选的（PR #4970），并添加了对最新Gateway API推理扩展的支持（PR #4886）。

原文链接：llm-d: Stop Using Round-Robin for LLM Inference Load Balancing

汇智网翻译整理，转载请标明出处