📚 课程目录第4章多模型加载原理

4、多模型加载原理：多模型并发加载机制、显存管理、调度策略

4.1 多模型并发加载的核心机制

在 vLLM 中，多模型加载并非简单地将多个模型权重依次读入显存，而是由 ModelLoader 与 Worker 协同完成的一套并发流程。每个模型实例在加载时会被拆分为 权重加载、KV Cache 预留、图编译/预热 三个阶段。vLLM 默认使用 异步加载 方式：当模型 A 正在执行权重拷贝时，模型 B 的元数据解析和内存映射可以并行进行，从而缩短整体加载时间。

关键并发原语：

加载锁（Load Lock）：控制同一时刻只有 N 个模型可同时写入显存，避免带宽争抢。
内存屏障（Memory Barrier）：确保前一个模型的 KV Cache 分配完成后再启动下一个模型的图编译。
引用计数（Refcount）：每个模型实例持有独立的显存块引用，卸载时仅释放自身占用的块。

并发加载的典型时序如下：

时间轴 →
模型A: [元数据解析] → [权重拷贝] → [KV Cache预留] → [图编译/预热]
模型B:                [元数据解析] → [权重拷贝] → [KV Cache预留] → [图编译/预热]
模型C:                               [元数据解析] → [权重拷贝] → [KV Cache预留] → [图编译/预热]

这种流水线设计使得 3 个模型的加载总时间约等于“最慢模型加载时间 + 2 个解析时间”，而非三者之和。但若某个模型的权重文件位于机械硬盘或网络文件系统（NFS）上，其 I/O 等待会阻塞后续模型的权重拷贝阶段，形成 I/O 串行瓶颈。

4.2 显存管理：预分配、复用与碎片控制

vLLM 的显存管理以 PagedAttention 为核心，将 KV Cache 划分为固定大小的 块（Block），每个块默认 16 个 token 的 KV 数据。多模型场景下，显存管理遵循以下原则：

权重区与缓存区隔离：每个模型的权重独占一段连续显存，不可被其他模型抢占；KV Cache 则从公共池中按需分配。
块级复用：当模型 A 卸载后，其 KV Cache 块立即归还公共池，可被模型 B 复用，但权重区需等待显存整理（defragmentation）。
预分配上限：通过 --max-num-seqs 和 --gpu-memory-utilization 控制每个模型可占用的最大显存比例，防止单个模型耗尽全部显存。

显存区域	分配时机	释放条件	碎片风险
模型权重	模型加载时一次性分配	模型显式卸载（`del` 或 API 调用）	高（权重块大小不一）
KV Cache 块	推理过程中按需分配	请求结束立即归还	低（块大小固定）
激活值（Activation）	每次前向传播临时分配	前向传播结束自动释放	低
CUDA Context	首次加载模型时创建	进程退出时释放	中（每个模型约 300~800 MB）

常见误区：许多用户认为 gpu-memory-utilization=0.9 表示“每个模型最多使用 90% 显存”。实际上，该参数是 所有模型共享的全局上限。当加载第二个模型时，vLLM 会尝试在剩余显存中分配权重，若不足则抛出 CUDA out of memory，而非自动驱逐第一个模型。

4.3 调度策略：连续批处理与优先级

多模型加载完成后，vLLM 的调度器（Scheduler）负责决定 哪个模型的请求先被处理。其核心策略包括：

连续批处理（Continuous Batching）：每个模型的请求队列独立维护，调度器以“迭代级”粒度切换模型。例如，模型 A 的当前迭代完成后，若模型 B 有更高优先级的请求，则立即切换。
水位线调度（Watermark Scheduling）：当某个模型的 KV Cache 使用量超过预设水位线（如 80%）时，调度器暂停该模型的新请求，优先处理其他模型的请求，避免显存溢出。
优先级队列：支持为不同模型设置 priority 参数（0~10），数值越高，请求被选中的概率越大。默认所有模型优先级相同，按 FIFO 轮转。

