云原生大模型推理的最佳组合：KServe + llm-d + vLLM

一块 GPU 把大模型跑起来，门槛已经很低了。pip install vllm，加载权重，起个 HTTP 服务，完事。

但流量一上来，问题就开始指数级爆炸：几百张 GPU 怎么调度？KV-cache 怎么跨 Pod 复用？某台 GPU 满了怎么不让请求继续往它身上涌？节点挂了 PVC 删不掉怎么办？这些问题，单机 vLLM 一个都解决不了。

2026 年 3 月和 4 月，KServe 团队和 Tesla 的 SRE 陆续发了两篇博客，讲他们在生产环境怎么用 KServe + llm-d + vLLM 这套组合跑 Llama 3.1 70B。结论很硬：换一层路由，输出吞吐 3 倍，首 token 延迟快 2 倍；llm-d 项目基准测试里，P90 首 token 甚至快了 57 倍。

这两篇博客值得揉在一起读。它们回答的是同一个问题——大模型推理要规模化，到底该怎么分层——只是一个从平台架构视角讲，一个从生产落地视角讲。我把它们合并、补上背景，讲清楚一件事：这三个项目怎么分工，以及为什么这种分法是当前最合理的答案。

一、朴素部署，很快就撞墙

Tesla 团队一开始的部署方式，是绝大多数人起步时的样子：vLLM 塞进 Kubernetes StatefulSet，前面挂个负载均衡。听起来没毛病，跑起来全是坑。三个坑，每一个都够让生产翻车。

坑一：存储拖后腿。 Llama 3 这种 70B 级别的模型，权重动辄上百 GB。用 NFS 网络存储拉模型，启动一个 Pod 要等网络把整个模型拽过来，慢到不可接受。改用节点本地 LVM 卷，速度上来了，但 Pod 被死死钉在某个节点上——硬件一坏，管理员得手动删 PVC 才能让 Pod 重新调度。K8s 引以为傲的「Pod 自由迁移」直接失效，Day-2 运维成本高得离谱。

坑二：裸轮询负载均衡，对 LLM 是灾难。 标准的 round-robin 把请求均匀分到所有副本上——对无状态 web 服务这是金科玉律，对 LLM 这是自毁长城。原因在 KV-cache：LLM 推理时，每个请求的 prompt 前缀会被算成一组 KV 对缓存在 GPU 显存里，下一个请求前缀重合就能直接复用、跳过大量重复计算。可 round-robin 根本不管这个——请求 A 在 Pod 1 算完缓存了，请求 B（前缀一模一样）被分到 Pod 2，从头算一遍。你明明有缓存，却用不上。在 GPU 成本居高不下的今天，这几乎是不可接受的浪费。

坑三：没有集群视角的调度。 单个 vLLM 实例内部，连续批处理、PagedAttention、KV-cache 复用都做得很好。但 K8s 原生调度器调度 LLM 请求时，只看「哪个副本数最少」，看不到哪个 Pod 的 GPU 显存快满了、哪个 Pod 缓存命中率高、哪个 Pod 队列已经堆积。单机优化到极致，集群层面是瞎子。

结论很清楚：大模型推理需要专门为 AI/ML 设计的 Operator 和调度能力，套用通用 Workload 就是会撞墙。

二、三个项目，三层职责

这套组合的核心智慧，不在任何一个项目多强，而在职责切得干净——每层只管自己的事，不越界。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

┌─────────────────────────────────────────────────────────┐
│  你写的:   LLMInferenceService (KServe CRD)              │
│            "我要一个 Llama-3.1-70B，OpenAI 兼容接口"      │
├─────────────────────────────────────────────────────────┤
│  KServe:   模型生命周期 + 自动伸缩 + 流量治理              │
│            (InferenceService 控制平面)                    │
├─────────────────────────────────────────────────────────┤
│  llm-d:    集群级智能调度层                                │
│            (KV-cache 感知路由 / prefill-decode 分离)       │
├─────────────────────────────────────────────────────────┤
│  vLLM:     单机推理执行引擎                                │
│            (连续批处理 / PagedAttention / KV-cache)        │
├─────────────────────────────────────────────────────────┤
│  Kubernetes: 资源编排 (GPU / 存储 / 网络)                  │
└─────────────────────────────────────────────────────────┘

一张表锁死边界：

