买卡就像中彩票Karpathy转赞前谷歌科学家离职创业

　　一家大模型初创公司从创立到训练出大模型，要克服怎样的难题？前谷歌科学家离职后创业一年，发文自述算力是训练大模型的难点。

　　在这篇博文中，我讨论了： 1. 在不同计算提供商中采购计算和差异的经验。我们最大的发现/惊喜是差异超级不同，几乎是人们可以获得的「硬件彩票」！ 2. 讨论「野外」基础设施/代码，并过渡到我在谷歌的习惯 3. 训练模型时的新思维方式。

　　在整个创业过程中，他认为最大的困难便是——算力稀缺、算力提供商差异巨大，让大模型的训练比预期要难得多。

　　对此，Yi Tay写了一篇长文，自述了从0开始如何创办一家公司，筹集资金、购买芯片，训练出了能够与Gemini pro/GPT 3.5，甚至超越其他LLM的模型。

　　Karpathy对此表示深刻地赞同：「这篇文章精彩地讨论了一个鲜为人知的话题：训练LLM的难点」。

　　工程师需要像「保姆」一样密切监控训练过程，关注关键指标，一旦出现问题要及时排查，否则会浪费大量计算资源。

　　训练常常因为各种未知原因失败，需要重启尝试。训练大模型考验整个计算系统的容错能力，因此除了考虑性能和成本，还要评估整体服务质量和团队效率。

　　人们总是认为，这只是一个关于加速器选择的问题/争论（TPU还是GPU等等），所有的GPU集群都是平等的。

　　当我们对不同的服务提供商进行抽样时，发现即使对于相同的硬件，即GPU（H100），硬件质量的差异也有很大差异。

　　请注意，这里的硬件指的是整体集群质量，而不一定是芯片或加速器本身。就像「彩票」一样。基本上：

　　并非所有硬件都是一样的。不同硬件提供商的集群质量差异非常大，以至于要想训练出好的模型需要付出多大的代价，这简直就是在抽签。简而言之，LLM时代的硬件彩票。

　　我们已经看到了各种集群，从还可以的（只存在一些小问题，但只需花几个小时的时间就能解决）到完全不可用的集群，每隔几个小时就会因为无数的原因而失败。

　　具体地说，一些群集的节点每N小时出现一次故障，出现的问题包括布线问题（其中N小得不合理）、GPU硬件错误等。

　　与此同时，即使其他一些群集可能具有更稳定的节点，它们也可能会受到I/O和文件系统不佳的影响，即使保存检查点也可能导致超时或极长的时间消耗在群集利用率上。

　　博彩通

　　其他一些计算源甚至需要完全不同的软件层才能运行，并且对带来自己代码库的团队不友好——需要额外的迁移成本来运行实验或大型工作。

　　最令人沮丧的是什么？几乎不可能真正提前判断，特别是在万事俱备的情况下，人们将获得什么样的硬件，以及体验的鲁棒性/容错性如何？

　　最重要的是，你也无法知道供应商是否只是未能按时交货，将发货推迟了几个月，导致用户滞留数周或数月，无法从其他来源采购。

　　你也会得到一个不同的模型翻转使用(Mfu)为不同的集群！？如果不幸发现提供商的节点布线不良或出现其他问题，计算量浪费是无法忽视的。

　　在团队成员开始跨集群传输大量数据的那一刻，如果系统的文件系统非常不理想，训练运行的MFU就会下降。

　　每个服务提供商的售后服务也各不相同。有礼貌客气的，有不冷不热的，也有把每一件事都归咎于用户的套话。

　　而且，似乎每个集群都需要针对自己的一组问题，使用热修复程序。尽管如此，我们已经了解到故障安全是重要的，为任何集群找到快速热修复方案是关键所在。

　　在过去的几个月里，我们构建了这么多，只是为了确保东西是可用的，例如，围绕监控、高效检查点和各种其他优化的工具。

　　就我个人而言，在谷歌Pre-Reka生活中，当涉及到LLM训练时，我一直使用TPU。Cuda和NCCL对我来说是最陌生的东西。

