Question

本来准备今天开始写 Caffe 代码阅读的第三部分的，结果找到了一片介绍 GPU 通信的文章，觉得这篇文章的内容讲得非常好，而这方面的背景知识也是非常缺乏的，另外 Caffe 多卡训练的一些细节和这里面的知识也有关系，所以今天就来翻译一下这篇文章。

当然了，翻译之前先扯一段。读大学的时候我曾经报名过一节英文翻译课，当时教过我的一些具体的翻译小技巧我已经忘光了，但是有一段话我还记得，那就是翻译的三个目标 - 信、达、雅。翻译首先要准确，然后要通顺，最后要能做到优美那就再好不过了。这里不免想吐槽一下一些文章翻译，在达的方面做得实在不够好，我都可以从中文翻译中读出原文定语从句的味道……我个人希望自己能做到达，最后不需要做到雅，做到俗也是极好的。

文章出处： http://exxactcorp.com/blog/exploring-the-complexities-of-pcie-connectivity-and-peer-to-peer-communication/

这篇文章我们来深入地看看 PCI-E 总线上数据通信方面存在的一些瓶颈，以及我们 Exxact 公司最新的牛逼系统是如何搞定这些问题，使得像机器学习这样严重依赖 GPU 的工作可以轻松点。

传统套路

PCI-E 是个啥本文是没有兴趣给你讲的，我们直接来谈谈以它为主线的架构，以及架构的优势和劣势（主要是劣势）。在此之前，我们首先要明白一件事，那就是为啥 PCI-E 总线的数据传输速度是十分重要的。在 GPU 计算革命到来之前，PCI 总线主要是用于和磁盘做数据通信，或者计算机结点间通信的（HPC 小红人 infiniband）。一个经典的 PCI-E 总线架构图就长成这个样子：

以前这个架构用得很好没问题，但后来 GPU 计算时代来临，我们搞 GPU 计算的朋友开始有了新的诉求，我们希望主存数据和 GPU 显存的数据传输能够尽量快点，于是乎，传统设计就暴露出了三个问题：

1. GPU 被分在了两个区域中，就像上面的图片，它们分别被不同的 MCH（Memory Controller Hub）控制，连接在不同的 CPU 数据接口上。然后，不同区域的 CPU 在通过一个叫 QPI 的东西连接起来，以保证不同区域的数据也能够通信。当然这样只能说解决了数据可以传输的问题，但问题是，对于处于不同区域的 GPU，比方说 GPU0 和 GPU2，如果它们两之间想传递数据（多卡训练的时候你会遇到的）,就必须翻山越岭穿越层层障碍，绕个大圈才能把数据传过来。所以……它就是慢嘛，数据吞吐量和延时的数据肯定就不好看了。
2. 前面看到同一区域的 CPU 和 GPU 之间都是通过 PCI-E 的通道连接，但是 CPU 的 PCI-E 通道是有限的，这个问题相信不少自己装机搞深度学习环境的朋友都遇到过，如果想搞多 GPU，CPU 的 PCI-E 通道数一定不能少！那么对于现在这一代的 Intel CPU 架构 Haswell,它是拥有两个数据接口系统，像上面的图一样，每个接口的 PCI-E 通道数是 40 个，那么它最多只能接受 4 个 GPU（要多少是多啊……），因为我们现在的 GPU 每个都需要连 16 个数据接口，那么一边最多也就连 2 块 GPU。万一你要是觉得 4 块不够多，想再多搞点，对不起，那也不行，请走分布式的路子，再部署一台机器去，然后让机器间想办法互联（infiniband）。不过很显然，这比单机要慢一些了。而且 40 个通道已经被 GPU 分走 32 个了，inifiband 也需要 PCI-E 通道的，就给 inifiniband 分剩下的 8 个？太瞧不起 infiniband 了吧？万一跨机间的数据传输速度慢了，infiniband 表示这锅它不背。
3. 你以为同在一个区域的 GPU 就好过了？MCH 照样会把它们之间的传输速度拉下去（具体原理我也不懂……）

“这病听上去感觉还挺严重的，那大夫该怎么判断我有没有得这个病呢？”

“老司机早已为你准备好药方，一个命令+一个程序”

首先是 nvidia-smi ：

nvidia-smi topo -m
       GPU0   GPU1   GPU2   GPU3   CPU Affinity
