云原生推理体系的标准化与模块化，正让大模型部署像 Web 服务一样简单高效。
大模型推理正在从单机加速器时代迈向云原生分布式体系。当前最具代表性的组合是 KServe、vLLM、llm-d 与 WG Serving（Working Group Serving）。它们分别承担标准接口、执行引擎、调度层和协作规范四个角色，共同形成可扩展、可观测、可治理的推理底座。
下方时间线梳理了四件套的关键演进节点：
架构总览
下方架构图展示了四件套在推理体系中的分层协作关系：
KServe：云原生模型服务核心
KServe 是 Kubernetes 原生的推理控制平面。它以 CRD（Custom Resource Definition, 自定义资源定义）形式抽象模型服务，使 AI 推理像微服务一样可部署、可扩缩、可灰度。
下表总结了 KServe 的核心能力与新特性：
| 维度 | 描述 |
|---|---|
| 核心目标 | 提供 Kubernetes 原生的推理标准与控制面 |
| 核心能力 | CRD 标准化、弹性伸缩、流量治理、网关统一入口 |
| 新特性 | LeaderWorkerSet 支持、AI Gateway 集成、与 llm-d 对接 |
KServe 的关键能力包括：
- 统一接口：InferenceService CRD 定义输入输出协议，与 REST/GRPC 或 OpenAI API 兼容。
- 弹性调度：支持 GPU 自动伸缩与 ModelMesh 多模型托管。
- 流量治理：金丝雀发布、A/B 测试、推理图（InferenceGraph）。
最新版本引入 LeaderWorkerSet（LWS）机制与 Envoy AI Gateway 扩展，使多 Pod 大模型推理成为原生能力。KServe 正从传统 ML 服务平台转型为 生成式 AI 控制平面标准。
vLLM：高性能推理执行引擎
vLLM 聚焦极致吞吐与显存效率，是当前开源性能标杆。
下方时序图展示了 vLLM 推理的主要流程：
下表总结了 vLLM 的核心技术机制与效果：
| 特性 | 技术机制 | 效果 |
|---|---|---|
| PagedAttention | 显存分页管理 | 延长上下文，减少碎片 |
| Continuous Batching | 动态批调度 | 提高 GPU 利用率 |
| Prefix Cache | 前缀复用 | 降低延迟与成本 |
vLLM 兼容 OpenAI API，支持 INT8/FP8 等量化及多种并行模式，适配 NVIDIA、AMD、TPU、Gaudi 等硬件。在单机或小规模场景下，vLLM 可独立运行；在集群环境中，它是 KServe/llm-d 的执行底座。
llm-d：分布式推理调度层
llm-d 是 Kubernetes 上的大模型调度与编排系统，为 vLLM 提供多实例协同能力。设计目标：让集群像单机一样推理。
下表总结了 llm-d 的核心机制与技术亮点：
| 模块 | 功能 | 技术亮点 |
|---|---|---|
| Scheduler | 缓存感知路由 | 按前缀亲和调度 |
| Prefill/Decode 分离 | 异构硬件优化 | A100 Prefill + L40 Decode |
| Cache Manager | 全局缓存索引 | GPU/CPU/NVMe 层次化缓存 |
下方流程图展示了 llm-d 的分布式调度与缓存机制：
llm-d 在 KServe 控制面下以 Leader/Worker 形式运行，调度器嵌入 Envoy 或独立部署，可实时依据缓存与负载信息决策路由。其出现让多节点大语言模型（LLM, Large Language Model）推理首次具备了自治调度与弹性并行。
WG Serving：协同标准与生态枢纽
WG Serving 是 Kubernetes 社区推动的 AI Serving 工作组，定义推理在 K8s 中的统一语义。
下表总结了 WG Serving 的核心成果与标准化贡献：
| 成果/标准 | 说明 |
|---|---|
| Gateway Inference Extension (GIE) | 基于 Envoy 的推理网关协议，支持模型识别、流式转发、优先级与缓存亲和路由 |
| LeaderWorkerSet CRD | 显式描述 Leader–Worker 协作结构，成为 llm-d 和 KServe 实现多 Pod 推理的基础 |
| 接口对齐 | 倡导 OpenAI-style API 与 K8s 资源对象融合，推动多框架互通 |
GIE 是云原生 AI 推理的“统一网关语言”，就像 Ingress 定义 HTTP 服务入口一样，它定义了推理请求在 Kubernetes 内的标准语义与网关行为，使推理系统可组合、可观测、可扩展。
下方流程图展示了 WG Serving 在推理体系中的标准化协作关系：
WG Serving 不是产品，而是形成行业共识的标准层，正促成云原生 AI 推理的统一语言。
组合架构
下表总结了四件套在系统中的分工与角色：
| 层级 | 组件 | 角色 |
|---|---|---|
| 入口层 | Envoy + GIE | 统一 API 网关与流量调度钩子 |
| 控制层 | KServe + LWS | 生命周期管理、弹性伸缩、流量编排 |
| 调度层 | llm-d | 前缀感知路由、跨 Pod 协作、缓存管理 |
| 执行层 | vLLM | 高效推理执行与缓存复用 |
下方架构图展示了四件套的协同关系：
客户端以 OpenAI API 格式发送请求，经 GIE 网关调度到最优 Leader，Prefill 完成后缓存传递至 Worker Decode，最终流式返回结果。整套链路兼具标准接口、高吞吐与弹性伸缩特性。
生态收敛趋势
下表总结了云原生大模型推理生态的收敛趋势与特性对比：
| 趋势/特性 | 说明 |
|---|---|
| API 统一化 | OpenAI 式接口成为事实标准，KServe 与 vLLM 等均原生兼容 |
| 模块解耦 | 网关、调度、推理分层，利于独立演进与替换 |
| 缓存分层化 | GPU–CPU–NVMe 三级 KV 缓存成为主流方案 |
| 社区协同 | WG Serving、PyTorch 基金会、CNCF 等共同推动跨项目融合 |
下方对比矩阵展示了各项目的核心能力：
| 项目 | 控制面 | 推理性能 | 分布式能力 | 接口兼容 | 缓存机制 | 弹性扩缩 |
|---|---|---|---|---|---|---|
| KServe | ✅ CRD / LWS | ⚪ 中 | ⭐ 多模型管理 | ✅ OpenAI API | ⚪ 无 | ✅ |
| vLLM | ⚪ 无 | 🌟 极高 | ⭐ 多 GPU | ✅ OpenAI API | ✅ Paged KV | ⚪ 无 |
| llm-d | ⭐ K8s 原生调度 | 🌟 高 | 🌟 多实例协同 | ✅ 继承上层接口 | 🌟 全局缓存 | ✅ |
| WG Serving | 🌟 标准抽象 | ⚪ 无 | 🌟 跨项目协同 | 🌟 统一规范 | ⚪ 不涉及 | ⚪ |
未来推理栈将以标准 API 与可插拔模块为核心，实现像部署 Web 服务一样部署大语言模型（LLM, Large Language Model）。
部署范式示例
在 Kubernetes 集群中，四件套的部署范式如下：
- Prefill 层：4 × A100 Pod，负责长上下文计算。
- Decode 层：16 × L4 Pod，执行流式生成。
- llm-d 调度器：依据缓存命中率动态路由。
- KServe 控制面：管理 LWS 资源与扩缩容。
- Envoy GIE 网关：统一 OpenAI 接口入口。
下方拓扑图展示了部署结构：
此组合实现高并发、低成本、可观测的大模型服务。
结语：标准化的未来
下表总结了四件套在推理体系中的层级、角色与核心贡献：
| 层级 | 角色 | 核心贡献 |
|---|---|---|
| 入口层 | WG Serving (GIE) | 统一流量入口与接口规范 |
| 控制层 | KServe | Kubernetes 原生部署与管理 |
| 调度层 | llm-d | 前缀缓存感知的分布式推理调度 |
| 执行层 | vLLM | 高性能、低成本推理引擎 |
结论：
这套“四件套”标志着大模型推理进入标准化与可组合时代。未来趋势将聚焦于：
- API 规范化（OpenAI / OpenInference）
- 缓存分层与共享化
- 控制面与数据面解耦
- 云原生平台一体化编排
总结
云原生大模型推理“四件套”——KServe、vLLM、llm-d、WG Serving——正在推动推理体系的标准化、模块化与生态融合。通过分层协作与标准接口，开发者可实现高性能、低成本、可观测的大语言模型推理服务，助力 AI 原生架构的落地与创新。