llm-d 评测：把 vLLM 之上的调度、缓存与弹性做成 Kubernetes 原生层
Achieve state of the art inference performance with modern accelerators on Kubernetes
秒懂
- 它是什么？
- llm-d 是 CNCF 沙箱项目，由 Red Hat、Google Cloud、IBM Research、CoreWeave 与 NVIDIA 发起，定位在 vLLM、SGLang 等模型服务器之上，用智能路由、分层 KV 缓存和预填充/解码分离来压榨加速器性能。本文基于仓库文档与发布说明，拆解它的机制、部署路径和适用边界。
- 适合谁用？
- llm-d 适合已经用 Kubernetes 跑 vLLM 或 SGLang、并且遇到前缀缓存命中率低、多租户流量倾斜或超大模型扩展瓶颈的团队。它不适合只想简单起一个模型服务、不愿意引入额外控制面和运维负担的场景。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Shell（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是模型服务器之上的问题
vLLM 和 SGLang 已经解决了单机或单集群内高效跑模型的问题，但生产环境里真正的瓶颈往往在它们之上：请求该发给哪个副本、前缀缓存如何在多副本间共享、长上下文请求怎么不把 GPU 显存打爆、流量高峰时该扩哪个组件。llm-d 把自己定位成这些模型服务器之上的编排层，不替代 vLLM，而是调度、缓存和扩缩容的 Kubernetes 原生控制面。它的目标用户是那些已经在 Kubernetes 上跑推理服务、并且发现默认的 round-robin 负载均衡或单副本部署无法满足吞吐和时延要求的团队。项目由 Red Hat、Google Cloud、IBM Research、CoreWeave 和 NVIDIA 发起，2026 年 3 月进入 CNCF 沙盒，这解释了它为什么强调跨厂商的加速器支持，包括 AMD MI300X、NVIDIA H100/B200、Intel XPU 和 Google TPU。
四条技术主线：路由、缓存、分离与运维
llm-d 的功能组织成四个主题。智能路由是核心，它不只是按负载均衡，而是感知前缀缓存状态和每副本实时负载，文档提到实验性的预测延迟调度，基于历史推理信号预估请求延迟，而不是靠启发式规则。KV 缓存管理是第二个主题，叫 tiered-prefix-cache，把 KV 缓存从 GPU 显存卸载到 CPU 内存或磁盘，并维护全局索引，这样多轮对话的上下文不需要每次重新计算。第三个主题面向超大规模模型，prefill/decode 分离把预填充和解码阶段拆到不同实例，wide expert-parallelism 则把专家并行扩展到 16×16 的 B200 集群。第四个主题是运维，包括多租户的智能流控和基于实时推理信号的 SLO 感知自动扩缩容。这四条线不是孤立的，路由需要知道缓存状态，分离部署需要路由把 prefill 和 decode 请求导向不同后端，所以它更像一个整体的控制面设计。
从 Quickstart 到生产：Helm 与 well-lit path
部署入口是官方 Quickstart 和名为 well-lit path 的指南集合。文档明确建议大多数用户从 Optimized Baseline 开始，这是一套经过基准测试的 Helm chart 配置，覆盖常见 LLM 服务场景。v0.7 版本把配置迁移成 kustomize-first，意味着你既可以用 Helm 也可以用 kustomize 管理部署。仓库里的实际命令不在 README 中，需要查阅 llm-d.ai 上的文档，但根据发布说明，v0.9 和 v0.8 的更新节奏很频繁，v0.8.1 到 v0.9.0 只隔了不到两个月。这意味着你部署的版本很快会过时，升级路径需要提前规划。文档强调这些指南是可复现的，性能数据发布在 Prism 平台上，这比单纯读博客数字更有说服力，至少你可以自己跑一遍验证。
性能数字背后的机制和验证成本
README 列出了一些耀眼的数字，例如 Llama 3.1 70B 在 4× AMD MI300X 上比 round-robin 高 3 倍输出吞吐、2 倍 TTFT 改善，以及 16×16 B200 上 50k tokens/sec 的集群吞吐。这些数字来自 Red Hat、Google、AWS 和 Oracle 的博客，不是 llm-d 自己测的，这点很重要。它们的前提是特定模型、特定硬件和特定负载，例如 250 并发用户下 13.9 倍吞吐提升是分层 KV 卸载对 GPU-only 的对比。如果你的负载是短请求、低并发或者前缀复用率低，这些数字会大幅缩水。llm-d 的价值在于它把优化机制做成了可配置的 Kubernetes 组件，但你要验证这些机制是否适配你的流量模式，就得跑 Prism 上的基准工作流，这本身需要一套测试集群和时间成本。
限制与失败模式：它不是银弹
llm-d 的复杂度是实打实的。它引入了新的控制面组件、自定义路由器和可能的 KV 缓存存储层，这意味着你除了维护 vLLM 之外还要维护一套额外的系统。文档提到 predicted-latency scheduling 在 v0.7 才 GA，batch gateway 还处于 experimental 状态，说明部分核心功能仍在快速演进，API 可能不稳定。另一个明显的限制是硬件依赖：wide expert-parallelism 需要快速加速器互联，文档中提到的 16×16 B200 拓扑依赖 NVLink 或等效带宽，普通千兆以太网集群根本跑不出那个效果。分层 KV 卸载到 CPU 或磁盘会引入额外的 I/O 延迟，如果存储性能不够，TTFT 可能反而变差。对于单副本或小规模部署，llm-d 的收益非常有限，因为你没有多副本可路由，也没有显存压力需要卸载。
与 vLLM 原生方案的区别
一个真正的替代方案是直接使用 vLLM 自身的 prefix caching 和简单的水平扩展，配合 Kubernetes Service 的负载均衡。vLLM 也支持 prefix cache，但它是节点本地的，llm-d 的 tiered-prefix-cache 则通过全局索引让多个副本共享缓存状态，这是架构上的根本差异。另一个替代是 SGLang 的 RadixAttention，它在单进程内做缓存树管理，但同样不解决跨副本的调度问题。llm-d 的定位是把你从手动调优 vLLM 参数和编写自定义路由逻辑中解放出来，它把调度决策集中到一个智能路由器，而 vLLM 原生方案需要你自己处理亲和性、缓存命中率和负载感知。选择的关键在于你的规模：如果你有多个副本并且流量有较高的前缀复用，llm-d 的全局缓存索引会带来显著收益；如果只是几个副本且请求独立，vLLM 内置功能足够。
维护成本与许可视角
Apache-2.0 许可意味着你可以自由使用、修改和商用，没有 copyleft 义务，这对企业采用是友好的。但作为 CNCF 沙盒项目，llm-d 的治理和稳定性还在成熟过程中。发布节奏很快，v0.8 到 v0.9 只隔了两个月，v0.7 到 v0.8 也类似，这意味着你需要定期跟踪 release notes 来应对可能的配置变更，比如 v0.7 中把文档迁移到 kustomize-first，这会影响你的部署脚本。项目文档提到 nightly CI 覆盖 OpenShift、GKE 和 CoreWeave，说明多云兼容是测试目标，但具体支持矩阵需要查阅官方文档。维护成本主要在于你不仅要升级 llm-d，还要确保它与底层 vLLM 或 SGLang 版本兼容，因为 llm-d 的调度和缓存机制依赖模型服务器的特定接口。在采用前，你应该检查 llm-d 的文档是否列出了你正在使用的模型服务器版本，否则可能出现接口不匹配。
编辑结论
llm-d 适合已经用 Kubernetes 跑 vLLM 或 SGLang、并且遇到前缀缓存命中率低、多租户流量倾斜或超大模型扩展瓶颈的团队。它不适合只想简单起一个模型服务、不愿意引入额外控制面和运维负担的场景。项目文档强调从 Optimized Baseline 入手，先跑通默认 Helm chart 再逐步启用预测延迟调度与分层 KV 卸载。采用前应验证三件事：你的模型服务器版本是否在 llm-d 的兼容列表内，你的存储是否支持 KV 缓存卸载到 CPU 或磁盘的延迟要求，以及你的网络能否支撑 wide expert-parallelism 所需的加速器互联带宽。llm-d 的收益高度依赖负载特征，前缀复用率低或并发数小的场景可能只看到复杂度增加。Apache-2.0 许可允许商用，但 CNCF 沙盒阶段意味着 API 和默认配置仍可能随版本调整，v0.9 到 v0.7 的发布间隔只有几个月，升级节奏需要纳入规划。
社区笔记