在机器学习领域，如果单纯说优化，一般指的是模型的优化，通过数据处理，特征选择和调参等方法来提高模型的准确度。不过这些主要是算法工程师的工作，今天主要从工程的角度来说一说机器学习的性能优化，譬如运行速度，扩展性，资源使用率等方面的优化。

　　理论上讲，提高机器学习算法性能和普通应用性能的方法没什么本质区别，也是从计算方法，CPU/GPU，存储，网络等方面定位瓶颈，进而通过升级硬件或者改变实现来打破这些瓶颈。

　　1.算法层面的优化

　　从算法上进行优化带来的往往是数量级的提升。例如LDA模型中从普通Gibbs Sampling到AliasLDA再到LightLDA，在更新单个词时其计算复杂度从最初的O(K)降低到O(1)。另一个例子是SVD分解，没有任何优化的分解方法是O(n^3)，对于几十万维度的矩阵基本是无能为力的。采用梯度下降法不仅解决了missing值的问题，计算速度也提高了非常多。

　　在实际工作中，能够从算法层面进行优化的机会非常少，主要是因为设计一个新的算法的难度很大，算法工程师大多忙于业务分析和特征选择，然后选择一个合适的模型进行训练评估，因此算法工程师更希望能有一个高效的实现来帮助他们进行快速的模型训练。

　　2.选择合适的计算引擎

　　一般来说，C/C++的实现比Java/Python的实现由更好的性能，毕竟解释器本身要做额外的工作，即使使用了JIT技术，也不可能做到和C/C++一样快。但是每种流行的计算引擎自有其存在的道理，sklearn/keras等工具虽然无法处理海量数据，但是安装简单，使用方便;Spark上机器学习库的性能不算最好，但它为用户提供了统一的大数据处理框架，同时支持很多常用算法的分布式处理;TensorFlow/MXNet本身作为深度学习框架，为开发者快速训练各种神经网络提供了可能性，恰好弥补了Spark等平台在在深度学习方面的不足。

　　因此在实际工作中，算法工程师可以先使用简单快速的工具如sklean，matlab等进行数据分析和特征选择，特征和模型基本选定之后，需要在大数据集上进行训练验证，这个时候只能求助于Spark/TensorFlow等支持分布式机器学习的工具。

　　一个典型的例子是gbdt模型，初始做数据分析或者小数据量时可以采用sklearn里的gbdt来做训练，当数据量比较大时，可以采用陈天奇的XGBoost来进行快速训练。当数据量达到几十G甚至更多的时候，单机训练会很困难，这时可以采用XGBoost的Yarn版本来快速训练。由于Yarn版本的XGBoost得到的模型是近似的，如果担心有损失，也可以采用我们组鲁楠同学开发的MPI版本，既能使用海量数据快速训练，最终得到的也是和单机一样精确的模型。

　　3.使用硬件加速

　　最终的计算都是由硬件来执行的，因此充分利用硬件的能力是很重要的，上面提到的OpenBLAS或者MKL都充分利用了CPU的向量化指令。除了CPU，很多涉及到大的矩阵向量操作的计算都可以使用GPU来加速，尤其是深度学习，基本上GPU是标配的硬件。

　　还有一种情况是新的硬件会支持一些新的特性，而这些特性对算法的性能来说至关重要，比如fp16，在语音识别系统里用的很多，在Intel和Nvidia的最新的芯片里都增加了对fp16的支持，对模型关键部分的计算性能可以成倍的加速。

　　另外如果训练数据非常大，不能完全保存在内存里，在训练过程中就得反复从磁盘中读取，这样磁盘就会成为瓶颈。因此用于机器学习的集群，最好配备高速的SSD作为训练数据的存储介质。

　　事实上，涉及到算法层面和硬件层次，影响性能的因素相当多，CPU的主频，核数，NUMA，cache miss，线程互斥，内存带宽和latency等都可能成为性能的瓶颈，仍然以LDA为例，LightLDA从算法上来讲已经很快了，但陈键飞和李恺威等同学观察到cache miss比较高，进而提出了新的WarpLDA算法。

　　当然需要做到这么细粒度的优化的时候并不是太多，但是当模型已经大量应用并且性能要求比较高的时候，还是有必要从这些层面入手看看是否还有优化空间的，这时使用相应的性能监测工具比如Intel的VTune是有很大帮助的。

　　4.使用高性能的数学计算库

