vLLM与云端推理平台选型指南

从模型显存、并行方式和启动参数，到 Replicate、Modal 的队列与计费口径，给出自建 vLLM 或选择云端推理平台时可逐项核对的检查方法，并说明每项配置如何影响资源与费用。

如果你在问“vllm 怎么部署”，先看模型能否装入目标 GPU、请求是否持续、团队能否维护多卡环境：长期稳定流量可评估自建，间歇流量可评估按需云端。云端不是一种计费模式；先确定模型类型、上下文长度、并发方式和等待容忍度，再比较平台。硬件型号应放在这些条件之后。

“vllm”怎么部署：先算资源

先记录模型权重需求、输入与输出合计长度、单次迭代的序列数和 token 上限。max_model_len 覆盖 prompt 与 output，未设置时从模型配置推导；max_num_seqs 限制一次迭代处理的序列，max_num_batched_tokens 限制一次处理的 token，见 vllm serve 参数参考。若使用 N 张 GPU，文档要求至少 2 + N 个物理 CPU 核心，见 vLLM 的优化与调优文档。

vLLM 的显存管理说明给出了直接杠杆：降低 max_model_len 或 max_num_seqs 可减少内存；CUDA graphs 默认启用并额外占用 GPU 内存；多模态 processor cache 默认 4 GiB，可用 mm_processor_cache_gb 调整。设备选择应设置 CUDA_VISIBLE_DEVICES，而不是在启动前调用 torch 的 device 函数。启用 tensor parallelism 时，每个进程都会读取完整 checkpoint，磁盘读取时间会随 TP 大小增加。

多卡还要区分切分方式：tensor parallelism 在每层内切分参数，pipeline parallelism 把不同层放到不同 GPU 并依次处理。若节点没有 NVLINK，例如 L40S，vLLM 的并行与扩展示例建议考虑 pipeline parallelism，以降低通信开销。

自建参数如何落地

模型标识、权重获取方式和安装命令取决于具体模型与当前项目文档，不能套用通用值。下面只是追加到完整 vllm serve 命令中的参数片段，并非可独立运行的命令：

# 选择可见设备
CUDA_VISIBLE_DEVICES=YOUR_VALUE

# 按业务约束填写需要的参数
--gpu-memory-utilization YOUR_VALUE
--max-model-len YOUR_VALUE
--max-num-seqs YOUR_VALUE
--max-num-batched-tokens YOUR_VALUE
--tensor-parallel-size YOUR_VALUE
--pipeline-parallel-size YOUR_VALUE
--cpu-offload-gb YOUR_VALUE
--enforce-eager

--gpu-memory-utilization 取值范围为 0 到 1，文档默认值为 0.92，而且是单个 vLLM 实例的限制；TP、PP 默认值都是 1，--cpu-offload-gb 默认 0，表示不卸载。--enforce-eager 会关闭 CUDA graphs 和 torch.compile；文档说明它可获得最快启动，但会牺牲稳定阶段的 decode 性能。内存、启动速度与吞吐冲突时，应记录取舍，而不是固定照抄默认值。

云端平台：Replicate 先看模型类型

按 Replicate 的计费说明，public models 只对处理请求的 active 时间收费，setup 和 idle 免费；默认与其他客户共享硬件池和队列。多数 private models 使用专用硬件且无需共享队列，但 online 时间包含 setup、idle 和 active，都会计费；deployments 采用同样口径。fast-booting fine-tunes 是例外，无论 public 或 private，都只按 active 时间计费。无需求时，模型会缩到配置的最小实例数，默认 0；请求出现空档后，实例先 idle 几分钟，而不是立即关闭。

选型前，在模型页的 Run time and cost 查看硬件，再按报价的计费单位填写：

active_only_cost = YOUR_ACTIVE_DURATION × YOUR_ACTIVE_RATE
online_time_cost = YOUR_SETUP_COST + YOUR_IDLE_COST + YOUR_ACTIVE_COST
chained_model_cost = YOUR_ROOT_COST + YOUR_DOWNSTREAM_COST

若模型还调用其他模型，根模型和下游模型都要计入。取消与失败也要单列：按时间计费的模型取消后计到取消时，official model 取消仍可能收费；private models 和 deployments 的失败或取消则按实例实际 active 时间计。不要套用单一的“失败一律免费”假设。

云端平台：Modal 先看 GPU 分配

Modal 的 GPU 加速文档说明，GPU 通过 Function 装饰器的 gpu 参数指定；多 GPU 可写为：

gpu="H100:8"

文档列出的类型包括 T4、L4、A10、L40S、A100、A100-40GB、A100-80GB、RTX-PRO-6000、H100/H100!、H200、B200/B200+ 和 B300。多数类型每个容器最多使用 8 张 GPU，A10 最多使用 4 张；请求超过 2 张通常等待更久，且同一容器的 GPU 都位于一台物理机器。传入有序列表时，Modal 会先尝试靠前的类型，再向后回退；使用 GPU 还要求账户留有有效付款方式。

还要核对自动升级规则：gpu="H100" 可能升级为 H200 且不增加 GPU 成本，gpu="H100!" 可退出升级；gpu="A100" 可能升级为 80 GB A100 且成本不变；gpu="B200+" 可使用 B200 或 B300，但按 B200 计费。B300 要求 CUDA 13.1 或更高版本，容器 Image 和依赖必须兼容。

这些规则不能代替报价核算。将当前报价中的计费数量、单价和其余项目分别填入：

estimated_modal_cost = YOUR_BILLED_QUANTITY × YOUR_UNIT_PRICE + YOUR_OTHER_LINE_ITEMS

验证与常见出错点

启动日志中的 GPU KV cache size 表示 GPU KV cache 同时可容纳的总 token 数。将它与 max_model_len、max_num_seqs 和业务并发一起核对；若频繁发生 preemption，文档建议提高 gpu_memory_utilization，或降低 max_num_seqs、max_num_batched_tokens。V1 的默认抢占模式是 RECOMPUTE，待 KV cache 空间恢复后再重算请求。

不同延迟目标也有不同取舍：较小的 max_num_batched_tokens，例如 2048，可改善 inter-token latency；较大的值可改善 TTFT；针对小模型和大 GPU，文档建议为 throughput 设置 > 8192。最后按当前版本的 serving 文档发送最小请求，并核对云端面板中的实际 GPU、排队状态与账单类别，避免把默认值、自动升级或计费口径误当成固定条件。

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