📚 课程目录第4章多模型推理服务场景分析

4、多模型推理服务场景分析：典型架构、多模型并行推理的需求、资源隔离与共享策略

在生产环境中，单一模型推理服务往往无法满足复杂的业务需求。一个典型的AI平台通常需要同时承载多个模型：例如，一个智能客服系统可能需要同时运行意图识别模型、情感分析模型、实体抽取模型以及一个大型语言生成模型。这些模型在计算特性、资源占用、延迟要求和部署周期上差异巨大。本章将深入分析多模型推理服务的典型架构形态，剖析多模型并行推理的核心需求，并重点探讨在Docker Compose编排下如何设计资源隔离与共享策略，为后续章节的实战部署奠定理论基础。

4.1 多模型推理的典型架构形态

多模型推理服务的架构设计，本质上是在资源效率与故障隔离之间寻找平衡。根据模型间的耦合程度和部署方式，业界形成了四种主流架构形态。

4.1.1 单体多模型架构

这种架构将多个模型加载到同一个服务进程中，通过内部路由逻辑分发请求。例如，使用一个Python进程同时加载BERT和ResNet模型，根据请求中的model_name参数决定调用哪个模型。其优势在于内存共享（如共同的Tokenizer词表）和极低的内部调用延迟；但缺点是模型间相互影响，一个模型的显存溢出（OOM）可能导致整个进程崩溃，且无法独立扩缩容。

4.1.2 独立服务架构

每个模型独立部署为一个服务，拥有独立的容器、端口和资源限制。这是Docker Compose最擅长的模式。例如，一个NLP平台可以拆分为sentiment-service、ner-service、llm-service三个独立容器。每个服务可以独立选择基础镜像、Python版本和依赖库，互不干扰。这种架构的代价是容器数量增多，需要额外的服务发现和负载均衡机制。

4.1.3 网关聚合架构

在独立服务之上增加一个API网关层（如Nginx、Traefik或自研路由服务），所有外部请求先到达网关，由网关根据路径或请求头转发到对应的模型服务。这种模式将路由策略与模型计算解耦，便于实现灰度发布、流量镜像和统一鉴权。在Docker Compose中，网关通常作为独立的service，通过depends_on声明依赖关系。

4.1.4 混合架构

生产环境中最常见的做法是混合模式：将计算密集、资源占用大的大模型（如LLM）独立部署，将多个轻量级小模型（如文本分类、关键词抽取）合并到一个服务中。例如，一个智能文档处理系统，将OCR模型独立部署（需要GPU），而将文本纠错、格式转换等小模型合并为一个CPU服务。

架构形态	隔离性	资源效率	运维复杂度	Compose适配度
单体多模型	低（共享进程）	高（内存共享）	低	一般（单容器）
独立服务	高（进程隔离）	中（重复基础开销）	中	高（多service）
网关聚合	高	中	中高（需维护网关）	高（网关+服务）
混合模式	中高	高（按需分配）	高	高（灵活组合）

选型建议：对于Docker Compose部署场景，推荐优先考虑独立服务 + 网关聚合的混合模式。Compose的service定义天然支持多容器编排，配合Nginx或Traefik容器，可以快速构建生产级多模型推理平台。

4.2 多模型并行推理的核心需求

当多个模型同时对外提供服务时，会暴露出单模型场景下不存在的复杂需求。理解这些需求是设计合理架构的前提。

4.2.1 异构资源调度需求

不同模型的资源需求差异巨大。一个BERT-base模型约需400MB内存和少量CPU；而一个LLaMA-7B模型需要14GB以上显存和强大的GPU算力。Docker Compose通过deploy.resources.limits和reservations字段可以为每个服务设置CPU、内存限制，但对于GPU资源，需要依赖NVIDIA Container Toolkit，并通过gpus: all或gpus: '"device=0,1"'进行分配。

# docker-compose.yml 资源分配示例
services:
  bert-service:
    image: nlp/bert:latest
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 2G
        reservations:
          cpus: '1.0'
          memory: 1G
  
  llm-service:
    image: nlp/llama7b:latest
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

