漫画丨为了大模型，如何榨干每一滴算力？_风闻

丨搞掂大模型，如何榨干每一滴算力？原创 谭婧 亲爱的数据 2023-11-02 12:05 发表于浙江收录于合集#人工智能漫画25个#人工智能大模型14个

原创：亲爱的数据

失败不可怕，可怕的是朋友成功了。

此话用到大模型这儿，就是：

失败不可怕，可怕的是“朋友”有很多算力。

看出来了，大模型的训练和推理需要很多很多GPU，

有些爆款算力产品居然跻身“电子黄金”。

外部那些不怀好意的人还在GPU上捣乱，气煞我也。

不过，气归气，预期之内。

（一）什么是算力的发动机？

2023年9月，微软官网曾有一篇报道，其原文为：

“美国爱荷华州有一台Azure的超级计算机（Supercomputer），是微软为OpenAI团队打造的一套系统，用于训练突破性人工智能大模型。”

这个Supercomputer，可以翻译成“超级计算机”。

但是，这不可能是超级计算机，泛指厉害的计算机。

陈左宁院士曾说过，传统高性能计算机并不最合适用于AI对算力的需求。

我特意请教了权威专家，

他告诉我：“因为没有详细配置，不好判断是不是超级计算机，也有可能是智能计算平台。”

他还强调：“目前主流超级计算机架构设计尚不能高效率地支持大模型训练，需要专门设计，以GPU并行为主的智能计算平台。”

OpenAI大力出奇迹，高性能集群始终是算力的发动机。

但凡需要训练千亿参数的AI大模型，背后必然是一个复杂系统。

算力发动机必然是这个复杂系统的一部分。

而模型已是科技生产力里的重要生产元素。

即便现在盈利能力还不强，

但是在接触AI这件事情上，国内客户的兴趣和诉求非常强劲。

既然AI大模型必然广泛应用，那么算力要标准化，且性价比要高。

而这两件事都不件容易。

阿里云资深专家九丰告诉我：

“GPT-4出现，让模型训练的范式非常强地依赖高性能计算的硬件和高性能通信带宽的网络，此前完全不是这样。”

高性能很难，挑战还有两个。

这就带出了另外一个话题，如何衡量AI集群算力性能？

而对于训练大模型的算法同学来说，

他们不会仅仅关注性能数字，而是关注另一件具有同样内涵的事情：

用AI集群训练大模型，到底要花多少时间？

（二）时间都去哪里了？

大模型训练对算力“饥渴”，对时间“焦虑”；

原因是它有个特点是“强同步”。

比如，一个人做一道大计算题，需要一百天。

那就找一百个人来一起做。

当干活的人多，首先要分工，任务分配下去之后，需要同步工作。

然而，大模型解题需要好多步骤，中间步骤解出来，其计算结果需要同步传递给其他GPU。

那些还没有拿到答案的GPU只有枯坐傻等。

有点搞笑的是，等到最后一个GPU拿到答案才能一起开始算。

那些数量不大，还迟到很久的任务，有一个名字叫“长尾时延”。

等待时间，计入模型计算的总时间。

就好比，等待吃饭的时间，计入吃饭总时间。

常听专家们谈论一个百分比：通信占比。

当通讯占比是50%，整个训练时间里，计算和通信时间各占50%。

计算占一半时间，枯坐傻等也占一半时间。

同样的算力，别人的训练时间是你的一半。

太可怕了。

这叫直道超车。

按我的理解，把计算这件事情分成三块，

第一，“纯”计算的时间。

芯片性能很重要，任何软件优化的天花板，必然是硬件的上限。垃圾芯片再怎么优化，不可能有“电子黄金”跑得快。

第二，取数据的时间。

计算服务器和存储服务器之间打交道，相当于你先把原材料运过来。除了用高速存储，下一步就是做缓存，数据从存储那里拉比较慢，就把它缓存到离计算近的地方，拉起来速度就快了。

第三，网络的时间。

虽然是给计算打配合的，俗称“服务于计算”。

但是，它占用了大量的时间，是计算里面的重要一环。

用网络传数据，就像说话沟通一样。

机器多了，无法线性扩展，网络速度自然就慢了。

所以，想给计算集群做一个完整的优化，不能只优化“纯”计算部分，

这三块都要考虑到。

**（三）**系统稳定，情绪稳定

如果计算集群不稳定，那么算法同学很可能情绪不稳定。

从某种角度来说，芯片一直处于较高频率的计算状态，

硬件的故障率肯定会比传统玩法高很多。

机器规模越来越大，会不断刷新故障率“成绩单”。

并且，计算任务停止所付的代价也随规模增大。

好比，全村停电和全国停电，经济损失肯定不一样。

