本文来自微信公众号:安迪的写作间(ID:andy_writing),作者:安迪的写作间,题图来自:视觉中国


时间回到2021年9月,我,Andy,正式加入 OpenAI,着实花了不少功夫。


大概 2020 年中 GPT-3 发布了,于是我司也算开始正式商业化了,开放 API 搭建使用平台,拿了微软爸爸钱帮爸爸干活。过去一年里也开始收紧战略,将人力都往 GPT 方向转,之前做音频,图像相关也都暂时不作为重点。不久前整个机器人团队还被解散了呢。而关于 GPT-3 发布前的历史,可以看我好朋友总结的博客《GPTの野望》,中二是中二了点,但不失为一篇佳文。


NLP 方向会比机器人好做,因为数据较充足,能快速迭代。且我司已搭建了一个非常好的标注团队,听说最近对齐团队要放出一个对书籍总结的强化学习相关研究。去年就有个类似工作,看来这一年是花了不少时间磨合标注团队,还有将整个流程规模化起来。


啊,忘说了,我被招进来主要负责 NLP 预训练方向,算是 Capability 侧的人。之前也有过相关经验,对分布式训练架构也还算熟。


数据


由机器人团队的事,就可见现在数据驱动范式研究中数据的重要性,不光是迭代速度,还影响性能。


从去年 GPT-3 到现在节点,听同事介绍,主要进展是满足用户一些需求,比如 Retrieval-based、插入编辑的需求、少量数据finetune泛化等等。


预训练侧,比较大动静就是做 CodeX 模型,投入不少人,但也获得了不少关于代码数据的 Insight,比如发现自然语言混进较高比例代码数据对性能影响,并不会导致自然语言任务性能下降,还会对符号推理有一定提升。


所以,最近数据团队又整体收集了一大批高质量的自然语言数据,加上代码数据,用于训练。


关于数据来源,因为之前探索,发现数据量特别是高质量数据,对基座模型的性能影响很大,所以是想方设法找高质量数据,有传闻包括了:


  • Libgen,Z-library 这样电子书网站中的电子书


  • 还有不光是 Arxiv 这样公开预印论文网站,还有 Scihub 这样无版权论文网站


  • 当然 Github 全站也都有,也没管许可


这些如果能都用上,一定能训练出能力强大的基模型,对之后工作有了信心,预训练主要就得靠数据了,其他都能慢慢解决。


而老板们给到的目标,却不光是单单给预训练性能提上去,经过一年商业化尝试,发现不能光是增大规模一把梭哈,给单纯性能指标提上去。还要考虑训练和推理的效率平衡,首先预训练完后性能要有一个很大的提升,而且之后推理时消耗也要让大家用得起。


一年的尝试


于是将之前的经验汇总起来,基于新的一批数据开始训练模型。


我们实验了各种数据的配比,确定了一个较好值。而且训练时逐步增加长度,增大长度这是一些应用场景需求,原始 GPT-3 的 2048 长度不太够,这次我们增大到了 4096. 还训练了更长的时间,而不仅仅是 300B 的 Token 数量,因为发现对于大模型 300B tokens 远远不够。


于是我们拿到了一个新的版本,果然在一些能力如长文、代码还有自然语言任务都相比之前模型有一定提升,但却并没有一个质的提升,于是我们称这个模型为 3.5。


之后我们在 Scaling 方面做了些尝试,绘制了更多 Scaling 曲线,发现 GPT-3 架构上还能继续 Scaling,也会有收益,但要达到一开始的提升目标,需要给模型 Scale 到非常大规模,但这就导致训练和推理成本都非常高,真是头疼。


于是开始想着要不要尝试其他技术栈,比如说稀疏的 MoE 模型,最近谷歌有些还不错的成果展示。而且正好 2022 年年初,入职了一个相关同事,我们讨论了一下可行性。



讨论中还遇到一个问题,这位同事参与过 Chinchilla 论文,了解到如果要 Scale 到一个很大规模,现在数据量是不够的,很可能即使模型规模上去了,但因为数据的不足,导致整体性能也还是没太大提升。


一个比较大的担心是没有数据,没有更多高质量数据。现在高质量的 NLP 数据来源基本上都已经搜集遍了,只能想其他方法了。这时有人提议,现在拿的还只是纯粹以文本形式展现的数据,其实网上有以其他形式表现的文本数据,比如音频。


对啊,网络上那么多音频数据,那么多播客、有声书、视频内容,都可以转成文本数据。于是说干就干搜集了大量弱监督数据,训练了一个音频转文本模型,就叫做 Whisper 了。


而且除了音频数据,图像数据也能拿到很多,这样的话,就可以给一些带图的文本数据,还有视频数据更好地利用起来了。至于图片输入就照着 DALLE 的方式弄就行。


调研得差不多,可以开始进行新的挑战了。


GPT-4 的诞生


于是推翻之前技术栈,重新基于 MoE 模型来进行开发,从头开始调研 Scaling Law 一系列实验下来,一定数据量情况下,确实 MoE 是一个比较有效的 Scale 方法。而且通过曲线预估,可以在达到满意的 Scaling 规模同时,还能在推理上勉强达到需求。


