您的位置: 首页 > 技术杂谈 > 正文

许啸宇：从内部研发到开源开发之路｜OneFlow U

2022-01-20 15:00 https://my.oschina.net/oneflow/blog/5405524 OneFlow深度学习框架次阅读条评论

许啸宇，一流科技研发工程师，现主要从事框架开发工作。2017年，从北京邮电大学硕士毕业后，他去微软亚洲研究院实习，并在当时的导师袁进辉手下接触了系统研发工作。这段经历为他后来的工作埋下了伏笔。

毕业后，他先在腾讯做了一段视频推荐算法工作，而后转向了推荐系统开发。工作两年多，他开始想进入一个成长期的技术领域，在与OneFlow创始人袁进辉的交流后，于2020年7月成为OneFlow框架的开发者。

本文为许啸宇自述。

1

从算法工程师转向系统开发

2016年底，我在微软亚洲研究院跟袁老师前后做了大概三个月的实习。在那里，我第一次接触了比较基础的大型系统研发的工作，对它的结构和设计窥见了一眼。相对于“怎么实现一个功能”，袁老师更关注“最优的设计应该是什么样的”，这个对我影响很大。

正式毕业后，我选择离开北京到了深圳工作，在腾讯做视频推荐工作。记得刚进公司时，有个事业群的推荐算法比赛，其他小伙伴搞特征很厉害，我琢磨了一下不用公司训练平台的XGBoost，而是拿内存占用少、速度快的LightGBM自己搭训练工具。这样单机我们能用更快速度、更多数据去跑任务，小伙伴的特征工程配合这个工具，我们只是参与了一下，没想到拿了冠军。

后来这个训练工具在小组内逐渐就替换了平台部那边的XGBoost训练工具。曾经有共享这个工具的想法，但内部没有跨组共享的氛围，后来就不了了之。

我的兴趣开始从算法转到了系统开发，所以找机会转到了推荐引擎开发的工作。我感觉算法有很多黑盒部分，而系统则基本是白盒的。我当时所在项目维护第三方组件的方式比较特别，里面大部分的基础组件都不是二进制文件或者第三方库链接，而是C++源码，它们不少是腾讯前辈员工积累的内部实现源码，因为没有开源仓库共享的氛围而采用了源码Copy的共享方式，这也是一种特别的“开源”吧。所以几乎可以看到所有基础工具的实现，也可以根据自己需要做修改，只是无法很好地跨组织做组件的更新、交流。

我开始主要使用和维护一些模块，比如索引的容错、用RCU无锁Map缩减内存消耗、统一本地和远程的索引抽象，后来我的前导师给了一个机会，独立从0到1上线了一个服务。当时的代码支撑了很大的流量，但是基本只有3-5个人在维护。唯一一个跨组和部门共享的代码是当时我和我的Leader定的一个统一推荐协议，它逐渐被N个推荐服务和N个业务方作为协议接口。

刚毕业时，我主要考虑回南方，以及扩展下视野。工作两年多后，我的想法变成了找个不太成熟的领域深入进去。这时，机缘巧合地遇到袁老师来深圳出差，所以就认真考虑了他在推动的OneFlow。

我在腾讯推荐工作中的认识是，深度学习/机器学习这样有学习能力的软件已经像数据库一样无处不在了。Oracle数据库已经发布了40年，开源的TensorFlow才发布了5年，深度学习/机器学习软件还有很长的未来。另外，我去读了PyTorch的部分源代码，发现是可以读懂的。

问了两、三个朋友，他们都说OneFlow技术过硬，但都担心创业期的OneFlow会死掉。这是客观存在的风险，但我暂时搁置了这个问题，而基于另外三点优势做出了选择：

1、OneFlow在做硬核技术，个人和工作内容只要在不断成长就好；2、要合作的小伙伴是不是你想与之为伍的，我当时认识两个OneFlow的同事，我认为是的（现在也是如此）；3、我相信袁老师能搞定未来新出现的挑战。

