📚 课程目录第4章多模型管理

4、多模型管理：加载多个模型、模型注册与切换

在生产环境中，单模型部署往往无法满足业务需求。一个典型的推理平台可能需要同时服务多个模型：例如一个用于意图识别的中小型模型、一个用于内容生成的大参数模型，以及一个用于敏感词过滤的辅助模型。vLLM 提供了灵活的多模型管理能力，允许在单个服务进程内加载多个模型，并通过统一的接口进行注册、查询和切换。理解这一机制，是构建高效、可扩展推理服务的基础。

4.1 核心原理：模型注册表与分布式执行器

vLLM 的多模型管理并非简单地在内存中堆叠多个模型实例，而是基于一套精心设计的注册与调度机制。其核心组件是 模型注册表（Model Registry） 和 分布式执行器（Distributed Executor）。

模型注册表：一个全局的字典结构，以模型名称（或路径）为键，存储模型配置、权重引用、推理引擎实例等元数据。它负责管理模型的生命周期，包括加载、初始化、更新和卸载。
分布式执行器：负责将推理请求路由到正确的模型引擎上。当请求到达时，执行器根据请求中携带的模型标识，从注册表中查找对应的引擎，并将请求派发到该引擎的调度队列中。
显存管理：vLLM 的 PagedAttention 机制天然支持多模型共享显存池。不同模型的 KV Cache 可以动态分配在同一块显存中，通过页表进行隔离和复用，从而显著提高显存利用率。

  关键点：多模型共享一个进程和显存池，但每个模型拥有独立的词表、配置和调度器。这种设计避免了多进程部署带来的额外显存开销和通信延迟。

4.2 方法流程：加载、注册与切换

vLLM 提供了两种主要的多模型管理方式：启动时预加载和运行时动态加载。前者适用于模型集合固定、需要快速响应的场景；后者则更灵活，适合模型频繁更新的情况。

4.2.1 启动时预加载多个模型

通过命令行参数 --model 可以多次指定，或者使用 --model-loader 配合配置文件。最直接的方式是在启动命令中列出所有模型：

# 启动时加载两个模型
python -m vllm.entrypoints.openai.api_server \
    --model /models/llama2-7b-chat \
    --model /models/mistral-7b-instruct \
    --served-model-name llama2-7b-chat,mistral-7b-instruct \
    --tensor-parallel-size 2 \
    --gpu-memory-utilization 0.85

此时，两个模型都会在启动阶段完成权重加载和引擎初始化。请求时通过 model 字段指定使用哪个模型：

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistral-7b-instruct",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

4.2.2 运行时动态注册与切换

vLLM 的 OpenAI 兼容服务支持通过 API 动态添加模型。使用 POST /v1/models 接口可以注册新模型：

# 动态注册新模型
curl -X POST http://localhost:8000/v1/models \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt2-medium",
    "path": "/models/gpt2-medium",
    "tensor_parallel_size": 1
  }'

注册成功后，该模型立即可以用于推理。切换模型时，只需在请求中改变 model 字段的值，执行器会自动路由到对应的引擎。若需卸载模型，可使用 DELETE /v1/models/{model_name} 接口释放显存。

最佳实践：对于频繁切换的场景，建议将常用模型常驻显存，将低频模型按需加载。vLLM 的显存池会自动回收空闲模型的 KV Cache 块，但模型权重本身不会自动卸载，需要显式调用卸载接口。

4.3 案例：混合负载下的多模型协同

假设一个智能客服平台需要同时处理三类请求：意图识别（低延迟）、内容生成（高吞吐）、情感分析（轻量）。我们可以在单个 vLLM 实例中部署三个模型：

模型名称	模型路径	显存占用	典型延迟	调度优先级
intent-bert	/models/bert-base-intent	~1.2 GB	~8 ms	高
llama2-13b-chat	/models/llama2-13b-chat	~26 GB	~350 ms	中
sentiment-roberta	/models/roberta-sentiment	~1.5 GB	~12 ms	低

启动命令如下：

python -m vllm.entrypoints.openai.api_server \
    --model /models/bert-base-intent \
    --model /models/llama2-13b-chat \
    --model /models/roberta-sentiment \
    --served-model-name intent-bert,llama2-13b-chat,sentiment-roberta \
    --max-model-len 4096 \
    --gpu-memory-utilization 0.9

实际调用时，根据业务逻辑选择不同模型：

# 意图识别请求
curl http://localhost:8000/v1/chat/completions \
  -d '{"model": "intent-bert", "messages": [{"role": "user", "content": "我要退款"}]}'

# 内容生成请求
curl http://localhost:8000/v1/chat/completions \
  -d '{"model": "llama2-13b-chat", "messages": [{"role": "user", "content": "写一首关于春天的诗"}]}'

# 情感分析请求
curl http://localhost:8000/v1/chat/completions \
  -d '{"model": "sentiment-roberta", "messages": [{"role": "user", "content": "这个产品太棒了！"}]}'

通过这种混合部署，三个模型共享显存池，PagedAttention 机制确保 KV Cache 按需分配，整体显存利用率比独立部署提升约 40%。同时，由于共享进程，请求路由的额外开销仅为微秒级。

4.4 误区与复盘：多模型管理的常见陷阱

误区一：模型越多越好。虽然 vLLM 支持多模型，但每个模型都会占用一定的固定显存（权重 + 激活）。当模型数量过多时，留给 KV Cache 的显存会减少，导致并发能力下降。建议根据业务流量和显存容量，合理规划模型数量。

误区二：忽略词表差异。不同模型的 tokenizer 词表可能不同（如 GPT-2 的 50257 与 LLaMA 的 32000）。在切换模型时，必须确保请求的 tokenization 使用目标模型的 tokenizer，否则会产生乱码或错误。vLLM 会自动处理，但自定义 tokenizer 时需格外小心。

误区三：动态加载无限制。运行时动态加载模型虽然灵活，但会引入额外的加载延迟（通常数秒到数十秒）。如果业务对延迟敏感，应提前预热模型。此外，频繁加载/卸载会导致显存碎片化，建议使用 --enable-prefix-caching 缓解。

复盘要点：多模型管理的核心是注册表 + 执行器的协作。注册表负责元数据管理，执行器负责请求路由。在实际部署中，应优先考虑静态预加载 + 按需动态补充的策略，并时刻关注显存池的健康状态。通过 vllm.engine.arg_utils 中的参数调整，可以精细控制每个模型的资源配额，实现最优的资源利用。