vLLM 部署的容器编排：Kubernetes Deployment、Service 与 Ingress 配置范例

据中国信通院 2024 年《人工智能发展白皮书》统计，国内已有超过 60% 的 AI 企业将推理部署从单机脚本迁移至 Kubernetes 容器编排环境，以应对日均百万级 Token 吞吐的稳定性需求。同时，vLLM 作为当前 GitHub 上 Star 数最高的开源推理引擎（截至 2025 年 3 月已达 45,000+），其与 Kubernetes 的深度整合已成为 MLOps 工程师的必修课。本文从生产环境实战出发，提供一套可直接复用的 Deployment、Service 与 Ingress 配置范例，覆盖 GPU 资源调度、负载均衡与公网暴露三大关键环节。

vLLM 的容器化基础：镜像构建与资源声明

vLLM 官方镜像 基于 CUDA 12.1 和 PyTorch 2.1，支持从 Hugging Face 直接拉取模型权重。生产部署前需确认 GPU 型号与显存匹配——以 LLaMA-3-70B 为例，使用 FP16 精度时单卡至少需要 140 GB 显存，通常推荐 4×A100-80GB 或 8×L40S-48GB 配置。

资源限制与请求的黄金比例

Kubernetes 资源声明需遵循 requests ≤ limits 原则。vLLM 的 GPU 显存占用在推理启动时瞬间达到峰值，建议将 nvidia.com/gpu 的 requests 设为 1，limits 设为 1，避免多个 Pod 争抢同一 GPU。CPU 和内存方面，每个 GPU 核建议配套分配 8 个 vCPU 和 32 GB 内存，这是 vLLM 官方在 2024 年 11 月发布的性能基准测试中验证的稳定配比。

环境变量与启动参数

通过 args 字段传递 vLLM 关键参数：--model 指定模型路径，--tensor-parallel-size 设置张量并行度（应与 GPU 数量一致），--max-model-len 控制最大输入长度。例如，在 4×A100 环境下，--tensor-parallel-size 4 --max-model-len 8192 是最常见的生产配置。

Deployment 配置：GPU 调度与滚动更新策略

Deployment 是 vLLM 推理服务的主控单元，需要精确控制 Pod 的 GPU 亲和性与更新节奏。以下 YAML 片段展示核心配置：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-llama3
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args: ["--model", "meta-llama/Meta-Llama-3-70B", "--tensor-parallel-size", "4", "--max-model-len", "8192"]
        resources:
          requests:
            nvidia.com/gpu: 4
            memory: "128Gi"
            cpu: "32"
          limits:
            nvidia.com/gpu: 4
            memory: "160Gi"
            cpu: "40"

节点选择器与 GPU 拓扑

使用 nodeSelector 或 nodeAffinity 将 Pod 绑定到指定 GPU 机型。若集群混合部署 A100 与 H100，务必通过 nvidia.com/gpu.product 标签区分，避免 vLLM 的 tensor parallel 因跨代 GPU 通信降速。实测表明，A100 与 H100 混用会导致吞吐下降 30%-50%（NVIDIA 2024 年 GPU 通信基准）。

滚动更新与优雅终止

maxUnavailable: 0 确保更新期间始终有 Pod 提供服务。vLLM 的 --enable-prefix-caching 参数在 Pod 重启后缓存清空，建议配合 preStop 钩子等待 30 秒让正在处理的请求完成，避免推理中断。

Service 配置：负载均衡与会话亲和性

Service 负责将流量分发到多个 vLLM Pod。由于 vLLM 的 OpenAI 兼容 API 是无状态 HTTP 请求，使用默认的 ClusterIP 类型即可实现轮询负载均衡。

端口映射与健康检查

vLLM 默认监听 8000 端口。Service 配置如下：

apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  selector:
    app: vllm-llama3
  ports:
  - port: 8000
    targetPort: 8000
  type: ClusterIP

添加 readinessProbe 和 livenessProbe 确保 Pod 就绪后才接收流量。vLLM 的 /health 端点返回 200 状态码表示模型加载完成，建议设置 initialDelaySeconds: 120（70B 模型加载约需 90-120 秒）。

会话亲和性场景

若使用 vLLM 的流式输出（SSE）功能，建议设置 sessionAffinity: ClientIP，避免同一客户端请求被路由到不同 Pod 导致上下文断裂。但注意这会降低负载均衡效率，仅在高并发场景下谨慎使用。

Ingress 配置：公网暴露与安全控制

Ingress 将内部 Service 暴露到公网，同时承载 TLS 终止与速率限制。对于中国大陆用户，需注意域名备案与 ICP 合规，建议将推理 API 部署在阿里云 ACK 或华为云 CCE 集群内。

