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

RunPod 无服务器推理并发与扩容

说明 RunPod Serverless 的端点与单 worker 并发关系，给出请求量扩容公式、vLLM 参数配置，以及冷启动和稳态的验证清单。

RunPod 无服务器推理的并发由端点 max workers 与每个 vLLM worker 的 MAX_CONCURRENCY 共同决定；扩容可按请求积压或队列等待阈值触发。两者的职责分别见 RunPod 的端点配置和 vLLM worker 环境变量。做这类大模型部署时，还要同时核对 vLLM 引擎限制、worker 生命周期和验证口径。

并发上限要拆开看

MAX_CONCURRENCY 默认是 30，限制每个 worker 在 RunPod 侧接受的并发请求数，但它不是 vLLM 引擎参数。vLLM 的 --max-num-seqs 才限制单次迭代处理的 sequence 数量，定义见 vLLM 的引擎调度参数。

因此，端点能运行多少 worker、RunPod 接纳多少请求、vLLM 每轮调度多少 sequence，需要分别验收。不能把 MAX_CONCURRENCY 直接当作模型在目标 GPU 上的可持续并发能力。

设置请求数或队列等待扩容

在 RunPod 的端点配置中，max workers 默认是 3，官方建议将其设为约比预期峰值并发高 20%。请求数扩容按以下公式计算目标 worker 数量：

Math.ceil((requestsInQueue + requestsInProgress) / scalerValue)

对于 LLM 或频繁的短请求，文档建议把 scalerValue 设为 1。队列等待扩容则在请求等待超过阈值时增加 worker，默认阈值是 4 秒。

账户级 worker 上限与端点配置不是同一概念：它取决于账户余额，限制 flex 与 active 的合计数量，默认从 5 个 worker 起算。active worker 保持就绪，即使空闲也持续计费；flex worker 可缩到零，不使用时不计费，但扩容时会产生冷启动。参见 RunPod Serverless worker 概览。

同一端点配置还规定：请求完成后的 idle timeout 默认是 5 秒，这段时间仍计费；execution timeout 默认是 600 秒，可设置为 5 秒至 7 天，超时会使作业失败并停止 worker；job ttl 默认是 24 小时，从提交时开始计时。端点连续 3 天没有请求后，max workers 会降为 2，7 天后降为 0。

配置 vLLM 与请求入口

模型通过 MODEL_NAME 设置，不要把 RunPod 侧的 MAX_CONCURRENCY 写进 vllm serve 参数。在线服务的引擎参数可按 vLLM CLI 参考组织为：

vllm serve YOUR_VALUE \
  --gpu-memory-utilization 0.92 \
  --max-model-len auto \
  --max-num-seqs YOUR_VALUE

第一个 YOUR_VALUE 替换为模型标识或路径，最后一个替换为单轮 sequence 上限。--gpu-memory-utilization 是每个 vLLM 实例的显存使用比例，文档默认值为 0.92；--max-model-len 覆盖 prompt 和 output，未设置时从模型配置推导，设为 auto 时选择显存能够容纳的最大长度。若设置 --kv-cache-memory-bytes，它会覆盖 gpu_memory_utilization。

向 endpoint 发送请求时使用 Bearer API key。常用操作路径如下：

https://api.runpod.ai/v2/ENDPOINT_ID/run
https://api.runpod.ai/v2/ENDPOINT_ID/runsync
https://api.runpod.ai/v2/ENDPOINT_ID/status
Authorization: Bearer YOUR_VALUE

根据 RunPod 的 API 请求说明，/run 异步处理任务，需要通过 /status 获取结果，完成后的结果保留 30 分钟；/runsync 等待任务完成，结果保留 1 分钟，最长 5 分钟。/run 的限制是每 10 秒接受 1000 个请求，并发上限为 200，超额请求会收到 HTTP 429。

验证扩容是否真正生效

验证时固定模型、MAX_CONCURRENCY、max workers、扩容触发方式、vLLM 参数以及输入输出长度，避免一次改变多个变量。

冷启动请求和已有 worker 的稳态请求应分开记录。逐步提高请求到达率，同时保存实际 worker 数、队列等待、HTTP 状态、TTFT、TPOT 和任务完成情况；再把实际 worker 数与请求数扩容公式对照。

如果结果要按 MLPerf Inference 规则提交，所有提交都必须使用 LoadGen；Server 场景按 Poisson 分布发送查询，指标是最大 Poisson 吞吐量，LLM 还记录首 token 延迟 TTFT 和输出 token 间隔 TPOT，详见 MLPerf Inference 规则。

常见出错点

  • 不要把 MAX_CONCURRENCY、--max-num-seqs 和实际承载能力合并成一个“并发数”。
  • 端点 max workers 即使高于账户级上限，也无法突破余额对应的 worker 限制。
  • 不要把 job ttl 当成执行时间；排队阶段也会消耗 TTL。
  • 回收检查要同时记录 idle timeout、flex 缩零和 active 空转计费。
  • 显存比例按 vLLM 实例核对；使用 --kv-cache-memory-bytes 时，不要继续假定显存比例仍决定 KV cache。

本文步骤根据正文所链接的官方文档整理，使用前请对照当前版本复核。

资料来源