鉴于咱们在Reka成功地培训了相当弱小的多模态言语模型，许多人对从零开局建设基础设备并训练大型言语和多模态模型的阅历特意感兴味。
我在社交媒体上经常埋怨外部（Google之外）的基础设备和代码，这让人们对我在荒野中错过了什么，以及我对什么厌恶/青睐十分猎奇。所以终于有了这篇文章。这篇博客文章提醒了应战和阅历经验。
我宿愿这篇文章对许多人来说既幽默又有教育意义。
在荒野中训练LLMs（图片由Dall-E生成）
在LLMs时代的配件抽奖
人们总是以为这只是一个减速器选用（例如TPUs vs GPUs等）的疑问/争执，而一切GPU集群都是对等的。但对咱们来说，这很快就被证实是失误的。当咱们尝试不同的服务提供商时，咱们发现即使是相反的配件，例如GPU（H100），配件品质的差异也是渺小的。请留意，这里的配件指的是整个集群的品质，而不必定是芯片或减速器自身。就像彩票一样。基本上：
并非一切配件都是一样的。不同配件提供商的集群品质差异如此之大，以致于如何训练出良好模型会成为一场真正的抽奖。简而言之，这是LLM时代的配件抽奖。
更详细地说，咱们从多家计算资源提供商租用了几个集群，每个集群都有数百至数千个芯片。咱们看到的集群范围从尚可（只是一些烦人的疑问，只有破费一些 工程师的时期就可以处置）到齐全无法经常使用的集群，由于各种要素每隔几个小时就会失败。详细来说，一些集群的节点每隔N个小时就会产生缺点，疑问触及到布线疑问（其中N是不正当小的数字）、GPU配件失误等。更令人惊讶的是，同一提供商的每个集群在持重性方面也或者一模一样。
与此同时，即使其余一些集群或者领有清楚更稳固的节点，它们或者会遭遭到I/O和文件系统蹩脚的影响，甚至保留审核点都或者造成超时或破费少量时期降低集群应用率。其余一些计算资源或者须要齐全不同的软件层才干运转，关于带有自己代码库的团队来说并不友好，须要额外的迁徙成本来运转试验或大型作业。
没有完美的物品！但有些必需比其余的要蹩脚得多。
最令人丧气的局部是什么呢？简直无法能事前真正了解，尤其是在一切都在疯狂启动的状况下，人们将失掉什么样的配件以及体验的鲁棒性/容错性。
我提到了不同集群的模型浮点操作（Model Flop Utilisation，MFU）也会不同吗？假设可怜地找到布线不良或其余疑问的提供商，这将是一笔无法疏忽的计算资源糜费。具备十分次优文件系统的系统在团队成员开局在集群之间传输少量数据时，训练运转的MFU会瞬间降低。
每个服务提供商也提供不同级别的允许。这些允许从礼貌到不闻不问，从“ChatGPT格调”的套话回复再到嗔怪用户每一件事件都出错。
总的来说，咱们尝试过的每个集群都觉得有着自己的气氛、挣扎和失败形式。简直每个集群仿佛都须要为自己的一系列疑问提供自己的修复措施 - 有些疑问比其余疑问更容忍。也就是说，咱们曾经学到了备用打算的关键性，极速为任何集群找到修复措施或者是关键。
在过去的几个月里，咱们曾经做了很多上班，只是为了确保事物能够经常使用，例如，围绕监控工具、高效的审核点，以及各种其余优化，甚至装置咱们的自定义文件系统以成功可裁减的数据存储 - 并且这只是实践需求的冰山一角。
这些工具组合带来了MFU 的显着改良，同时还最大限制地缩小了蹩脚配件带来的停机时期。
GPU与TPU的对比
在Reka，咱们大局部时期都是在GPU上训练咱们的模型。就我团体而言，在Reka之前的Google生存中，我不时经常使用TPU启动大型言语模型训练。CUDA和nccl对我来说是最生疏的物品。（我只是从一个曾在Nvidia上班过的共事那里学到它的发音是“Nickel” 哈哈）
与我在Google经常使用TPU的阅历相比，我齐全惊讶于GPU的缺点率。理想上，我实践上不太记得在Google经常使用TPU时产生过太多缺点，即使是在大规模运转时，虽然我不确定我能否被这个简直太好的基础设备和专门的配件团队的弱小包全着。理想上，UL2 20B模型（在Google）是经过不小心让作业运转了一个月来训练的。它从未失败过。假设这是在GPU畛域，它必需会在最后的几天内就失败了。
话虽如此，我以为这更多地与治理减速器的配件团队的才干无关，而不是与底层芯片无关。领有良好的配件允许（来自计算资源提供商）很关键。很多事件取决于他们能否真的很有才干，这增强了“配件抽奖”的概念。
GPU畛域觉得很奇异。与在TPU架构中作为散布式训练的首要选用不同，在GPU畛域，多节点训练仿佛更像是预先想到的。在GPU畛域，仿佛不同的提供商以不同的形式将它们衔接起来以成功多节点训练，这造成了在不同中央启动事件的形式存在很大差异。虽然我不是配件方面的专家，但这是我失掉的印象。
多集群设置的痛苦
我职业生涯的大局部时期都花在了谷歌的基础设备上，它关键运转在Borg、Xmanager和Colossus上，从任何中央都可以访问一切内容。因此，实践上须要在不同的集群中设置新环境的概念对我来说是生疏的。
在环球中，除非专门为单个位置的少量集群构建，否则领有多个减速器池集群仿佛是无法防止的。更详细地说，GPU供应（或缺乏）也人造造成了这种以集群洽购的形式，其性质是扩散的。训练大型模型还须要少量的数据，即使只是将它们移动一下也会带来很多不便。与此同时，通常复制数据也不是间接的，在极大规模上是难以接受的。
显然，理想状况下是有一种专门建设的编排层，可以将作业发送到不同的主机。我置信许多大型AI优先公司通常都有某种基础设备来改善AI钻研人员的生存品质。但是，关于一个刚起步的精益的新创企业来说，构建这种复杂和花哨的ML训练基础设备实践上是不太或者的。
目前，咱们开发了许多外部上班流来减轻许多这些疑问，并且正在继续朝着环球一流的试验基础设备的黄金规范迈进。
（有人通知我，这种错乱的设置或多或少是非顶级/大公司的常态）。
代码在朝外
毫无不懂，我有史以来最青睐的代码库是T5X和Mesh Tensorflow（命名张量太赞了），但这些选项很快就变得无法行，要素是：1）它们在谷歌之外得不到太多允许，2）它们曾经有点被弃用了，3）关于咱们团队中的非谷歌人员来说并不友好。
咱们最终选用了一些惯例的、看起来比拟稳固且更受欢迎的选项（即，pytorch），这对大少数团队成员来说更易于接触（除了我哈哈）。在我最后的几个月里，我在pip、git、docker和一切这些家养的物品感到困惑。不过话说回来，我不太确定经常使用谷歌的代码库外部会有多稳固或用户友好（我猜这会十分令人厌恶）。
坦率地说，我不得不说外部代码库的品质清楚落后于我在谷歌习气的那些。关键是由于谷歌外部的代码库往往是由机器学习界的明星们亲身编写的（例如，Noam Shazeer、Barret Zoph、Adam Roberts、Hyung Won Chung等等），并且与我在外部尝试过的代码库相比，觉得更好（例如，优越的气氛）。特意是，当我尝试经常使用其余公司构建的物品时，我发现自己对代码品质感到十分恼火（有些比其余更蹩脚