AI Deploy大模型本地部署帮你部署

本地大模型流量预测与扩缩容实操

说明如何从 vLLM `/metrics` 的请求、等待、KV 缓存与延迟指标建立容量基线，再配置 Kubernetes HPA，并用 startup probe、readiness probe 验证扩缩容后的流量切换。

本地部署大模型后，先按 vLLM 的生产指标说明建立请求运行数、等待数、KV cache、排队时间和延迟的历史容量基线，再据此填写 Kubernetes HPA 的扩缩容条件，并验证新 Pod 是否具备接收流量的条件。本文所谓“预测”，落实为可审计的基线、阈值和稳定窗口记录，而不是声称能算出未来请求量；具体值必须从你的请求分布与可接受时延中填写。

先准备：固定指标入口与采集口径

vLLM 的指标使用说明明确，指标暴露在 OpenAI compatible API server 的 /metrics。先确认采集端能够访问该地址，主机与端口按实际部署填写，不在示例中虚构监听地址。

Prometheus 入门配置使用 scrape_configs 组织 job_name 与 static_configs.targets，入门配置通过 global.scrape_interval: 15s 抓取，job 可以覆盖间隔：

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: YOUR_VALUE
    static_configs:
      - targets:
          - YOUR_VALUE

这里的 YOUR_VALUE 应替换为能够访问 vLLM /metrics 的实际 target。同一份配置给出的启动形式如下；数据库默认位于 ./data，对应 --storage.tsdb.path：

./prometheus --config.file=prometheus.yml

开始采集前，应固定模型标识、服务配置、请求输入与输出长度分布以及业务时段，并记录基线窗口、可接受 TTFT、端到端时延和 KV cache 边界。这些值没有统一默认值。

流量基线：本地部署大模型后按用途分组

按 vLLM 的生产指标说明，可以把字段整理为：

  • vllm:num_requests_running 和 vllm:num_requests_waiting 是 gauge，分别反映模型执行批次中的请求数和等待处理的请求数；vllm:kv_cache_usage_perc 也是 gauge，值 1 表示 100% 使用率。
  • vllm:time_to_first_token_seconds、vllm:e2e_request_latency_seconds 和 vllm:request_queue_time_seconds 是 histogram，分别对应首 token 时间、端到端请求时延和 WAITING 阶段排队时间。
  • vllm:prompt_tokens、vllm:generation_tokens、vllm:num_preemptions、vllm:prefix_cache_hits 与 vllm:request_success 是累计活动的 counter，不应与 gauge 直接混作同一类容量值。

预测时，可把相同业务时段的历史指标排列成容量区间。当前请求运行数、等待数、KV cache 或时延明显偏离该区间时，先标记容量风险，再检查请求长度分布和 GPU 状态；不要为了消除告警直接放宽边界。

从 classic histogram 汇总分位数时，Prometheus 查询函数文档要求在聚合中保留 le，并给出了 P90 查询示例：

histogram_quantile(0.9, sum by (job, le) (rate(http_request_duration_seconds_bucket[10m])))

示例中的 HTTP 指标不是 vLLM 指标，不能直接照搬名称；它用于说明分位数查询的聚合结构。vLLM 基线应从上面列出的 histogram 中选择指标，再由你填写观察窗口。

把基线转成 HPA 扩缩容条件

Kubernetes HPA 文档说明，HPA 可从 metrics.k8s.io、custom.metrics.k8s.io 或 external.metrics.k8s.io 读取指标；自定义指标需要指标方案供应商提供的 adapter API server。控制循环默认每 15s 运行一次，由 --horizontal-pod-autoscaler-sync-period 设置；当前指标与目标指标之比处于容差内时不会扩缩容，容差默认为 0.1。若设置 minReplicas: 0，还必须配置 object 或 external metric，否则 API server 会拒绝该对象。

vLLM 指标如何转换为具体的 HPA 指标配置，取决于所用 adapter 的当前文档。先填写下面的决策表，而不是把它误当成可直接提交的 HPA YAML：

指标来源 = YOUR_VALUE
观察窗口 = YOUR_VALUE
扩容阈值 = YOUR_VALUE
缩容阈值 = YOUR_VALUE
稳定时长 = YOUR_VALUE
副本下限 = YOUR_VALUE
副本上限 = YOUR_VALUE

/metrics 能被采集，不代表 HPA 一定能消费该指标。遇到自定义指标缺失时，应先核对指标 API 和 adapter，而不是反复调整阈值。

用探针验证流量切换并排查故障

Kubernetes 探针文档说明，startup probe 适合启动较慢的容器；readiness probe 决定容器能否接收流量，也适合等待文件加载和缓存预热。readiness 失败后，Pod 会停止接收 matching Services 的流量，但容器不会被杀死；liveness probe 则用于在死锁等无法继续推进时重启容器。

在预发布环境中，应按你的现有请求方式验证：

  • 确认 /metrics 字段持续更新，再改变请求流量，并与历史基线及阈值记录逐项对照。
  • 检查 HPA 使用的指标来源、adapter、观察窗口和副本变化，避免把采集间隔误认为扩缩容延迟。
  • 检查新 Pod 的 readiness 结果及 matching Services 的流量切换；readiness 未通过时，Pod 数量增加不代表它能够服务请求。

常见故障也有固定排查顺序：分位数结果为空时，先检查聚合是否保留 le；HPA 没有动作时，先检查指标 API、adapter 和容差；Pod 已创建却没有流量时，先看 readiness，而不是用 liveness 判断是否可以接流量。升级后指标名称发生变化时，还应核对 vLLM 当前文档；官方说明指出，弃用指标会在下一 minor version 被隐藏，并在再下一个版本移除。

本文步骤依据正文所链接的官方文档整理，未运行或测量；使用前请按当前版本复核。

资料来源