前面已经做好了每个推理模型的基础配置，基本上就能正常让 Triton 服务器使用这些独立模型进行推理。接下来的重点，就是要让设备的计算资源尽可能地充分使用，首先第一件事情就是模型并发执行（concurrent model execution）的调试，这是提升 Triton 服务器性能的最基本任务。
Triton 服务器支持的模型并发能力，包括一个模型并发多个推理实例，以及多个模型的多个并发实例。至于能并发多少实例？就需要根据系统上的硬件配置，Triton 支持纯 CPU 以及多 GPU 的计算环境。
GPU 是能够同时执行多个工作负载的计算引擎，Triton 推理服务器通过在 GPU上同时运行多个模型，最大限度地提高性能并减少端到端延迟，这些模型可以完全相同也可以是不同框架的不同模型，显存大小是唯一限制并发运行模型数量的因素。
下图显示了两个计算模型 compute model 0 与 compute model 1 的示例，假设 Triton 服务器当前处于等待状态，当 request 0 与 request 1 两个请求同时到达时，Triton 会立即将这两个请求调度到 GPU 上（下图左），开始并发处理这两个模型的推理计算。
默认情况下，Triton 指定系统中的每个可用 GPU 为每个模型提供一个实例，如果同一模型的多个请求同时到达，Triton 将通过在 GPU 上一次只调度一个请求来串行化它们的执行（上图中）。这样的方式在管理上是最轻松的，但是执行效率并不好，因为计算性能并未被充分调用。
Triton 提供了一个 “instance_group” 的模型配置选项，通过在模型配置中使用这个字段，可以更改模型的执行实例数，调整每个模型的并发执行数量。
上图右就是在 model 1 配置文件中，添加 “instance_group” 配置，并且设置 “count: 3” 的参数，这样就允许一个 GPU 上可以并发三个实例的模型计算，如果用户端发出超过 3 个推理请求时，则第 4 个 model 1 推理请求就必须等到前三个实例中的任一个执行完之后，才能开始执行。
Triton 可以提供一个模型的多个实例，从而可以同时处理该模型的多条推理请求。模型配置 ModelInstanceGroup 属性用于指定应可用的执行实例的数量以及应为这些实例使用的计算资源。接下来就看看几个标准用法：
1. 单 CPU 或 GPU 单实例
未添加任何 instance_group 参数时，表示这个模型使用默认的配置，这时该模型可以在系统中可用的每个 GPU 中创建单个执行实例。如果用户端提出多个请求时，就会在 GPU 设备上按照串行方式执行计算，如同上图中 compute model 1 的状态。
2. 单 CPU 或 GPU 并发多实例
实例组设置可用于在每个 GPU 上或仅在某些 GPU 上放置模型的多个执行实例。例如，以下配置将在每个系统 GPU 上放置模型的两个执行实例。如果要让模型在一个 GPU 上执行多个并行实例，就将以下的内容写入模型配置文件内，这里配置的是 2 个并发实例：
instance_group [
{
count: 2
kind: KIND_GPU
}
]如果将上面配置的计算设备配置为 “kind:KIND_CPU” ，就是指定在 CPU 可以并发两个推理计算。
3. 多 CPU 或 GPU 并发多实例
如果设备上有多个计算设备，不管是 CPU 或 GPU，都可以使用以下配置方式，为模型配置多个并发推理实例：
instance_group [
{
count: 1
kind: KIND_GPU
gpus: [ 0 ]
},
{
count: 2
kind: KIND_GPU
gpus: [ 1, 2 ]
}
]这里的内容，表示 Triton 服务器至少启动 3 个 GPU 计算设备，这个推理模型在编号为 0 的 GPU 上启动 1 个并发实例，在编号为 1 与 2 的 GPU 上可以同时启动 2 个并发实例，以此类推。
以上是 instance_group 的基础配置内容，如果要对每个 GPU 设备的计算资源进行更深层的配置，还可以配合一个“比例限制器配置（Rate Limiter Configuration）”参数设置，对于执行实例进行资源的限制，以便于在不同实例直接取得计算平衡。
这个比例限制器的配置，主要有以下两部分：
- 资源（Reousrces）限制：
这个资源主要指的是 GPU 的显存调用，因为数据在 CPU 与 GPU 之间的交换传输，经常在整个计算环节中造成很大的影响，如果当我们需要对同一组数据进行不同的计算，或者计算过程中有流水线前后关系的话，那么将这些需要重复使用的数据保留在 GPU 显存上，就能非常有效减少数据传输次数，进而提升计算效率。
因此我们可以对模型实例提出限制，只有当系统闲置资源能满足资源需求时，才进行这个推理模型的计算。如果模型配置里没有提供任何资源限制的需求，那么 Triton 服务器就认定这个模型实例的执行并不需要任何资源，并将在模型实例可用时立即开始执行。
这个配置项里有三个参数内容：
（1）“name”字段：资源名称；
（2）“count”字段：组中模型实例需要运行的资源副本数；
（3）“global”字段：指定资源是按设备还是在系统中全局共享。
下面是一个简单的模型配置内容的 instance_group 参数组：
instance_group [
{
count: 2
kind: KIND_GPU
gpus: [ 0 ]
rate_limiter {
resources [
{
name: "R1"
count: 4
}
]
}
},
{
count: 4
kind: KIND_GPU
gpus: [ 1, 2 ]
rate_limiter {
resources [
{
name: "R2"
global: True
count: 2
}
]
}
}
]
第 1 组配置：可并发执行数量为 2，指定使用 gpu[0] 设备，需要名为 “R1” 的计算资源，其内容是需要 2 份设备内存的副本；
第 2 组配置：可并发执行数量为 4，指定使用 gpu[1, 2] 两个设备，需要名为 “R2” 的计算资源，其内容是需要 4 份全局共享内存的副本，
这里面的并发数量与资源配置数量并不存在线性关系，开发人员必须根据模型所需要数据的张量尺度，以及 GPU 卡显存大小去进行调配。
Triton 允许我们指定要为推理提供的每个模型的副本数量，默认情况下会获得每个模型的一个副本，但可以使用 instance_group 在模型配置中指定任意数量的实例。通常拥有一个模型的两个实例会提高性能，因为它允许 CPU 与 GPU 之间的内存传输操作与推理计算重叠。多个实例还通过允许在 GPU 上并发更多推理工作来提高 GPU 利用率。
- 优先级（Priority）设置：
因为计算资源是有限的，因此也可以在资源配置是对其进行优先级的配置，如此也会影响实例进行的先后顺序。下面是一个简单的优先级配置示范：
instance_group [
{
count: 1
kind: KIND_GPU
gpus: [ 0, 1, 2 ]
rate_limiter {
resources [
{
name: "R1"
count: 4
},
{
name: "R2"
global: True
count: 2
}
]
priority: 2
}
}
] 上面配置组的 3 个模型实例，每个设备（0、1和2）上执行一个，每个实例需要 4 个 “R1” 和 2 个具有全局资源的 “R2” 资源才能执行，并将比例限制器的优先级设置为 2。
这三个实例之间不会争夺 “R1” 资源，因为 “R1” 对于它们自己的设备是本地的，但是会争夺 “R2” 资源，因为它被指定为全局资源，这意味着 “R2” 在整个系统中共享。虽然这些实例之间不争 “R1”，但它们将与其他模型实例争夺 “R1“，这些模型实例在资源需求中包含 “R1” 并与它们在同一设备上运行。
这是对所有模型的所有实例进行优先级排序，优先级 2 的实例将被赋予优先级 1 的实例 1/2 的调度机会数。
以上是关于 Triton 服务器“模型并发执行”的基础内容，后面还有更多关于调度器（scheduler）与批量处理器（batcher）的配合内容，能更进一步地协助开发人员调试系统的总体性能。