GPU0   X     PHB    SOC    SOC    0-9,20-29
GPU1   PHB    X     SOC    SOC    0-9,20-29
GPU2   SOC    SOC    X     PHB    10-19,30-39
GPU3   SOC    SOC    PHB    X     10-19,30-39

Legend:
  X   = Self
  SOC = Path traverses a socket-level link (e.g. QPI)
  PHB = Path traverses a PCIe host bridge
  PXB = Path traverses multiple PCIe internal switches
  PIX = Path traverses a PCIe internal switch

从上面的结果可以看到，PHB 表示了 PCI-E Host Bridge，就是我们上面图中的连接方式，而 SOC 就是要通过 GPU-CPU-QPI-CPU-GPU 这样长途跋涉才能传输的连接方式。

其次是 CUDA 中自带的一个程序，在 examples/1_Utilities/p2pBandwidthLatencyTest，编译一下就可以运行，亲测会输出很多内容，以下只显示一部分：

p2pBandwidthLatencyTest
Bidirectional P2P=Enabled Bandwidth Matrix (GB/s)
   D\D     0      1      2      3
     0     X   19.18  12.22  11.77
     1  19.17     X   17.07  11.81
     2  12.23  12.17     X   19.17
     3  11.73  11.88  19.18     X

从上面的数据可以一目了然的看出，在一个区域和在不同区域的带宽差是比较明显的。当然如果不是 MCH 背锅，这个差距还可以更亮眼一点，16 通道的 PCI-E 理论传输上限是 32GB/s。所以不论是同一区域，还是不同区域，这个数据都不够好。

P2P=Enabled Latency Matrix (us)
   D\D     0      1      2      3
     0   3.39   8.18  16.86  16.26
     1   7.22   3.74  13.56  16.54
     2  16.27  16.06   3.52   5.81
     3  15.98  15.92   6.62   3.20

传输时延的结果也十分明显，就不说了。

重新思考以 GPU 为核心的三个代表母版设计思想

前面喷了那么多，下面该说说我们设计方案了，首先展示的是我们的关键道具，PCI-E switch chip(PLX)，这家伙的通道数有 48，80，96 条，这样 4 块 GPU 就不用分到 2 个区域了，而且它可以让机器上 GPU 的数据传输更快！

产品 1： Deep Learning Dev Box

废话不多说了，直接上架构图……

我们略去浮华的产品介绍，我们的产品加上深度学习软件包，心动价只卖 8999 刀！8999 你买不了吃亏，8999 你买不了上当！下面直接看下数据：

nvidia-smi topo -m
      GPU0  GPU1  GPU2  GPU3  CPU Affinity
GPU0  X    PIX   PHB   PHB   0-11
GPU1  PIX   X    PHB   PHB   0-11
GPU2  PHB   PHB   X    PIX   0-11
GPU3  PHB   PHB   PIX   X    0-11
 

Legend:
  X   = Self
  SOC = Path traverses a socket-level link (e.g. QPI)
  PHB = Path traverses a PCIe host bridge
  PXB = Path traverses multiple PCIe internal switches
  PIX = Path traverses a PCIe internal switch

Bidirectional P2P=Enabled Bandwidth Matrix (GB/s)
   D\D     0      1      2      3
     0     X   26.13  20.31  20.32
     1  25.97     X   20.31  20.32
     2  20.32  20.32     X   26.12
     3  20.32  20.32  26.12     X

可以看到，这数据好得吓人，要知道我们距离理论极限 32GB/s 已经不远了。再看看时延：

P2P=Enabled Latency Matrix (us)
   D\D     0      1      2      3
     0   4.15   6.10   6.27   6.05
     1   6.10   4.13   6.12   6.00
     2   6.31   5.96   4.19   6.04
     3   6.07   5.97   6.15   4.09

在数据面前一切语言都显得那么的苍白，不要犹豫，赶紧订购吧！

产品 2，3，4

你以为我还会一个挨一个的翻译这些产品介绍？想看就去看原文吧[微笑][微笑]

总结（非翻译）

抛开广告的环节，这篇文章很好地向我们解释了多 GPU 间数据传输这个问题。这个问题总体上算是个硬件层次的问题，那么对于软件方面，我们能做些什么呢？

• 让你的 CPU 和 GPU 在同一个区域内，减少跨区域的数据拷贝传输
• 如果涉及到跨区域的 GPU 数据传输，尽量减少传输的次数，不然真的有可能会让程序慢下来

带着这两个结论，我们就可以更好地去看 Caffe 多卡训练中的一些问题了。