您已经构建了深度学习推理模型,并将其部署到 NVIDIA Triton ®声波风廓线仪推理服务器 中,以最大限度地提高模型性能。如何进一步加快模型的运行速度?进入 NVIDIA Model Analyzer ,即将发布的工具,用于收集模型的计算需求。
如果没有这些信息,在理解一个 GPU 上运行多少个模型就有一个知识缺口。通过收集热存储和冷存储需求,您可以使用它们来通知模型的调度,从而获得以下几个好处:
- 最大化模型吞吐量 – 确保放置在每个 GPU 上的模型总和不超过可用内存和 GPU 利用率的某个阈值,例如 100% 。这将最大限度地提高硬件的吞吐量。
- 优化的硬件使用 – 检查 GPU 内存需求,以便在较少的硬件上运行更多的模型。您可以使用这些数据来确定每个 GPU 可以加载的模型的最大数量,而不是针对吞吐量进行优化,从而减少所需的硬件,或者权衡吞吐量。
- 提高可靠性 —知道您在 GPU 上加载的模型不会超出其功能,从而消除内存不足错误。
此外,还有两个关键的非日程安排好处:
- 有效模型 – 比较和对比不同的模型,将计算需求作为附加数据点,以了解模型的性能。这有助于生成更轻量级的模型,并减少推理所需的内存量。
- 更好的硬件尺寸 – 根据内存需求确定运行模型所需的确切硬件数量。
简言之,理解推理模型的计算需求提供了从模型创建和硬件大小调整到可靠、高效运行模型的一系列好处。下面我们来看看 Model Analyzer ,看看它如何为最大性能推断解决方案做出贡献。
获取 Model Analyzer Docker 容器
在使用推理服务器容器之前,必须安装一些软件,如 Docker 。有关详细信息,请参阅 NVIDIA Docker : GPU 服务器应用程序部署变得容易 中的 安装 Docker 和 NVIDIA Docker 部分。
ModelAnalyzer 以 Helm 图表、 Docker 容器或独立的命令行界面运行。这三种方法中的每一种都可以从 NVIDIA NGC 注册表中获得,并列出说明。模型分析器会定期更新,因此请确保获取文件的最新版本。
对于本教程,请使用 Docker 容器。您可以将容器拉到本地系统或使用任何 支持 NGC 容器的平台 。
docker pull nvcr.io/nvidia/clara/model-analyzer:latest
要运行模型的容器,请确保端口 8000 、 8001 和 8002 可用。然后,运行以下命令,替换大写参数:
docker run -v /var/run/docker.sock:/var/run/docker.sock \ -v /ABSOLUTE/PATH/TO/MODELS:ABSOLUTE/PATH/TO/MODELS \ -v /ABSOLUTE/PATH/TO/EXPORT/DIRECTORY:/results --net=host \ nvcr.io/nvidia/clara/model-analyzer:ANALYZER-VERSION \ --batch BATCH-SIZES \ --concurrency CONCURRENCY-VALUES \ --model-names MODEL-NAMES \ --triton-version TRITON-VERSION \ --model-folder /ABSOLUTE/PATH/TO/MODELS \ --export --export-path /results/
下面是一个示例命令,供参考:
docker run -v /var/run/docker.sock:/var/run/docker.sock \ -v /home/user/models: /home/user/models \ -v /home/user/results:/results --net=host \ nvcr.io/nvidia/clara/model-analyzer:latest \ --batch 1,2,4 \ --concurrency 1,2,4 \ --model-names chest_xray,covid19_xray\ --triton-version 20.02-py3 \ --model-folder /home/user/models \ --export --export-path /results/
当容器完成时,将为每个模型、批大小和并发值将度量导出到您选择的目录中。这些信息是在系统运行时通过收集系统上的指标来收集的,因此最好是在一个独立的 GPU 或仅运行 Model Analyzer 的系统上运行它。
使用计算需求进行优化
下面是如何使用这些指标来优化系统性能。我们使用医学推理模型讨论两个案例研究:
- 第一个案例研究探讨了如何最小化间歇性运行的系统的硬件,例如需要在最小硬件上运行许多模型的低预算医疗提供商。
- 第二个案例研究探讨了使用最少的硬件来最大限度地提高这些模型的吞吐量,例如一个大型急诊室,在一致的基础上运行许多模型。
这两个案例研究都是手动完成这些步骤的,因此我们最后讨论将模型元数据合并到自动调度中的下一个步骤。对于这两个研究,为了简化分析,我们使用总结的数据,对每个模型使用 2 的模型批大小和 4 的并发性。
Max Memory Utilization (%) | Max GPU Utilization (%) | Max GPU Memory (MB) |
0 | 9 | 309 |
Model | Batch | Concurrency | Throughput | Max Memory Utilization (%) | Max GPU Utilization (%) | Max GPU Memory (MB) |
classification_breast | 2 | 4 | 1381.6 infer/sec | 1 | 23 | 1461 |
classification_chest | 2 | 4 | 172.4 infer/sec | 11 | 56 | 5035 |
classification_malaria | 2 | 4 | 586 infer/sec | 2 | 43 | 1851 |
segmentation_ct_colon_tumor | 2 | 4 | 33.6 infer/sec | 60 | 60 | 6955 |
segmentation_ct_ pancreas | 2 | 4 | 29.6 infer/sec | 51 | 79 | 6955 |
segmentation_ct_ spleen | 2 | 4 | 32 infer/sec | 54 | 54 | 6955 |
segmentation_liver | 2 | 4 | 28 infer/sec | 53 | 76 | 11051 |
segmentation_mri_ brain_tumor | 2 | 4 | 4 infer/sec | 48 | 48 | 8579 |
segmentation_mri_ hippocampus | 2 | 4 | 30.8 infer/sec | 52 | 52 | 6955 |
通常,有几种可能的方法:
- 根据 GPU 放置一个模型。对于这九款车型,这 9 款车型的售价为 9 GPUs 。例如,如果要在 DGXs 上运行这些,这种方法将需要两个 dgx ,而这两个 dgx 将无法充分利用。
- 将所有模型放在一个 GPU 上。这只需要一个 GPU ,但会导致“内存不足”错误。
- 在每个 GPU 上放置任意数量的模型。这就遇到了以前方法的问题。如果你在每个 GPU 上放两个模型,你只需要五个 GPUs 。然而,记忆错误仍然是一个风险,例如,如果你把肝脏分割和脑瘤分割模型放在一个 GPU 上。同时,其他的 GPUs 没有得到充分或最佳的利用,例如当你把乳房和胸部 x 光分类放在一个 GPU 上时。
还有什么选择?
案例研究:最小化间歇系统的硬件
假设您有一个系统,您知道它只能间歇性地启动,所以您希望在最少的硬件上安装尽可能多的型号。在这种情况下, GPU 内存是瓶颈。您可以减去 Triton Server 的 309 MB 内存,仅获得模型的 GPU 内存,然后查看 GPU 上一台服务器上可以容纳多少个型号。
表 3 显示,这些型号可以匹配到只使用四个 16GB 的 GPUs ,配置如下,这就为这些需要 53GB 内存的机型提供了最少的 GPUs 。
GPU # | Models | Total GPU Memory (MB) With Server |
1 | classification_chest, segmentation_ct_colon_tumor | 11681 |
2 | classification_breast, segmentation_liver | 12203 |
3 | classification_malaria, segmentation_mri_hippocampus, segmentation_ct_spleen | 15143 |
4 | segmentation_ct_pancreas , segmentation_mri_brain_tumor | 15225 |
有了这个配置,您的 GPUs 数量最少,同时保证没有内存错误。当吞吐量不需要达到最大时,这是间歇运行模型的良好设置。
案例研究:使一致的关键系统的性能最大化
对于这个设置,最大吞吐量是优先级,所以您必须确保吞吐量不会因为所有模式上的并发负载而下降。查看所有指标,以确保内存利用率, GPU 利用率和总 GPU 内存不会超过计算机的计算资源。
由于总的 GPU 利用率加起来高达 491% ,因此与总内存利用率( 332% ,即 4 个 GPU )或总 GPU 内存( 52gb ,或 4 个 GPU )相比,至少需要 5 个 GPUs ,因此 GPU 利用率是瓶颈,也是一个很好的起点。
表 4 假设 GPU 的利用率阈值为 100% ,并显示了一个只有 6 个 16-GB GPUs 的配置示例。
GPU # | Models | Memory Utilization (%) | GPU Utilization (%) | Total GPU Memory (MB) With Server |
1 | segmentation_ct_colon_tumor | 60 | 60 | 6955 |
2 | segmentation_liver | 54 | 76 | 11051 |
3 | classification_chest, classification_breast | 12 | 79 | 2939 |
4 | segmentation_ct_pancreas | 51 | 79 | 6955 |
5 | classification_malaria, segmentation_ct_spleen | 56 | 97 | 8497 |
6 | segmentation_mri_hippocampus, segmentation_mri_brain_tumor | 100 | 100 | 15225 |
这对于每个模型来说都具有相同的批处理大小和并发性值。通过调整以使用不同的批处理大小和并发值来最大化吞吐量,内存和 GPU 利用率将有更大的变化,从而实现更大的节省。此外,如果您的系统可以牺牲一些吞吐量,那么您可以使用略高于 100% 的内存或 GPU 利用率来使用更少的硬件。
进一步的用例:自动调度
虽然这两个案例研究显示了优化系统运行的手动努力,但最有可能的用例是将这些数据自动纳入调度中。调度规则将放在计算需求之上,比如在模型运行时,使用的 GPU 或 GPU 内存的 80% 以上。这些规则是你自己塑造的,模型计算元数据的使用也是如此。
有了计算机需求,您就可以确定什么对您最重要,并从您的硬件中获得最佳性能。
结论
使用即将推出的 Triton ®声波风廓线仪服务器工具,模型分析仪,您可以轻松高效地描述模型,从而最大限度地提高硬件性能。无论您使用命令行界面、 Docker 容器还是 Helm chart , Model Analyzer 都会收集模型的计算需求,从而最大限度地提高性能并最小化运行模型所需的硬件。
正如将 9 个 GPUs 减少到 4 个或 6 个 GPUs 的案例研究所示,将这些数据整合到您的调度中是非常强大的。对数据的进一步探索将深入了解批处理大小和并发性如何影响模型,使您能够使用 Triton Server 以最大的性能运行模型。
计划于 2020 年 9 月下旬发布, NVIDIA Clara 部署 7 . 2 。