于是大概将模型的规模扩大十倍,因为一次训练成本太高,出于保守起见,先只用了 16 个专家,每个 111B参数,而共享部分是 55B参数,所以总计大概是 1831B参数量,可以说非常大了,特别还准备投入上线使用。之后推理时,每次前向会走两个专家,加上共享参数也就是 280B 的参数,勉强能抗住。


数据方面,用调配好的数据比例,大概 1 个大 epoch 会包含 1 个 epoch 的自然语言数据,加上 2 个 epoch的代码数据,于是 1 个 epoch 大概就是 6.5T tokens 的数据量。之前发现代码配比能占到较大比例,如果按40%算的话,自然语言有 3.9T 的tokens,而代码则是 1.3T 的 tokens.


训练方面,策略方面我们和之前一样,用课程学习逐步增加 Batch Size 大小,一直到 6000万 tokens,逐渐增大长度,但主要在 8k 上进行训练。如果有更长长度的需求,也有专门的长文团队,基于 8k 来进一步训练;分布式方面,我们为了最大化利用 NV-Link 的通讯优势,用了 8 路的 tensor 并行,同时出于硬件方面的限制,用的是 15 路的管道并行。


模型结构方面,完整的 Multi-Head Attention 会带来非常大的 KV-Cache,所以改成了 Multi-Query Attention,虽然性能可能会下降些但在推理时带来的收益是非常大的。最近还出来了一个 Flash Attention,看起来很不错,但保守起见先没上,先做一些实验看看实际效果,这个对长文至关重要。


之后就启动文本 GPT-4 的训练了。


过程中,我们会进行阶段性评估,发现当前这个训练策略果然是有效的,非常振奋人心,中间就已经超过了之前的 GPT-3.5。这时微软那边想要做相关的分析工作,于是给了他们一个部署的接口,让他们能持续做实验。


ChatGPT 小插曲


Alignment 侧的同事们这一年也做得不错,给预训练+SFT+RLHF这条路走通后。在 API 建设中发现,用户喜欢直接给模型指令,因此就直接复用流程做了个 InstructGPT. 我试用了一下挺有意思的,就是还主要是单轮,不能和模型讨论,用起来不方便。


出于这个考虑,Alignment 团队开始搜集标注多轮相关的数据,用 InstructGPT 的技术又调了一版,果然交互就自然了很多。


大家讨论了一下就叫 ChatGPT 吧,因为是用 Chat 的方式来进行交互的。


Murati 体验后感觉效果很好,就让公开发布一个版本,于是准备了下放出一版。然后就继续各做各的事情去了。


然而没想到,一刷 Twitter 大家都开始提到 ChatGPT,公司内也都开始讨论起来,用户使用数也不断增加,使得给 ChatGPT 的推理资源,也越来越多了,超出了大家的预期。


一开始以为也就在英文用户圈,毕竟模型都是在英文数据上训练的,结果没想到在全球都开始引起了热议,公司内的人开始被不断找,大家出现了一个共识,我们火了。


明明相同的技术差不多大半年前大家也都知道了,只是简单换了下数据和交互方式,突然就火了,真的申请。但火了肯定是好事,财富自由指日可待。


因为用户量的激增,找微软爸爸借算力,还有对 ChatGPT 模型进行量化降低推理成本马上提上了日程。


GPT-4 的发布


同时,因为大家知道了 ChatGPT 后面基座模型是 3.5 模型,于是压力也就给到了我们。


我们需要发布一个满足大家期待的 GPT-4 模型。


于是大家也都开始紧锣密鼓地准备 4 的发布,准备三月份发布。多模能力可以先做一个 demo 版本,所以在多模态的数据上只进行了 2T 数据的继续训练。


然后就是一些推理方面的优化,尽量先让用起来,包括推理机器的规划,怎么提高推理时候 GPU 的使用率,而一些推理上通用策略可以直接复用之前 3.5 的经验,比如 Batch 推理,还有 Continuous Batching 减少无用计算等等。量化还需要做大量实验,之后再做。


解码时,可以用前段时间提出来的,Speculative Decoding. 自回归生成文本中,有简单部分和困难部分,让 4 模型来处理难的就行,用一个更简单推理成本更低的模型处理简单的,一次生成几个 token,然后让 4 模型看看,OK 就接受,不行就打回自己生成。


发布后,果然访问量直接炸了,用户也觉得能力确实有很大提升,我们算是基本完成了我们的任务。放出了4接口之后,算力却彻底吃紧了,本来大家算力还比较余裕,突然就捉襟见肘,很多实验都开展不起来,只能先让给推理。


所以 4 的 32k,还有多模接口完全不敢放出去,算力根本扛不住。


现在第一优先级就是降低 4 的推理成本,目标是如 3.5 Turbo 一样不降低性能给推理成本降低10倍。一些临时方案只能是如降低 Speculative Decoding 的拒绝概率这样,但看网友反应好像觉得性能下降了。


等给 Long-Context 的场景解决了,再考虑多模态的事情。而现在用接口的人越来越多,而且还有很多创业公司,于是各种需求也要开发,调工具啊,Code Interpreter啊,stateful api啊,低成本 finetune 啊。


害,会忙碌好一阵子了。


本文来自微信公众号:安迪的写作间(ID:andy_writing),作者:安迪的写作间