　　事实上，我并不记得TPU即使在大型运行中失败率很高。不过我不确定，自己是否只是因为拥有出色的基础架构和专门的硬件团队才不知道这一点。

　　事实上，UL2-20B模型（在谷歌）的训练是意外运行一个月来进行的。它从未失败过。如果这是在GPU领域，它肯定会在最初的几天内失败。

　　拥有良好的硬件支持（来自你的计算提供商）非常重要。而这在很大程度上取决于他们是否真正有能力，这强化了「硬件彩票」的概念。

　　GPU领域给人感觉很奇怪。感觉多节点训练更像是事后才想到的，而不是作为TPU pods舱上的一等公民进行的分布式训练。

　　在GPU领域，感觉不同的提供商似乎以不同的方式对它们进行布线，以实现多节点训练，这导致在不同地点如何完成工作的差异很大。

　　在当今世界，拥有多个加速器池集群似乎是不可避免的，除非一个加速器池专门在一个地点建设大量加速器池。

　　更具体地说，GPU供应（或缺乏）也自然导致了这种集群式采购模式，在这种模式下，事物本质上是支离破碎的。

　　训练大型模型还需要大量的数据，即使只是移动它们也会造成许多不便。同时，在超大规模复制数据通常也不是直截了当和令人望而却步的。

　　然而，对于一家精干的新创业公司来说，在一开始就构建这种复杂而别致的ML训练基础设施是不可能的。

　　目前，我们最终开发了许多内部工作流来缓解其中许多问题，并正在继续朝着世界级实验基础设施的黄金标准迈进。

　　我们最终选择了一些普通的，看起来很稳定，更受欢迎的（例如pytorch），团队中的大多数人都更容易接触到它。

　　在我最初的几个月里，我被pip、git、docker和所有这些野外的东西绊倒了。线%确定在外部使用谷歌代码库会有多稳定或用户友好。

　　主要是因为谷歌内部的代码库往往是由ML大神自己编写的（比如Noam Shazeer、Barret Zoph、Adam Roberts、Hyung Won Chung等），并且与我在外部尝试过的代码库相比感觉更好。

　　此外，我从来不知道更改模型并行性的能力，并不是自动的（免费的），直到一些代码库要求我编写一个转换器来更改模型的并行性。对我来说，这肯定是个难得的时刻。

　　另一件令人惊讶的事情是，这些代码库对大规模编解码器训练，甚至prefixLM训练的支持是如此之少。

　　为此，尽管出于任何原因对GitHub问题提出了合理的要求，但即使是闪电般的关注也一直拒绝为Prefix LM训练提供支持。

　　系统地扩展模型通常需要一个人以有原则的方式从小到大，即分多个阶段 （1B-8B-64B-300B等）进行实验，并挑选获胜者并不断扩大参数规模。

　　最终，我们只用了较小规模和较短的烧蚀运行，即可获得强大的21B Reka Flash和7B EDGE模型，以及我们即将推出的最大核心模型。

　　在运行次数非常有限的情况下，找到可靠的方案具有挑战性，并且考虑到搜索空间极其巨大，需要立即更改许多变量。

　　为了做到这一点，人们必须放弃大科技公司的系统性，而在很大程度上依赖「Yolo」、直觉和本能。

　　庆幸的是，我和团队中的许多人，在我们的ML职业生涯中积累了相当多的这种直觉，以便在相当短的时间内将得到正确结果。

　　虽然我们以前的工作中训练过非常好的模型，但在训练基础设施、数据、新想法的纳入和其他环境问题上的差异仍然会导致结果上的巨大差异。

　　这是一家专注于人工智能研究和产品的初创公司，旨在构建令人惊叹的生成式模型和推进AI研究。据介绍，目前Reka正在训练先进的多模态AI模型。

　　在创立Reka之前，Yi Tay曾在谷歌大脑度过了精彩的3.3年，在那里他为许多业界定义的LLM做出了贡献，如PaLM、UL2、Flan-2和Bard，以及多模态模型，如Pali-X和VIT-22B。

　　在Yi Tay担任谷歌研究科学家期间，他发表的大部分作品都围绕着Transformer展开，尤其是与效率、可伸缩性和架构研究相关的内容。