大模型服务弹性扩容：基于 K8s HPA 与 GPU 指标的自动伸缩实战
一、大模型服务的扩容困境：传统 HPA 的失灵
Kubernetes 的水平 Pod 自动伸缩器（HPA）是云原生应用弹性扩容的标准方案。传统 Web 服务通过 CPU 利用率触发扩缩容，效果良好——CPU 利用率与请求负载之间呈强正相关。但大模型推理服务打破了这一假设。
GPU 是大模型推理的核心算力，而 GPU 利用率与请求延迟之间并非简单的线性关系。当 GPU 显存利用率达到 80% 时，推理延迟可能仍然正常；但当显存利用率超过 95% 时，延迟会突然飙升数倍——因为 GPU 开始频繁进行显存换页。此时 CPU 利用率可能仍然很低，传统 HPA 完全无法感知这种即将到来的性能悬崖。
更复杂的是，大模型推理服务存在冷启动问题。一个新启动的 Pod 需要加载模型权重到 GPU，这个过程可能耗时数十秒到数分钟。这意味着扩容不是即时的，从 HPA 触发到新 Pod 真正就绪之间存在不可忽视的延迟窗口。
本文将深入分析大模型服务的弹性扩容机制，给出基于自定义指标的 HPA 策略和预热调度的生产级方案。
二、大模型服务弹性扩容的核心机制
2.1 扩容决策链路
大模型服务的弹性扩容需要一条从指标采集到 Pod 就绪的完整链路，每个环节都有其特定的延迟和约束。
flowchart LR subgraph 指标采集层 A[GPU 指标<br/>DCGM Exporter] --> D[Prometheus] B[推理延迟<br/>vLLM Metrics] --> D C[请求队列深度<br/>自定义指标] --> D end subgraph 决策层 D --> E[Prometheus Adapter<br/>指标转换] E --> F[K8s HPA Controller<br/>扩缩容决策] F --> G{扩容 or 缩容?} end subgraph 执行层 G -->|扩容| H[创建新 Pod] G -->|缩容| I[优雅终止 Pod] H --> J[模型预热<br/>加载权重到 GPU] J --> K[就绪探针通过<br/>加入 Service Endpoints] I --> L[排空请求<br/>等待处理完成] L --> M[终止 Pod] end style J fill:#fff3e0 style K fill:#e8f5e92.2 自定义指标体系
大模型推理服务的扩容决策不能依赖单一指标，需要构建多维指标体系：
| 指标类别 | 指标名称 | 采集来源 | 扩容触发阈值 |
|---|---|---|---|
| GPU 算力 | GPU 计算利用率 | DCGM Exporter | > 80% |
| GPU 显存 | GPU 显存使用率 | DCGM Exporter | > 85% |
| 推理延迟 | P99 推理延迟 | vLLM Metrics | > 2s |
| 队列深度 | 等待推理的请求数 | 自定义 Metrics | > 10 |
| 吞吐量 | 每秒处理 Token 数 | vLLM Metrics | 下降 30% |
2.3 扩容延迟的组成与优化
gantt title 大模型服务扩容延迟分解 dateFormat X axisFormat %s秒 section HPA 决策 指标采集间隔(15s) :a1, 0, 15 HPA 评估周期(15s) :a2, 15, 30 section Pod 创建 调度器分配节点 :b1, 30, 35 拉取容器镜像 :b2, 35, 55 section 模型预热 加载模型权重到 GPU :c1, 55, 95 预热推理(填充 KV Cache) :c2, 95, 105 section 就绪验证 就绪探针通过 :d1, 105, 110从 HPA 触发到 Pod 就绪，总延迟可能超过 100 秒。其中模型预热是最耗时的环节，需要通过模型预热策略来优化。
三、生产级弹性扩容实现与最佳实践
3.1 自定义 Metrics Pipeline 搭建
基于 Prometheus + Adapter 的自定义指标链路：
# prometheus-adapter 配置：将自定义指标暴露给 K8s API apiVersion: v1 kind: ConfigMap metadata: name: adapter-config namespace: monitoring data: config.yaml: | rules: # GPU 显存使用率指标 - seriesQuery: 'DCGM_FI_DEV_FB_USED{gpu="."}' resources: overrides: namespace: { resource: "namespace" } pod: { resource: "pod" } name: matches: "DCGM_FI_DEV_FB_USED" as: "gpu_memory_usage_percent" metricsQuery: 'avg_over_time(DCGM_FI_DEV_FB_USED{namespace="<<.Namespace>>",pod=~"<<.Pod>>"}[1m])' # 推理 P99 延迟指标 - seriesQuery: 'vllm_inference_latency_seconds{quantile="0.99"}' resources: overrides: namespace: { resource: "namespace" } pod: { resource: "pod" } name: matches: "vllm_inference_latency_seconds" as: "inference_p99_latency_ms" metricsQuery: 'avg_over_time(vllm_inference_latency_seconds{quantile="0.99",namespace="<<.Namespace>>",pod=~"<<.Pod>>"}[1m]) * 1000' # 请求队列深度指标 - seriesQuery: 'vllm_num_requests_waiting' resources: overrides: namespace: { resource: "namespace" } pod: { resource: "pod" } name: matches: "vllm_num_requests_waiting" as: "request_queue_depth" metricsQuery: 'avg_over_time(vllm_num_requests_waiting{namespace="<<.Namespace>>",pod=~"<<.Pod>>"}[30s])'3.2 多指标 HPA 策略配置
# 大模型推理服务的多指标 HPA 配置 apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: llm-inference-hpa namespace: ai-serving spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: llm-inference minReplicas: 2 maxReplicas: 10 metrics: # 指标1：GPU 显存使用率（核心指标） - type: Pods pods: metric: name: gpu_memory_usage_percent target: type: AverageValue averageValue: "80" # 平均显存使用率超过 80% 触发扩容 # 指标2：推理 P99 延迟（延迟兜底） - type: Pods pods: metric: name: inference_p99_latency_ms target: type: AverageValue averageValue: "2000" # P99 延迟超过 2s 触发扩容 # 指标3：请求队列深度（实时负载感知） - type: Pods pods: metric: name: request_queue_depth target: type: AverageValue averageValue: "8" # 平均队列深度超过 8 触发扩容 behavior: scaleUp: # 扩容策略：快速响应 stabilizationWindowSeconds: 30 # 扩容稳定窗口仅 30 秒 policies: - type: Pods value: 3 # 每次最多扩 3 个 Pod periodSeconds: 60 - type: Percent value: 100 # 或翻倍扩容 periodSeconds: 60 selectPolicy: Max # 取两种策略的最大值 scaleDown: # 缩容策略：保守执行 stabilizationWindowSeconds: 300 # 缩容稳定窗口 5 分钟 policies: - type: Pods value: 1 # 每次最多缩 1 个 Pod periodSeconds: 120 selectPolicy: Min3.3 模型预热与就绪探针
模型预热是解决冷启动延迟的关键。通过 Init Container 预加载模型，并通过就绪探针确保 Pod 只在模型完全加载后才接收流量：
apiVersion: apps/v1 kind: Deployment metadata: name: llm-inference namespace: ai-serving spec: replicas: 2 selector: matchLabels: app: llm-inference template: metadata: labels: app: llm-inference spec: # 优先调度到 GPU 资源充足的节点 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: nvidia.com/gpu.product operator: In values: ["A100-SXM4-80GB"] containers: - name: vllm-server image: vllm/vllm-openai:latest resources: limits: nvidia.com/gpu: 1 requests: nvidia.com/gpu: 1 cpu: "4" memory: "16Gi" # 环境变量：模型预热配置 env: - name: MODEL_NAME value: "/models/llama-7b-chat" - name: GPU_MEMORY_UTILIZATION value: "0.90" - name: ENABLE_PREFIX_CACHING value: "true" ports: - containerPort: 8000 # 就绪探针：确保模型加载完成后才接收流量 readinessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 10 periodSeconds: 5 failureThreshold: 30 # 最多等待 150 秒 # 存活探针：检测推理服务是否卡死 livenessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 120 periodSeconds: 30 failureThreshold: 3 # 启动后执行预热推理 lifecycle: postStart: exec: command: - /bin/sh - -c - | # 等待 vLLM 服务启动 until curl -s http://localhost:8000/health > /dev/null; do sleep 2 done # 发送预热请求，填充 KV Cache curl -s -X POST http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"/models/llama-7b-chat","messages":[{"role":"user","content":"warmup"}],"max_tokens":1}'3.4 优雅缩容：请求排空机制
缩容时直接终止 Pod 会导致正在处理的推理请求中断。需要实现请求排空机制：
# 在 Pod 的 preStop 钩子中标记 Pod 为不可调度 # 并等待正在处理的请求完成 lifecycle: preStop: exec: command: - /bin/sh - -c - | # 1. 从 Service Endpoints 中移除，不再接收新请求 curl -s -X PUT http://localhost:8000/drain # 2. 等待正在处理的请求完成（最多 120 秒） for i in $(seq 1 120); do active=$(curl -s http://localhost:8000/metrics | \ grep 'vllm_num_requests_running' | \ awk '{print $2}') if [ "$active" = "0" ] || [ -z "$active" ]; then break fi sleep 1 done # 配合 terminationGracePeriodSeconds terminationGracePeriodSeconds: 150四、弹性扩容的架构权衡与适用边界
4.1 扩容延迟与资源浪费的矛盾
为了减少扩容延迟，可以维持一定数量的冗余 Pod（如 minReplicas=3 而非 2），但这意味着常态下 GPU 资源利用率降低。在 GPU 成本极高的场景下，这种浪费不可忽视。折中方案是使用预测性扩容：基于历史流量模式提前扩容，而非等到指标超阈值才反应。
4.2 缩容震荡问题
流量波动场景下，HPA 可能在扩容和缩容之间反复切换，导致 Pod 频繁创建销毁。通过增大缩容稳定窗口（5 分钟以上）和限制缩容速率（每次最多缩 1 个 Pod）来缓解。但稳定窗口过长会导致低峰期资源浪费。
4.3 多指标冲突
当 GPU 显存使用率正常但 P99 延迟超标时，HPA 的行为取决于selectPolicy配置。Max策略会取所有指标中最大的扩容建议，可能导致过度扩容；Min策略则可能忽略延迟告警。建议以 GPU 显存为核心指标，延迟和队列深度作为辅助触发条件。
4.4 适用边界
| 场景 | 弹性扩容是否适用 | 替代方案 |
|---|---|---|
| 在线推理服务 | 适用 | — |
| 模型训练任务 | 不适用 | 作业调度器（Volcano） |
| 批量推理任务 | 不适用 | 队列式调度 |
| 低延迟对话服务 | 需配合预热 | 预留冗余 + 预测性扩容 |
五、总结
大模型服务的弹性扩容需要从指标感知、扩容决策到 Pod 就绪的全链路优化。落地路线建议如下：
第一，指标先行。在实施 HPA 之前，先部署 DCGM Exporter 和 vLLM Metrics，确保 GPU 指标和推理延迟指标可观测。没有可靠的指标，自动扩容就是盲人摸象。
第二，多指标组合决策。单一指标无法覆盖所有异常场景。GPU 显存是核心指标，推理延迟是兜底指标，队列深度是前瞻指标。三者组合才能做出准确的扩容决策。
第三，预热是必选项。大模型服务的冷启动延迟远超传统应用，必须通过 postStart 钩子执行预热推理。否则新 Pod 加入服务后，首批请求的延迟会极高。
第四，缩容必须保守。GPU 资源昂贵，但频繁缩容导致的请求中断和冷启动代价更高。缩容稳定窗口至少 5 分钟，缩容速率限制为每次 1 个 Pod。
