推理服务弹性伸缩与冷启动优化：从 HPA 到缩容到零

三个直接后果：
① CPU 不是瓶颈 → 用 CPU 做 HPA 指标失灵
② 扩容慢 → 峰值来临时「扩不动」，必须提前/预热
③ 实例贵 → 缩容要谨慎，缩多了扛不住下一个峰值

队列深度作为伸缩信号的优势：
□ 领先性：请求在队列里等待时，还没开始消耗算力
  → 队列一涨就扩，能在延迟恶化前响应
□ 线性性：队列长度 ∝ 超出容量，扩 N 个副本能明确消化
□ 稳定性：比 GPU 利用率平滑，不易引发振荡

KV cache 占用率：
□ 直接反映「显存还能接多少并发」
□ 逼近 100% 时，新请求会被迫排队或抢占
□ 是「还能不能接更多」的最准确信号

# 推理引擎暴露的 Prometheus 指标（示例）
# vLLM: vllm:num_requests_waiting  → 队列深度
#       vllm:gpu_cache_usage_perc   → KV cache 占用
#       vllm:num_requests_running   → 在飞请求

def scale_signal(waiting, cache_usage, running):
    # 双阈值：队列积压 或 KV 逼近上限 → 扩容
    if waiting > 8 or cache_usage > 0.9:
        return "scale_up"
    if waiting == 0 and cache_usage < 0.4 and running < 2:
        return "scale_down"
    return "hold"

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: llm-inference-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: llm-inference
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Pods
      pods:
        metric:
          name: vllm_num_requests_waiting   # 队列深度（Prometheus Adapter）
        target:
          type: AverageValue
          averageValue: "8"                 # 每副本平均队列 ≤ 8
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0         # 扩容要快
      policies:
        - type: Percent
          value: 100                        # 一次最多翻倍
          periodSeconds: 30
    scaleDown:
      stabilizationWindowSeconds: 300       # 缩容要稳（5 分钟观察窗）
      policies:
        - type: Pods
          value: 1                          # 一次最多缩 1 个
          periodSeconds: 60

HPA 配置要点：
□ scaleUp 快：stabilizationWindow=0，允许翻倍
□ scaleDown 慢：观察窗 300s + 每次缩 1 个 → 防抖动
□ 指标用 AverageValue（每副本平均），非总量
□ 需要 prometheus-adapter 把队列指标暴露给 HPA

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: llm-inference-scaledobject
spec:
  scaleTargetRef:
    name: llm-inference
  minReplicaCount: 0            # 允许缩到零
  maxReplicaCount: 20
  cooldownPeriod: 300           # 缩容冷却
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus:9090
        query: |
          avg(vllm:num_requests_waiting{app="llm-inference"})
        threshold: "8"
    - type: prometheus
      metadata:
        serverAddress: http://prometheus:9090
        query: |
          avg(vllm:gpu_cache_usage_perc{app="llm-inference"})
        threshold: "0.85"

HPA vs KEDA：
□ HPA：K8s 原生，指标来自 metrics-server/自定义指标
□ KEDA：支持任意事件源（Prometheus/Kafka/Redis/HTTP），支持缩到零
□ 推理场景推荐 KEDA（队列/KV 指标来自 Prometheus，天然契合）

冷启动耗时分解（典型 7B 模型）：
□ 调度 + 容器拉起          5-15s
□ 镜像拉取（已缓存则跳过）  0-60s
□ 模型权重加载（本地）      10-60s
□ 引擎初始化（编译/CUDA Graph 捕获）  5-30s
□ 首次推理预热              1-5s
────────────────────────────────
合计：约 30s ~ 3 分钟

# 权重本地缓存：用 hostPath / local PV 挂载模型目录
# 节点上预置模型，Pod 直接挂载，避免每次下载

# 镜像层缓存：模型作为独立层，与其他依赖分层
# → 代码更新时模型层命中缓存，不重复拉取

# 就绪探针必须等「真正能服务」，而非「进程起来了」
readinessProbe:
  httpGet:
    path: /health/ready      # 引擎加载完成 + 预热跑过一次
    port: 8000
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 60       # 允许最多 5 分钟才就绪

关键：readiness 不能只探「端口通」——
□ 必须确认：模型加载完成 + 引擎初始化完成 + 预热请求跑过
□ 否则流量会在「进程起来但引擎没就绪」时打到实例上 → 全失败
□ 预热请求应覆盖「典型输入形状」，触发 CUDA Graph 捕获等一次性开销

缩容的风险：
□ 缩太快 → 下一个峰值来了，扩容又来不及（冷启动几分钟）
□ 抖动 → 缩了又扩，反复加载模型（浪费 + 不稳定）
□ 缩掉正忙的实例 → 在飞请求被中断

缩容纪律：
□ 长冷却期（cooldown ≥ 模型冷启动时间的数倍）
□ 每次只缩 1 个
□ 优雅终止：先摘流量，等请求排空，再停实例
□ 保留最小副本数（除非确定可缩到零）

缩到零的前提：
□ 能接受「首个请求等待冷启动」（秒~分钟级）
□ 有预热池或快速冷启动方案
□ 有请求排队机制（缩零期间请求先入队）

缩到零的方案：
□ KEDA minReplicaCount: 0 + 队列触发
□ 请求入队 → 触发扩容 → 实例就绪 → 消费队列
□ 配合「预热池」：保留 0 副本的常驻引擎快照，快速实例化

与 Serverless 的衔接：
□ 缩到零本质是「冷启动换成本」
□ 详见 Serverless 推理的实例池与预热分级

缩到零 vs 保留最小副本：
□ 缩到零：省成本，但首请求慢（适合低频、可容忍延迟）
□ 保留 1-2 副本：常驻成本，但无冷启动（适合在线、延迟敏感）
□ 折中：低谷保留 1 副本，深夜缩到零

多级伸缩架构：
Level 1  副本级（HPA/KEDA）
  → 增减同一模型的副本数
Level 2  节点级（Cluster Autoscaler）
  → 增减 GPU 节点（副本需要 GPU 时才触发）
Level 3  模型级（多模型共享池）
  → 按请求量加载/卸载模型到共享 GPU（见多 LoRA 服务）

预热池（Warm Pool）：
□ 常备 N 个「已加载模型但未接流量」的实例
□ 扩容时从池中直接接管（秒级），池空了才走冷启动
□ 池大小按「峰值扩容量」与「可接受冷启动比例」权衡

伸缩决策树：
请求量上升？
├─ 有 warm 实例 → 直接从池中接管（秒级）
├─ 无 warm，有 GPU 空闲 → 冷启动新实例（分钟级）
└─ 无 GPU → 触发节点扩容（更慢）→ 再冷启动

→ 预热池的作用：把「分钟级扩容」变成「秒级扩容」
→ 代价：常驻成本（池中实例空转）
→ 权衡：峰值可预测 → 池大一点；波动大 → 靠弹性