随着 LLM 应用规模不断扩大，单机推理早已无法满足生产需求。本文梳理了当前主流的多集群/分布式 LLM 推理方案，帮助你根据自身场景做出合理选型。
一、为什么需要分布式 LLM 推理？
单机运行 vLLM 或 SGLang 时，会遇到三个核心瓶颈：
| 瓶颈 | 表现 | 根因 |
|---|---|---|
| 资源浪费 | GPU 利用率只有 40--60% | Prefill（计算密集）和 Decode（带宽密集）混跑在同一 Pod，互相干扰 |
| KV Cache 失效 | TTFT（首 token 延迟）高 | Round-robin 路由无视缓存状态，每次请求都要重算 system prompt |
| 显存瓶颈 | 长上下文（128K+）OOM | KV Cache 只存在 GPU HBM，容量有限 |
分布式方案的核心目标就是解决这三个问题。
二、技术层次划分
理解各方案前，先明确它们的层次关系：
┌─────────────────────────────────────────┐
│ 用户请求 / 应用层 │
├─────────────────────────────────────────┤
│ 编排/路由层：llm-d / Ray Serve / KServe │ ← 负责调度、路由、扩缩容
├─────────────────────────────────────────┤
│ 推理引擎层：vLLM / SGLang / TRT-LLM │ ← 负责实际计算 token
├─────────────────────────────────────────┤
│ 硬件层：NVIDIA / AMD / Intel GPU │
└─────────────────────────────────────────┘核心认知：vLLM 和 SGLang 是"推理引擎"，而 llm-d、Ray Serve 等是"编排调度层"，两者不是竞争关系，而是搭配关系。
三、主流方案详解
方案 1：vLLM Production Stack
定位：vLLM 官方出品的 Kubernetes 生产部署参考栈，2025 年 1 月发布。
核心能力：
- Prefix-Cache 感知路由：将请求路由到已缓存对应 KV 的 Pod，大幅提升缓存命中率
- KV Cache 卸载 ：通过集成 LMCache 实现 GPU → CPU 两级缓存
- 一键部署：单条 Helm 命令即可在 K8s 上拉起完整服务栈
- 开箱即用监控：内置 Prometheus + Grafana 仪表盘，展示 TTFT、KV 命中率、吞吐等指标
性能数据（官方 benchmark）：
- 相比裸 vLLM + KServe：吞吐 2--5x ，延迟 3--10x 更低
适合场景：
- 已经在用 vLLM，想快速上 K8s 集群
- 中小规模集群（几十张 GPU），希望快速落地
限制：
- KV Cache 卸载目前只到 CPU（无 NVMe 层）
- Prefill/Decode 分离处于实验阶段
链接： github.com/vllm-project/production-stack
方案 2：llm-d（CNCF Sandbox）
定位：由 IBM Research、Red Hat、Google Cloud 联合捐献给 CNCF 的 Kubernetes 原生分布式推理中间件，2026 年 3 月进入 CNCF Sandbox。底层推理引擎默认使用 vLLM。
核心能力：
| 能力 | 说明 |
|---|---|
| Prefill/Decode 分离 | Prefill Pod（算力优先）和 Decode Pod（带宽优先）独立部署、独立扩缩容 |
| 三级 KV Cache 卸载 | GPU HBM → CPU DRAM → NVMe SSD，支持 128K+ 长上下文 |
| EPP 前缀感知路由 | Endpoint Picker 根据 prompt 前缀哈希路由到缓存命中的 Pod |
| MoE 宽专家并行 | 使用 K8s LeaderWorkerSet 跨节点分布 MoE Expert（支持 DeepSeek、Mixtral） |
| Scale-to-Zero | 无流量时自动缩至 0 Pod，节省成本 |
| 硬件中立 | 同时支持 NVIDIA / AMD / Intel Gaudi / Google TPU |
性能数据（v0.5，Qwen3-32B，16 张 H100）：
- 吞吐：约 120,000 tokens/sec（8 vLLM Pod 线性扩展）
- GPU 利用率：从基线 40--60% 提升至 80%+
- TTFT：多租户共享 system prompt 场景下接近零（前缀缓存命中）
适合场景：
- 超大规模 K8s 集群（百张 GPU 以上）
- 多租户 SaaS，大量用户共享同一 system prompt
- 长上下文（128K+）推理
- 异构硬件集群（Prefill 跑 H100，Decode 跑 MI300X）
限制：
- CNCF Sandbox 阶段，API 可能有 breaking changes，不建议直接上生产
- 依赖完整 K8s 基础设施，运维复杂度高
- 当前版本（v0.5.1）仍在快速迭代
方案 3：Ray Serve + vLLM/SGLang
定位：Anyscale 出品的通用分布式 ML 服务框架，通过挂载 vLLM 或 SGLang 作为推理后端实现 LLM serving。
核心能力：
- 原生支持跨节点 Tensor Parallelism 和 Pipeline Parallelism
- 与 Ray 生态深度集成，可与训练、数据处理任务共享集群资源
- 支持 Python 代码级灵活定制路由逻辑
- 通过 Anyscale 平台提供托管服务
适合场景：
- 已有 Ray 集群基础设施
- 需要在同一集群上混合推理和训练任务
- 追求 Python 层面的高度灵活定制
限制：
- 原生路由策略较弱（缺乏 prefix-cache 感知），需自行实现
- 相比 llm-d/production-stack，开箱即用的 LLM 专属优化较少
方案 4：NVIDIA Triton + TensorRT-LLM
定位：NVIDIA 官方推理服务器，配合 TensorRT-LLM 引擎，针对 NVIDIA GPU 做深度优化。
核心能力：
- TensorRT-LLM 内核级优化，延迟最低（同等硬件下）
- 支持 In-Flight Batching、Paged KV Cache、Chunked Context
- 多节点 Tensor Parallelism 通过 NCCL 实现
- 完善的 Triton 生态（支持 gRPC、HTTP、共享内存等）
适合场景：
- 全 NVIDIA 硬件栈，不考虑多硬件厂商
- 对推理延迟要求极致（金融、实时语音等）
- 已有 NVIDIA AI Enterprise 授权的企业
限制：
- 强硬件绑定，不支持 AMD / Intel
- 配置复杂，学习曲线陡峭
- 不支持 Prefill/Decode 分离
- 模型支持范围相比 vLLM 窄
链接： github.com/NVIDIA/TensorRT-LLM
方案 5：KServe v0.17+
定位 ：Kubernetes 原生 ML 服务平台，v0.17 引入 LLMInferenceService CRD，底层基于 llm-d 实现。
核心能力：
- 统一的模型生命周期管理（部署、灰度、回滚）
- v0.17 起支持 KV-Cache 感知调度、Prefill/Decode 分离（via llm-d）
- ModelMesh 支持数百到数千个小模型的高密度部署
- 与 Knative、KEDA 集成实现弹性扩缩容
适合场景：
- 已有 KServe 基础设施，想升级到 LLM 场景
- 同时需要管理传统 ML 模型和 LLM
- 追求 K8s 生态标准化
注意：KServe v0.17 的 LLM 能力本质上是 llm-d 的封装，两者能力基本相同。
链接： kserve.github.io
四、横向对比一览
| 维度 | vLLM Production Stack | llm-d | Ray Serve | Triton + TRT-LLM | KServe v0.17 |
|---|---|---|---|---|---|
| 推理引擎 | vLLM | vLLM | vLLM/SGLang | TRT-LLM | vLLM（via llm-d） |
| Prefix-Cache 路由 | ✅ | ✅ | ⚠️ 需自实现 | ❌ | ✅ |
| Prefill/Decode 分离 | ⚠️ 实验性 | ✅ | ⚠️ 需配置 | ❌ | ✅ |
| KV Cache 三级卸载 | GPU→CPU | GPU→CPU→NVMe | ❌ | ❌ | GPU→CPU→NVMe |
| 多节点并行 | ✅ | ✅ | ✅ | ✅ | ✅ |
| Scale-to-Zero | ⚠️ KEDA | ✅ | ⚠️ | ❌ | ✅ |
| 硬件支持 | 主要 NVIDIA | NVIDIA/AMD/Intel/TPU | NVIDIA/AMD | 仅 NVIDIA | NVIDIA/AMD/Intel |
| 上手难度 | 低 ⭐ | 高 | 中 | 高 | 中高 |
| 生产成熟度 | ✅ 稳定 | ⚠️ Sandbox | ✅ 稳定 | ✅ 最成熟 | ⚠️ v0.17 较新 |
| 开源协议 | Apache 2.0 | Apache 2.0 | Apache 2.0 | Apache 2.0 | Apache 2.0 |
五、选型决策树
你有 Kubernetes 集群吗？
├── 否 → Ray Serve（最灵活，不强依赖 K8s）
└── 是
├── 全 NVIDIA 硬件 + 对延迟要求极致？
│ └── 是 → Triton + TensorRT-LLM
├── 规模 < 100 张 GPU，想快速上线？
│ └── 是 → vLLM Production Stack（首选）
├── 规模 ≥ 100 张 GPU / 多租户 SaaS / 长上下文？
│ └── 是 → llm-d（接受 Sandbox 风险）或等其 GA 版本
└── 已有 KServe 基础设施？
└── 是 → KServe v0.17（本质是 llm-d 封装）六、2026 年趋势展望
- Prefill/Decode 分离将成标配：从实验特性走向生产默认，vLLM Router、llm-d、SGLang 均在推进
- KV Cache 分级存储普及：NVMe 层缓存将大幅降低长上下文推理成本
- 硬件异构化加速：AMD MI300X、Intel Gaudi 在 Decode 场景性价比突出，多硬件混合部署需求增加
- llm-d 走向成熟：预计 2026 年底从 CNCF Sandbox 晋升，成为 K8s LLM 推理事实标准
- 路由智能化：Prefix-Cache 感知路由、LoRA 感知路由、SLO 感知调度逐步落地