Karpathy:中肯的,一针见血的。

怎么在不到一年的时间里兴办一家公司、筹集资金、购买芯片,并搭建出追逐 Gemini pro/GPT 3.5 的 LLM?

很多人都对构建根底架构和练习大言语模型和多模态模型感到猎奇,但真实走完「从零开端」这一流程的人很少。咱们普遍以为,储藏技能人才是前提,把握中心算法是要害,但实践上,工程实践中冒出来的挑战,也真实令人头疼。

一年前,乘着大模型的热潮,Yi Tay 离开了作业 3 年多的谷歌,参加兴办了一家名为 Reka 的公司并担任首席科学家,主攻大型言语模型。

在谷歌时,Yi Tay 参加过许多知名的大型言语模型和多模态模型作业,包含 PaLM、UL2、Flan-U-PaLM、LaMDA/Bard、ViT-22B、PaLI、MUM 等。即便经验如此深沉,他仍是遇到了以往无法幻想的困难。为了协助更多创业者避雷,Yi Tay 在一篇博客中共享了自己踩过的那些「坑」。

「核算稀缺和不可靠的核算提供商使事情比预期困难得多,但咱们凭借强壮的技能实力渡过了难关。终于,我写了这篇博文,揭示了其中的一些挑战和经验教训。我期望这篇文章对很多人来说都是风趣或有教育意义的。」

文章发出后,得到了很多技能创业者的谈论和转发。

「仍是谷歌好」,离任创业一年,我才发现练习大模型有这么多坑

连 Andrej Karpathy 也深有同感:

「仍是谷歌好」,离任创业一年,我才发现练习大模型有这么多坑

老练的公司有专门的团队保护集群。随着规划的扩大,集群已经脱离了工程学的范畴,变得更加生物化,因而需求专门担任「硬件健康」的团队。

「照看」练习运转是一项令人懊丧的练习大型模型日常日子体验。你需求仔细监控运转的生命体征:丢失峰值、数值问题、吞吐量、梯度标准、策略熵等。每当运转性能下降或趋于平稳时(或许经常产生),你都要快速查找堆栈盯梢,看看产生了什么。你有必要快速完结这项作业,不然或许会有 10000 个 GPU 搁置。一般,这是你从未见过的新的、独特的、可怕的过错,所以你需求寻求协助,看看是否有人能发现问题所在。

最严重的过错产生在凌晨 4 点。一般没人能看到,所以你只能制止一些看起来有点可疑的节点,并尝试重新启动运转。有时,运转失利仅仅由于你当天没有得到神的眷顾,所以你在启动命令中参加了 while True: 循环。潜在的问题或许多种多样,从某些 GPU 发热过高、偶然忽然做错乘法运算到某些路由器宕机导致网络文件体系 I/O 削减,再到数据中心的某个人在未交流的保护过程中物理断开电线衔接。有的问题你乃至永远不会知道。

也有人发现了亮点:Yi Tay 所说的「荒野」(Wild)意思是「谷歌之外的公司」。

「仍是谷歌好」,离任创业一年,我才发现练习大模型有这么多坑

要是从根底设施和硬件的视点来说,能比美谷歌的团队还真是不多。

现在,让咱们一起看看博客内容:

LLM 年代的硬件彩票

练习模型的首要条件是取得核算才能。这看似简单易行,可是,最大的惊喜却是核算提供商的不安稳性,以及集群、加速器及其衔接质量因来历不同而存在的巨大差异

人们总以为这仅仅一个加速器选择的问题 / 争论(TPU 与 GPU 等),一切 GPU 集群都是相同的。咱们的体验是,这很快就被证明是过错的。

咱们对不同的服务提供商进行了抽样调查,发现即便是相同的硬件,即 GPU(H100),硬件质量的差异也十分大。请注意,这儿的硬件指的是集群的全体质量,而不一定是芯片或加速器自身。全体感觉就像购买彩票相同。

