Kubernetes 遇上 LLM 推理。

Google、NVIDIA、IBM 和 Red Hat 都在支持同一个开源项目，让它运转起来。

问题是 LLM 推理无法像普通 Web 服务那样扩展，而 Kubernetes 的常规解决方案只会让情况更糟。

让我解释一下：

运行一个 vLLM 或 SGLang 服务器，KV 缓存就是一个明显的优势。服务器会保留已处理 token 的注意力键和值，因此一个与先前提示共享前缀的提示会跳过那部分计算，直接开始生成。

在几个副本前放一个标准的 Kubernetes Service，那种节省大多就烟消云散了。Service 会将每个请求交给下一个轮转的 pod，而那个 pod 通常从未见过前缀，所以它会从头重新计算整个上下文。

轮询假设每个副本都能同样高效地处理每个请求。对于无状态的 Web 流量，这是对的。但一旦存在预填充缓存，这就不对了，因为副本现在因它们记住的内容而不同。

教 Kubernetes 理解这种差异会变成四个问题。

→ 知道哪个副本持有前缀。每个服务器在创建或驱逐缓存块时都会流式传输一个事件，而路由器会维护一个实时索引，记录谁持有什么。

→ 知道何时忽略该索引。缓存亲和性会将流量拉到温暖的副本上，因此超过负载阈值后，路由器会放弃亲和性，仅基于负载选择。否则，温暖的副本就会成为瓶颈。

→ 扩展缓存的位置。加速器内存很快就会填满，因此块会溢出到 CPU 内存，然后是磁盘。在四个 H100 上，针对 250 个并发用户，这种层次结构提供了将一切保留在 GPU 上的 13.9 倍吞吐量。

→ 将预填充与解码分离。预填充是计算受限的，解码是内存带宽受限的，在一个副本上同时运行两者会低效利用各自资源。AWS 测量到，将它们拆分到专用池后，每秒 token 数提高了高达 70%，尽管 KV 缓存现在必须在第一个 token 出现前跨越网络。

KV 缓存不再是单个服务器管理的东西。它变成了集群状态，而路由层必须跟踪它。

解决这个问题，你就能在相同硬件上运行相同模型时，大约获得 3 倍的输出吞吐量和一半的首 token 时间。

llm-d 是处理 Kubernetes 上所有四个问题的项目。它位于 vLLM 和 SGLang 之上，而不是取代它们，因此你可以保留你已运行的任何引擎，它会接管路由、缓存索引、卸载以及预填充/解码拆分。Apache 2.0，CNCF 沙箱，由 Tesla、Snowflake、Cohere 和 DigitalOcean 运行。

在 GitHub 上查看它：网页链接

我写了关于所有这些之下推理工作原理的完整分解。文章引述如下。

网页链接