KServe 自己在博客里很坦诚地划了边界：「KServe 本身不做跨副本的 KV-cache 局部性路由，不做集群级 prefill/decode 分离，不做 SLA 感知路由，也不做跨 Pod 的 GPU 利用率优化。」——这些活，全交给 llm-d。这种分工不是拍脑袋，是承认每个项目都有天花板。

下面三节分别拆开讲。

三、KServe：模型服务的控制平面

KServe 是 CNCF 的模型服务项目（原名 KFServing），定位是 Kubernetes 原生的模型服务控制平面。核心抽象是 InferenceService 这个 CRD，把「一个模型怎么部署、怎么伸缩、怎么暴露」全封装了：

• 自动创建与调谐 Deployment
• 基于请求/并发的自动扩缩容，支持 Scale-to-Zero（对省 GPU 成本极其关键）
• 版本管理与金丝雀发布
• 端点暴露与流量路由
• 统一的运行时抽象（预测式与生成式 AI 都能接）

KServe v0.16 引入了专门针对大模型的 LLMInferenceService，因为 LLM 和传统 ML 模型的负载特征完全不同：

LLMInferenceService 提供原生 OpenAI 兼容 API（/v1/chat/completions），支持长连接流式输出、高并发 token 流、Prefix KV-Cache 管理、多轮对话。它底下接 vLLM、HuggingFace TGI 这些高效运行时，直接享受连续批处理、Paged Attention 等单机优化。

几个 K8s 层面的硬能力：

• Tensor / Pipeline Parallelism，可跨节点跑 70B+ 模型——「KServe 编排部署拓扑，运行时管理执行并行。」
• 和 Kubernetes Gateway API 深度集成，企业级路由、TLS 终止、流量分割、多模型路由，全走标准 API，不搞私有协议。
• Scale-to-Zero，流量低谷时把 GPU 还回去，这是省钱的杀手锏（冷启动预热得配好，模型加载不能让用户干等）。

但 KServe 有明确的边界——它不做跨副本的 KV-cache 感知路由，也不做 prefill/decode 的集群级分离。这两件事，正是 llm-d 的专长。

四、llm-d：集群智能层

llm-d 是这套架构里最年轻、也最关键的一层。2025 年 Red Hat 主导开源，NVIDIA、Google Cloud、IBM 背书，定位是 Kubernetes 原生的分布式 LLM 推理框架，口号是「分布式智能调度层」。

它回答的是一个被长期忽视的问题：单机 vLLM 已经把 PagedAttention 和 KV-cache 做到极致了，集群层面谁来管？ llm-d 干两件 KServe 和 vLLM 都管不了的事。

4.1 分离式推理：把 prefill 和 decode 拆开

大模型推理天然分两个阶段，这俩阶段的资源画像完全相反：

传统做法是两个阶段在同一个 GPU 上交替跑，互相抢资源——prefill 时 decode 排队，decode 时 prefill 闲置。llm-d 把它们物理拆到不同的 GPU 资源池：计算型资源专心做 prefill，延迟型资源专心做 decode，中间用智能调度把请求接力送过去。

效果直接：GPU 利用率上去、尾延迟下来、每 token 成本降下来。

4.2 KV-cache 感知调度：别让缓存白算

vLLM 单机内部会做 prefix（前缀）缓存——把常见 prompt 前缀的 KV 对算出来存着，下次遇到相同前缀直接复用。单机很有效。

一到集群就废了：缓存分散在各个 Pod 的 GPU 显存里，没人知道全局有哪些缓存。朴素负载均衡把请求随机分到任何 Pod，缓存命中率惨不忍睹。

llm-d 维护一个集群级的缓存索引。请求进来，调度器先查这个请求的前缀在哪个 Pod 上有缓存，优先路由到缓存命中的 Pod。把「随机分」变成「缓存感知分」，救回 KV-cache 的复用价值。

这个调度器做路由决策时，综合考量一堆因素：

• GPU 利用率
• 队列深度
• 缓存驻留情况
• SLA 约束
• 负载分布

目标不只是把请求分出去，而是在满足 SLA 的前提下最大化集群整体吞吐。

五、实测：换一层路由，性能翻倍

理论再漂亮不如数据说话。两篇博客里最硬核的，是 Tesla 在生产环境的实测。

Tesla 测试配置：

他们一开始用 KServe + vLLM + round-robin 负载均衡，后来把路由层换成 Envoy + Envoy AI Gateway + Gateway API Inference Extension，实现 prefix-cache 感知路由。切换前后：

llm-d 项目级的基准测试更夸张：