4.2.2 并发与吞吐需求

多模型场景下，不同模型的QPS（每秒查询数）差异可能达到两个数量级。例如，一个关键词提取服务可能承受1000 QPS，而一个对话生成模型可能只有10 QPS。这要求架构支持按模型独立扩缩容。在Compose中，可以通过docker compose up --scale sentiment-service=3实现水平扩展，但需要注意负载均衡的配置。

4.2.3 独立生命周期管理

模型迭代频率不同：一个规则类模型可能每月更新一次，而一个深度学习模型可能每周更新。独立服务架构允许单独升级某个模型服务而不影响其他服务。Compose的docker compose build <service-name>和docker compose up -d <service-name>命令支持对单个服务进行重建和滚动更新。

4.2.4 故障爆炸半径控制

一个模型服务的内存泄漏或死循环不应拖垮整个推理平台。通过容器级别的restart: on-failure策略和健康检查（healthcheck），可以确保单个服务故障后自动恢复，而其他服务继续正常运行。

常见误区：很多初学者将所有模型打包进一个容器，认为这样“节省资源”。实际上，当模型A发生OOM时，内核可能会触发OOM Killer杀掉整个容器进程，导致模型B也同时不可用。正确的做法是：宁可多开几个容器，也要保证故障隔离。

4.3 资源隔离与共享策略

资源隔离与共享是多模型推理平台设计的核心矛盾。完全隔离会导致资源浪费，过度共享则会引入相互干扰。Docker Compose提供了多层次的策略工具。

4.3.1 计算资源隔离

CPU和内存隔离通过cgroups实现。Compose的deploy.resources字段直接映射到Docker的--cpus和--memory参数。对于CPU密集型模型，建议设置cpus: '1.5'限制其最大使用量；对于内存敏感型模型，设置memory: 1G和memswap_limit: 1G防止swap抖动。

4.3.2 GPU共享策略

GPU是稀缺资源，多模型共享GPU需要精细策略。三种主流方案：

时间片共享（MPS）：NVIDIA MPS（Multi-Process Service）允许多个进程共享GPU计算资源，适合多个小模型并发推理。在容器中启用MPS需要设置环境变量NVIDIA_DRIVER_CAPABILITIES=compute,utility并挂载MPS控制目录。
显存分区（MIG）：A100/A30等GPU支持MIG（Multi-Instance GPU），可将物理GPU划分为多个独立实例，每个实例拥有专属显存和计算单元。Compose中通过device_ids指定MIG设备。
整卡分配：对于大模型，最稳妥的方式是独占整张GPU。通过gpus: '"device=0"'指定。

4.3.3 模型文件共享

多个服务可能需要读取相同的模型文件（如共享的Embedding表）。为避免每个容器重复拷贝大文件，可以使用Compose的只读卷（Read-Only Volume）挂载。例如，将模型仓库目录挂载到多个服务：

volumes:
  model-repo:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: /data/models

services:
  bert-service:
    volumes:
      - model-repo:/models:ro
  llm-service:
    volumes:
      - model-repo:/models:ro

4.3.4 网络策略

多服务间通信应使用Compose内部网络（默认的bridge网络），避免将每个服务都映射到宿主机端口。只有网关需要暴露端口。通过expose指令（仅内部可访问）和ports指令（宿主机可访问）的区分，可以控制网络暴露面。

资源类型	隔离手段	共享手段	Compose配置项
CPU	cpus限制	多容器共享多核	deploy.resources.limits.cpus
内存	memory限制	overcommit（不推荐）	deploy.resources.limits.memory
GPU	整卡分配/MIG	MPS时间片	gpus / device_ids
模型文件	各自拷贝	只读卷挂载	volumes: /models:ro
网络	独立端口	内部DNS服务发现	networks + expose

4.4 实战案例：构建一个多模型推理平台

下面通过一个完整的案例，演示如何综合运用上述策略。假设我们要构建一个智能文档审核系统，包含三个模型服务：

