K8s HPA 弹性伸缩基于自定义 PromQL 指标驱动推理副本扩缩在 KubernetesK8s集群中管理常规 Web 微服务的弹性伸缩通常非常简单配置一个基于 CPU 利用率或内存使用率如CPU 80%的HPAHorizontal Pod Autoscaler水平 Pod 自动扩缩器即可平稳运行。然而当我们要对托管私有化大模型如 vLLM、Triton、Ollama或重型 Agent 服务的 Pod 进行自动伸缩时默认的 CPU/内存指标会彻底失效GPU 推理服务的“假饱和”现象当模型加载进显存后无论是否有请求正在处理GPU 显存占用始终维持在 95% 以上被模型权重和 KV Cache 预分配占满而 GPU 核心算力GPU Utilization在处理 Prefill 阶段会瞬间拉满但在等待网络 IO 时又会突然跌到 0%。基于这种剧烈波动的指标做 HPA会导致 Pod 疯狂地扩容、缩容、再扩容引发集群剧烈颠簸Thrashing推理冷启动时间过长一个 14B 参数的模型从拉取镜像、分配 GPU 到加载权重进显存冷启动耗时通常需要 30 到 90 秒。如果等到 CPU 达到 80% 才开始扩容新 Pod 还没准备好现有的旧 Pod 早已被排队请求彻底压垮。如何通过Prometheus Adapter 自定义业务指标如当前请求排队队列深度、并发请求数、KV Cache 使用率构建灵敏、平滑的 AI 推理 HPA 架构一、AI 推理服务三大核心扩缩容黄金指标┌────────────────────────────────────────────────────────┐ │ 指标 1: 推理排队请求数 (vllm:num_requests_waiting) │ │ 意义最灵敏的扩容前瞻信号只要等待队列 5立即触发扩容│ ├────────────────────────────────────────────────────────┤ │ 指标 2: 活跃并发请求数 (vllm:num_requests_running) │ │ 意义反映当前每张 GPU 正在处理的负载饱和度 │ ├────────────────────────────────────────────────────────┤ │ 指标 3: KV Cache 显存占用率 (vllm:gpu_cache_usage_perc)│ │ 意义当 KV Cache 85% 时说明即将发生请求降级或截断 │ └────────────────────────────────────────────────────────┘二、基于 Prometheus Adapter 导出自定义 K8s 外部指标1. 配置 Prometheus Adapter ConfigMap将 Prometheus 中的 vLLM 业务指标转换为 K8s Custom Metrics APIapiVersion: v1 kind: ConfigMap metadata: name: adapter-config namespace: custom-metrics data: config.yaml: | rules: - seriesQuery: vllm:num_requests_waiting{namespace!,pod!} resources: overrides: namespace: {resource: namespace} pod: {resource: pod} name: matches: vllm:num_requests_waiting as: vllm_waiting_requests_per_pod metricsQuery: sum(.Series{.LabelMatchers}) by (.GroupBy)三、生产级 HPA YAML 声明实操在业务 Namespace 中创建 HPA 资源配置基于自定义指标的伸缩规则并加入防抖动冷却窗口Behavior Stabilization WindowapiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: vllm-inference-hpa namespace: ai-workload spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: vllm-qwen-14b minReplicas: 2 # 保底 2 副本支撑常态流量 maxReplicas: 8 # 最大允许扩容到 8 副本 (受 GPU 物理总卡数限制) metrics: # 核心指标当每个 Pod 平均等待排队请求数超过 4 个时触发扩容 - type: Pods pods: metric: name: vllm_waiting_requests_per_pod target: type: AverageValue averageValue: 4 # 行为控制快速扩容平稳慢速缩容关键 behavior: scaleUp: stabilizationWindowSeconds: 0 # 扩容无需等待0 秒瞬间响应突发流量 policies: - type: Percent value: 100 # 允许瞬间翻倍扩容 periodSeconds: 15 scaleDown: stabilizationWindowSeconds: 300 # 缩容必须经历 5 分钟的稳定观察期防止缩容后再次突发引发冷启动 policies: - type: Pods value: 1 # 每次最多只缩容 1 个 Pod periodSeconds: 60四、生产避坑与最佳实践预拉取镜像与节点预热Image Pre-pulling大模型镜像体量通常在 10GB~20GB 之间。必须在所有 GPU 物理节点上通过 DaemonSet 预先拉取镜像或使用远程分布式镜像加速方案将冷启动耗时从 3 分钟压缩至 20 秒以内。GPU 节点弹性联动K8s Cluster Autoscaler当 HPA 决定将 Pod 从 2 扩容到 4 时如果集群里没有空闲的 GPU 物理机Pod 会进入Pending状态。必须将 HPA 与云厂商的 Cluster Autoscaler 打通实现“HPA 扩 Pod - 触发云平台分钟级弹出 GPU 物理云主机”。告别粗放的 CPU 监控下沉到模型推理引擎底层的排队与显存指标才能构建出既能秒级抗住突发流量、又能在夜间平稳缩容省钱的企业级 AI 弹性算力平台。