P90 首 token 快 57 倍这个数字尤其值得玩味。它不是 vLLM 单机优化能榨出来的——单机再快也就那样。这个数量级的提升只能来自一个地方：集群层面把请求精准路由到已经有缓存的 Pod，让 GPU 几乎不做重复的 prefill 计算。

这就是「集群智能」的价值。同样的 GPU，什么都不用超频，只换一层路由，吞吐就翻倍了。而且这些优化是可插拔、可演进的——不推倒重来，在现有 K8s 生态上叠加智能。

六、生产落地：Tesla 反哺了什么

Tesla 团队把这套架构推上生产后，反过来给 KServe 社区提了一堆改动和 issue。这些 issue 本身就是「生产环境真实痛点」的最佳注脚：

• 让 storageInitializer 可选——允许用 RunAI Model Streamer 作为替代方案（对应第一节那个存储痛点）。
• 支持最新的 Gateway API Inference Extension（prefix-cache 感知路由的基础设施）。
• 新增特性请求 issue：#4901、#4900、#4898、#4899（都在 KServe 仓库）。

这不是玩具项目的需求，是真金白银的 GPU 集群跑出来的。开源项目被生产环境倒逼着演进，是最健康的生态信号。

当前这套组合已经具备的落地能力：

• 深度定制：通过 LLMInferenceService / LLMInferenceConfig 能覆盖几乎所有 vLLM 启动参数，按硬件调优。
• 灵活拓扑：可演进不同的 prefill/decode 架构，不锁死一种部署形态。
• 标准 K8s API 体验：不引入额外学习成本，和现有集群无缝集成。
• 企业级网络与治理：Gateway API、TLS、流量分割、多模型路由一应俱全。

七、给落地者的决策清单

按规模对号入座：

几个坑提前打预防针：

• 存储：别用 NFS 存模型，慢到哭。要么节点本地卷 + 模型预分发，要么上支持流式加载的方案（RunAI Model Streamer）。
• 负载均衡：绝对不要用 round-robin 跑 LLM。哪怕不上 llm-d，至少上 Envoy AI Gateway 做 prefix-cache 感知路由。
• 自动伸缩：开 Scale-to-Zero 能省巨量 GPU 成本，但要配好冷启动预热。
• 多加速器：llm-d 设计上支持 GPU/TPU/XPU/CPU，生产验证最多的是 NVIDIA GPU 和 AMD MI300X（Tesla 用的就是 MI300X）。

八、为什么这事值得关注

这套架构的意义，不在于「又多了个开源项目」，而在于它标志着 LLM 推理基础设施走向成熟分工。

2023-2024 年，大家在卷单机推理引擎——vLLM、TGI、TensorRT-LLM 你追我赶，PagedAttention、FlashAttention、连续批处理，单机吞吐每年翻几倍。但单机优化是有天花板的，物理极限摆在那。

2025-2026 年，战火烧到集群层面。怎么调度几百张 GPU、怎么跨节点复用缓存、怎么拆分推理阶段——这些才是规模化降本的关键。llm-d 不是又一个 vLLM，它是站在 vLLM 肩膀上的集群大脑。

vLLM 解决单实例效率，KServe 解决模型服务的生命周期与治理，llm-d 解决跨实例的智能调度与资源协同。三者叠在一起，才是一个云原生、可扩展、成本可控、性能可预测的生产级 LLM 推理平台。

Red Hat + NVIDIA + Google Cloud + IBM 四家联手背书，Tesla 在生产环境验证，KServe 社区积极跟进集成——这个项目背后的势能是实打实的。如果你在做 LLM 平台工程，这是 2026 年最值得跟进的开源动向之一。社区文档、Slack、例会、代码仓库都已开放，值得去翻。

参考来源

• KServe 博客：《Best of Both Worlds: Cloud-Native AI Inference at Scale using KServe and llm-d》https://kserve.github.io/website/blog/cloud-native-ai-inference-kserve-llm-d
• llm-d 博客：《Production-Grade LLM Inference at Scale with KServe, llm-d, and vLLM》https://llm-d.ai/blog/production-grade-llm-inference-at-scale-kserve-llm-d-vllm
• llm-d 官网 https://llm-d.ai
• llm-d GitHub https://github.com/llm-d/llm-d
• KServe 官网 https://kserve.github.io/website/
• Red Hat Developer：Intelligent inference scheduling with llm-d https://developers.redhat.com/articles/2026/06/11/intelligent-inference-scheduling-llm-d-red-hat-ai

（文中数据均来自上述公开文章及引用基准）