OCR服务：基于PaddleOCR，需要GPU，显存需求约2GB。
敏感信息识别服务：基于BERT，CPU即可，内存需求1GB。
文档分类服务：基于TextCNN，CPU即可，内存需求512MB。

4.4.1 初始架构与约束

宿主机配置为：8核CPU、32GB内存、1张NVIDIA T4 GPU（16GB显存）。约束条件：OCR服务必须使用GPU，且显存占用不能超过4GB（预留空间给其他任务）；两个CPU服务共享8核CPU，但每个服务最多使用3核。

4.4.2 分析判断过程

首先，评估GPU共享方案。T4不支持MIG，因此只能选择MPS或整卡分配。由于OCR服务是唯一GPU需求者，且显存需求（2GB）远小于T4的16GB，我们选择整卡分配，但通过环境变量限制PaddleOCR的显存池大小为4GB（FLAGS_initial_gpu_memory_in_mb=4096），避免其占用全部显存。

其次，CPU服务的内存分配。BERT服务需要1GB内存，但考虑到推理时的峰值（通常为模型大小的2-3倍），设置memory: 2G。TextCNN服务设置memory: 1G。

4.4.3 实际操作步骤

编写docker-compose.yml如下：

version: '3.8'

services:
  ocr-service:
    image: registry.example.com/ocr:1.2.0
    ports:
      - "8081:8080"
    environment:
      - FLAGS_initial_gpu_memory_in_mb=4096
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 5s
      retries: 3

  bert-service:
    image: registry.example.com/bert-sent:0.9.0
    expose:
      - "8080"
    deploy:
      resources:
        limits:
          cpus: '3.0'
          memory: 2G
    volumes:
      - model-cache:/models:ro

  textcnn-service:
    image: registry.example.com/textcnn:0.3.1
    expose:
      - "8080"
    deploy:
      resources:
        limits:
          cpus: '3.0'
          memory: 1G
    volumes:
      - model-cache:/models:ro

  gateway:
    image: nginx:1.25-alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - ocr-service
      - bert-service
      - textcnn-service

volumes:
  model-cache:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: /data/models

4.4.4 结果对比与复盘

部署后，通过docker compose ps查看所有服务状态，通过docker stats监控资源使用。实测数据：OCR服务GPU显存占用稳定在3.2GB（含CUDA上下文），BERT服务CPU峰值2.1核，TextCNN服务CPU峰值1.8核，整体资源利用率良好。

风险与代价：MPS方案虽然能提高GPU利用率，但会增加约10%的推理延迟。本案例中由于OCR独占GPU，避免了该问题。另外，模型文件通过只读卷共享，节省了约1.5GB的磁盘空间，但需要注意模型更新时的版本一致性——建议使用不可变标签（如bert-sent:0.9.0）而非latest。

  复盘经验：1）GPU资源规划时，不仅要考虑模型显存，还要预留CUDA上下文和推理框架的额外开销（通常为模型大小的20%-30%）；2）CPU服务的内存限制应设置为模型大小的2-3倍，防止峰值OOM；3）网关层务必配置超时和重试机制，避免某个模型服务慢导致整个链路阻塞。

4.5 常见误区与总结

在多模型推理场景的规划中，以下误区需要特别警惕：

误区一：所有模型必须使用同一框架。实际上，不同模型可以使用不同框架（PyTorch、TensorFlow、ONNX Runtime），只要通过HTTP/gRPC通信即可。Compose的镜像独立性天然支持这种异构。
误区二：资源限制越严格越好。过紧的CPU限制会导致推理延迟飙升，过小的内存限制会频繁触发OOM。建议先以reservations设置下限，再根据压测结果逐步调整limits上限。
误区三：忽略健康检查。没有健康检查的容器，在模型加载失败或死锁时不会被自动重启。务必为每个服务配置healthcheck，并设置合理的start_period（模型加载时间）。
误区四：将所有端口暴露到宿主机。这增加了端口冲突和安全隐患。内部服务间通信应使用Compose网络内的服务名（DNS解析），仅网关暴露必要端口。