vLLM Production Stack：Kubernetes 推理栈的落地评估
面向 Kubernetes 集群的 vLLM 生产参考实现，组合推理引擎、请求路由和可观测组件。
vLLM Production Stack inference Kubernetes open-source 面向 Kubernetes 集群的 vLLM 生产参考实现，组合推理引擎、请求路由和可观测组件。
1. 项目定位
vLLM Production Stack 是 vLLM 项目下的开源生产参考栈，目标是在 vLLM 之上组织集群级推理服务。官方文档称应用可在不改调用代码的情况下，从单个 vLLM 实例扩展到分布式部署，并获得路由、KV Cache 利用与监控能力。[S2] 它不是托管模型服务，也不负责训练模型。
2. 核心组成
官方架构包含运行不同模型的 vLLM serving engine、把请求分配到后端的 router，以及由 Prometheus 和 Grafana 组成的观测栈。[S2] Router 可按路由键或会话 ID 分发请求，以提高缓存复用；对外仍提供与 vLLM 一致的 OpenAI API 风格接口，便于现有客户端接入。[S2]
3. 部署前提
最小部署使用 Helm，前提是已有带 GPU 的 Kubernetes 环境。[S2] 这意味着团队必须自行承担节点、驱动、镜像、网络、存储、容量和集群升级。它适合已有平台工程能力的组织；如果只有单机低流量服务，先使用基础 vLLM 往往更容易判断真实瓶颈。
4. 可观测与运维
官方仪表盘覆盖健康实例数、端到端延迟、首 Token 时间、运行与等待请求数、GPU KV Cache 使用率及命中率。[S2] 这些指标足以建立推理服务的第一版容量基线，但不能替代业务成功率、模型输出质量和单请求成本。生产环境仍需加入日志留存、告警责任人与故障演练。
5. 适用场景
多副本推理、会话亲和、需要统一观测的 GPU 集群，是最直接的场景。对多模型端点或突发请求，路由层也可作为扩展入口。若工作负载主要是批处理、无稳定 Kubernetes 团队，或模型受外部 SaaS 托管，部署整套栈可能增加的运维成本高于收益。
6. 主要风险
参考实现不等于开箱即用的生产保证。GPU 资源不足、模型加载过慢、路由策略不匹配和缓存倾斜都可能造成排队或尾延迟。项目路线图中的功能不能提前当作现有能力；官方文档仍把部分路由改进和特性列为持续工作。[S2] 升级前应锁定版本并在副本环境验证。
7. 开源与治理
代码仓库公开，站点标明采用 MIT License，并通过标准 GitHub 流程接受贡献。[S1][S2] 开源使团队可以审查与修改部署逻辑，但也意味着补丁、兼容性和安全响应需要内部负责人跟踪。采用前应检查发行版本、提交活跃度、依赖镜像和所用 Helm values，而不只看主分支演示。
8. 接入路径
先用单一模型、固定 GPU 和最小 Helm 配置建立基线，再逐步增加副本和路由算法。保留现有客户端请求格式，分别压测短输入、长上下文、连续会话和突发流量。只有当扩容后吞吐提高且 P95/P99 延迟、失败率与显存占用仍在阈值内，才进入灰度流量。
9. 验收建议
验收至少包括：实例故障后服务发现是否生效；滚动升级是否中断请求；路由能否避免单后端过载；仪表盘与原始指标是否一致；容量上限是否可复现。还要记录每种模型和硬件的 tokens/s、TTFT、排队时间和单位请求成本，形成可回归的版本基线。
10. 来源与更新时间
调研截至 2026 年 8 月 7 日。部署前应以所选版本的仓库、文档和发行说明为准。