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

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

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

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

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

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

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

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

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

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

一年的尝试

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

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

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

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

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

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

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

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

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

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

GPT4 的诞生

于是推翻之前技术栈，重新基于 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，看起来很不错，但保守起见先没上，先做一些实验看看实际效果，这个对长文至关重要。

之后就启动文本 GPT4 的训练了。

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

ChatGPT 小插曲

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

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

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

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

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

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

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

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

GPT4 的发布

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

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

于是大家也都开始紧锣密鼓地准备 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 啊。

害，会忙碌好一阵子了。