vLLM 多副本部署时，每个副本都要独立完成模型权重的读取、切分与装载。如果存储端带宽或 CPU 处理能力跟不上，几百 GB 的权重文件会让 Pod 启动时间变成数十分钟。`--max-parallel-loading-workers` 是 vLLM 启动期的一个调优参数，用来控制并行加载权重的工作进程数量。它并不改变推理性能，只影响启动阶段的数据加载速度。
提升多副本启动效率的关键不是单纯调大 worker 数，而是先确认启动瓶颈是否真的在权重加载阶段。只有当存储读取能力、CPU 核数和模型分片方式都有余量时，增大该参数才能压缩启动时间。它属于启动参数，只在加载阶段生效，不会影响运行期吞吐或延迟。
先判断瓶颈在哪里
在调整参数前，需要确认启动慢是哪一段造成的。vLLM 启动大致分为：读取权重文件、切分并分发到各设备、初始化 CUDA 上下文和模型结构、预热阶段。`--max-parallel-loading-workers` 只影响前两步。如果日志显示大量时间花在“Loading weights”“Reading model snapshot”或“Mapping parameters”上，这个参数才值得调。如果卡在“Initializing torch distributed”或“CUDA context creation”，调该参数没有意义。
参数作用与边界
该参数会被 vLLM 内部用于决定并行加载权重文件的进程数。以常见启动命令为例：
python -m vllm.entrypoints.openai.api_server \
`--model` /data/models/llama-2-70b \
`--tensor-parallel-size` 8 \
`--max-parallel-loading-workers` 8这里 `--max-parallel-loading-workers 8` 表示用 8 个 worker 同时读取并处理权重分片。适用场景包括：单节点多卡并行加载大模型、同一时间多个副本同时冷启动、共享存储（NFS、GPFS 等）带宽未打满。风险边界也很明确：如果磁盘本身是机械盘或带宽很低，提高并行度只会让争抢更严重；如果 CPU 核数紧张，加载 worker 会挤占初始化阶段所需资源；如果 storage 吞吐已经饱和，多 worker 也不会提升速度。
如何选择初始值
没有通用最优值，但可以按以下顺序尝试：
- 先查看宿主机可用 CPU 核数。建议不超过 `总核数 / tensor_parallel_size`，因为每个 worker 需要 CPU 做反序列化和重计算。
- 从默认值开始，逐步增加：比如 1、2、4、8，记录每次启动耗时。
- 同时观察 `iostat` 或 `dstat` 中的磁盘读速率。如果读速率没有随 worker 数提升，说明瓶颈在存储 P95 延迟或文件系统元数据，而不是并发度。
验证方式：在启动命令前加 `time`，然后比较权重加载日志中的时间戳。vLLM 启动日志通常会打印每个阶段的耗时，这个信息比整体 `time` 更准确。
多副本场景下的额外注意点
多副本同时冷启动时，所有副本都会读取同一个模型目录。如果共享存储在文件系统锁或元数据操作上有限制，调大每个副本的 worker 数可能加剧锁竞争。此时可以先尝试限制同一时间启动的副本数量，或者错峰启动，再确定 worker 数。另一种做法是把模型文件提前拷贝到本地 SSD，再加载，但这属于缓存策略，不要和本参数混为一谈。该参数只解决加载并行度，不负责数据本地化。
常见问题
为什么调大后启动反而更慢？
可能原因有：CPU 争抢导致反序列化变慢；存储随机读性能差，多线程反而增加寻道开销；或者 vLLM 内部其他初始化步骤与加载 worker 竞争资源。建议先降到默认值，再单独监控磁盘和 CPU 使用率。
这个参数和 tensor-parallel-size 有冲突吗？
两者没有直接冲突，但 `tensor-parallel-size` 决定模型切分后的分片数量，而 `max-parallel-loading-workers` 决定加载这些分片的进程数量。如果分片数小于 worker 数，多余的 worker 可能空转；反过来，worker 数不足时，分片会排队。通常可以先按分片数设置为相同值，再微调。