前面给大家分享了模型推理服务化结构Triton保姆式教程（一）：快速入门，关于一个模型推理服务结构来说，一般重视的目标有延时、吞吐、效率、灵活性和可扩展性等。那么，针对每个点应该如何去处理，这是在进行推理结构规划时需求去考虑的问题。因此，本文从更高的技能视野来看一个推理体系以及Triton的架构是如何进行规划的。

推理体系架构规划

关于一个推理体系来说，主要由两部分组成：客户端和服务端。

模型推理服务化框架Triton保姆式教程（二）：架构解析

关于客户端来说，一般比较简单，如上图左半部分所示。它能够是手机、平板、电脑或者下游使用体系等。

而关于服务端，一般比较复杂，它也是整个推理体系的中心，如上图右半部分所示。下面，咱们来看下服务端架构应该怎样规划？

首要，它得有一个布置渠道/集群（如：Kubernetes）。用于对一个推理服务的生命周期的办理（模型的加载/卸载，模型服务实例的弹性扩缩容等）。

然后，它还应该有一个负载均衡器（如：Ingress），处理模型推理服务实例负载均衡的问题。将客户端的恳求，均衡的分配给推理服务实例。

其次，它还应该有一个模型库房（如：本地文件体系），对模型权重文件和模型输入输出装备进行办理。

之后，它还应该有一个模型监控服务，用于调查模型的微观/微观的数据。

最后，也是最中心的，它还应该有一个推理服务，进行模型推理。比方，Triton就是一个推理服务化结构，这也是Triton的定位：

  • 单节点推理服务。
  • 支撑异构，比方：CPU、GPU、TPU等。
  • 支撑多结构，比方：TensorRT、Pytorch、FasterTransformer等。

模型推理服务化框架Triton保姆式教程（二）：架构解析

接下来，咱们一起来看一下 Triton 的全体架构是如何规划的？

Triton 架构解析

下图展示了 Triton 推理服务的全体架构。

模型推理服务化框架Triton保姆式教程（二）：架构解析

Triton推理服务的大体流程为推理恳求经过 HTTP/REST、GRPC 或 C API 抵达推理服务，然后路由到每个模型相关的调度行列中。 Triton 实现了多种调度和批处理算法，能够在每个模型上面进行装备。 每个模型的调度器可挑选履行推理恳求的批处理，然后将恳求传递给与模型类型对应的后端。后端使用批处理恳求中供给的输入履行推理以生成恳求的输出。 然后回来输出。

下面是Triton生态的重要组成组件和重要特性：

榜首，Triton需求一个模型库房，一个根据文件体系的模型存储库，Triton 将使其可用于推理。

第二，Triton 支撑 C API 后端，答应 Triton 扩展新功能，例如：自定义预处理和后处理操作，乃至是新的深度学习结构。

第三，Triton 供给的模型能够经过专门的模型办理 API 进行查询和操控，该 API 可经过 HTTP/REST 或 GRPC 协议或 C API 获得。

第四，Triton 服务中的准备就绪（readiness）和存活（liveness）健康接口、利用率、吞吐量和延迟目标简化了 Triton 与布置结构（如：Kubernetes）的集成。

第五，Triton支撑模型办理，模型的加载/卸载，模型更新，查看模型的状况。

第六，Triton供给了恳求行列，用于行列中的恳求进行分发和调度。

第七，Triton供给恳求的生命周期办理，比方：推理恳求/呼应的办理。

另外，Triton 服务架构答应多个模型或同一模型的多个实例在同一体系上并行履行（并发）。 体系可能有零个、一个或多个 GPU 卡。

模型推理服务化框架Triton保姆式教程（二）：架构解析

模型推理服务化框架Triton保姆式教程（二）：架构解析

模型并行履行推理的逻辑

下图显现了具有两个模型（模型 0 和模型 1）并行履行推理的流程。 假设 Triton 当时没有处理任何恳求，当两个恳求一起抵达时Triton服务，每个模型一个恳求，Triton 当即将它们都调度到 GPU 上，GPU 的硬件调度程序开端并行处理这两个核算。

在体系的 CPU 上履行的模型由 Triton 进行相似地处理，除了 CPU 线程履行每个模型的调度由体系的操作体系处理之外。