训练大模型的算法同学对故障非常痛恨。

讲一个前几天阿里云异构计算产品负责人王超告诉我的段子：

当年，阿里算法同学曾内部吐槽早期的灵骏集群不好用。

的确，那时候，在千卡稳定运行8小时这个段位上都努力了好一阵子。

8小时是什么概念，你得让算法同学安稳睡一觉。

算法同学得罪不起，他们拿灵骏的拼音开头（LJ）开了个玩笑（垃圾集群）。

听到此，相信你很难不记住产品名字（蚌埠住了）。

模型训练之时，GPU的状态一路打满，

都把设备累到这个份上了，故障多点实属正常（虽然不可接受）。

于是，保障稳定性对于AI集群的重要性不言而喻。

甚至说，现在比过去更应该重视怎么通过软件层面的优化，降低故障发生。

在庞大的复杂系统里，

底层元气满满支持上层软件专注做事，

上层软件如何能让硬件的计算性能“精神抖擞”？

软件层面的方法应该有很多，就看怎么设计。

当某个硬件可能会出现故障或者降速的时候，能够提前迁移训练节点。

假如，带宽由800G掉到400G，这是一个很严重的事情，训练受到降速影响，算法同学完全无法接受。

找到问题，干掉问题；

实际上，如果说不去做一些任务状态的精细监控，没有办法发现故障。

AI大模型的训练，已经是一个很大的复杂系统了，出现千里之堤毁于蚁穴的概率比以往大很多。

需要有人为此做出专门的设计。

合理的思路是，检测到这一类降速故障，把任务迁移到正常节点。起把故障节点下线，自动维修，之后再自动上线。

我拿PAI灵骏（PAI的读音为π）里的功能AIMaster为例子来分析。

它是一种兜底的容错方法。

这种方法又好像一种最低战损法，

只要我的作战单元足够小，即使该单元全军覆没，我的战损也会控制在很小范围内。

 因为没有人能100%搞定高性能计算时候的故障，除了故障监控和故障修复，还有一种办法也很重要，最小化故障损失法。

这种方法好像一种安全防御理念，

只要我的作战单元足够小，即使这个作战单元全部都被干掉，我的损失也会控制在很小范围内。

大语言模型的Checkpoint很大很大，千亿规模模型的Checkpoint大小达到了数T级别大小。

这时候，我们发现Checkpoint是个好东西，Checkpoint是一组文件，不是一个单独的文件。

一般来说，一组文件都会放在一个文件夹内。

虽然Checkpoint很珍贵，但是保存太花时间也很讨厌。

我写文章在Word里打3个字，保存3秒。

那真是要说“栓Q了”，灵感早没了。

从第一性原理上讲，算法同学不是不想存储，而是存储耽误时间，他们真正想要的是存储的时候别耽误计算。

为了不让存储耽误计算，存储和计算得做到异步。

现在保存Checkpoint，还对训练自身不产生任何影响，已经是一个基本操作了。

我暗想以前是分钟级，是不是有产品做到秒级那样更厉害。

保存当然是越快越好，还要保存颗粒度更小的单位的Checkpoint。

比如：每一个小批次数据（Iteration）计算状态。

如此这般频繁的保存，会不会影响存储性能，性价比降低，要知道“算力贵如油”的日子里，人人都精打细算。

就这个问题，我请教了阿里云专家肖文聪。

他给我的答案是，考虑性价比固然有理，但更重要的是无感知。

保存Iteration虽然次数多，但控制存储总量能搞定。

他向我强调：“以前，把GPU上的任务停下来，从GPU写到存储，比如一千张卡，同时做这件事，存下来就需要几分钟，但是如果训练时间不长，就显得存储时间很长。”

那真痛苦。

于是，我理解了PAI的EasyCKPT的设计思路，支持到Iteration级别的Checkpoint无感知，背后是更高频次存储，更少故障，减少计算步骤结果损失。

而且肖文聪告诉我：“EasyCKPT保存的时候无感知，是巧用了训练任务多副本的模式和GPU服务器多级存储架构。”

这确实是一种最小化故障损失的办法。

以上方法科技含量挺高，我再介绍一种科技含量更高的方法，

算是一道学霸附加题：

PAI-TorchAcc（Acc是Accelerator的缩写）是一种在编译层面优化的方法。

Python原生深度学习任务的特点是会不断给GPU很多小指令，在效率上，很多小指令不如让GPU执行一个大指令。把这些小指令“按”成一条大指令，相当于把小运算转换成连续运算，再给GPU执行。

这可以充分打开优化的空间，减少GPU算力损耗，降低访存瓶颈，甚至可以更加智能地切分这个大指令到不同的GPU上做分布式训练优化。

