NVIDIA Triton 系列文章(11):模型类别与调度器-2

描述

在上篇文章中,已经说明了有状态(stateful)模型的“控制输入”与“隐式状态管理”的使用方式,本文内容接着就继续说明“调度策略”的使用。  (续前一篇文章的编号)  (3) 调度策略(Scheduling Strategies)在决定如何对分发到同一模型实例的序列进行批处理时,序列批量处理器(sequence batcher)可以采用以下两种调度策略的其中一种:  
  • 直接(direct)策略
当模型维护每个批量处理槽的状态,并期望给定序列的所有推理请求都分发到同一槽,以便正确更新状态时,需要使用这个策略。此时,序列批量处理程序不仅能确保序列中的所有推理请求,都会分发到同一模型实例,并且确保每个序列都被分发至模型实例中的专用批量处理槽(batch slot)。  下面示例的模型配置,是一个 TensorRT 有状态模型,使用直接调度策略的序量批处理程序的内容:  
name: "direct_stateful_model"platform: "tensorrt_plan"max_batch_size: 2sequence_batching  {   max_sequence_idle_microseconds: 5000000  direct  { }   control_input [    {      name:  "START"       control [        {           kind: CONTROL_SEQUENCE_START           fp32_false_true: [ 0, 1 ]        }      ]    },    {      name:  "READY"       control [        {           kind: CONTROL_SEQUENCE_READY           fp32_false_true: [ 0, 1 ]        }      ]    }  ]}  # 续接右栏 # 上接左栏input [  {    name:  "INPUT"     data_type: TYPE_FP32    dims: [  100, 100 ]  }]output [  {    name:  "OUTPUT"     data_type: TYPE_FP32    dims: [  10 ]  }]instance_group [  {     count: 2  }]
 现在简单说明以下配置的内容:
  • sequence_batching 部分指示模型会使用序列调度器的 Direct 调度策略;
  • 示例中模型只需要序列批处理程序的启动和就绪控制输入,因此只列出这些控制;
  • instance_group 表示应该实例化模型的两个实例;
  • max_batch_size 表示这些实例中的每一个都应该执行批量大小为 2 的推理计算。
 下图显示了此配置指定的序列批处理程序和推理资源的表示:  英伟达  每个模型实例都在维护每个批处理槽的状态,并期望将给定序列的所有推理请求分发到同一槽,以便正确更新状态。对于本例,这意味着 Triton 可以同时 4 个序列进行推理。  使用直接调度策略,序列批处理程序会执行以下动作:  
所识别的推理请求种类 执行动作
需要启动新序列 1. 有可用处理槽时:就为该序列分配批处理槽2. 无可用处理槽时:就将推理请求放在积压工作中
是已分配处理槽序列的一部分 将该请求分发到该配置好的批量处理槽
是积压工作中序列的一部分 将请求放入积压工作中
是最后一个推理请求 1. 有积压工作时:将处理槽分配给积压工作的序列2. 有积压工作:释放该序列处理槽给其他序列使用
 下图显示使用直接调度策略,将多个序列调度到模型实例上的执行:  英伟达  图左显示了到达 Triton 的 5 个请求序列,每个序列可以由任意数量的推理请求组成。图右侧显示了推理请求序列是如何随时间安排到模型实例上的,  
  • 在实例 0 与实例 1 中各有两个槽 0 与槽 1;
  • 根据接收的顺序,为序列 0 至序列 3 各分配一个批量处理槽,而序列 4 与序列 5 先处于排队等候状态;
  • 当序列 3 的请求全部完成之后,将处理槽释放出来给序列 4 使用;
  • 当序列 1 的请求全部完成之后,将处理槽释放出来给序列 5 使用;
 以上是直接策略对最基本工作原理,很容易理解。  接下来要进一步使用控制输入张量与模型通信的功能,下图是一个分配给模型实例中两个批处理槽的两个序列,每个序列的推理请求随时间而到达,START 和 READY 显示用于模型每次执行的输入张量值:  英伟达  随着时间的推移(从右向左),会发生以下情况:
  • 序列中第一个请求(Req 0)到达槽 0 时,因为模型实例尚未执行推理,则序列调度器会立即安排模型实例执行,因为推理请求可用;
  • 由于这是序列中的第一个请求,因此 START 张量中的对应元素设置为 1,但槽 1 中没有可用的请求,因此 READY 张量仅显示槽 0 为就绪。
  • 推理完成后,序列调度器会发现任何批处理槽中都没有可用的请求,因此模型实例处于空闲状态。
  • 接下来,两个推理请求(上面的 Req 1 与下面的 Req 0)差不多的时间到达,序列调度器看到两个处理槽都是可用,就立即执行批量大小为 2 的推理模型实例,使用 READY 显示两个槽都有可用的推理请求,但只有槽 1 是新序列的开始(START)。
  • 对于其他推理请求,处理以类似的方式继续。
 以上就是配合控制输入张量的工作原理。  
  • 最旧的(oldest)策略
 这种调度策略能让序列批处理器,确保序列中的所有推理请求都被分发到同一模型实例中,然后使用“动态批处理器”将来自不同序列的多个推理批量处理到一起。  使用此策略,模型通常必须使用 CONTROL_SEQUENCE_CORRID 控件,才能让批量处理清楚每个推理请求是属于哪个序列。通常不需要 CONTROL_SEQUENCE_READY 控件,因为批处理中所有的推理都将随时准备好进行推理。  下面是一个“最旧调度策略”的配置示例,以前面一个“直接调度策略”进行修改,差异之处只有下面所列出的部分,请自行调整:  
直接(direct)策略 最旧的(oldest)策略

direct {}

oldest

{

max_candidate_sequences: 4

    }
   在本示例中,模型需要序列批量处理的开始、结束和相关 ID 控制输入。下图显示了此配置指定的序列批处理程序和推理资源的表示。  英伟达  使用最旧的调度策略,序列批处理程序会执行以下工作:  
所识别的推理请求种类 执行动作
需要启动新序列 尝试查找具有候选序列空间的模型实例,如果没有实例可以容纳新的候选序列,就将请求放在一个积压工作中
已经是候选序列的一部分 将该请求分发到该模型实例
是积压工作中序列的一部分 将请求放入积压工作中
是最后一个推理请求 模型实例立即从积压工作中删除一个序列,并将其作为模型实例中的候选序列,或者记录如果没有积压工作,模型实例可以处理未来的序列。
   下图显示将多个序列调度到上述示例配置指定的模型实例上,左图显示 Triton 接收了四个请求序列,每个序列由多个推理请求组成:  英伟达  这里假设每个请求的长度是相同的,那么左边候选序列中送进右边批量处理槽的顺序,就是上图中间的排列顺序。  最旧的策略从最旧的请求中形成一个动态批处理,但在一个批处理中从不包含来自给定序列的多个请求,例如上面序列 D 中的最后两个推理不是一起批处理的。  以上是关于有状态模型的“调度策略”主要内容,剩下的“集成模型”部分,会在下篇文章中提供完整的说明。        


原文标题:NVIDIA Triton 系列文章(11):模型类别与调度器-2

文章出处:【微信公众号:NVIDIA英伟达企业解决方案】欢迎添加关注!文章转载请注明出处。


打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分