模型推理服务化框架Triton保姆式教程（二）：架构解析

默许情况下，假如同一模型的多个恳求一起抵达，Triton 将经过在 GPU 上一次只调度一个来序列化它们的履行，如下图所示。

模型推理服务化框架Triton保姆式教程（二）：架构解析

Triton 供给了一个名为 instance-group 的模型装备选项，它答应每个模型指定该模型的并行履行数。每个这样启用的并行履行都称为一个实例。 默许情况下，Triton 会在体系中每个可用的 GPU 上为每个模型供给一个实例。 经过使用模型装备中的 instance_group 字段，能够更改模型的履行的实例数。 下图显现了当 model1 装备为答应三个实例的模型履行。 如下图所示，前三个 model1 服务的推理恳求当即并行履行。 第四个 model1 服务的推理恳求有必要比及前三个履行中的一个履行完结才能开端。

模型推理服务化框架Triton保姆式教程（二）：架构解析

Triton 支撑多种调度和批处理（batching）算法，能够为每个模型独立设置。

模型类型及调度器

针对不同的场景，Triton定义了三种模型类型：无状况（stateless）、有状况（stateful）和集成（ensemble）模型，一起，Triton 供给了调度器来支撑这些模型类型。

模型类型

Triton中三种模型类型如下：

  • 无状况模型（Stateless models）：简单来说就是应对不同推理恳求没有相互依靠的情况。往常遇到的大部分模型都属于这一类模型，比方：文本分类、实体抽取、目标检测等。
  • 有状况模型（Stateful Models）：当时的模型输出依靠上一刻的模型的状况（比方：中间状况或输出）。关于推理服务来说，就是不同推理恳求之间有状况依靠，比方：次序依靠。
  • 集成模型（Ensemble model）：表明一个或多个模型组成的工作流(有向无环图)。最常见的使用场景就是：数据预处理->模型推理->数据后处理。经过集成模型能够避免传输中间tensor的开销，而且能够最小化恳求次数。比方：bert实现的文本分类使命，需求在前置处理中对输入文本做Tokenizer，Tokenizer输出结果作为模型属性输入。如下所示，preprocess表明前置处理模型；bert_onnx表明文本分类模型；ensemble_bert_classification表明集成模型。
 ├── bert_onnx
 ├── ensemble_bert_classification
 └── preprocess

调度器

Triton供给了如下几种调度战略：

  • Default Scheduler：默许调度战略，能够理解为推理结构内部的模型实例负载，将推理恳求按份额分配到不同的模型实例履行推理。
  • Dynamic Batcher：在应对高吞吐的场景，将一定时间内的恳求聚组成一个批次（batch）。该调度器用于调度无状况的模型。

模型推理服务化框架Triton保姆式教程（二）：架构解析

模型推理服务化框架Triton保姆式教程（二）：架构解析

  • Sequence Batcher：相似Dynamic batcher，Sequence batcher也是动态聚合推理恳求。区别是Sequence batcher使用于有状况模型，而且一个序列的恳求只能路由到同一个模型实例。

模型推理服务化框架Triton保姆式教程（二）：架构解析

  • Ensemble Scheduler：只能调度集成模型，不能用于其他类型的模型。

模型推理服务化框架Triton保姆式教程（二）：架构解析

关于给定的模型，调度战略的挑选和装备是经过模型的装备文件完结的，后续的文章会进行深入讲解。

总结

本文扼要介绍了一个推理体系架构应该如何规划以及Triton的架构、Triton推理服务恳求的履行流程、Triton中的重要组成组件，比方：

  • Triton 支撑 C API 后端，答应 Triton 扩展新功能。
  • Triton 供给的模型能够经过专门的模型办理 API 进行查询和操控。
  • Triton 服务中的准备就绪（readiness）和存活（liveness）健康端点、利用率、吞吐量和延迟目标简化了 Triton 与布置结构（如：Kubernetes）的集成。
  • Triton 服务架构答应多个模型或同一模型的多个实例在同一体系上并行履行。 Triton 支撑多种调度和批处理（batching）算法，能够为每个模型独立设置。

希望经过本文的讲解能够给你带来帮助。

参阅文档：

  • NVIDIA Triton
  • NVIDIA Triton 推理服务
  • Triton User Guide
  • Triton 视频教程