「AI大咖谈」FLAG资深工程师谈ML Infra和分布式模型服
这里是「王喆的机器学习笔记」的第三十六篇文章。今天我们「AI大咖谈」邀请的大咖是一位在FLAG中某家工作了4年的资深机器学习工程师。他一直深耕于机器学习平台架构ML Infra方向，在分布式深度学习平台，线上大规模模型服务领域可以说经验颇深。大咖这次还不愿公开姓名，访谈中一些涉及公司的敏感信息也会被去除，但这丝毫不妨碍这是一次让我自己都受益匪浅的谈话。
我们知道，深度学习在业界的应用可以说进入一个全新的阶段，复杂模型的结构红利正在被吃尽，深度学习模型和工程架构的协同演进正在成为新的效果增长极。国内外的巨头互联网公司在分布式深度学习框架，线上大规模模型服务领域可以说优势颇大，有时候也略显神秘。今天我们就通过七个问题，尝试揭开互联网巨头们模型服务领域的神秘面纱，看一看能否从中一窥这深度学习领域“核弹”的奥秘。
1. 你如何看待一家公司Infra/ML engineer与data scientist/researcher们的配合问题，作为一名资深的机器学习架构工程师，你想对researcher们提点什么建议？
我自己是一名架构工程师，并没有过多的research的经历，但是在诸多项目中，我们Infra部门都需要跟不同业务领域的researcher们合作，所以我可以谈一谈在合作中的一些经验。
在合作中最显著的一个特点是大家经常在不同的抽象层面思考问题，有些看起来有一定创新性的模型结构调整其实在产品化、工程化的道路上困难重重。比如我最近关注的一个项目，offline training的时候发现效果很好，模型CTR的提升非常显著，但是在推进到生产环境阶段时，会发现90%的剩余工作都是infra方面。
比如如何处理模型变大之后offline training阶段的各种限制，典型的像模型推断时间过长，内存占用过多，online training如何避免数据的丢失，并且能以合理的速度更新，inference阶段如何在不显著增加系统开销的前提下顺利满足所有的在线推理要求（比如实时特征的准备）等等。
我现在的理解是，一个模型在离线效果上验证有收益只是第一步，甚至是比较小的第一步，尤其是在模型规模、复杂度显著增加的基础上，模型效果上的收益扣除Infra上的开销之后，实际还剩多少收益是要打一个问号的。在第一步之后，剩下的路肯定会有很多infra上的限制要去处理。
所以，从我的角度来说，无论是Infra engineer，还是researcher们，都要加深对对方领域的理解，只有一个人对这些可能的问题越熟悉越了解，也就越能增加自己的模型落地的可能。毕竟，没有任何一个人希望自己的模型改进仅仅是无法落地的空中楼阁。
2. 你在比较庞大模型的serving上有什么经验，拆解模型？剥离Embedding？
我的理解这里的庞大模型说的是深度学习中典型的有sparse feature的ads/recommendation model。这类模型的特点就是参数量巨大，单机内存放不下，自然也就无法做推断。这个时候如你所问，我们就必须进行模型的拆解，而且最可行的手段就是选择在Embedding层进行拆解。因为模型大小完全由Embedding size主导（后续的MLP等结构的参数量级远小于Embedding层）。
针对Embedding，可以通过sharding和partitioning（分表、分片）等手段把一个完整的推断过程从单节点的执行过程拆解成单节点推断主过程+多RPC call分布式Embedding查找过程。
具体来说，这里会有一个单节点做End2End的推理执行，包括最开始的特征准备、预处理以及最后几层FC layers的矩阵运算，但是中间的Embedding查找以及相关运算因为内存原因就没法在单节点上完成，但是可以通过blocking RPC call来和几个专门存放embedding 的service或者数据库做交互，这样一个完整的推断过程就可以在多个节点上分开运行。
3. （紧接上一个问题）你之前提到，当模型体积大到一定程度的时候，就无法通过单机进行预测了，那么在分布式inference这个方向，有没有什么best practice，或者实现上的建议？
这个问题非常重要，但是解决的方法又非常细，需要实现者在机器学习工程领域有非常扎实的基础。
通常来说我们首先要关心的就是节点间的通信开销问题（Communication overhead）。 单机的推断其实是有非常好的性质的，比如具备着极致的执行效率，良好的服务接口的特性，像便于 replication（复制）, load balancing（负载平衡）; 而拆解到多个分布式的模块之后，每个模块内部的串并联解耦、不同模块之间的通信开销，根据我们的观察会占到很大比重，这是非常值得优化的方向。
但总的原则是固定的，就是尽量从模型中拆解出可以并行的部分（比如最后的MLP部分就很难并行化，那么就完全在单节点内完成，但是Embedding的部分，模型中可以并行化的部分，独立的特征生成的部分，都可以拆解成不同的服务模块）。在这个拆解的过程中，还要尽量去减少模块间的通信总次数，所以这个过程是一个非常细致，非常考验基本功的地方。
以Youtube ranking模型为例，示意模型拆解的方案
聚焦到Embedding部分来说，如何把一个巨大的embedding table分配到不同的服务模块是很讲究策略的，会对最终的整个推断效率产生非常大的影响。讲一个简单的例子，比如说有一个embedding table，有10台参数服务器，如果把这个embedding table拆成十份，分配给10台参数服务器，好处当然是每台服务器上的embedding规模只是1/10。但坏处是如果有一个average pooling的操作，要查找10次embedding，那么很有可能我们要向不同参数服务器节点发出多次请求，才能最终在主推断节点完成average pooling的操作。
但是如果我们采用replication的策略，把这个embedding table全量的分配到10个参数服务器，那么在参数服务器内部就可以完成average pooling的操作，通信一次就可以了。这对于节省整个网络的通信开销贡献是巨大的。当然了，这个策略浪费了宝贵的服务器内存资源。
类似sharding和replication的权衡在Embedding规模变得更大之后会变得更加复杂，我们往往需要更加复杂的策略才能找到一个平衡通信开销和系统内存开销的平衡点。
4. 你觉得模型结构的改进，和ML infra上的改进，哪个更重要一些？特别是在当前这个模型结构已经被充分挖掘的时期，你觉得现阶段算法/模型的红利在哪？
看公司，也看业务发展的阶段。对于绝大多数公司，数据量不够的情况下经典的各种 ML 算法都可以取得不错的效果，而使用神经网络只在数据量和 infra 到了一定程度之后才会有明显效果。
个人觉得从数据量从小到大来看，是一个经典的
非深度学习模型
简单深度学习模型
大规模深度学习模型
过渡的过程，这其中每一步在起步阶段都会有对应的 low hanging fruit。 而当模型足够复杂之后，一个最有效的办法其实是返璞归真到模型本身：你能直接或者间接支持起更多的 feature，用更大的 embedding，用更多的参数，一样的模型效果就会显著 out-perform 现有的模型，于是 ML 的问题其实就又变成了一个 infra 问题。
夹带私货，这段我觉得这位大咖说的非常好，深表赞同，深有感触。
5. 你已经在ML infra领域工作了四年了，对于刚工作的ML engineer们，你有什么建议？他们最好避免哪些固有思维？
和第一个问题的答案一样。最好看到全貌并有一个健康而正确的全量架构上的认识。 我个人的理解是在生产环境里面 ML engineer 碰到的问题绝大多数都是一个还没有解决很完善的 coding 问题。
夹带私货，这段话跟我常说的先构建起推荐系统领域知识的架构，再去寻找最优的解决方案不谋而合，你不能够从infra，模型的综合角度去考虑问题，就没法提出全局更优的解决方案，也就没办法让你的想法真正落地。再岔开一点，新同学很多不喜欢也不屑于做所谓的dirty work，但本质上来说，工业界的机器学习问题几乎全都是dirty work，不存在什么训练一个模型，创新一个模型结构就交给其他人的事情，你说的根本不是新人，你说的是老板。
6. 对于embedding store这个方向，你觉得哪个技术途径是比较优秀的？你们公司采用了哪种方式去做embedding的更新？
我们在生产环境中最主要的方式还是去做全量的更新。比如一个模型通过fully training/incremental training/online training得到一个新的模型，那么由于相应的embedding层结构会发生变化，那么还是会走完全部的模型压缩、发布流程生成一个全新的snapshot，然后让已经比较成熟的线上环境自主去发现、载入、进而使用新的snapshot进行推断。
当然据我所知，国内有几家公司其实在这方面走的更靠前一些，比如做Embedding的增量更新。实际上同一个模型两个 snapshot 之间 embedding 的更新比例并不会特别高（大家可以思考一下哪些情况下某个id对应的embedding才会更新），因此实验和部署 incremental checkpointing 就会是一个很有意义的方向，尤其是模型大小越来越大的情况。
7. 能谈一谈你对模型更新实现的经验吗？全量更新？增量训练？如何做版本控制？
同上，embedding 模型 incremental checkpointing 效率上会比全量更新高效很多。
要点总结
总的来说，跟大咖的这次聊天是非常有价值的，干货很多。最重要的是可以让我们一睹海量用户/高QPS条件下的模型服务策略，这一点是任何paper都很难传递的干货经验。
最后，我们再回顾一下这次大咖谈的要点：
无论是Infra engineer，还是researcher们，都要加深对对方领域的理解，只有一个人对这些可能的问题越熟悉越了解，也就越能增加自己的模型落地的可能
有些看起来有一定创新性的模型结构调整其实在产品化、工程化的道路上困难重重，所以在构建模型的时候，也要提前充分考虑工程化的关键问题
实现庞大模型线上服务最可行的手段就是选择在Embedding层进行拆解。因为模型大小完全由Embedding size主导。
在分布式inference的过程中，我们首先要关心的就是节点间的通信开销问题
在分布式inference的过程中，尽量从模型中拆解出可以并行的部分
巨大Embedding table的sharding和replication策略是需要精确设计的
当模型足够复杂之后，一个最有效的办法其实是返璞归真到模型本身：你能直接或者间接支持起更多的 feature，用更大的 embedding，用更多的参数，一样的模型效果就会显著 out-perform 现有的，于是 ML 的问题其实就又变成了一个 infra 问题。
embedding 模型 incremental checkpointing 效率上会比全量更新高效很多，是一个极有价值的方向
文章的最后当然少不了安利我的书和课程。。我想这次访谈给我的另一个感触就是senior sde们都在提全面的知识架构，特别是全面的工程知识体系的重要性，毫无疑问，我也完全支持这个观点，所以在设计课程和写书的时候也是一以贯之这个思路，有心的同学可以尝试学习。
深度学习推荐系统实战_王喆_深度学习_推荐系统_实战-极客时间time.geekbang.org
最后欢迎大家关注我的微信公众号：王喆的机器学习笔记（wangzhenotes），跟踪计算广告、推荐系统等机器学习领域前沿。想进一步交流的同学也可以通过公众号加我的微信一同探讨技术问题。
