使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

阅读数:21 2019 年 11 月 11 日 08:00

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

作者:Iris Fu 和 Cambron Carter

这是一篇由工程总监 Cambron Carter 和 GumGum 的计算机视觉科学家 Iris Fu 联合发布的访客文章。用他们自己的话说,“GumGum 是一家在计算机视觉领域具有深厚专业知识的人工智能公司,能帮助客户充分发挥网络、社交媒体及广播电视每天生产的图像和视频的价值。”

目标物检测的最新技术

检测是许多经典计算机视觉问题之一,已随着卷积神经网络 (CNN) 的采用而得到显著改善。随着 CNN 越来越多地用于图像分类,许多人都依靠粗糙和昂贵的预处理程序来生成候选区域 (region proposal)。通过诸如“选择性搜索”之类的算法根据区域的“客体性”(它们包含目标物的可能性) 生成候选区域,这些区域随后被馈送到训练用于分类的 CNN。虽然这种方法能得到准确结果,但需要很高的运行成本。Faster R-CNN,You Only Look Once (YOLO) 和 Single Shot MultiBox Detector (SSD) 等 CNN 架构通过将定位任务嵌入到网络中来折中解决该问题。

除了预测等级和置信度,这些 CNN 还尝试预测包含某些目标物的区域极值。在本文中,这些极值只是矩形的四个角点,通常称为边界框。先前提到的检测架构需要已经用边界框注释的训练数据,即,该图像包含一个人,而且此人在该矩形区域内。以下是分类训练数据和检测训练数据:
使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试
超级帅气又非常能干的工程师

我们开始对使用 Apache MXNet 和 Caffe 来训练 SSD 的体验进行比较。明显动机是以分布式方式训练这些新架构,而不降低准确性。有关架构的更多信息,请参阅“ SSD: Single Shot MultiBox Detector”

训练工具

对于这组实验,我们尝试了几款 NVIDIA GPU:Titan X、1080、K80 和 K520。我们使用 Titan X 和 1080 在内部进行了几次实验,但也使用了基于 AWS GPU 的 EC2 实例。此帖子仅限于 g2.2x 和 p2.8x 实例类型。幸运的是,我们已经有一些使用 MXNet 的可用 SSD 实施方案,例如这个,在此次讨论的实验中我们就使用了这个实施方案。值得注意的是,为了使实验更详尽,您应该将其他常见框架 (如 TensorFlow) 的基准测试数据也包含在内。

速度:使用 MXNet 调整批处理大小和 GPU 计数的影响

首先,我们来看看使用 MXNet 的多 GPU 训练会话的性能影响。前几个实验侧重于在 EC2 实例上使用 MXNet 对 SSD 进行训练。我们使用 PASCAL VOC 2012 数据集。这第一个练习的目的是了解 GPU 计数和批处理大小对特定 GPU 速度的影响。我们使用了几种不同的 GPU 来说明它们的绝对性能差异。如果您想进一步探索,还可了解有关不同 GPU 的价格和性能的许多信息。让我们从 g2.2x 实例附带的 K520 开始:

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试
请注意,在批处理大小不变的情况下,添加额外的 g2.2x 实例 (每个实例一个 K520) 会使每台机器有大致恒定的速度。因此,每小时的训练周期数几乎呈线性增加。添加机器应该能继续缩短运行时间,但在某一点上可能会影响准确性。我们不在此处探讨这种情况,但需要提一下。

然后,我们想看看在本地 1080 上是否观察到这一趋势:

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

如预期的一样,一个 1080 轻松胜过五个 K520。除了发现的这个情况外,该实验也引起了一些人的质疑。我们发现在组合中再加入一个 1080 时,每个 GPU 的速度会大大降低。由于本实验中的进程间通信通过以太网进行,因此一开始我们认为自己受到了办公网络的限制。但根据 Iperf 数据,该假设并不成立:

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

我们的测试表明,我们办公网络中的带宽和传输量都高于两个 EC2 实例之间的这两个值。这就引出了我们的下一个问题:如果批处理大小是导致效率低下的原因怎么办?

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

啊哈!虽然仍比使用一个 1080 慢得多,但在增加一个 1080 (在单独的机器上) 的同时增加批处理大小可提高速度。我们来看一下训练对具有多个互连 GPU 的机器的影响:

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试
我们使用了自己的内部 NVIDIA DevBox,其中包含四个 Titan X。保持批处理大小不变,但增加 GPU 数量 (技术上减少每个 GPU 的单个批处理大小),可将速度提高大约 2.5 倍!这就引出了一个显而易见的问题:如果我们增加每个 GPU 的批处理大小会怎样?

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

我们观察到,当我们保持批处理大小恒定 (16),并增加同一机器上的 GPU 数量时,最终速度也会提高大约 2 倍。我们本想进一步探索,但 DevBox 风扇嗡嗡作响,让我们无法再增加批处理大小。我们 1080 实验的奇案仍然无解,作为一个悬而未决的问题而为人所知。AWS 的潜在解决方案可能是使用放置组,在本文中我们不探讨此方案。

