前谷歌大脑科学家YiTay去年3月离职后，创办了一家初创公司。
创业一年，他发文表示「痛并快乐着」。
在这篇博文中，我讨论了：
1.在不同计算提供商中采购计算和差异的经验。我们最大的发现/惊喜是差异超级不同，几乎是人们可以获得的「硬件彩票」！
2.讨论「野外」基础设施/代码，并过渡到我在谷歌的习惯
3.训练模型时的新思维方式。
在整个创业过程中，他认为最大的困难便是——算力稀缺、算力提供商差异巨大，让大模型的训练比预期要难得多。
对此，YiTay写了一篇长文，自述了从0开始如何创办一家公司，筹集资金、购买芯片，训练出了能够与Geminipro/GPT3.5，甚至超越其他LLM的模型。
在大公司维护计算集群的时候，随着规模扩大，集群管理更像是生物学而非工程学。
训练常常因为各种未知原因失败，需要重启尝试。训练大模型考验整个计算系统的容错能力，因此除了考虑性能和成本，还要评估整体服务质量和团队效率。
接下来看看他是如何讲述，自己一年来的创业历程。
「野外」训练LLM（由Dall-E生成）
LLM时代的硬件彩票
训练模型的首要条件是获取算力。这看起来很简单易行。
然而，最大的惊喜是计算提供商的不稳定性，以及集群、加速器及其连接性的质量存在着巨大的差异。
人们总是认为，这只是一个关于加速器选择的问题/争论（TPU还是GPU等等），所有的GPU集群都是平等的。
对我们来说，这很快被证明是错误的。
当我们对不同的服务提供商进行抽样时，发现即使对于相同的硬件，即GPU（H100），硬件质量的差异也有很大差异。
请注意，这里的硬件指的是整体集群质量，而不一定是芯片或加速器本身。就像「彩票」一样。基本上：
并非所有硬件都是一样的。不同硬件提供商的集群质量差异非常大，以至于要想训练出好的模型需要付出多大的代价，这简直就是在抽签。简而言之，LLM时代的硬件彩票。
更具体地说，我们从几家计算供应商那里租用了几个集群，每个集群都有数百到数千个芯片。
具体地说，一些群集的节点每N小时出现一次故障，出现的问题包括布线问题（其中N小得不合理）、GPU硬件错误等。
更令人惊讶的是，同一提供商的每个群集在鲁棒性方面也可能存在很大差异。
其他一些计算源甚至需要完全不同的软件层才能运行，并且对带来自己代码库的团队不友好——需要额外的迁移成本来运行实验或大型工作。
凡事没有什么是十全十美的！但提供商的服务质量是参差不齐的。
最令人沮丧的是什么？几乎不可能真正提前判断，特别是在万事俱备的情况下，人们将获得什么样的硬件，以及体验的鲁棒性/容错性如何？
有些供应商还会不小心，删除你的检查点。
我有没有提到过，不同的集群会有不同的模型翻转利用率（MFU）？
你也会得到一个不同的模型翻转使用(Mfu)为不同的集群！？如果不幸发现提供商的节点布线不良或出现其他问题，计算量浪费是无法忽视的。
在团队成员开始跨集群传输大量数据的那一刻，如果系统的文件系统非常不理想，训练运行的MFU就会下降。
每个服务提供商的售后服务也各不相同。有礼貌客气的，有不冷不热的，也有把每一件事都归咎于用户的套话。
总体而言，我们尝试的每个集群都有自己的风格、斗争和失败模式。
而且，似乎每个集群都需要针对自己的一组问题，使用热修复程序。尽管如此，我们已经了解到故障安全是重要的，为任何集群找到快速热修复方案是关键所在。
在过去的几个月里，我们构建了这么多，只是为了确保东西是可用的，例如，围绕监控、高效检查点和各种其他优化的工具。
甚至，到了安装我们的定制文件系统以实现可扩展数据存储的程度——而这只是实际需要的冰山一角。
GPUvsTPU
就我个人而言，在谷歌Pre-Reka生活中，当涉及到LLM训练时，我一直使用TPU。Cuda和NCCL对我来说是最陌生的东西。
与我在谷歌使用TPU的经历相比，GPU的故障率让我完全大吃一惊。
事实上，我并不记得TPU即使在大型运行中失败率很高。不过我不确定，自己是否只是因为拥有出色的基础架构和专门的硬件团队才不知道这一点。
事实上，UL2-20B模型（在谷歌）的训练是意外运行一个月来进行的。它从未失败过。如果这是在GPU领域，它肯定会在最初的几天内失败。
也就是说，我认为这可能更多地，取决于管理加速器的硬件团队的能力，而不是底层芯片。
拥有良好的硬件支持（来自你的计算提供商）非常重要。而这在很大程度上取决于他们是否真正有能力，这强化了「硬件彩票」的概念。
GPU领域给人感觉很奇怪。感觉多节点训练更像是事后才想到的，而不是作为TPUpods舱上的一等公民进行的分布式训练。
在GPU领域，感觉不同的提供商似乎以不同的方式对它们进行布线，以实现多节点训练，这导致在不同地点如何完成工作的差异很大。
多集群设置的痛苦
因此，必须在不同的集群中实际设置新环境的概念，对我来说是陌生的。
在当今世界，拥有多个加速器池集群似乎是不可避免的，除非一个加速器池专门在一个地点建设大量加速器池。
更具体地说，GPU供应（或缺乏）也自然导致了这种集群式采购模式，在这种模式下，事物本质上是支离破碎的。
训练大型模型还需要大量的数据，即使只是移动它们也会造成许多不便。同时，在超大规模复制数据通常也不是直截了当和令人望而却步的。
显然，最理想情况是建立某种编排层，它是专门将作业发送到不同的服务器而构建的。
我相信许多注重AI的大公司通常都有某种基础设施，以提高人工智能研究人员的生活质量。
然而，对于一家精干的新创业公司来说，在一开始就构建这种复杂而别致的ML训练基础设施是不可能的。
目前，我们最终开发了许多内部工作流来缓解其中许多问题，并正在继续朝着世界级实验基础设施的黄金标准迈进。
「野外」代码
我一直以来最喜欢的代码库是T5X和MeshTensorFlow，但它们存在一些问题：
1)它们在谷歌之外得不到太多支持，
2)它们有点不受欢迎
3)它们对我们团队中非Xoogler的人不友好。
我们最终选择了一些普通的，看起来很稳定，更受欢迎的（例如pytorch），团队中的大多数人都更容易接触到它。
在我最初的几个月里，我被pip、git、docker和所有这些野外的东西绊倒了。话又说回来，我不能100%确定在外部使用谷歌代码库会有多稳定或用户友好。
坦率地说，我不得不说，外部代码库的质量远远落后于我在谷歌习惯的那些代码库。
主要是因为谷歌内部的代码库往往是由ML大神自己编写的（比如NoamShazeer、BarretZoph、AdamRoberts、HyungWonChung等），并且与我在外部尝试过的代码库相比感觉更好。
特别是，当我涉足其他公司开发的东西时，我发现自己对代码质量超级恼火。
此外，我从来不知道更改模型并行性的能力，并不是自动的（免费的），直到一些代码库要求我编写一个转换器来更改模型的并行性。对我来说，这肯定是个难得的时刻。
另一件令人惊讶的事情是，这些代码库对大规模编解码器训练，甚至prefixLM训练的支持是如此之少。
少一点原则，多一点Yolo
系统地扩展模型通常需要一个人以有原则的方式从小到大，即分多个阶段（1B->8B->64B->300B等）进行实验，并挑选获胜者并不断扩大参数规模。
在一家初创公司中，我们执行这些大规模扫描，以检查超参数所需的计算机数量要少得多。
我们不得不多次运行Yolo，幸运的是结果很好。
最终，我们只用了较小规模和较短的烧蚀运行，即可获得强大的21BRekaFlash和7BEDGE模型，以及我们即将推出的最大核心模型。
在运行次数非常有限的情况下，找到可靠的方案具有挑战性，并且考虑到搜索空间极其巨大，需要立即更改许多变量。
为了做到这一点，人们必须放弃大科技公司的系统性，而在很大程度上依赖「Yolo」、直觉和本能。
虽然我们以前的工作中训练过非常好的模型，但在训练基础设施、数据、新想法的纳入和其他环境问题上的差异仍然会导致结果上的巨大差异。
也就是说，强大的先验有助于显著减少搜索空间，这可能是我们能够以如此少的试验、资源和实验来训练真正强大的模型的最容易的解释之一。
作者介绍
YiTay
YiTay目前是人工智能初创公司Reka的联合创始人兼首席科学家。
这是一家专注于人工智能研究和产品的初创公司，旨在构建令人惊叹的生成式模型和推进AI研究。据介绍，目前Reka正在训练先进的多模态AI模型。
在创立Reka之前，YiTay曾在谷歌大脑度过了精彩的3.3年，在那里他为许多业界定义的LLM做出了贡献，如PaLM、UL2、Flan-2和Bard，以及多模态模型，如Pali-X和VIT-22B。
值得注意的是，YiTay也是PaLM-2和PaLM-2API建模的联合负责人。