更具体地说,咱们从几家核算提供商那里租用了几个集群,每个集群都有数百到数千个芯片。咱们所见过的集群有的还过得去(只存在一些小问题,但只需花几个小时的时间就能处理),有的则彻底无法运用,每隔几个小时就会因各种原因呈现毛病。具体来说,有些集群的节点每隔 N 个小时就会呈现毛病,问题包含布线问题(N 小得不合理)、GPU 硬件过错等。更令人惊奇的是,同一家提供商的每个集群在鲁棒性方面也或许存在巨大差异。

同时,即便其他一些集群的节点明显更安稳,它们也或许存在 I/O 和文件体系不佳的问题,乃至连保存查看点都或许导致超时,或消耗很多时间来下降集群利用率。其他一些核算资源乃至需求彻底不同的软件层才能运转,而且对自带代码库的团队不友爱 — 运转实验或大型作业需求额外的搬迁本钱。

凡事都不会一无是处,但可以确认的是,提供商的服务质量是良莠不齐的。

最令人懊丧的是什么?简直不或许真实提前知道,尤其是在万事俱备的状况下,会得到什么样的硬件,以及体验会有多么强壮 / 容错性怎么。

此外,假如供货商不能准时交货,将配备时间推迟几个月,导致用户在数周或数月内无法从其他来历采购,你更无从得知。有些供货商还会不小心删去你的查看点。

我有没有说过,不同的集群会有不同的模型翻转利用率(MFU)?假如你不幸找到了一个节点布线不良或存在其他问题的提供商,那么糟蹋的核算量是不可忽视的。假如体系的文件体系十分不理想,那么当团队成员开端跨集群传输很多数据时,练习运转的 MFU 就会下降。

每个服务提供商的售后水平也各不相同。从礼貌客气到不冷不热,从「对话式」的预制回复到将一切问题都归咎于用户,不一而足。

总之,咱们尝试过的每一个集群都有自己的风格、奋斗和失利形式。而且,简直每个集群都需求自己的热修复程序来处理一系列问题。尽管如此,咱们仍是认识到毛病安全是十分重要的,为任何集群找到快速的热修复方案都是要害所在。

在过去的几个月里,咱们构建了许多东西,以确保一切都可用,例如,环绕监控、高效查看点和其他各种优化的东西,乃至安装了咱们的自定义文件体系,以完成可扩展的数据存储,而这仅仅实践需求的冰山一角。

这些东西的组合为 MFU 带来了非同寻常的改善,同时也最大极限地削减了在硬件条件恶劣的状况下的停机时间。

GPU vs TPU

就我自己的公司来说,大部分时间都在运用 GPU 练习模型。不过在参加 Reka 之前,我在谷歌的大型言语模型练习中一直运用 TPU。CUDA 和 nccl 对我来说是最生疏的东西 (我是从一位曾在 Nvidia 作业的同事那里才知道它的发音是 Nickel 的)。

与我在谷歌运用 TPU 的阅历相比,GPU 的毛病率让我彻底大吃一惊。事实上,我并不记住 TPU 产生过很多毛病,即便是在大型运转中也是如此,不过我不确认,自己是否仅仅由于具有出色的根底架构和专门的硬件团队才不知道这一点。事实上,谷歌的 UL2 20B 模型是经过意外运转一个月来练习的。假如是在 GPU 范畴,它肯定会在开始几天内就失利。

话虽如此,我以为这或许更多与管理加速器的硬件团队的才能有关,而不是底层芯片。具有良好的硬件支撑(来自核算提供商)十分重要。而这在很大程度上取决于他们是否真的有才能,于是,又印证了「硬件彩票」的概念。

GPU 范畴给人的感觉很奇怪。与分布式练习在 TPU pods 上的一等公民地位相比,多节点练习更像是一种过后考虑。在 GPU 范畴,感觉就像不同的提供商以不同的方法将它们衔接起来,以完成多节点练习,这导致不同地方的做法差异很大。

尽管我不是硬件专家,但这便是我的真实印象。

多集群设置的苦楚

