Modal GPU 选型与资源配置指南

在 Modal 上选 GPU，先按模型权重、上下文和批处理所需显存判断单卡是否够用，再决定 GPU 数量；不要用卡名代替容量核对。做算力租赁配置时，还要同时限定 gpu、vLLM 并发键、容器扩缩边界和保活时间，并按 Modal 的按秒计费说明核算，不能只看卡名。

Modal GPU 选型先看什么

提交前先写下模型权重占用、目标上下文、最大批处理、预期输入并发和可接受的等待时间，再进入卡型选择。

Modal 的 GPU 加速指南记录的 gpu 值包括 T4、L4、A10、L40S、A100、A100-40GB、A100-80GB、RTX-PRO-6000、H100/H100!、H200、B200/B200+ 和 B300；对推理，官方建议先从配备 48 GB GPU RAM 的 L40S 开始。把权重、上下文、KV cache 和批处理开销放进同一张容量表；这个建议是通用起点，不是特定模型的结果承诺。

把 GPU 型号和数量写进 Function

多卡数量通过在 gpu 值后追加 :n 表示，回退列表则表达偏好的优先顺序：

@app.function(gpu="H100:8")

@app.function(gpu=["H100", "A100-40GB:2"])

Modal 的 GPU 加速指南还规定：多数型号每个容器最多支持 8 张 GPU，A10 最多支持 4 张；请求超过 2 张通常会增加等待时间，同一容器的 GPU 始终位于同一台物理机上。H100 可能自动升级为 H200 且不改变该 GPU 费用，H100! 可退出升级；A100 请求 40 GB 版本，也可能升级到 80 GB 而不改变费用，A100-80GB 用于显式请求该版本；B200+ 可运行 B200 或 B300，但始终按 B200 计费；B300 要求 CUDA 13.1 或更高版本，并应先确认容器镜像和库与 CUDA 13 兼容。上述代码只展示语法，不能直接当作资源建议。

用扩缩边界控制容器数量

按 Modal 的扩缩说明，每个 Function 都有独立的自动扩缩容器池，没有待处理输入时默认缩到零；max_containers 是容器数上限，min_containers 是非活动期仍保持温热的最低容器数，buffer_containers 是活动期维护的额外缓冲，scaledown_window 是容器缩下前允许的最大空闲秒数。已部署的 Function 可以不重新部署就更新扩缩配置，但下次部署会恢复装饰器中的设置：

f.update_autoscaler(min_containers=2, max_containers=10)

这里的 2 和 10 是官方语法示例，不是适合你的工作负载的默认值。

vLLM 并发参数怎么配

按照 Modal 的输入并发说明，每个容器默认一次处理一个输入，可用 @modal.concurrent 和 max_inputs 开启并发；需求超过 max_inputs 时，Modal 会增加容器，新增输入可能在容器冷启动期间排队。target_inputs 应根据期望延迟设置，max_inputs 则要根据 GPU 显存等资源约束设置，以避免 GPU OOM：

@modal.concurrent(max_inputs=100)

100 只是文档示例，不能直接视为显存安全值。同步 Function 的并发输入会分别在线程中执行，因此实现必须线程安全；异步 Function 使用单线程上的 asyncio 任务。输入并发适合 GPU 容器上的 continuous batching，例如 vLLM。同一份输入并发说明给出了这两类执行方式。

vLLM 显存项怎么核对

vLLM 的内存配置文档说明，tensor_parallel_size 可以把模型拆到多张 GPU，但启用后每个进程都会读取完整 checkpoint，磁盘读取时间会随 tensor parallel size 增长。设备选择应使用 CUDA_VISIBLE_DEVICES，而不是在 vLLM 启动前通过 torch 的 device 函数选择设备。

限制上下文长度和最大批处理也能减少内存占用；对应配置键是 max_model_len 和 max_num_seqs。该文档将前者定义为模型上下文长度，后者定义为最大批处理大小。提交前应把以下键逐项列入验收表：

tensor_parallel_size
max_model_len
max_num_seqs
CUDA_VISIBLE_DEVICES

算力租赁成本怎样核对

截至 2026-10-01 核对的 Modal 定价页按秒计量 CPU、内存和 GPU 时间；CPU 和内存按请求量与实际使用量中的较高者计费。应用加载、输入处理以及最后一次输入后的默认 60 秒保活时间都计入费用，应用缩到零个容器后才停止收费。

Modal 的账单说明规定 Workspace 按月结算并在周期结束时自动扣款；首次超过特定阈值时，还可能在周期中产生增量费用。使用 GPU 不要求预留，也没有最低使用时长增量，但必须登记有效付款方式。结账时还应核对抵扣、增量费用和适用的订阅费。

从自己的报价或账单填入以下公式，不要沿用他人的配置值：

GPU费用估算 = GPU单价_YOUR_VALUE × GPU计费秒数_YOUR_VALUE
CPU费用估算 = CPU单价_YOUR_VALUE × max(CPU请求_YOUR_VALUE, CPU实际使用_YOUR_VALUE)
内存费用估算 = 内存单价_YOUR_VALUE × max(内存请求_YOUR_VALUE, 内存实际使用_YOUR_VALUE)
周期账单估算 = GPU费用估算 + CPU费用估算 + 内存费用估算 + 页面列示增量费用_YOUR_VALUE + 适用订阅费_YOUR_VALUE - 页面列示抵扣_YOUR_VALUE

怎么验证配置生效

按照 Modal 的扩缩说明，Function.map() 可以并行处理多个输入，返回结果顺序与输入顺序一致。对已经部署的 Function 传入一组带可识别编号的输入，再逐项检查返回 iterable，即可核对调用是否完成以及顺序是否正确。

这只能验证函数调用和结果顺序，不能代替实际卡型、CUDA 兼容性、显存峰值或吞吐验收。若这些项目属于验收条件，应先从当前 Modal GPU 文档和项目文档中确认对应的检查入口与判定方法。

提交前的排错清单

按前文规则，提交前逐项回答：

• 容量表是否同时包含模型权重、上下文、批处理和 tensor parallel size？
• 卡型配置是否写清了请求数量、回退顺序以及是否允许自动替换？
• 并发上限是否由显存约束推导，同步 Function 的共享状态是否检查过线程安全？
• 成本表是否分别记录加载、处理、保活和缩到零的边界？

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

资料来源

• Modal：GPU acceleration
• Modal：Scaling out
• Modal：Input concurrency
• Modal：Pricing
• Modal：Billing
• vLLM docs：Conserving Memory