浅谈机器学习模型推理性能优化

前言

在机器学习领域，清晰明了的数据预处理和表现优异的模型往往是数据科学家关注的重点，而实际生产中如何让模型落地、工程化也同样值得关注，工程化机器学习模型避不开的一个难点就是模型的推理（Inference / Serving）性能优化。 可能许多数据科学家都对模型的推理性能比较陌生，我举几个对推理性能有强要求的场景例子：

1. 在公共安全领域中，视频监控中实时的人脸识别需要有实时的展示能力方便执法人员快速定位跟踪人员。
2. 在互联网应用领域中，电商网站、内容应用实时的个性化推荐要求能够快速响应，推荐的卡顿感将直接影响购物或者内容获取的体验。
3. 在银行领域中，电子支付中异常交易的实时识别也至关重要，任何异常的交易需要被快速识别并拦截，而正常的交易则不能被影响。
4. 在金融领域中，量化模型毫秒级的交易判断输出能帮助华尔街的交易员们套取巨额利润。

从上面的例子不难发现，其实在不同的领域的场景下，推理的性能都是模型表现之外最关注的点，在某些极端的场景，数据科学家和机器学习工程师甚至愿意牺牲一部分的模型表现来换取更高的推理性能。

在统计学和传统机器学习算法时代，推理的性能往往都能达到人们的预期，毕竟一个模型算法的计算量很有限；随着多媒体的发展和计算机性能的提升，集成学习和深度学习的模型运用越来越广泛， 而因为这些模型往往由成百上千个基模型构成，所以推理的性能大幅下降，在摩尔定律已经失效的今天，这慢慢变成了许多数据科学家和机器学习工程师的眼中钉。最近在项目中刚好完成了相关的需求， 所以抛砖引玉给大家分享一下做推理优化的roadmap。

计算图优化

“提高硬件性能是优化的最后一步，而不应该是第一步。”

上面这句话是我们项目PO说的话，其在Spark性能优化上有非常丰富的经验，我非常赞同这种论点。据我观察，在遇到算法模型的训练和推理性能瓶颈的时候，大部分机器学习工程师都希望能获得更高的硬件性能来突破瓶颈，却忽略了计算逻辑本身的优化。更高性能的硬件为模型推理带来的性能提升并不是线性的，而花费的硬件成本却是指数级上升的，所以一定要记得，不到万不得已，千万不要指望硬件带来的性能提升。

基本上数据处理和算法模型都可以被抽象为计算图，而计算逻辑的优化往往在领域内被称为图优化（这里的图优化并不是指图模型的表现优化哦 😄）。

每个计算图中都包含许多计算节，图优化的目标很简单，就是简化计算图中计算节点的计算量。常用的方式分为以下几种：

1. 减少节点的数量
2. 用高效替换低效的节点
3. 用高效子图替换低效子图
4. 用并行化分支代替单分支

减少节点的数量

在构造机器学习模型的时候，我们往往会无意中对数据做了多余或者反复的操作，这类操作就像写工程代码中的code smell一样，在模型构造完成之后一定要对这种操作多加注意。拿矩阵的转置（transposeÿ