本文来自微信公众号：安迪的写作间（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），作者：安迪的写作间