利用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

表4。 最大吞吐量的示例配置。

这与每个模型的批处理大小和并发值相同。 通过调整，使用不同的批处理大小和并发值来最大化吞吐量，内存和GPU利用率会有更高的变化，从而节省更多的资源。 此外，如果您的系统可以牺牲一些吞吐量，您可以使用更少的硬件，只需占用内存或GPU利用率的100。

进一步用例：自动调度

虽然这两个案例研究显示了优化系统运行的手工操作，但最有可能的用例是将这些数据自动纳入调度。 调度规则将放在计算需求之上，例如在模型运行时不要使用超过80%的GPU或80%的GPU内存。 这样的规则是你的模式，模型的使用计算元数据收集。

有了计算机需求，您就可以确定什么对您最重要，并从硬件中获得最大的性能。

结局推论

使用Triton Server工具Model Analyzer，您可以轻松高效地描述您的模型，使您能够最大限度地提高硬件的性能。 无论您使用命令行接口、Docker容器还是Helm图表，ModelAnalyzer都会收集模型的计算需求，允许您最大化性能并最小化运行模型所需的硬件。

正如将9个GPU减少到4个或6个GPU的案例研究所显示的，将这些数据合并到您的调度中是非常强大的。 对数据的进一步探索提供了对批处理大小和并发如何影响模型的洞察，使您能够使用Triton Server以最大的性能运行模型。

Model Analyzer 是开源的，在GitHub上可用。

关于作者

关于大卫·亚斯特雷姆斯基
大卫·亚斯特雷姆斯基是NVIDIA的软件实习生，从事克拉拉部署工作。 他是一名硕士学位学生，在宾夕法尼亚大学学习计算机科学，对医疗AI充满热情，未来人人都能获得高质量的医疗保健。

审核编辑 黄昊宇