自 2012 年，Hinton 的学生 Alex Krizhevsky 提出 AlexNet，一举摘下 ILSVRC 2012 的桂冠后，ILSVRC 比赛冠军的准确率越来越高。与此同时，其中使用到的深度学习算法也越来越复杂，所需要的计算量也越来越大。SENet 与 AlexNet 相比，计算量多了近 30 倍。我们知道，ImageNet 大概有 120 万张图片，以 SENet 为例，如果要完成 100 个 epoch 的完整训练，将需要 2.52 * 10^18 的计算量。如此庞大的计算量，已经远远超出传统的机器学习算法的范畴。更别说，Google 在论文《Revisiting Unreasonable Effectiveness of top="1957.0625">物理计算性能
面对如此庞大的计算量，那么，我们业界当前常用的计算单元的计算力是多少呢？
根据以上数据结果可以看出：在深度学习领域，GPU 训练数据集所需要耗费的时间，远远少于 CPU，这也是当前深度学习训练都是采用 GPU 的重要原因。
业界的解决方案
从前面的计算可知，即使使用 GPU 来计算，训练一次 ImageNet 也需要 4 天的时间。但对于算法工程师做实验、调参而言，这种耗时数天的等待是难以忍受的。为此，目前业界针对深度学习训练的加速，提出了各种各样的解决方案。
异构计算的并行方案
数据并行（Data Parallelism）
数据并行，即每个计算单元都保留一份完整的模型拷贝，分别训练不同的数据，经过一个 Iteration 或若干个 Iteration 后，把各个计算单元的模型做一次同步。这是最常见的深度学习训练方式，好处在于逻辑简单、代码实现方便。
模型并行（Model Parallelism）
模型并行，即各个计算单元存储同一层模型数据的不同部分，训练相同的数据。相对于数据并行，因为各个运算单元每训练完一层神经网络，就必须要同步一次，频繁的同步通信导致系统不能充分地利用硬件的运算能力，所以更为少见。但是在一些业务场景下，Softmax 层需要分类的类别可能会有很多，导致 Softmax 层太大，单个计算单元无法存储，这个时候，需要把模型切割成若干部分，存储在不同的运算单元。模型并行常见于 NLU、推荐、金融等领域。
流式并行（Stream Parallelism）
流式并行，即每个计算单元都存储不同层的模型数据，训练相同的数据。如上图所示，GPU1 只负责第一层神经网络的计算，GPU2 只负责 2~5 层神经网络的计算，GPU3 只负责第 6 层的计算。流式并行的好处在于每个运算单元之间的通信和计算重叠（overlap），如果配置得当，可以非常充分地利用硬件资源。缺点在于，根据不同的模型，需要平衡好各个计算单元的计算量，如果配置不好，很容易形成“堰塞湖”。如上图所示，很有可能出现 GPU1 负责的运算量太少，而 GPU2 负责的运算量太多，导致 GPU1 和 GPU2 之间堵塞住大量的 Mini-batch，更常见于线上环境。
混合并行（Hybrid Parallelism）
混合并行，即上面提到的并行方式的混合。如对于一些图像识别任务来说，可能前几层使用数据并行，最后的 Softmax 层，使用模型并行。
异构计算的硬件解决方案
异构计算的通信解决方案
根据上面的硬件解决方案，我们以 ResNet 为例：模型的大小为 230M，单张图片运算量为 11 GFLPOS，Mini-batch 假设为 128。可以计算出各个硬件模块在深度学习训练中的耗时比较：
根据上面的数据结果，我们似乎可以得出一个结论：PCI-E 和网络的传输耗时，相对于 GPU 来说，整整少了一个数量级，所以网络通信同步的时间可以忽略不计。然而问题并没有那么简单，上面例子中的耗时只是单个模型的耗时，但是对于 8 卡的集群来说，如果使用数据并行，每次同步就需要传输 8 份模型，这就导致数据传输的时间和 GPU 的计算时间“旗鼓相当”。这样的话，GPU 就得每训练完一个 Mini-batch，都得等候很久的一段时间（采取同步更新），这会浪费很多计算资源。因此，网络通信也需要制定对应的解决方案。下面我们以 Nvidia NCCL 中单机多卡的通信解决方案为例介绍，而多机多卡的通信解决方案其实是类似的。
上图是单机 4 卡机器，在硬件上，两种不同的通信体系。左边为普通的 PCI-E 通信，即 4 个 GPU 之间组成一个环状。右边为 NVLink 通信，即两两之间相互连接。
常见的通信类型如下图所示 ：
对于深度学习训练而言，关键的两种通信类型为：Broadcast 和 Reduce。Broadcast 用于 Master 分发最新的模型给各个 GPU。Reduce 用于各个 GPU 计算完 Mini-batch 后，把模型更新值汇总到 Master 上。以 Broadcast 为例，最简单的通信方式是 Master 往各个 GPU 上发送数据，这样的耗时就是 4 次模型传输的时间，通信时间就会太长，一种简单的优化方法如下图所示：
即把所需要传输的数据分成若干块，然后通过接力的方式逐个传递，每个 GPU 都把自己最新的一块数据发送到下一个 GPU 卡上。这种传输方式能充分利用硬件层面的通信结构，使得需要的耗时大幅缩减。与此类似的，Reduce 的通信优化也可以采取相同的方式进行提速。
美团的定制化深度学习系统
尽管目前在业界已经推出了很多著名的深度学习训练平台，通用的训练平台如 TensorFlow、MxNet 等等，还有领域专用的训练平台，如语音识别中的 Kaldi，但是我们经过调研后，决定内部自主开发一套深度学习系统，理由如下：
NLU 线上系统
线上系统的业务特点
我们在设计 NLU 线上系统时，考虑了 NLU 业务的一些特性。发现其具备如下的一些特点：
业务多变
NLU 任务的算法流程是多层级的，并且业务经常发生变化。如下图所示：
即随着业务要求的变化，NLU 系统一开始的算法流程，只需要把一个 Query 分为两个类，但是到后面，极有可能会变成需要分为三个类别。
热更新
根据业务需求，或者为了紧急处理一些特殊问题，NLU 线上系统经常需要做出快速响应，热更新算法模型。如最近的热点词“skr”，几乎是一夜之间，突然火爆起来。如下图所示的微博，如果不能正确理解“skr”的正确语义，可能就不能准确理解这条微博想要表达的意思。
为了避免影响用户体验，我们可能会对 NLU 系统，马上进行热更新，把新模型紧急进行上线。
数据驱动的自动迭代闭环
对于线上系统而言，构建如上图所示的自动迭代闭环，能更好地利用业务数据来提升服务质量。
NLU 线上系统的核心设计
算法流程的抽象
为了适应线上系统串联、多变的算法流程，我们把线上系统的算法进行抽象，如下图所示：
即每一个算法，都依赖于若干个槽位（Slot）和资源（Resource），一旦槽位和资源就位，就会触发对应的算法执行。算法的执行先通过算法适配器，来适配槽位和资源中的数据，转换成算子的输入格式。然后算子执行算法本身，执行完算子后，再经过算法解析器。算法解析器主要用于解析算法执行的结果，触发对应的槽位。如根据算法的结果，触发 Top 3 的结果。
多个算法串联起来，就构建成如下结果：
热更新流程的设计
如上图所示，我们把算法的热更新流程设计如上。初试状态为左上角，即多个 Query 使用同一份模型数据。当遇到模型更新的请求后，系统将会 block 住新的 query（右上角状态）。然后更新模型完后，新的 query 使用新的模型，旧 query 依然使用旧模型（右下角状态）。最后，当使用旧模型的 query 结束后，把旧的模型从内存中删除（左下角），然后系统恢复到初始状态。
声学模型训练系统
因为 TensorFlow 等通用深度学习训练平台，缺乏了特征提取等业务相关的领域功能，而 Kaldi 的声学模型训练过程又太慢。所以美团开发了一个声学模型训练系统——Mimir，其具备如下特性：
