利用NVIDIA模型分析仪最大限度地提高深度学习的推理性能-电子发烧友网

你已经建立了你的深度学习推理模型并将它们部署到 NVIDIA Triton Inference Serve 最大化模型性能。你如何进一步加快你的模型的运行速度？进入 NVIDIA模型分析器，一个收集模型计算需求的工具。

没有这些信息，在理解在GPU上运行多少模型方面就存在知识差距。通过收集冷热储存需求，您可以使用它们通知模型的调度，以获得几个好处：

最大化模型吞吐量—确保放置在每个GPU上的模型总和不超过可用内存和GPU利用率的特定阈值，例如100%。这样可以最大限度地提高硬件的吞吐量。

优化硬件使用—检查GPU内存需求，以便在较少硬件上运行更多型号。您可以使用此数据来确定每个GPU可以加载的最大模型数，而不是优化吞吐量，从而减少所需的硬件，或者权衡吞吐量的权衡。

提高了可靠性—通过了解在GPU上加载的模型不会超出其能力，消除内存不足错误。

此外，还有两个关键的非调度好处：

有效的模式—比较和对比不同的模型，将计算需求作为一个额外的数据点来衡量模型的性能。这有助于生成更轻量级的模型，并减少推理所需的内存量。

更好的硬件尺寸—使用内存需求确定运行模型所需的确切硬件数量。

总之，理解推理模型的计算要求提供了从模型创建和硬件大小到模型的可靠、高效运行的大量好处。下面我们来看看ModelAnalyzer，看看它如何为最高性能的推理解决方案做出贡献。

获取模型分析器Docker容器

在使用推理服务器容器之前，必须安装一些软件，如Docker。有关更多信息，请参见安装Docker和NVIDIA Docke 一节进去 NVIDIA Docker：GPU服务器应用程序部署容易.

模型分析器作为Helm图表、Docker容器或独立命令行接口运行。对于本教程，您可以从源代码the构建Docker容器 triton-inference-server/model_analyzer Github回购。

git clone https://github.com/triton-inference-server/model_analyzer.git
cd model_analyzer
docker build -t memory-analyzer

要为您的模型运行容器，请确保端口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 /
memory-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 /
memory-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或仅运行模型分析器的系统上运行它是理想的。

使用计算需求进行优化

下面是如何使用这些度量来优化系统性能。我们讨论了两个使用医学推断模型的案例研究：

第一个案例研究探讨了如何将间歇性运行的系统的硬件最小化，例如需要在最小硬件上运行许多模型的低成本医疗提供商。

第二个案例研究探讨了使用最少的硬件来最大化这些相同模型的吞吐量，例如在一致的基础上运行许多模型的大型急诊室。

这两个案例研究都是手动完成这些步骤的，因此我们最后讨论了将模型元数据纳入自动调度的下一步。对于这两项研究，为了简化分析，我们使用总结的数据，对每个模型使用2的模型批处理大小和4的并发。

马克斯记忆用法（%）	马克斯GPU使用（%）	最大GPU内存(MB)
0	9	309

表1。只运行TritonServer的内存使用。

Model	Batch		流率	马克斯记忆用法（%）	马克斯GPU使用（%）	最大GPU内存(MB)
classification_breast	2	4	1381.6推断/秒	1	23	1461
classification_chest	2	4	172.4推断/秒	11	56	5035
分类_玛利亚	2	4	586推断/秒	2	43	1851
节段_CT_Colon_Tumo	2	4	33.6推断/秒	60	60	6955
segmentation_ct_胰腺	2	4	29.6推断/秒	51	79	6955
节段_CT_脾	2	4	32推断/秒	54	54	6955
肝段	2	4	28推断/秒	53	76	11051
分段_MRI_脑_肿瘤	2	4	4推断/秒	48	48	8579
分段_MRI_海马	2	4	30.8推断/秒	52	52	6955

表2。每个运行模型的内存使用情况。

通常，有几种潜在的方法：

每个GPU放置一个模型。这意味着这9种型号的9个GPU。例如，如果要在DGX上运行，这种方法将需要两个不能充分利用的DGX。

把所有的模型放在一个GPU上。这只需要一个GPU，但会导致“内存不足”错误。

在每个GPU上放置任意数量的模型。这涉及到以前方法的问题。如果每个GPU放置两个模型，则只需要5个GPU。然而，记忆错误仍然是一个风险，例如，如果你把肝脏分割和脑肿瘤分割模型放在一个GPU上。同时，其他GPU没有得到充分或最佳的利用，例如当您将乳房和胸部x射线分类放在一个GPU上时。

另一种选择是什么？

案例研究：尽量减少间歇系统的硬件

想象一下，你有一个系统，你知道它只会断断续续地出现，所以你想在最少的硬件上安装尽可能多的模型。在这种情况下，GPU内存是瓶颈。您可以为Triton Server减去309MB的内存，以单独获得模型的GPU内存，然后查看在GPU上的一个服务器上可以容纳多少模型。

表3显示，可以匹配的模型只使用四个16GB GPU与以下配置，这协调了最小的GPU可能为这些模型，需要53GB的内存。

GPU #	模特儿典型	带有服务器的GPU内存(MB
1	分类_胸部，节段_CT_结肠_肿瘤	11681
2	classification_breast，segmentation_live	12203
3	分类_疟疾，节段_MRI_海马，节段_CT_脾	15143
4	节段_CT_胰腺，节段_MRI_脑_肿瘤	15225

表3。最小硬件的示例配置。

使用这种配置，您的GPU数量最少，同时保证没有内存错误。这是一个很好的设置，用于间歇性地运行模型，当吞吐量不需要达到最大值时。

案例研究：最大限度地提高一致的、关键的系统的性能

对于此设置，最大吞吐量是优先级，因此必须确保吞吐量不会因为所有模式的并发负载而下降。查看所有指标，以确保内存利用率、GPU利用率和GPU内存总量不超过机器的计算资源。

As total GPU utilization adds up to 491% and would therefore require a minimum of five GPUs, compared to total memory utilization (332%, or four GPUs) or total GPU memory (52 GB, or four GPUs), GPU utilization is the bottleneck and a great place to start.

表4假设GPU利用率阈值为100%，并显示了一个只有6个16GB GPU的示例配置。

GPU #	模特儿典型	内存使用（%）	GPU使用（%）	带有服务器的GPU内存(MB
1	节段_CT_Colon_Tumo	60	60	6955
2	肝段	54	76	11051
3	classification_chest，classification_breast	12	79	2939
4	segmentation_ct_pancreas	51	79	6955
5	级化_级，细分_级	56	97	8497
6	Segmentation_MRI_海马，segmentation_mri_brain_tumo	100	100	15225