# 启动两个模型并设置优先级示例
python -m vllm.entrypoints.openai.api_server \
  --model /models/llama2-7b \
  --port 8000 \
  --priority 5 \
  --gpu-memory-utilization 0.4

# 第二个模型（低优先级）
python -m vllm.entrypoints.openai.api_server \
  --model /models/qwen-7b \
  --port 8001 \
  --priority 2 \
  --gpu-memory-utilization 0.3

调度器还包含 抢占（Preemption） 机制：当高优先级模型的请求到达且显存不足时，调度器会终止低优先级模型的部分正在执行的请求，将其 KV Cache 块释放，待显存充足后再重新调度。这种策略保证了关键业务的低延迟，但可能导致低优先级模型的请求延迟显著增加。

4.4 案例：双模型加载失败与调度冲突

场景描述：某生产环境同时加载 Llama-2-13B（约 26 GB 权重）和 Mistral-7B（约 14 GB 权重），GPU 为 80 GB A100。启动时设置 --gpu-memory-utilization 0.9，但第二个模型加载时报 CUDA out of memory。

根因分析：

第一个模型加载后，实际占用显存 = 26 GB（权重）+ 8 GB（KV Cache 预分配）+ 1.2 GB（CUDA Context + 激活值）= 35.2 GB。
第二个模型尝试分配 14 GB 权重 + 6 GB KV Cache = 20 GB，但此时剩余显存仅 80 × 0.9 - 35.2 = 36.8 GB，看似足够。
实际失败原因：显存碎片化。第一个模型权重分配在显存低地址区域，而 CUDA Context 和激活值散落其间，导致连续空闲块不足 14 GB。

修复方案：

# 方案1：降低第一个模型的显存预留
--gpu-memory-utilization 0.6   # 第一个模型
--gpu-memory-utilization 0.3   # 第二个模型

# 方案2：启用显存整理（需 vLLM ≥ 0.4.2）
--enable-memory-defrag

# 方案3：先加载小模型，再加载大模型（改变分配顺序）

经验法则：多模型加载时，建议将 gpu-memory-utilization 总和控制在 0.85 以下，预留 15% 显存作为碎片缓冲和激活值波动空间。同时，优先加载权重较大的模型，因为大模型更容易因碎片化而分配失败。

4.5 误区与复盘：多模型加载的三大认知陷阱

误区一：显存足够就一定能加载成功。 如前例所示，即使总剩余显存大于模型权重，也可能因碎片化导致分配失败。vLLM 的显存分配要求 连续地址空间，而 CUDA 的默认分配策略并不保证连续性。

误区二：并发加载等于并行加载。 并发（Concurrency）是指多个加载任务在时间上重叠，但受限于 PCIe 带宽和显存带宽，实际权重拷贝阶段仍是串行的。若两个模型同时从同一块 NVMe 磁盘读取，I/O 竞争反而会降低整体加载速度。

误区三：调度优先级越高越好。 将多个模型都设为高优先级会导致调度器频繁切换模型，增加上下文切换开销（每次切换约 50~100 μs），反而降低整体吞吐。建议将延迟敏感型模型设为高优先级，批量处理型模型设为低优先级。

复盘清单：

加载前使用 nvidia-smi 检查显存碎片率（Fragmentation 字段）。
为每个模型设置独立的 --max-num-seqs，避免单个模型创建过多序列挤占 KV Cache。
监控 vllm:num_requests_running 指标，若长期低于 1，说明调度切换过于频繁。
使用 vllm:gpu_cache_usage_percent 判断 KV Cache 水位，及时调整水位线参数。

多模型加载的稳定性取决于对显存分配粒度、调度切换开销和 I/O 瓶颈的综合把控。理解这些底层机制后，排查加载失败问题时就能从“盲目调参”转向“精准定位”。