zerone_nasa
4月底的时候，RiseML发表了一篇文章对TPUv2 和 Nvidia V100进行了对比，这是迄今为止TPUv2和V100芯片之间最为彻底的比较。原文译文如下：
Google最近在其云产品中新增了一种定制开发的微型芯片——TPUv2，用于加快深度学习。TPUv2是该芯片的第二代产品，也是第一款公开上市的深度学习加速器，有望成为Nvidia GPU的替代品。我们最近报告了对该产品的第一次体验，并收到了许多请求，希望能与Nvidia V100 GPU进行更详细的比较。
对深度学习加速器展开一个均衡且有意义的对比并非易事。考虑到未来这类产品的重要性以及当前缺乏详细对比，我们认为有必要自己进行一个比较。这还包括倾听可能与我们意见相左一方的意见，所以我们一早就分别联系了谷歌和Nvidia的工程师，让他们就本文的草稿发表意见。为了保证不会偏袒任何一方，我们还邀请了独立专家来审查这篇文章。据我们所知，这是迄今为止TPUv2和V100芯片之间最为彻底的比较。
实验方案
接下来，我们将四个TPUv2芯片（即一个云TPU）和四个Nvidia V100 GPU进行比较。两者的内存都为64GB，因此可以训练相同的型号，使用相同的批量。在实验中，我们还以同样的方式训练模型:云TPU上的四个TPUv2芯片进行一种同步数据并行分布式的训练，如同四个V100所做的一样。
至于模型，我们决定在ImageNet上使用ResNet-50——一种用于图像分类的事实标准和参考点。ResNet-50的参考实现是对外开放的，但目前没有一个实现可以同时支持云TPU和多个GPU上的训练。
对于V100，Nvidia建议我们使用MXNet或TensorFlow实现，这两种实现都能在Nvidia GPU云上的Docker映像中找到。然而，我们发现这两种实现在具有多个GPU和由此产生的大批量的情况下无法很好地快速融合。因此需要做出调整，尤其是在学习率计划方面。
相反，我们使用了来自TensorFlow基准存储库的ResNet-50实现，并在Docker映像中运行它( TensorFlow / TensorFlow : 1 . 7 . 0 - GPU、CUDA 9.0、CuDNN 7 . 1 . 2 )。它比Nvidia推荐的TensorFlow实现要快得多，而且只比MXNet实现略慢一点(约3 %，见下文)。并且，它融合得很好。这样做还有一个另外的好处，那就是可以在相同的版本( TensorFlow 1 . 7 . 0 )中比较同一框架中的两个实现。
对于云TPU，Google建议我们使用来自TensorFlow 1.7.0官方TPU存储库的bfloa 16实现。TPU和GPU实现都在各自的体系结构上使用混合精度计算，并以半精度存储大部分张量。
在V100实验中，我们用4个V100 GPU（每个GPU内存为16GB）在AWS上进行了一个p3.8 xlarge实例( Xeon E5–2670 @ 2.30 GHz 16核，244 GB内存，Ubuntu 16.04 )。在TPU实验中，我们使用小型n1 - standard - 4实例作为主机( Xeon @ 2.3 GHz双核、15gb内存、Debian 9 )，为其配置了一个由4个TPUv2芯片组成的云TPU (每个芯片内存为16GB)。
我们做了两个不同的比较。首先，分别从合成数据的吞吐量以及不增强数据情况下的吞吐量(每秒映像数)来看原始性能。这种比较独立于收敛性，并确保I / O中的瓶颈或数据增强不会影响结果。在第二个比较中，我们将介绍ImageNet上两种实现的精度和收敛性。
吞吐量结果
我们利用合成数据上的每秒图像来计算吞吐量，即使用动态创建的训练数据，计算不同批量的吞吐量。请注意，TPU的唯一推荐批量型号是1024型，但根据大量读者的要求，我们还汇报了其他批量的性能。
上图为合成数据和w / o数据增强的不同批量下每秒图像的性能。批量型号是“通用的”，例如1024表示在每个步骤中每个GPU / TPU芯片上的256批量。
批量大小为1024时，吞吐量几乎没有差别！TPU以大约2 %的差距领先。较小的批量导致两个平台上吞吐量的下降，GPU在这方面表现略好一些。但是如上所述，这些批量目前并不是TPU的推荐设置。
根据Nvidia的建议，我们还在MXNet上进行了一个使用GPU的实验。我们使用了Nvidia GPU云上Docker映像( mxnet : 18.03 - py3 )中提供的ResNet-50实现。当批量大小为768 ( 1024太大)时，GPU的处理速度约为每秒3280张图像。这比上述最佳TPU结果约快了3 %。然而，如上所述，MXNet实现在此批量的多个GPU上并不能很好地融合，这也是我们在此以及接下来都非常关注TensorFlow的原因。
基于云价格的成本
目前，云TPU (四个TPUv2芯片)仅能从Google云中获取。只有在需要计算时，它才可以按需附加到任何VM实例。我们考虑为V100提供的云产品来自AWS ( Google云尚不能提供V100)。基于以上结果，我们可以将相应平台和提供商每美元每秒的图像数标准化。
每美元每秒的图像性能
以这种定价来看，云TPU无疑是一个赢家。但是，如果考虑长期租赁或购买硬件(尽管目前这不是云TPU的选项)，情况可能会有所不同。上图中，我们还包括了在AWS上租用12个月p3.8 xlarge预留实例的价格(无需提前付款)。这大大降低了价格，导致每美元（生成）375张图像/秒。
对于GPU，除了购买之外，还有可以考虑其他有趣的选项。例如，Cirrascale提供月租服务，价格约为7.5千美元(约每小时10.3美元)，每台服务器有4个V100 GPU。但是，由于硬件不同于AWS ( CPU类型、内存、NVLink支持等)，因此需要进一步的基准测试来进行直接比较。
精度和收敛性
除了报告原始性能之外，我们还希望验证计算实际上是“有意义的”，即实现融合到良好的结果。由于我们比较了两种不同的实现方式，所以可能会存在一些偏差。因此，我们的对比不仅包括衡量硬件速度，还包括衡量实现质量。例如，TPU实现应用了最佳计算密集型的图像预处理步骤，实际上牺牲了原始吞吐量。根据Google预测，这是一种预期行为，而且正如我们将在下文看到的那样，这样做是有代价的。
我们在ImageNet数据集上训练这些模型，任务是将图像分为1000个类别，如蜂鸟、墨西哥卷饼或比萨饼。数据集由大约130万个用于培训的映像(约142 GB )和5万个用于验证的映像(约7GB )组成。
我们对90个epoch进行了1024批量的培训，并对验证数据的结果进行了比较。TPU实现处理的图像大约始终为每秒2796个，GPU实现约为每秒 2839个。这与上面的吞吐量结果不同，此前计算吞吐量时我们禁用了数据增强，并使用合成数据来比较TPU和GPU的原始速度。
90个epoch之后两种实现方式的最高精度(即，仅考虑对每个图像具有最高置信度的预测)。
如上所示，TPU实现90个epoch后的最高精度提升了0.7 %。虽然这种提升看起来可能很小，但在这个已经非常高的水平上进行改进是极困难的，而且取决于不同的应用，这种小进步最终可能产生很大的不同。让我们来看看模型学习过程中不同时期的最高精度。
两种实现验证集的最高精度上图中的急剧变化与学习率的变化一致。TPU实现的收敛性能较好，在86个epoch后最终精度达到76.4 %。GPU实现落后一点，84个epoch之后最终精度达到75.7 %，而TPU实现只需64个epoch即可达到这一精度。TPU的收敛性得到改善可能是预处理和数据增强变得更好的结果，但还需要进一步的实验来证实这一点。
基于云定价的解决方案成本
最终来说，真正重要的是达到一定精度所需的时间和成本。如果我们假定的可接受解决方案为75.7 %( GPU实现的最佳精度)，我们可以基于所需的epoch和每秒图像的训练速度来计算实现该精度的成本。这不包括评估epoch和训练启动时间之间模型的时间。Cost to reach 75.7% top-1 accuracy. *reserved for 12 months达到最高精度75.7 %的所需成本（保留12个月）
如上所示，云TPU当前的定价可以让它以55美元的价格在ImageNet上将一个模型从零训练到75.7 %，而所需时间9小时不到！将收敛性培训到76.4 %的费用为73美元。尽管V100的运行速度类似，但其较高的价格和实现结果较慢的收敛速度会导致相当高的解决方案成本。请再次注意，这种比较取决于实现的质量以及云定价。另一个有趣的对比将基于功耗。然而，我们目前还没有任何关于TPUv2功耗的公开信息。
小结
就ResNet -50的原始性能而言，四个TPUv2芯片(一个云TPU )和四个V100 GPU在我们的基准测试中速度相当(彼此相差不到2 % )。我们可能会看到软件(例如TensorFlow或CUDA )的进一步优化，这些优化可以提高性能并改变这种情况。
然而，在实践中最重要的往往是在某个问题实例上达到某个精度所需的时间和成本。云TPU目前的定价，加上ResNet -50的世界级实现，在ImageNet上实现了令人印象深刻的时间和精度成本——使我们能够以大约73美元的价格将模型的精度训练到76.4 %。
未来，我们需要对来自其他域和具有不同网络体系结构的模型进行基准测试，以提供进一步的见解。另一个还需要考虑的有趣问题是，如何有效地利用特定的硬件平台。例如，混合精度计算带来了很大的性能提升，但其在GPU和TPU上的实现和行为不同。
感谢汉娜·巴斯特( Hannah Bast，弗赖堡大学)、大卫·安德森(David Andersen，卡内基梅隆大学)、蒂姆·德特默（Tim Dettmers）和马蒂亚斯·迈耶（Mathias Meyer）对本文草稿的阅读。