2

对抗内卷、开放改进的开源文化

2020年7月，我来到了OneFlow。到OneFlow的前半年多，出于工作和兴趣需要，我做了很多开源实现的调研。之前也看过《计算机程序的构造和解释(SICP)》，上个月读了《黑客：计算机革命的英雄》，了解到了开源文化的本源。

如果让早期的IBM那种商业公司的工程师来主导软件世界，那么现在估计只有拿到“计算机执业证”、打着领带的人才能进入体量巨大的机房，写下受保密协议约束的私有代码。我们远在中国，估计只能看到各种软件的二进制文件。软件有什么新进展，我几乎是无法很快知道的。我看不到LightGBM的代码，可能也比较难接触到一个靠谱的RCU实现，我们的推荐服务可能不会存在，因为没有这么一个繁荣的软件市场。

“对计算机的访问（以及任何能帮助我们认识世界的实物）应该是完全不受限制的。任何人都有上手尝试的权利。”这是最早接触计算机的MIT Hacker开创的开放、改进的文化，他们在早期就通过共享软件、代码、文档，来对抗封闭、内卷的文化。

要让其他人舒服的使用你创造的工具，理解你的实现。理解了的人会批评和改进，那么软件和知识就有了生命力，能够不断变得更好。工具的作者也在批评和改进中得到不断地进步。

现在，我们在OneFlow的工作，代码都是GitHub公开的，一些早期的工作计划讨论也基本是全公司可见的。我最近主要参与动静转换和静态执行相关的工作，说下最近一个多月具体做的几个Feature吧：

一个是静态图执行的自动化单测。 其他同事做了个有趣的工作，一段Torch风格的代码，每个函数执行时，实际会两遍函数，一遍Torch的函数、一遍OneFlow Eager函数，对比结果后就能验证和Torch结果的一致性。我在这里又拓展了一点，从一段代码中想办法找到需要静态执行的对象，构造出OneFlow Graph的执行函数并执行，这样就能同时验证静态图的结果了。写一行Op测试的代码，它内部实际会按三种模式执行，这种hack极大提高了单测用例的实现效率。

一个是提高debug便利性 ，从CPython解释器中获取Python代码的函数调用栈信息，记录到C++层的Operation的元信息中。这样OneFlow的图执行模式nn.Graph在构图、编译图、执行图时，如果程序在C++层挂掉了，可以方便的定位出其原本对应的Python代码文件、行位置，提高debug效率。

一个是ZeRO内存优化在静态图nn.Graph的复现 ，主是把数据并行中模型更新部分的冗余显存占用给简化掉。DeepSpeed写了N千行的代码实现了这个功能，OneFlow因为有SBP的推理机制和基于计算图编程的机制，所以只需要对计算图中的参数的数据分布做下改写，再增加些调整执行顺序的控制边，就能达到目的。熟练SBP，对计算图编程更加了解的话，对程序做分布式优化是事半功倍的。不过，需要对系统内置的机制有比较多的了解，所以有一些学习成本。

上面的这些工作，我去读了OneFlow小伙伴对对象执行的hack、读了CPython解释器对调用栈的记录、读了DeepSpeed的代码，和小伙伴做设计讨论，最后加上了自己的理解进行了实现，这些实现都在OneFlow仓库可见。

另外，这里无法体现的是我们对设计的争吵，包括一些关键接口，我们曾经对线了一个星期才达成一致。现在看来，当时讨论时把后来很多可能会碰到的坑都考虑到了，真是值得。

从之前的内部开发逐渐转变到了现在的开源开发的方式，我感觉和其它开源软件的关系更近了，可以看到、跟进、推进一些最新的东西。如果你对开源开发也感兴趣，欢迎加入我们的OneFlow项目，跑OneFlow的demo、提issue、修bug、review我们的PR，或者直接加入我们，一起做提高开发者效率和机器效率的工具：talent@oneflow.org

其他人都在看