PAI灵骏团队内部有一个标准，叫做千卡。

当一千张卡在一定时间长度内不暂停，可视为复杂系统的稳定性跨过了一个门槛。

或者说，在行业里拿得出手。

他们认为，一千卡的以内的能力没有必要拿出来说。

目前，PAI灵骏一千卡任务可以稳定运行3周以上。

当一千卡的任务暂停了，报错是某节点通讯超时。

值得问的问题很多：

1. 你通讯节点出了什么问题？

2. 你有没有备用的通讯节点给我？

3. 备用的计算节点和现有的节点组网的时候，网络拓扑要不要重新优化？

客户不用管这些，先睡个美容觉。

第二日清晨，客户醒来，看到昨晚有一个日志：

任务暂停又重跑了。

我们谈到很多大模型算力里的痛点，归根结底都是时间。

那PAI灵骏给自己定的目标什么呢？

我抄了阿里云异构计算产品负责人王超的答案：让不可用的时间越来越少。

（四）锤炼“PAI灵骏****”****

对于大模型来说，计算可以弹性，计算不能联合。

谭老师我所掌握的是，现在国内100%大模型创业团队都采用线下集群+公有云+租计算节点（服务器），三种模式组合来解决算力捉襟见肘的尴尬。

面对一个需要1000卡来训练的大模型，有多个选项：

或用线下机房里的1000卡跑任务，

或租1000卡的节点跑任务，

或跑在阿里云上。

可惜，三个不同形态的1000卡AI集群不能训练同一个大模型。

当你遇见一个需要3000卡来训练的大模型，怎么办?

国内公有云中，阿里云规模最大。

公有云的本质是能够资源共享，当训练模型的时候，1000卡不够了，可以“弹性扩容”到3000卡。训练结束后，释放资源给其他人用。

美国爱荷华州那台号称“超级”的计算机可能是微软云Azure的智算平台。OpenAI团队大约300号人，做出来一个令人震惊的东西，但不要忘了他们背靠微软Azure。

我把PAI灵骏也理解为 “智算平台”，这个平台的底座是一个超大规模并行计算集群。

或者说PAI灵骏是专门面向智算的软硬一体的服务，就是名字有些复杂。

很多人第一次见PAI，不知道怎么读（包括谭老师我）。

在高端的英文名中混合了文绉绉，总之是既拗口，又难记。

全靠时间长才自然记住的。

（谭老师种草不行，拔草第一）

不过，PAI灵骏底层能力强，上层指挥调度也得力。

通义千问、通义万相全部都跑在PAI灵骏上，它肯定不缺锤炼。

一个大模型团队，仅有一群算法工程师不够，还配备管控、计算节点、运维、网络共4个团队，一起服务计算集群。

坦白讲，市面上有不少线下产品的选择，比如，线下版PAI灵骏，华为Atlas，英伟达Super POD，开箱即用。

这样，“服务团队”的人数能少些。

不过，没有PaaS层和IaaS结合的能力，大量工作都得自己干。

本质上，最好能使用一体化的设计，AI软件栈里的组件配合得越紧密，算力使用得越充分。

最后，谭老师我想说，模型训练是一个离线过程，而模型推理服务是在线上的。

如果团队有能力线下自建集群，将大模型训练于线下完成，这也是中国大模型团队自身实力的体现。

在中国，有的是这样有科技含量的团队。

不过，当用户量大到一定规模的时候，他们一定会上云。

有一天，中国本土一定会生长出一批千万日活的大模型（我希望越多越好），

而现在看来，中国5000万级别日活的APP有很多，每一个都生长在云上。

One More Thing

2014年PAI团队组建，

2017年，灵骏起步。

谭老师我在2021年因M6模型接触到灵骏和PAI，并和多个主要研发负责人都有过深入交流，有些人已重新开始了另一段旅程，但我们至今仍在联络。

做公有云，要对技术趋势有很强的判断力。

跑错了，纠错成本高；

错过了，抓不到新的增长点。

回头看来，PAI和灵骏都是早期预判准确，且死死咬住需求变化的产物。

那时候的PAI和灵骏和现在很不一样。

长坡滚雪球，我看到了一段PAI灵骏的由来和过往。

回忆起来，仿佛外面雨声不断，听到短波收音机广播里另一个世界的声音。

此后历练打磨，又是几多风雨。

时光如梭，在今天2023年的云栖大会上，看到PAI灵骏的新面貌慨叹万千，背后是多少技术人的用心探索，精心打磨。

很高兴能把我所知道的PAI灵骏写下来。

我想这是中国大模型和云的故事里，重要一章。

（完）

《我看见了风暴：人工智能基建革命》，作者：谭婧