我职业生涯的大部分时间都是在谷歌根底架构上度过的,这些根底架构首要运转在 Borg、Xmanager 和 Colossus 上。因而,有必要在不同的集群中树立新环境的概念对我来说十分生疏。

在当今年代,具有多个加速器池集群似乎是不可避免的,除非专门在一个地点树立很多的加速器池。更具体地说,GPU 的供应(或供应缺乏)自可是然地造成了这种集群采购形式,在这种形式下,事物的性质是支离破碎的。练习大型模型还需求很多的 TB 级数据,即便仅仅移动数据也会带来诸多不便。同时,仿制数据一般也不是一件简单的事情,而且在超大规划的状况下,仿制数据的本钱也很高。

显然,最理想的状况是树立某种编列层,专门将作业发送到不同的服务器。我信任,许多注重人工智能的大公司一般都有某种根底设施,以进步研究人员的日子质量。可是,关于一家草创公司来说,在开端阶段树立这种杂乱而花哨的 ML 练习根底设施其实是不或许的。

现在,咱们公司开发了许多内部作业流程来缓解这些问题,并持续朝着世界级实验根底设施的黄金标准跨进。(有人告诉我,关于非尖端 / 大型公司来说,这种简陋的设置或多或少是一种常态)。

野生代码

众所周知,一直以来我最喜欢的代码库是 T5X 和 Mesh Tensorflow,但它们有一些缺陷:

1)它们在 Google 之外没有得到那么多的支撑;

2)它们有点被弃用了;

3)它们对咱们团队中的非 xoogler 不友爱。

咱们终究选择了一些一般的、看似安稳且更盛行的东西,即 pytorch。pytorch 对团队中的大多数人(除了我)来说更简单运用。

在开始的几个月里,我对 pip、git、docker 和一切「野生(wild)」的东西感到困惑。话又说回来,我不能 100% 确认在外部运用 google 代码库有多安稳或多用户友爱。

坦率地说,外部代码库的质量明显落后于我在谷歌习惯运用的代码库。首要是由于谷歌内部的代码库往往是由 ML 大牛自己编写的(例如 Noam Shazeer、Barret Zoph、Adam Roberts、Hyung Won Chung 等人),而且与我在外部尝试过的代码库相比感觉更好。

别的,我从来不知道更改模型并行性的才能不是主动(免费)的,直到某些代码库要求我编写一个转换器来更改模型的并行性。对我来说,这肯定是一个「WTF 时间」。

令人惊奇的是,这些代码库对大规划编码器 – 解码器练习乃至 prefixLM 练习的支撑十分少。

少一点准则,多一点 Yolo

体系地扩展模型一般需求有准则地从小到大,即分多个阶段(1B→8B→64B→300B 等)进行实验,然后选出获胜者并不断扩展它们。在草创公司中,咱们履行大规划扫描来查看超参数的核算量要少得多。终究,咱们不得不屡次运转 Yolo,走运的是成果很好。

终究,咱们只需求极少数的较小规划和较短的烧蚀运转即可取得强壮的 21B Reka Flash 和 7B 边缘模型,以及咱们行将推出的最大中心模型。在运转次数十分有限的状况下找到可靠的方案具有挑战性,而且考虑到搜索空间极端巨大,需求立即更改许多变量。为了做到这一点,人们有必要放弃大型科技公司的体系性,而在很大程度上依赖「Yolo」、直觉和天性。

值得庆幸的是,我以及咱们团队中的许多人在咱们的 ML 职业生涯中已经积累了相当多的「直觉」,可以在很短的尝试时间内得到正确的成果。尽管咱们在之前的作业中练习过十分好的模型,但练习根底设施、数据、新想法的交融和其他环境问题的差异依然或许导致成果的巨大差异。也便是说,强壮的先验有助于显著削减搜索空间,这或许便是咱们能够经过如此少的实验、资源和实验练习出真实强壮的模型的原因之一。

原文链接:www.yitay.net/blog/traini…