企业官网建设流程全解析

K8s HPA 弹性伸缩：基于自定义 PromQL 指标驱动推理副本扩缩

在 Kubernetes（K8s）集群中，管理常规 Web 微服务的弹性伸缩通常非常简单：配置一个基于 CPU 利用率或内存使用率（如CPU > 80%）的HPA（Horizontal 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 API：

apiVersion: 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 Window）：

apiVersion: 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

四、生产避坑与最佳实践

1. 预拉取镜像与节点预热（Image Pre-pulling）：
   大模型镜像体量通常在 10GB~20GB 之间。必须在所有 GPU 物理节点上通过 DaemonSet 预先拉取镜像，或使用远程分布式镜像加速方案，将冷启动耗时从 3 分钟压缩至 20 秒以内。
2. GPU 节点弹性联动（K8s Cluster Autoscaler）：
   当 HPA 决定将 Pod 从 2 扩容到 4 时，如果集群里没有空闲的 GPU 物理机，Pod 会进入Pending状态。必须将 HPA 与云厂商的 Cluster Autoscaler 打通，实现“HPA 扩 Pod -> 触发云平台分钟级弹出 GPU 物理云主机”。

告别粗放的 CPU 监控，下沉到模型推理引擎底层的排队与显存指标，才能构建出既能秒级抗住突发流量、又能在夜间平稳缩容省钱的企业级 AI 弹性算力平台。