　　Spark MLlib的内部数据表示和计算使用了Breeze库，Breeze库使用了netlib-java和JBLAS。由于license的关系，缺省情况下netlib-java使用的是java实现的BLAS接口，由于JVM的额外操作，以及没有充分利用硬件上的指令，这样的计算性能很低。我们可以为MLlib配置使用ATLAS/OpenBLAS库，或者使用Intel MKL库，将带来非常明显的性能提升。

　　相应的，Nvidia也提供了cuBLAS和cuSPARSE库用于在GPU上支持向量和矩阵的运算，同样对于深度学习的应用来说，cuDNN也提供了专门针对深度学习做了优化，而且TensorFlow , Caffe, MXNet和CNTK等深度学习工具里已经实现了cuDNN的支持。

　　5.数据并行

　　互联网公司要处理的数据量远远不是单机所能承受的，像Spark这样的引擎通常会把数据分成很多partition，每个节点处理一部分数据。对于机器学习任务来说，Spark需要把模型分发到各个节点上分别训练，然后再统一发回Driver端进行merge，之后再重新发给客户端开始下一个迭代的训练。

　　在配置合适的资源的情况下，这种方式一般工作的很好，但是如果存在数据倾斜，某个节点要处理的数据量太大，会导致其余任务都在等待其完成，甚至由于内存等问题导致根本完不成。解决的思路一般是对数据量特别大的key特殊处理，尽量避免多个数据量的key分配到一个节点上，必要的时候甚至要对key进行分拆。

　　深度学习是Spark的弱项，虽然社区里有Yahoo开源的CaffeOnSpark，支持的模型仍然受Caffe的限制，所幸TensorFlow和MXNet现在都支持了多级多卡的并行训练，当然前提有两个，一是有足够多足够好的GPU机器，二是有足够高的网络支持，比如InfiniBand。

　　6.模型并行

　　数据并行的方式提高了算法的横向扩展能力，但是对于机器学习任务来说，每个节点上仍然要做相同的训练任务，同时都保存了模型的一个副本。但是追求极致的算法工程师们并不满足，他们希望能够训练超大规模(几十亿几百亿参数)的模型，比较常见的是大规模LR，可以在推荐领域帮助算法工程师寻找相关性最大的那些特征。

　　另一个类似的情况发生在深度学习领域，如果神经网络的规模太大，比如全连接层的参数太多，GPU的内存里可能存不下，这个时候只能使用多卡来协同工作。

　　目前解决超大模型训练问题的方法主要是参数服务器，顾名思义，是把整个模型分散存储在多个PS(Parameter Server)节点上，各个Worker节点在训练时如果需要用到参数，可以从PS节点上读取。粗看来，这种方式相当于把远程节点的内存当作本地的内存来使用，但是由于网络的延迟远远大于内存的延迟，带宽一般也很有限，所以网络往往成为瓶颈。

　　另外一方面，机器学习的任务有其特殊性，在训练过程中需要不断地更新参数。在参数服务器的情形下，节点之间对同一参数的更新相互影响，有可能降低收敛的速度，因此对那些训练数据稀疏性很高情况效果会比较好。另外为了提高训练速度，通常不再采用BSP的训练模式，而是采用ASGD或者SSP的方式来进行训练。

　　参数服务器的方法最早见于Google的DistBelief，但是DistBelief并没有开源。如果需要训练大规模LR、LDA等模型，可以部署李沐的Parameter Server或者刑波的Petuum项。如果是想在Spark上训练超大模型，可以尝试一下DistML。

　　这两年机器学习平台的发展相当快，Google内部已经从DistBelief发展到了TensorFlow，在刚刚过去的2016年，Google和Microsoft, 百度等公司分别开源了自己的机器学习平台，活跃在社区里的陈天奇和李沐等人也推出了MXNet，这些平台基本上都带有内置的参数服务器支持。

　　总结

　　性能优化是没有止境的，但是目前没有一个机器学习平台能够一统天下，一个公司靠自己维护一个平台的可能性已经微乎其微，事实上也没有太大的必要，更多的是相互借鉴相互融合，因此从性能优化的角度来看，跟紧学术前沿，跟紧社区潮流是必要的。在这个基础上，有针对性的对关键算法进行优化也许是合适的选择。

　　36大数据(www.36dsj.com)成立于2013年5月，是中国访问量最大的大数据网站。36大数据(微信号:dashuju36)以独立第三方的角度，为大数据产业生态图谱上的需求商 、应用商、服务商、技术解决商等相关公司及从业人员提供全球资讯、商机、案例、技术教程、项目对接、创业投资及专访报道等服务。

        编辑：silence