准确性:使用 MXNet 调整批处理大小的影响

由于我们花那么精力来调整批处理大小,因此值得探讨一下调整批处理大小如何影响准确性。目标很简单:我们希望在保持准确性的同时尽可能地缩短训练时间。我们在用于徽标检测的内部数据集中进行了这组实验。我们使用 MXNet 在一个 p2.8x large 实例上开展这些实验。如果检测区域和地面实测区域之间的交并比为 20% 或更高,则我们认为检测是正确的。首先,我们尝试了批处理大小 8:

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

训练的三个不同阶段的查准率查全率曲线。SSD 使用 300×300 像素的输入尺寸,批处理大小为 8。

如果我们同等地对查准率和查全率进行加权,就会得到大约 65% 的查准率和查全率。让我们看看使用 MXNet 调整 SSD 中的输入尺寸时会发生什么:

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

SSD 使用的输入尺寸为 512×512 像素,其他所有数据均与上一个实验相同。

此时,我们实际上看到性能有所改善,查准率和查全率均为 70% 左右。输入尺寸仍为 512×512 像素,我们来研究一下调整批处理大小对准确性有何影响。同样,我们的目标是保持准确性,同时尽可能缩短运行时间。

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

SSD 使用的输入尺寸为 512×512 像素,批处理大小为 64。准确性与之前的实验不差上下。

再试一次!准确性保持一致,我们可以通过更大的批处理大小来缩短训练时间,从而从中获益。本着科学的精神,让我们进一步深入实验…

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

SSD 使用的输入尺寸为 512×512 像素,批处理大小为 192。准确性与之前的实验不差上下。

基本相同,虽然我们的操作准确性与上一曲线相比有所下降。尽管如此,我们成功地保持了准确性,同时将批处理大小增加了 24 倍。重申一下,每个实验都是使用 MXNet 在实施了 SSD 的 p2.8x large 实例上进行的。下面是批处理大小实验的总结,显示了各个实验不差上下的准确性:

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

MXNet 的 SSD 与使用 Caffe 训练的 SSD 一样准确。

要点是准确性不差上下。言归正传,我们来研究一下训练时间:

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

使用多种批处理大小的 Caffe 和 MXNet 的训练时间汇总。

当批处理大小增加时,预计减少的训练时间是显而易见的。不过,为什么我们在 Caffe 中增加批处理大小时,训练时间会大幅增加?我们来看看这两个 Caffe 实验的 nvidia-smi:

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

使用 Caffe 训练时 nvidia-smi 的输出,使用的批处理大小 8。请注意 GPU 使用率的波动。

GPU 要处理反向传播的巨大计算开销,这通过使用率峰值反应出来。为什么使用率会波动?可能是因为需要将训练数据从 CPU 批量传输到 GPU。在这种情况下,当 GPU 等待下一个批处理加载时,使用率将下降为 0%。我们来看看将批处理大小增加为 16 后的使用率:

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

使用 Caffe 训练时 nvidia-smi 的输出,使用的批处理大小 16。

使用率停滞的情况更为夸张,揭示出显而易见的低效率。这解释了为什么增加批处理大小后训练时间反而增加的现象。这并不新鲜或出乎意料。事实上,我们使用 Keras (和 TensorFlow 后端) 训练 Siamese-VGG 网络时,也遇到过这个问题。关于这个话题的讨论通常倾向于“您的模型越复杂,您能感知到的 CPU 到 GPU 的瓶颈就越少。”虽然这是事实,但并没有多大帮助。是的,如果您通过增加计算梯度的方式让 GPU 承担更多工作,一定会看到平均 GPU 利用率的增加。我们不想增加模型的复杂性,即使我们这样做了,也不是为了帮助我们实现总体目标。在这里,我们关注的是绝对运行时间,而不是相对运行时间。

如果对我们的实验加以总结,那就是使用 Caffe 的 SSD 训练时间远远多于使用 MXNet 的训练时间。使用 MXNet,我们观察到训练时间稳步减少,直至我们达到 192 这一批处理大小临界规模。仅通过采用 MXNet,我们就将训练时间从 21.5 小时缩短为 4.6 小时。与此同时我们没有发现准确性有所降低。这么说绝不是在攻击 Caffe – 它是我们非常看重的一个框架 – 而只是为了庆祝 MXNet 取得的成功。我们可以通过多种方式批评数据加载问题。也许 Caffe2 已经解决了这个问题。在这里我想说明的是我们并不需要这么做,如果有任何东西能够让机器学习开发人员感到暖心,那就是编写尽可能少的代码。虽然我们还有一些问题尚未得到解答,但这是采用新工具时的正常现象。我们很乐意被当做“实验豚鼠”,并且对 MXNet 的未来充满希望。

本文转载自 AWS 技术博客。

原文链接:
https://amazonaws-china.com/cn/blogs/china/benchmarking-training-time-for-cnn/

欲了解 AWS 的更多信息,请访问【AWS 技术专区】

评论

发布