做网站公司logo,网站建设的7种流程,临邑建设局网站,公司简介ppt内容2022年11月30日#xff0c;OpenAI发布ChatGPT#xff0c;以很多人未曾预料的速度迅速走红。与此同时#xff0c;由于短时间内用户量的暴涨#xff0c;导致服务器过载#xff0c;迫使OpenAI停止新用户的注册。 ChatGPT发布这一年#xff0c;同样的情景发生了好几次。在最近… 2022年11月30日OpenAI发布ChatGPT以很多人未曾预料的速度迅速走红。与此同时由于短时间内用户量的暴涨导致服务器过载迫使OpenAI停止新用户的注册。 ChatGPT发布这一年同样的情景发生了好几次。在最近的OpenAI开发日之后使用量再度激增随后OpenAI宣布暂停新用户使用其付费服务。 这背后体现了大模型提供规模化服务时运维的重要性。Evan Morikawa是OpenAI的工程团队经理目前他主要负责将ChatGPT API等工程产品和设计安全地推向全世界。在近期的一次演讲中他分享了OpenAI在ChatGPT发布过程中面临的工程、产品和组织方面经历的挑战以及从中学到的经验和教训。 以下内容由OneFlow编译发布转载请联系授权。原文https://www.youtube.com/watch?vPeKMEXUrlq4t109s 来源 | LeadDev OneFlow编译 翻译杨婷、宛子琳 2022年11月30日我们发布了ChatGPT。当时OpenAI团队对ChatGPT发布后的前景持不同看法。 这是我们第一次允许公众无需预约即可自由访问模型这让一些同事感到紧张。在团队内部我们已经感受到ChatGPT的有趣之处并且认为在它发布以后很可能迅速走红。此外我们的GPU资源有限可能会出现访问资源上的供不应求。过去我们对聊天应用一直持保守态度尽管ChatGPT更安全对齐程度更高安全系统更加完善但仍面临着被滥用的风险。 同时团队中有人对此并不太担心因为人们已经可以通过开发者平台免费使用ChatGPT并且ChatGPT也不一定会走红。此外这只是几个月前发布的GPT-3.5的微调版本并不是下一代模型GPT-4而微调版本的模型更加安全。最后我们没有媒体发布会只是发布了一篇博客和一条推文因此似乎不会出什么问题。 在完成最后一次负载测试后我们发布了ChatGPT。随后平台流量开始上涨并逐渐稳定实际上发布后的流量低于我们的预期。我们一直密切关注发布后的情况在当天的Hacker News上我们的最高热度甚至没有进入前五但我们还是感到比较满意。 在内部我们将这种情况称为“低调的研究预览low key research preview”现在这一术语已经带上了一些负面色彩但当时我们的发布会确实是一个相对低调的研究预览因此当天大家都能在11月30日晚上正常休息。 第二天早上凌晨4点我们收到了值班室的警报。出于某种原因日本的用户访问量激增因为日本是最早醒来的地区。之后消息在Twitter上传开Elon Musk也发布了一篇关于ChatGPT的推文导致热度进一步高涨。 这时候我们遇到了一点麻烦为处理突增的流量团队实施了一个容量控制措施这种方法类似于俱乐部门卫即一旦达到容量限制我们将不允许新用户注册直到有用户离开。 我们认为相比传统的预约等待列表这种方式能让更多人有机会体验ChatGPT。然而在内部我们将这称之为“失败鲸fail whale”。当时我们已经达到了容量上限没有更多GPU可用了但“失败鲸”数量一直在上涨。网站常常崩溃网页经常显示“容量已达上限”实际上我们已经尽了最大努力提供最大容量。 在ChatGPT发布后的几个月里网站流量越涨越多越涨越快因此我们团队一直在努力使网站保持稳定以满足人们的需求。 在ChatGPT的发布过程中我们学到了很多经验教训在这里我主要强调三点第一GPU和大规模运行语言大模型的能力第二打造一个理智且不断学习成长的团队第三学习应对模型可能面临的滥用问题和安全挑战。 1 ChatGPT与GPU 首先我想讨论一下GPU以及ChatGPT如何更好地利用GPU。GPU对ChatGPT及其构建的API至关重要由于GPU供应极为有限其特性和成本决定了我们的运营和扩展方式。 为ChatGPT提供动力的计算机拥有大量GPU每个节点有8块A100 GPU每个GPU都配备了特殊的高带宽内存HPM并且需要在所有GPU之间进行通信。为实现这一点我们采用了NVIDIA提供的特殊NVLink互联技术并通过板上的开关将多个GPU紧密连接起来使它们能够高速交换数据。同时系统的每张GPU卡还通过以太网和InfiniBand技术连接到外界该技术为每张GPU提供了200Gb/s或将提升到400Gb/s的网络带宽。对于ChatGPT等大模型每一点额外的计算能力或带宽的提升都直接影响模型的用户体验和我们所能提供的服务质量。 GPU有许多值得关注的方面但今天我主要专注以下几个方面GPU内存和KV缓存、批处理大小、算子、数据传输量与浮点运算数量Bytes and arithmetic intensity、任务调度以及自动扩展等。 GPU内存和KV缓存 为了更好地介绍这些内容先简要带大家复习一下AI模型的工作原理。 当我们向ChatGPT提问时模型首先接收文本将其切分成词元tokens然后将每个词元转换为一组数字向量再通过数百亿个模型权重进行乘法运算。这些模型权重通过梯度下降逐渐微调方法是预测互联网上所有单词的下一个单词来进行训练然后我们会计算出下一个最可能出现的词元的概率。通过不断重复这个步骤ChatGPT会最终生成相应的内容。 在这种架构中每个词元都能感知到其他单个词元这就是自注意机制。文本或上下文越长我们需要进行的数学运算就越多。不幸的是自注意机制的复杂度是二次的文本越长所需的数学运算也会呈二次增长。此外我们还需要昂贵的投影操作来用不同维度来映射事物这听起来可能不太具有优势但我们需要关注几个相关的属性。 首先我们可以在先前的所有词元上进行数学计算并进行缓存这就是KV缓存K、V指的是在注意力机制中使用的主要矩阵的名称。需要注意的是第三个矩阵Q的数值每次都会变化并且无法被缓存实际上这只是一种命名约定。最关键的是我们需要将这个缓存存储在GPU中这是一种特殊的HBM3内存。之所以选择使用HBM3内存是因为通过PCIe总线传输数据的速度比HBM3内存慢两个数量级而HBM3内存的传输速度达到3TB/s对于处理大量数据非常重要。由于HBM3内存与GPU相连因此具有极高的并行数据吞吐量。 由于GPU HBM内存价格昂贵且容量有限因此主要用于存储模型权重。一旦这些内存空间用完系统将按照“最旧的先过期”原则来管理内存。如果发生缓存未命中即需要的数据不在缓存中我们就需要重新计算整个聊天对话。此外由于我们在所有用户之间共享GPU内存如果某个对话在一段时间内没有操作它可能会被移出内存。 上述情况意味着首先GPU内存实际上成为我们最宝贵的资源之一它常常代表着某些运算瓶颈而不仅仅是计算量本身。其次缓存未命中会对GPU的工作量产生显著的非线性影响因为我们突然需要重新计算所有内容。 因此在扩展ChatGPT时我们不能只简单考虑CPU利用率指标还需要关注KV缓存尽可能充分利用所有GPU内存。 批处理大小 批处理大小是另一个指标大致表示在同一时间发送到GPU的并行请求数量。在H100 GPU中最多可以在内存寄存器中移动3.35TB/s的RAM并且在这一秒内我们可以执行1.98千万亿次8位浮点数的乘法运算。 这意味着在移动一个字节的时间可以执行591次浮点运算在行业中这被称为591:1的运算比率。换句话说如果要花一定时间移动整个千兆字节的数据就应该至少执行5910亿次浮点运算否则会浪费GPU和潜在计算能力。但如果超过这一比率就需等待内存带宽将数据传输到内存中。 在ChatGPT模型中需要移动的内存量基本是固定的大致等于模型权重大小。这意味着通过改变批处理大小可以控制可执行的数学运算量。 因此在扩展ChatGPT时我们还需要监视批处理大小以确保GPU得到充分利用。 总体而言批处理大小和KV缓存的结合是我们确定服务器负载程度的主要指标我们花了一些时间才确定这一结论。最初我们使用类似于标准CPU利用率指标的简化GPU利用率指标但结果证明这一指标具有误导性。 简单的利用率指标只能告诉我们在某个时间段内GPU是否在进行数学计算而不能告知我们计算强度是否已经饱和或者我们是否正在耗尽KV缓存。 数据传输量与计算强度 虽然在这里我只讨论了KV缓存和批处理大小但实际上瓶颈也可能来自内存带宽、网络带宽、GPU以及节点等各种因素。此外这些瓶颈的位置在模型大小、架构和使用模式上也差异巨大。例如相比让ChatGPT写文章它在总结文章方面的性能特性有着天壤之别。 实际上对于OpenAI和芯片制造商来说由于上述差异要设计出完美平衡的芯片十分困难。例如尽管下一代H100相比A100计算性能提高了6倍但内存带宽只增加了2倍我们与其他语言大模型公司发现很容易碰到内存限制这实际上限制了新GPU的增益价值。而且由于H100设计方案几年前就已经确定NVIDIA本身无法预知这一点。 未来的机器学习架构和规模对于我们和其他人来说都难以预测但总体而言我们需要不断调整数学计算使其与模型的演进相匹配。 其次我们面临的挑战是GPU的供应问题。OpenAI和整个AI领域的发展速度远远超过了NVIDIA或整个台积电供应链能够生产的速度。由于半导体和数据中心供应链的复杂性我们会遭遇各种瓶颈。因此摆脱这一困境的方式之一就是尽可能地获取GPU而选择合适的地理位置可能会缓解GPU紧张的问题。 因此我们的业务范围很快就覆盖了全球多个地区。需要注意的是上图实际上是Azure公共区域的地图我们是基于Microsoft Azure进行部署的但仅限于图中所示的部分地区。为应对业务范围的扩展团队不得不迅速熟悉Terraform和集群管理以便快速创建和管理这些部署。尽管从一开始就实现多区域和多集群的部署极具挑战但由于GPU资源紧缺这是不可避免的。 此外需要注意的是响应时间主要由GPU逐个输出词元的时间所决定。因此为提高整体响应速度关键是增加服务器集群的容量并优化而不是单纯追求服务器与用户离得近以减少网络延迟。 最后一个主要挑战是无法迅速扩展服务器集群没有更多GPU资源可供自动扩展。这意味着当ChatGPT显示“已满载”页面时团队无法手动或自动地增加服务器来应对增加的用户流量。这也导致由于GPU容量不足我们不得不推迟一些发布计划和产品功能的推出。 我认为人们可能没有充分意识到如果GPU不受限地供应ChatGPT所取得的增长可能会更大、更快。 因此在解决GPU带来的挑战时我们学到了一些关键教训。 首先我们需要明确这是一个系统工程挑战而不仅仅是纯粹的研究项目这至关重要。我们优化键值KV缓存、全球数据中心战略以及产品需求的能力非常重要团队能够跨越整个技术栈也是关键所在。 其次适应性地考虑系统的约束条件十分关键。在OpenAI之前我习惯于观察只有80%的CPU利用率指标就自动扩展到一个无限大的云平台并优先考虑边缘计算但在这里这一切都不适用。此外每当模型架构发生变化、提出新的推理想法或产品决策发生变化时我们都需要灵活适应并重新运行这些计算。 最后深入研究的重要性。对于我们而言最底层的实现细节至关重要。尽管我愿意将其视为一个黑匣子接收文本输入然后在另一端输出更智能的文本但实际上更多人深入研究这个“匣子”的细节我们就能取得更大进步。随着GPT-5、微调、代码执行和更大规模等问题不断升级这些挑战只会变得更加复杂。尽管我谈论这些问题时是以ChatGPT为背景但我预计这些经验在未来仍将继续发挥作用。 2 团队建设 我想讨论的第二个经验教训是在努力保持灵活性和快速推进的同时扩大团队。 在ChatGPT项目发布时应用工程团队包括我在内总共大约有30人。现在10个月后团队规模已增长到近100人。众所周知OpenAI在团队规模增长方面一直存在着高度的紧张关系。我们的首席执行官Sam Altman一直坚信高人才密度并致力于以尽可能小的团队完成尽可能多的工作。因此我们一直在努力保持团队的小规模以保持快速迭代、充满朝气的实干文化。 然而随着产品规模的扩大我意识到扩大团队规模的迫切性。在其他地方可能需要数百人的部门在我们团队却只有几个人在支撑而且有时甚至有人在度假。我认为我们做过的最有影响力的事情之一就是将自己组织起来以捕捉高度整合、快速发展的初创企业最初阶段的本质。 ChatGPT背后的团队看起来像一家刚成立10个月的初创公司。在ChatGPT项目刚开始时团队有意识地选择了一个全新的代码仓库、新的集群和轻量级的安全控制。我们还确保研究团队与产品开发周期紧密结合对我们来说DERP设计、工程、研究和产品应该集中在一个团队中。 如今团队的运行节奏、流程状况、沟通效率以及每个人的责任水平都更加贴近我们对成立一年的初创公司的预期。此外OpenAI还有一点与众不同当初大家都在同一个办公室里共同努力实际上这在混乱的初创时期起到了一定作用。 实际上ChatGPT并非OpenAI第一次采用这种合作模式的项目。大约三年前当应用团队研究API时我们也做了类似的事。因此在整个组织中尽管ChatGPT项目感觉像是一个嵌套在有三年历史初创公司中的10个月大的创业项目但这些都嵌套在有八年历史的OpenAI研究实验室中。随着新的产品类别不断涌现我们预计将尝试并继续采用这种分形初创公司模式fractal startup pattern。 如今这一策略要取得成功确实存在一定挑战我们承担了部分技术债务和重复的情况现在开始加大对泛工程平台团队的投资以提前应对其中的部分挑战。 我们还存在人才扩张的严重倾向因为OpenAI一直推崇小团队理念希望充分利用其优势但我们也开始面临规模和安全相关问题这些问题需要定制化程度更高和更高效的解决方案。 实际上我们确实需要一个极具抱负的团队和一个非常坚定的使命来帮助保持每个人都朝着同一个方向前进。 OpenAI的首要使命是实现一个安全且对齐的通用人工智能AGI这使得我们需要权衡许多不同的愿景。我们的确会扪心自问这是否使我们更接近实现安全且对齐的AGI以指导未来的发展。 与此同时像这样的小型初创公司具有巨大的优势。当拥有高度的所有权、低依赖性和简化的流程时工作更容易完成。初创公司更能保持一种斗志旺盛的环境我们的迭代周期可以非常短。 同时在这一领域中产品问题与研究问题密切相关。我们可以深入思考一下使创业公司保持高效率的因素并观察如何在结构上融入这些因素。这并非毫无代价但我们认为当高效率成为我们的关键优势之一时这种权衡是值得的。 3 滥用问题和安全挑战 最后系统滥用和即将到来的人工智能安全问题是我们面临的主要挑战。在OpenAIAI安全、API滥用和产品是密不可分的。防止AI用于大规模的虚假信息宣传、放大互联网上最糟糕的部分或导致其他形式的伤害是我们的核心使命。确保采取适当的安全措施一直是项目发布和其他行动的主要阻碍因素。 尽管OpenAI采取了一系列的安全措施来防止系统滥用但是滥用者往往能够迅速适应并找到新的方式来滥用系统。特别是当滥用行为可以带来经济利益时这种适应性尤为明显。 我想给大家分享一个故事关于一群人对ChatGPT的API进行逆向工程以及我们对此所采取的措施。一位工程师发现我们的端点上出现了一些与标准客户端签名不完全匹配的流量。当时相比API流量ChatGPT应用程序在某种程度上拥有特权。因此通过ChatGPT获取访问权限的滥用者可以比普通API做更多的事。如果我们直接封锁这些攻击者他们会立即察觉并做出调整。 团队中的一位成员提出了一个想法我们采纳了该想法并立即采取了相应行动。事实证明我们的安全团队一直在积极监控这些滥用者的活动。他们加入了滥用行为发生的Discord社区以便能够从滥用者的角度观察和了解情况。 攻击者很快就察觉到了异常他们的山寨API不再有任何意义。但他们很快弄清了状况不仅如此甚至给了我们下次更新的建议。随着时间推移我们发现了更多试图滥用API的人尽管他们的能力不及ChatGPT。 因此虽然ChatGPT可能只是今天一个有趣的例子但随着模型变得更加强大如果落入错误的人手中可能造成更大的危害。我们需要以指数级速度增加对滥用行为的警惕性。尽管如此仅靠团队成员、研究人员和红队成员是不可能识别所有可能的滥用和误用途径。这就是为什么我们相信逐步与现实世界进行有限的接触是识别和解决安全问题最重要的方式之一。 与真实用户进行早期和频繁的迭代是产品开发中一种常见的做法。在开发ChatGPT时我们也采用了这种理念。不过我需要指出的是一次性向所有人发布ChatGPT是因为我们花了数年时间在更受控制的环境中逐渐适应了这些模型。而对于较新、风险较高的产品我们将在识别和缓解风险的过程中经历几个阶段后才会推出。 此外我们还相信随着风险的增加需要根据情况调整这一策略。波音公司之所以不像Facebook那样快速地发布产品是有其原因的而我们今天的关注点与明天的关注点将会有很大不同。 4 结语 ChatGPT的故事只是刚刚开始我预计今天我谈到的这三个挑战将以新的形式持续存在。虽然随着芯片供应链的迎头赶上GPU可能会变得更加丰富但随着消耗越来越大的预算更加高效地利用GPU的需求也将不断增长。 GPT-5和其他产品的发布对计算资源的需求将变得更加紧迫。这个层面会考虑到不同的扩展因素因为GPU的RAM和高带宽互连与每秒能够进行多少次乘法运算同等重要。 保持团队中初创企业的本质一直是我们保持灵活性的唯一方式。虽然这涉及到权衡但我们已经多次重复这样的努力。随着我们的成长这将变得更加具有挑战性。同时随着新的挑战出现OpenAI在企业文化方面的努力也必须不断调整以延续这种精神。 最后OpenAI一直面临一些意想不到的挑战尤其是那些精明滥用者的挑战。虽然这些挑战并不总是令人愉快但有时我们也能从中有所收获。因此尽管前文提到的CatGPT可以缓解先前的滥用问题但在未来滥用安全和对齐挑战将更加严峻如果这些问题变得更为复杂我们将需要投入更多努力。安全任务是一个核心问题我们将持续重点关注这一领域。 关于ChatGPT的幕后故事还有很多至少和那些为实现这一切作出贡献的人一样多。即使这些故事的一小部分也代表了数十位工作人员的辛勤努力。非常有幸与你分享他们的工作。 其他人都在看 GPU架构与计算入门指南 为什么开源大模型终将胜出 可复现的语言大模型推理性能指标 OpenAI“驾驭”超级智能的四年计划 语言大模型推理性能工程最佳实践 OpenAI首席科学家直面AGI的可能性 开源语言大模型演进史向LLaMA2看齐 试用OneFlow: github.com/Oneflow-Inc/oneflow/http://github.com/Oneflow-Inc/oneflow/
