大模型推理容量规划：资源预留与扩缩容
容量基线可按峰值并发除以单副本承载量并向上取整；结合峰值请求率、请求时长、vLLM 缓存压力与 Kubernetes 就绪状态，安排云端预留和自动扩缩容。
大模型部署的容量规划，应先把峰值请求率与请求时长换算为并发量，再用经校准的单副本承载量估算基础副本。资源预留守住可预期的底座，扩缩容再根据就绪状态、KV cache 压力和云端容量变化调整；只按 GPU 型号采购，无法回答高峰时能承载多少请求。
大模型部署的容量基线：从峰值流量到副本数
先准备峰值请求率、平均或高分位请求时长、单副本承载量和预留余量，把它们写成可复核的规划变量。以下公式不是产品配置项，而是容量估算方法：
峰值并发估算 = YOUR_PEAK_REQUESTS_PER_SECOND × YOUR_AVERAGE_REQUEST_SECONDS
基础副本 = 向上取整(峰值并发估算 ÷ YOUR_VALIDATED_CONCURRENCY_PER_REPLICA)
预留副本 = YOUR_RESERVED_HEADROOM_COUNT
平均请求时长只能形成初始基线；输入输出长度、上下文长度或批处理方式改变后，应重新校准单副本承载量，不能长期套用同一个并发数字。
在 vLLM 中，KV cache 空间耗尽时可能发生请求抢占，空间恢复后再计算；vLLM 的优化文档给出的处理顺序是先提高 gpu_memory_utilization，再降低 max_num_seqs 或 max_num_batched_tokens。如果更看重启动速度，文档中的 --enforce-eager 可获得最快启动，但会牺牲稳态 decode 性能，因此它不是扩容吞吐的承诺。
在 Kubernetes 中，GPU 会作为 nvidia.com/gpu 这样的可调度资源出现；按 Kubernetes 的 GPU 调度说明，GPU 只写在 limits 中时，Kubernetes 默认用它作为 requests，若两处都写则必须相等，且不能只有 request 没有 limit。
resources:
limits:
nvidia.com/gpu: YOUR_VALUE
YOUR_VALUE 应由你的单 Pod 资源设计填写，不是官方默认值。
资源预留：把容量底线和计费承诺分开
自有机器没有云端容量预留问题，重点是给模型权重、KV cache 和运行时组件留出余量。租用 GPU 时，可以根据供应商文档判断预留范围；以下以 AWS EC2 的文档语义说明边界，不替代供应商当前报价。
根据 EC2 On-Demand Capacity Reservations 文档，Capacity Reservation 可在指定 Availability Zone 预留计算容量，期限不限，并可随时取消以停止该预留产生的费用。Capacity Reservation 的计费与定价页说明，即使没有实例使用预留容量，也会按相应的 On-Demand 费率计费；计费粒度为秒，最低为 60 秒，Savings Plans 和 Regional Reserved Instance 的折扣也适用于 Capacity Reservation。
核算预算时，逐项读取报价中的预留范围、计费时长、费率、折扣、存储和其他费用，并保持所有单价与时长单位一致：
预留预算 = YOUR_QUOTED_RESERVATION_RATE × YOUR_ACTUALLY_BILLED_DURATION
按量预算 = Σ(每项资源实际用量 × YOUR_QUOTED_UNIT_RATE)
总预算 = 预留预算 + 按量预算 + 存储预算 + YOUR_OTHER_DOCUMENTED_CHARGES
先确认报价是否已经包含适用折扣，避免再次扣减。预留层承担常态底线，按量层承接超出基线的负载；取消预留前还应安排应用摘流，停止计费并不代表业务实例已经自动下线。
扩缩容：先让副本可用，再让它承接流量
按 Kubernetes 的探针文档，Readiness probe 决定 Pod 是否可以接收流量；失败时，Pod 会被标记为未就绪，并停止接收 matching Services 的流量，但不会被杀死。Liveness probe 则决定是否重启容器，例如检测到应用无法继续推进时。
扩缩容决策可以先写成内部计算规则：
扩容判断 = YOUR_PENDING_WORK > READY_REPLICAS × YOUR_VALIDATED_CONCURRENCY_PER_REPLICA
缩容判断 = READY_REPLICAS > RESERVED_BASELINE_REPLICAS
AND YOUR_TRAFFIC_WINDOW < YOUR_SCALE_IN_THRESHOLD
这些是规划公式，不是可直接粘贴的 HPA 字段。新副本通过 readiness 后再加入服务；缩容时先确认待退出 Pod 不再接收流量，并保留 YOUR_DRAIN_WINDOW，随后才减少副本，且不能越过预留基线。具体的 HPA 指标适配器、阈值和稳定窗口没有通用值，应按当前 Kubernetes 与监控系统文档配置。
验证与监控：先看到压力，再开放自动扩缩
Prometheus Getting Started使用 prometheus.yml 组织抓取任务，启动命令为：
./prometheus --config.file=prometheus.yml
入门示例把抓取目标放在 scrape_configs 下，并使用以下结构；其中 15s 是该示例采用的抓取间隔，不是必须照搬的扩缩容阈值：
global:
scrape_interval: 15s
scrape_configs:
- job_name: YOUR_VALUE
static_configs:
- targets: [ 'YOUR_TARGET' ]
启用自动扩缩前，应逐项确认：新 Pod 只有在 readiness 通过后才接收流量；扩容计算使用的是当前模型配置对应的单副本承载量；缩容不会突破预留基线；监控能显示待处理工作、就绪副本和 vLLM 抢占信号；预算公式能够与供应商报价逐项对应。还要区分调度资源名、业务压力指标和探针状态，避免把 nvidia.com/gpu 直接当成扩缩容指标，或用 Liveness probe 代替流量就绪判断。
上述步骤依据正文所链接的官方文档整理，未运行或测量；使用前请按当前版本核对。