4. Triton Inference Server 核心概念：模型仓库、模型版本管理、调度器、并发模型实例、动态批处理

在生产级高并发推理场景中，Triton Inference Server 凭借其灵活的架构设计，成为业界部署深度学习模型的首选方案之一。理解其核心概念——模型仓库、模型版本管理、调度器、并发模型实例与动态批处理——是构建高性能推理服务的基础。本章将逐一拆解这些概念，并展示它们如何协同工作以支撑高吞吐、低延迟的推理负载。

4.1 模型仓库：推理服务的“文件系统”

模型仓库是 Triton 用于发现、加载和管理模型的目录结构。它遵循严格的层级约定，使得 Triton 能够自动识别模型名称、版本以及关联的配置文件。

model_repository/
├── resnet50/                  # 模型名称
│   ├── 1/                     # 版本号（整数）
│   │   ├── model.onnx         # 模型文件
│   │   └── config.pbtxt       # 模型配置（可选）
│   └── 2/
│       ├── model.plan         # TensorRT 引擎文件
│       └── config.pbtxt
├── bert_qa/
│   ├── 1/
│   │   ├── model.py           # Python 模型定义
│   │   └── config.pbtxt
│   └── 2/
│       └── ...
└── ensemble_model/            # 组合模型
    └── 1/
        └── config.pbtxt

4.2 模型版本管理：策略与生命周期

Triton 支持灵活的版本控制策略，允许运维人员在不中断服务的情况下进行模型热更新、回滚或灰度发布。版本管理通过 --model-control-mode 启动参数和 config.pbtxt 中的 version_policy 字段共同实现。

• 轮询模式 (POLL)：Triton 定期扫描仓库目录，自动加载新版本或卸载已删除的版本。适合开发测试环境。
• 显式模式 (EXPLICIT)：通过管理 API（HTTP/gRPC）手动控制版本的加载与卸载。适合生产环境，避免文件系统抖动导致意外加载。
• 版本策略 (version_policy)：在 config.pbtxt 中定义，决定哪些版本对外可见。
  • latest { num_versions: 2 }：只保留最新的 2 个版本。
  • specific { versions: [1, 3] }：只加载指定的版本 1 和 3。
  • all {}：加载所有版本（默认行为，不推荐用于生产）。

4.3 调度器与并发模型实例

调度器是 Triton 推理引擎的核心决策单元，负责将客户端请求高效地分配给模型实例。并发模型实例（Model Instance）是 Triton 实现高吞吐的关键——它允许一个模型在 GPU 或 CPU 上同时运行多个副本。

并发模型实例通过 config.pbtxt 中的 instance_group 字段配置。每个实例可以绑定到特定的 GPU 设备或 CPU，并拥有独立的计算上下文。

# config.pbtxt 示例：配置 2 个 GPU 实例和 1 个 CPU 实例
name: "resnet50"
backend: "onnxruntime"
max_batch_size: 32

instance_group [
  {
    count: 2
    kind: KIND_GPU
    gpus: [0]          # 绑定到 GPU 0
  },
  {
    count: 1
    kind: KIND_CPU
  }
]

4.4 动态批处理：吞吐量与延迟的平衡艺术

动态批处理是 Triton 应对高并发请求的核心优化手段。它允许调度器将多个在时间窗口内到达的独立请求，动态组合成一个批次，一次性送入模型推理引擎。这能显著提高 GPU 的并行计算效率，但也会引入额外的等待延迟。

4.5 核心概念协同总结

上述五个概念并非孤立存在，而是构成一个完整的推理服务生命周期：

1. 模型仓库 提供结构化的模型存储，支持多版本共存。
2. 版本管理 控制哪些版本被加载和对外服务，实现平滑升级。
3. 调度器 根据请求特征和模型配置，决定使用何种策略（默认、动态批处理、序列等）。
4. 并发模型实例 在调度器的指挥下，利用多 GPU/多 CPU 并行处理请求。
5. 动态批处理 在调度器内部工作，通过合并请求最大化硬件利用率。