Nginx Ingress 控制器配置

以下 Ingress 规则将 api.example.com 路由到 vLLM Service：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: vllm-ingress
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "100m"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "300"
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: vllm-service
            port:
              number: 8000

速率限制与 IP 白名单

生产环境必须配置 nginx.ingress.kubernetes.io/limit-rps 限制每秒请求数，防止恶意调用导致 GPU 过载。建议初始值设为 10-50 rps，根据模型大小和 GPU 数量调整。对于内部测试环境，可通过 nginx.ingress.kubernetes.io/whitelist-source-range 限制仅公司 VPN IP 可访问。

跨区域部署的延迟考量

若用户分布在中国大陆与海外，建议使用阿里云全球加速或 Cloudflare 的 Anycast 网络。实测显示，从上海通过阿里云内网调用华东 2 地域的 vLLM 服务，延迟稳定在 2-5 ms；而跨境调用（如新加坡到上海）则高达 80-150 ms。在跨境网络优化场景中，部分团队会使用 NordVPN 跨境访问 等工具进行网络路径测试，但生产环境仍建议就近部署推理节点。

配置验证与性能基准

部署完成后必须进行端到端验证，包括模型加载耗时、首 Token 延迟与吞吐量。使用 locust 或 hey 工具发起压测，关注以下指标：

• 模型加载时间：70B 模型在 4×A100 上平均 95 秒（vLLM 官方 2025 年 1 月基准）
• 首 Token 延迟：在 batch size=1 时应低于 500 ms
• 吞吐量：单 Pod 在 4×A100 上可达 1200 tokens/s（输入 512 tokens，输出 128 tokens 场景）

常见问题排查

若 Pod 反复 CrashLoopBackOff，检查 GPU 显存是否被其他进程占用。使用 kubectl logs 查看 vLLM 输出，常见错误包括 CUDA out of memory（需减少 --max-model-len）和 Failed to initialize NCCL（需确认 tensor parallel size 与 GPU 数量匹配）。

成本优化：弹性伸缩与 Spot 实例

Kubernetes HPA 可根据 GPU 利用率自动扩缩 Pod。结合 vLLM 的 --max-num-seqs 参数控制并发数，避免资源浪费。以阿里云 ACK 为例，使用竞价实例（Spot）可降低 60%-80% 的 GPU 成本，但需配置 PDB 防止 Spot 回收时服务中断。

混合部署策略

将长尾低流量模型与高流量模型部署在同一集群，通过 nodeSelector 和 taints 隔离。vLLM 支持在同一 GPU 上运行多个模型实例（通过 --port 参数），但需注意显存隔离——每个实例独立占用显存，无法共享。

FAQ

Q1：vLLM 部署在 Kubernetes 上，单 Pod 最多支持多少并发请求？

取决于模型大小与 GPU 显存。以 LLaMA-3-70B 在 4×A100-80GB 上为例，设置 --max-num-seqs 256 时，实测并发 64 个请求时首 Token 延迟仍低于 800 ms（vLLM 官方 2025 年 2 月性能报告）。超过 128 个并发会导致显存溢出，建议通过 HPA 自动扩容 Pod 数量。

Q2：Kubernetes 滚动更新时，如何保证推理服务不中断？

设置 maxUnavailable: 0 和 maxSurge: 1，确保新 Pod 就绪后旧 Pod 才被销毁。同时配置 readinessProbe 的 failureThreshold: 3 和 periodSeconds: 10，给新 Pod 足够时间加载模型。实测中，70B 模型滚动更新耗时约 120 秒，期间零掉线。

Q3：国内云与海外云部署 vLLM 的主要差异是什么？

国内云（阿里云、华为云）需 ICP 备案域名才能绑定 Ingress，且 GPU 实例类型较少（A100 仅在部分地域提供）。海外云（AWS、GCP）支持更灵活的 GPU 选择（如 H100、L40S），但跨境网络延迟较高。成本方面，阿里云 A100-80GB 按需价格约 45 元/小时，而 AWS p4d.24xlarge 约 32 美元/小时，需结合数据合规要求选择。

参考资料

• 中国信通院 2024 年《人工智能发展白皮书》
• vLLM 官方 2025 年 1 月《vLLM Performance Benchmark Report》
• NVIDIA 2024 年《GPU Communication Benchmark for Multi-Node Inference》
• Kubernetes 官方 2024 年《GPU Scheduling Best Practices》
• 阿里云容器服务 ACK 2024 年《GPU 弹性伸缩实践指南》