NVIDIA Triton系列10-模型并发执行

简介: NVIDIA Triton服务器支持模型并发执行,通过在单个或多个GPU上同时运行多个模型实例,提高计算资源利用率和性能。配置`instance_group`可调整每个模型的并发实例数,优化推理效率。此外,通过设置资源限制和优先级,确保在有限的计算资源下实现高效的任务调度。

NVIDIA Triton系列10-模型并发执行

B站:肆十二-的个人空间-肆十二-个人主页-哔哩哔哩视频 (bilibili.com)

博客:肆十二-CSDN博客

问答:(10 封私信 / 72 条消息) 肆十二 - 知乎 (zhihu.com)

前面已经做好了每个推理模型的基础配置,基本上就能正常让 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 上(下图左),开始并发处理这两个模型的推理计算。

img

默认情况下,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)的配合内容,能更进一步地协助开发人员调试系统的总体性能。

目录
相关文章
|
2天前
|
编解码 Java 程序员
写代码还有专业的编程显示器?
写代码已经十个年头了, 一直都是习惯直接用一台Mac电脑写代码 偶尔接一个显示器, 但是可能因为公司配的显示器不怎么样, 还要接转接头 搞得桌面杂乱无章,分辨率也低,感觉屏幕还是Mac自带的看着舒服
|
4天前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1540 5
|
1月前
|
弹性计算 人工智能 架构师
阿里云携手Altair共拓云上工业仿真新机遇
2024年9月12日,「2024 Altair 技术大会杭州站」成功召开,阿里云弹性计算产品运营与生态负责人何川,与Altair中国技术总监赵阳在会上联合发布了最新的“云上CAE一体机”。
阿里云携手Altair共拓云上工业仿真新机遇
|
7天前
|
人工智能 Rust Java
10月更文挑战赛火热启动,坚持热爱坚持创作!
开发者社区10月更文挑战,寻找热爱技术内容创作的你,欢迎来创作!
578 22
|
4天前
|
存储 SQL 关系型数据库
彻底搞懂InnoDB的MVCC多版本并发控制
本文详细介绍了InnoDB存储引擎中的两种并发控制方法:MVCC(多版本并发控制)和LBCC(基于锁的并发控制)。MVCC通过记录版本信息和使用快照读取机制,实现了高并发下的读写操作,而LBCC则通过加锁机制控制并发访问。文章深入探讨了MVCC的工作原理,包括插入、删除、修改流程及查询过程中的快照读取机制。通过多个案例演示了不同隔离级别下MVCC的具体表现,并解释了事务ID的分配和管理方式。最后,对比了四种隔离级别的性能特点,帮助读者理解如何根据具体需求选择合适的隔离级别以优化数据库性能。
201 3
|
10天前
|
JSON 自然语言处理 数据管理
阿里云百炼产品月刊【2024年9月】
阿里云百炼产品月刊【2024年9月】,涵盖本月产品和功能发布、活动,应用实践等内容,帮助您快速了解阿里云百炼产品的最新动态。
阿里云百炼产品月刊【2024年9月】
|
10天前
|
Linux 虚拟化 开发者
一键将CentOs的yum源更换为国内阿里yum源
一键将CentOs的yum源更换为国内阿里yum源
578 5
|
23天前
|
存储 关系型数据库 分布式数据库
GraphRAG:基于PolarDB+通义千问+LangChain的知识图谱+大模型最佳实践
本文介绍了如何使用PolarDB、通义千问和LangChain搭建GraphRAG系统,结合知识图谱和向量检索提升问答质量。通过实例展示了单独使用向量检索和图检索的局限性,并通过图+向量联合搜索增强了问答准确性。PolarDB支持AGE图引擎和pgvector插件,实现图数据和向量数据的统一存储与检索,提升了RAG系统的性能和效果。
|
6天前
|
XML 安全 Java
【Maven】依赖管理,Maven仓库,Maven核心功能
【Maven】依赖管理,Maven仓库,Maven核心功能
233 3
|
9天前
|
存储 人工智能 搜索推荐
数据治理,是时候打破刻板印象了
瓴羊智能数据建设与治理产品Datapin全面升级,可演进扩展的数据架构体系为企业数据治理预留发展空间,推出敏捷版用以解决企业数据量不大但需构建数据的场景问题,基于大模型打造的DataAgent更是为企业用好数据资产提供了便利。
327 2