在这样的背景下，打破 AI 实践中的资源限制与壁垒的重要性也越发显著。在即将到来的一年里，在 AI 算法的工程优化与性能提升的道路上，将有哪些值得探索的方向呢？
2022 年 1 月，来自华为昇腾 CANN 的首席架构师闫长江老师、一流科技 OneFlow 创始人袁进辉博士及北京大学数据与智能实验室崔斌教授指导的河图团队负责人苗旭鹏做客机器之心「2021-2022 年度 AI 技术趋势洞察」的「工程专场」直播间，共同探讨了「如何突破 AI 实践中的资源限制与壁垒？」这一主题。
当前AI计算体系架构方面的进展回顾
在 2021 年的 AI 计算体系架构相关方面的工作回顾中，最让您印象深刻的是哪一个？
袁进辉老师介绍到自己印象最深是有关偏底层的一个软硬协同设计工作。该工作是出于国外的一家创业公司 Tenstorrent 做的一个软件和硬件的架构层面的创新：实现了在单个芯片内部以及多个芯片协同和通信的抽象的统一，这一套抽象机制简单高效，同时软件栈要比其他芯片的软件栈要简单很多。
苗旭鹏博士回答到自己印象深刻是以 Transformer 为代表的一系列设计深度学习稀疏性的相关工作。在过去的这几年中， 使用 GPU 或者其他加速器加速一些稠密的深度学习模型的计算已经得到很好的解决，因为 GPU 本身就适合去进行一些稠密的矩阵计算，再加上现在的算子库在不断的优化，甚至包括新的编译器的出现。GPU 的性能在很多场景上已经达到了一个极致的水平。在过去这一年当中，我们看到 Transformer 可以解决 CV、NLP 里面的很多问题。Transformer 模型里面主要矩阵乘法，这个时候有人就会觉得好像只要解决大规模的分布式矩阵乘法，AI 计算的加速就完成了。但事实上这个显然是比较片面。在过去一年的研究中，比如说在 Transformer 内部去进行 sparse attention 这样的一个计算。在 Transformer 之间，可以通过 MOE 这样的架构来进行连接。甚至 Google 后面提出的 Pathways 等更高级的面向多模态多任务场景下新模型架构。事实上这种稀疏性深度学习模型的出现可能会导致我们不会再专注于稠密的计算场景，可能会在这些稀疏场景上对底层的 AI 芯片包括体系架构有更新的一些探索。
目前在AI计算的实际应用中，尤其是随着大模型时代的到来，经常会遇到各种被开发环境卡住的情况，基于您的观察，目前有哪些具体的场景是比较明显的具有限制？以及，在过去一年当中，随着AI计算体系架构方面的进展，有哪些问题被比较好地被解决了？几位嘉宾 各自团队去年都在哪些相关方向进行探索，目前取得了哪些进展？还有哪些具体问题让人头疼？
袁进辉老师觉得训练大模型现在显然能看到的是它需要非常大的计算集群，这个是需要比较多投入的。再一个就是在集群上去训练这种模型的时，并行的模式比较复杂，它里面要用到数据并行、模型并行、流水并行、专家并行等等，还要用到一些比如说亚线性内存等等。第一，目前计算资源是非常昂贵的，第二个是并行技术还是比较复杂的。在过去几年 OneFlow 团队也一直在攻坚的一个问题：在框架中原生支持大型预训练模型需要的这些数据并行、模型并行、流水并行、专家并行等等这样的技术。而去年 OneFlow 发布《从零重新设计分布式深度学习框架》这一论文，一流科技基于 SBP（split, broadcast和partial-value）抽象和 actor 模型，研发出拥有各种并行范式的 OneFlow 分布式深度学习框架。SBP 使数据并行和模型并行的编程比现有框架更容易，并且actor提供了一套简洁的运行时机制来管理分布式深度学习中的资源约束、数据搬运和计算所施加的复杂依赖关系。
那还有什么问题比较让人头疼呢？有一个比较明显的是，即使现在支持数据并行、模型并行、流水并行、专家并行等等，它还是需要人工的去为某一个模型某一个集群配置它的并行模式。在这种工业级的大模型训练上，还没有一个企业到今天为止完全自动地解决好这个复杂的并行。
再来闫长江老师谈到，华为在大规模集群训练这方面研究比较靠前的。华为跟鹏城实验室建立了一个大集群，整体算力相当于有 4k 个节点，有 1000P 的算力。模型相对较小的时候，我们通常采用数据并行，这样就足以满足训练需求。但模型扩大时，几百亿到上千亿可能就开始采用模型并行，但它不完全是模型并行。实际上是模型并行加上数据并行，相当说把计算资源分成一些组，一组内进行模型并行，组间进行数据并行的一个策略。随着模型进一步扩大，后来就考虑另外一个方案：再分一层还进行流水并行。就相当于把数据并行、模型并行、流水并行在整个系统中去穿插使用。但这个过程中整体也有一些非常大的难点，包括切多少节点作为模型并行多少节点进行数据并行，以及流水并行用多少节点。这种探索起来就非常困难，因为最终要以整体的性能来衡量算法好坏。在真实环境中进行不断实验是挺困难的，所以实际上一开始可能需要借助建模去分析，相当于通过一些优化软件去进行探索不同技术部分所需要的节点。在这些方面做了不少的探索研究事实上追求的目标就同袁博士刚是讲的希望能够让用户表达计算，之后通过软件去解决用户表达计算在大规模集群上怎么跑性能更高。也可能有个建模工具去帮助分析这个性能，然后比较早到实际环境上去跑。总体上也就这几个思路。难点确实怎么在大模型的基础上，在这个集群上，怎么表达简单又能够跑得高性能。这始终是未来几年可能是大家一直努力的方向。
突破资源限制之道，“从上往下，还是”从下往上”？
袁进辉老师在过去和机器之心的交流中也谈过，未来的事实工业标准是需要完备性、易用性、高效性等各方面综合都需要做好，在保证算子库、模型库、文档教程、上下游工具链等的完备之外，需要能够通过简单操作、动静合一、自动并行、训练推理一体化等 加速开发流程，最后在性能上还要能实现高吞吐、低延时、内存优化、线性加速比、数据并行、模型并行、流水并行等等。目前要实现这样的效果还是非常不容易的，我们看到算法领域有算法的解法、算力领域有算力的解法，有的是从改进算法入口”从上往下”，有的是从算力适配入手”从下往上”，下面想要去各位嘉宾谈谈在这方面的看法。
苗博士谈到自己在早期科研的时候是从后者来说，从下往上。先去看底层算力，它的硬件性能有没有达到一个最高。比如说在吞吐上想要性能尽可能好，我们可能会去看 GPU 的利用率、 GPU 里面的一些 kernel 的执行时间，并期待从这些 GPU 的这些性能指标上入手，发现它存在哪些问题，然后去优化它。如果这个指标达到了我们期待的目标的话，可能我们认为性能达到极致了。而随着后面科研的工作展开，我们逐渐发现说其实这样是片面的有瓶颈的。后面其实就会考虑说从算法的角度来入手。机器学习系统领域本质上是 AI 和系统的一个交叉领域，所以更多的情况下是从下往上和从上往下反复迭代的过程。我们可能从算法上去进行改进的，例如可能是数量级这的一个加速。但是往往在改进到一定程度的时候，会发现实现的底层硬件利用率没有达到要求，这个时候再去改进算法，可能会和期望产生一些冲突。所以这个时候需要尽可能地去优化实现，要去充分地利用硬件。然后当硬件达到极致之后，可能再回过头再去思考算法领域是否还能再进一步去调优，通过这个反复的迭代过程，可能这样最终才能达到一个比较理想的情况。
接着闫长江老师谈到自己做的有关算力在这里面就算从下往上。比如说今年做的很多性能优化工作基本上就是把业界的网络拿过来，到我们的这个系统上去跑，整个这个优化措施有几点：一个是单算子层面，因为我们知道算子面临不同的 shape 的时候，算子的性能表现可能不一样。所以我们首先可能网络一跑就会快速地找到哪些算子的性能是明显有问题的，所以要优化算子。再来闫老师谈到他们会针对计算图进行分析优化，看看图层面算子融合，哪些能做常量折叠，哪些这个格式转换能消除。这样结合图层面优化，结合算子层面优化，包括算子融合这些技术去改进算力。他们内部也提供了一些工具，包括跑一个网络，它自动会分析这个网络里面哪个算子计算利用率没达到。图层面也会告诉图层面哪页占的计算时间最长，会有很多的改进建议直接提出来。这是他们的改进。另外华为本身内部也会做上层模型算法的优化改进，例如华为的诺亚方舟团队。
请袁进辉老师跟我们聊聊最近观察到一些您感觉比较有启发的角度？
袁老师谈到最近感觉一个比较有启发的思路是在训练这些大模型，它都是在专用集群上做的，而且服务器之间的带宽是非常高的，同时这个芯片也高度同构的，基本上都是同一类型的 GPU 或者同一类的 AI 芯片。这基本上意味着训练要提前做比较多的投资。在以前做分布式计算，以及更早有一个概念叫网格计算。比如有一些不同的GPU卡，而且各个服务器之间带宽没那么高，并通过广域网连起来的 GPU 卡，在集群上能不能训练出来比较大的模型呢？这个是闫老师感觉比较有意思的一个问题。最近也看到一些觉得使得这个事可能性提高的一些做法，例如快手提出的Bagua，它实际上在分布式计算中不要求所有节点之间都要通信，只是关心必要的节点之间做一下通信，这样通信量肯定减少，但在数学上是一种近似。灵活的通信策略，还有弹性的计算性质，袁老师觉得会使得基于广域网上大多数的算力能不能整合进来成为一种可能。
AI计算的软硬结合之道
算法在不断演进，硬件的利用率由架构和编译器决定，架构负责把算法转化为相对架构而言最优的质量、序列和执行模式。算法+芯片需进行联合优化，才能兼顾计算架构和算法设计。在软硬联合优化方面，想请袁老师和闫老师分享一下您们的一手经验与思考？首先想请袁老师跟我们分享一下。那么袁老师，OneFlow 在没有自己的硬件产品的情况下，通过研发深度学习编译器来支持第三方的硬件的一些相关案例？
袁老师谈到深度学习软硬件协同就是 Software/Hardware Co-Design 是一个趋势，在实力非常雄厚的大企业里面，几乎都是同时做软件和硬件。对于一流这样的创业公司，事实上没有实力去做硬件，所以就聚焦在软件。通过和很多专门做硬件的公司去合作提取出通用的需求，例如和我们合作的芯片公司，包括寒武纪岁元，曙光 DCU、英伟达 GPU 等，在这样的多种芯片上提炼出通用的规律。比如，软件和硬件的最通用的接口是什么？那在框架层次就把最小的接口集合设计出来，任何一款新的芯片只要支持了这个最小的接口集合，就可以和 OneFlow 对接起来，就是通过这样一些思路出发。另外在做分布式的时候，基本上所有的框架在使用英伟达 GPU 做分配计算时，都是依赖于 NCCL 。但是一般的芯片是没有研发 类似 NCCL 这样的通信集群通信库，基于此袁老师团队研发出一个与硬件无关的集群通信库，当另一款芯片过来之后，只要提供一个最基础点到点的通信功能，即一个卡拷贝到另一个卡这样一个基本的功能，就可以和 OneFlow 这个集群通信对接起来，就能让别的芯片具有集群通信的能力。这是袁老师团队在做的一些工作，总结来说两点，一个是说提炼出软硬件界面最小的接口，再来在分布式硬件无关的集群通信库上做一些努力。
下面请闫长江老师给我们分享一下CANN的解法思路，讲讲相关的一些案例？
闫老师分享到 CANN 在昇腾架构设计上起到了一个核心的责任。比如在芯片设计里面的 AI Core 有两个计算引擎，一个矩阵计算引擎 ，另外一个是向量计算引擎，它们内部之间还有一个 buffer 的通讯硬件通道。在神经网络里大部分是做完矩阵乘积例如卷积，再来跟着向量计算。这种情况下如果不跟硬件结合优化，可能做的就是利用 AI Core 里的这个矩阵乘计算单元，把矩阵乘算完。计算结束后把数据保存到 DDR。然后再进行向量计算。这个过程会发现计算矩阵乘的时候，向量计算单元是空闲的，而在向量乘计算的时候，向量乘计算单元是属于空闲的。这样的话整个资源利用率只有50%。所谓设计的算子融合，例如 10 兆数据按 100K 平均切分，这样第一个 100K 矩阵乘计算完成之后送到向量计算单元去进行加法计算，接着第二个 100 K数据类似，以及形成流水计算。在这个过程中会发现 cube 和 vector计算单元实际上计算这 100 兆数据的过程中只有一个启动开销。而这种算子融合就是典型软硬结合的一个设计。像这种其实案例很多，包括格式转换消除、集合通讯等也是类似。再来华为的芯片里面内嵌了一个 100G 参数量的通讯网口，这样直接可以在芯片中直接发起即刻通讯，这使得通信效率很高，线性度很高。
AI计算体系架构未来发展方向
您团队目前所发力的方向，往下一步发展，目前存在的主要瓶颈是什么？您目前比较关注哪个方面？您认为下面一年在AI计算体系架构的发展或者说在AI计算的工业标准逐步形成的道路上，可能会有较大进展与突破的方向是什么？为什么？
首先，苗博士说到合图团队的研究方向方向相对来说会广一些，从稀疏大模型，包括稠密的 Transformer 模型、 Graph 领域最近比较火的 GNN 模型以及 AI 框架周边的工具，比如上游的数据管理等。目前主要的工作重心在于当下比较紧迫的预训练大模型的探索。尤其是最近以 MOE 为代表的万亿规模的大模型训练其实是一个还没有完全成熟的领域。大家对这一类模型从 AI 模型设计来看，它的学习机理还尚不完善，还有很多改进的空间。如何充分发挥这些 expert 之间的一些差异性等等，这些都是可以给系统检索带来可能性的一些方向。过去的一年，企业训练了很多大规模的模型，这些模型真正让它落地发挥作用的话肯定离不开一个问题，就是解决它实际部署和应用上的一个问题。目前来说，对于超大规模参数的模型还没有一个特别公认的一套解决方案，大家还是沿着之前的一些思路，比如去做蒸馏或者压缩等等。苗博士期待说在未来的一年能不能在系统和算法上去进行一个结合来对这一类大模型的实际落地部署产生一些帮助。
再来袁老师谈到自己关注的是刚谈到的自动并行，即做分布式训练时如何做到不需要用户去关心任务怎么分布，中间怎么连，数据怎么划分，只要写出来单卡代码就在一个集群上，就能以最优的或者接近最优的方式并行出来。再来关注的是微观层面的自动化分布式。微观层面指的是一个 AI 芯片上，用户写了一个数学逻辑算子，怎么能为这款芯片或是另一款芯片自动化生成最高效的代码。这个其实就是深度学习编译器这个课题所研究的问题。那现在这方向我们也看到了有比较大的进展，比如说基于 TVM 的这种编译器的工作。在有的算子上自动优化出来的 binary 已经是不输于专家写的代码了。但是还存在一些不足，所以比较预期的说在微观单芯片层面的代码生成能完全实现自动化。这是袁老师比较期待的一个方向。
最后闫老师跟我们分享到自己团队会持续地在图优化、算子优化领域发力，以解决如何模型跑得更快。以及在编程易用性方面能够做出比较大的提升，让用户更容易写入程序。然后在团队开发编译器的努力下，能够编译出高性能的计算。同时这里有一个比较大的问题是将来面向大模型，我们怎么做集群？让用户表达计算，剩下的事情交给我们来做。这个也是 CANN 计算架构的核心责任。再来是关于工业体系这个方面，闫老师认为比较关键的方面，第一个是如果在一个标准体系形成，即上层应用表达标准化之后形成一个工业体系，这样实际上会大大降低整个工业体系的应用开发成本。另外比较关键的地方是图的 IR 和算子 IR 这两层结合底下的体系结构如果有一套工业标准，可能在创新改进速度上会更快一点。
