前面已经做好每个推理模型的基础配置,基本上就能正常让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属性用于指定应可用的执行实例的数量以及应为这些实例使用的计算资源。接下来就看看几个标准用法:
未添加任何instance_group参数时,表示这个模型使用默认的配置,这时该模型可以在系统中可用的每个GPU中创建单个执行实例。如果用户端提出多个请求时,就会在GPU设备上按照串行方式执行计算,如同上图中compute model 1的状态。
实例组设置可用于在每个GPU上或仅在某些GPU上放置模型的多个执行实例。例如,以下配置将在每个系统GPU上放置模型的两个执行实例。如果要让模型在一个GPU上执行多个并行实例,就将以下的内容写入模型配置文件内,这里配置的是2个并发实例:
|
instance_group [ { count: 2 kind: KIND_GPU } ] |
如果将上面配置的计算设备配置为“kind:KIND_CPU”,就是指定在CPU可以并发两个推理计算。
如果设备上有多个计算设备,不管是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)”参数设置,对于执行实例进行资源的限制,以便于在不同实例直接取得计算平衡。
这个比例限制器的配置,主要有以下两部分:
这个资源主要指的是GPU的显存调用,因为数据在CPU与GPU之间的交换传输,经常在整个计算环节中造成很大的影响,如果当我们需要对同一组数据进行不同的计算,或者计算过程中有流水线前后关系的话,那么将这些需要重复使用的数据保留在GPU显存上,就能非常有效减少数据传输次数,进而提升计算效率。
因此我们可以对模型实例提出限制,只有当系统闲置资源能满足资源需求时,才进行这个推理模型的计算。如果模型配置里没有提供任何资源限制的需求,那么Triton服务器就认定这个模型实例的执行并不需要任何资源,并将在模型实例可用时立即开始执行。
这个配置项里有三个参数内容:
下面是一个简单的模型配置内容的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 } ] } } ] |
这里面的并发数量与资源配置数量并不存在线性关系,开发人员必须根据模型所需要数据的张量尺度,以及GPU卡显存大小去进行调配。
Triton允许我们指定要为推理提供的每个模型的副本数量,默认情况下会获得每个模型的一个副本,但可以使用instance_group在模型配置中指定任意数量的实例。通常拥有一个模型的两个实例会提高性能,因为它允许CPU与GPU之间的内存传输操作与推理计算重叠。多个实例还通过允许在GPU上并发更多推理工作来提高 GPU 利用率。
因为计算资源是有限的,因此也可以在资源配置是对其进行优先级的配置,如此也会影响实例进行的先后顺序。下面是一个简单的优先级配置示范:
|
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)的配合内容,能更进一步地协助开发人员调试系统的总体性能。【完】
好文章,需要你的鼓励
后来广为人知的“云上奥运”这一说法,正是从这一刻起走上历史舞台。云计算这一概念,也随之被越来越多的人所熟知。乘云科技CEO郝凯对此深有感受,因为在2017年春节过后不久,他的公司开始成为阿里云的合作伙伴,加入了滚滚而来的云计算大潮中。同一年,郝凯带领团队也第一次参加了阿里云的“双11”活动,实现了800万元的销售业绩。
随着各行各业数字化变革的不断深入,人类社会正加速迈向智能化。作为智能世界和数字经济的坚实底座,数据中心也迎来了蓬勃发展。面