-
友情链接:
Powered by 开云(中国)Kaiyun·官方网站 - 登录入口 @2013-2022 RSS地图 HTML地图
开云(中国)Kaiyun·官方网站 - 登录入口
图片系 AI 生成
现时,大模子最权贵的特征之一即是参数目呈指数级增长。凭证 Scaling Law(标准定律)的纪律,东说念主工智能神经麇集的参数目越多,模子越大,关于常识的总结归纳和推理泛化才气就越强。因而,从 ChatGPT 出现考证了"流露"才气,到如今的两年里,业内重要温暖的即是算力,如何打破硬件算力,如何故尽可能少的 Token 数目磨真金不怕火好一个模子。但在这一权贵挑战以外,数据量猛增带来的数据存储,可能是仅次于算力的另一大本事难点。
大模子"卷"向存储
岁首,一位长期温暖 AI 大模子应用的 CTO 与钛媒体 APP 相易中示意:"企业使用外部数据磨真金不怕火大模子,长文本是枢纽念念路之一。但问题是,长文本处理特等破费内存和硬件,因为模子磨真金不怕火和推理的内存变大,模子结尾才能更好。这也导致在其每次查询的资本高于 GPT-4,尔后者基于微调。这不是 ToB 企业大要职守得其起的。"
他对钛媒体 APP 阐明:微软提议了大模子的"不能能三角",如果但愿模子的微调才气很强,那么模子参数就不会很大,或者小样本的学习才气不会很强。长文本的逻辑是,让小样本学习的才气变强,同期烧毁微调,这么模子参数细则就会相应扩大。
彼时,恰巧国内长文本高涨。除了最早的 Kimi,阿里巴巴、百度、360 等宽敞厂商接踵晓喻进军长文本,从率先的可处理 200 万字高下文,迅速膨胀至 1000 万字长文本才气。而在这股高涨中,也不异留传了诸多待管束的问题。
凭证本事博客 Medium 上一位 AI 工程师 Szymon Palucha 的记载:
以阿里开源的 Qwen2-7B(7 亿参数)大模子为例。目下 GPU 显存大小基本在 80GB(以英伟达 A100 为例),那么如果拿不到更好的 A100 时,他凭证公式:参数模子内存 =7B*32 位 =7B*32/8 字节 =28B 字节 =28GB,测算出运行该模子至少还需要 28GB 内存,这还不算推理经过中对存储产生的额外支拨。
为此,最简便的目的是镌汰参数精度,因为当今多数大模子不错半精度使用,而不会权贵影响准确性。这意味着大模子在实质运行时,需要一定的内存或存储空间来存储和处理数据,大模子所需的内存量会凭证高下文窗口的大小而变化。窗口越大,所占用的内存也就越多。
钛媒体介意到,这亦然当下大模子应用厂商在破解算力问题以外,碰到的另一大本事贫苦点,昨年还莫得太多东说念主温暖——数据量猛增带来的数据存储、内存带宽、时延等一系列问题。而且跟着需求的爆发,照旧带来一些本事侧产物侧的演进。
支抓万卡算力和万亿参数 LLM,存储两说念槛
目下内行的科技巨头都在布局万卡算力集群和万亿参数范围的大模子磨真金不怕火,关于这些集群而言,高性能的推敲、存储和麇集不能偏废。从存储层面来看如何提供支抓?一是要至少达到 TB 级带宽、百万级 IOPS 的存储性能,改日可能会演变为数十 TB、上亿级 IOPS 的需求;二是要升迁数据跨域改变、数据安全、数据可抓续性拜谒等才气。
追思夙昔两年间大模子带来的存储挑战,不错从三个阶段总结:
2022 岁首:大模子爆发初期,国内有杰出 100 家的大模子公司驱动迅速进行商场布局。在这个阶段,模子磨真金不怕火追求的即是"快",通过 IT 基础设施的决策优化,有用地升迁 GPU 服从,加快模子的磨真金不怕火并取得商场认同,即可霸占商场先机。
为此,模子磨真金不怕火的数据加载、模子磨真金不怕火经过中的断点续训要尽可能地镌汰对推敲时刻的占用,在万卡算力集群万亿参数的大模子的快速磨真金不怕火时,小于 1 分钟断点续训,需要存储提供 TB 级的带宽,同期小模子的磨真金不怕火推理则对 IOPS 提议更高条件,存储系统需提供杰出百万级的 IOPS。
2023 年底到 2024 岁首:跟着模子在各行业落地的需求,在许多的行业场景里,行业数据贫窭积蓄,夙昔散布在各末端、地域数据的夸合同、夸地域高服从分享整合。这就条件存储具备数据跨域改变,通过异构纳管罢了全局定名空间管束,升迁数据汇集、分析的服从。
2024 年下半年驱动:模子的简直落地,对数据质地条件更高,语料公司需要将数据汇集并进行精加工。大模子的行业化落地经过中,为了升迁通用模子的专科化才气,磨真金不怕火出精度更高的模子,条件有更高质地的数据集。为取得高质地数据,原始数据要经过粗加工、精加工等多个功课花样。这个阶段,对数据的安全存储和数据可抓续性拜谒提议了更高条件。
波浪信息存储产物线副总司理刘希猛指出,模子参数目、磨真金不怕火数据量、GPU 算力、网卡性能、GPU 范围近些年均在连忙增长,原有存储不及以搪塞 AI 的快速发展。不管是海量磨真金不怕火数据加载、PB 级查验点断点续训,如故高并发推理问答等,存储性能径直决定了通盘这个词磨真金不怕火推理经过中的 GPU 行使率。特等在万卡集群范围下,较差的存储性能会严重增多 GPU 闲置时刻,导致模子落地贫苦、业务资本剧增。因此,当代存储照旧由传统的数据载体和数据仓储,转移为 AI 发展的枢纽组件。存储系统正逐渐演进到提供更高的隐约量,更低的时延,更高效的数据管束。
AI 存储何时爆发?
既然针对 AI 场景的存储系统在前几年并莫得取得太多喜爱,从需求侧,何时会迎来新的爆发点?"夙昔一年,存储的增量商场基本沿途来自于 AI 场景。"刘希猛对钛媒体 APP 阐明。
如果将改日的 AI 商场分为约莫两类:一类是 AI 产业化的商场,在 AI 产业化进程中,更多的温暖点可能都集在了模子磨真金不怕火,紧随自后的是语料坐褥,然后是算法优化。那么,存储启程点就会在模子磨真金不怕火、语料坐褥界限产生价值,特等是语料,从本年驱动就已有迹象,并在接下来两年里罢了快速增长。
在刘希猛看来,从目下来看,大模子磨真金不怕火中最紧缺的是数据,各行业在可能都会驱动入部属手网罗各自界限的数据,并进行相应的数据加工处理。算力方面,尽管有东说念主合计算力设立已接近泡沫阶段,以致有些用劲过猛。这一判断可能在一定程度上具有处所性的正确性。接下来,算力的发展可能会干预一个相对巩固的阶段。
第二类是产业的 AI 化,即大模子信得过落地到行业并产业实质价值,不错不雅察到一些界限照旧先行一步。举例,金融界限的量化往返、证券往返,在科研界限,AI 也驱动被用来援助科研职责。此外,制造业亦然 AI 应用的一个进击界限。这两方面都会对 AI 存储商场带来相比好的促进作用。
刘希猛还指出,现时 AI 存储面对的挑战尚未都备管束,若赓续上前发展,其实如故要从性能、服从以及可靠性三方面出手。一是高性能,以管束搀杂 AI 负载对存储读写带宽、IOPS,以及低时延的条件;二是高服从,通过存储支抓文献、对象、大数据等非结构化合同交融互通,全局定名空间等,减少多份数据重迭存储,以及数据夸合同、夸区域、夸系统改变检索的问题;三是高韧性,通过故障的快速收复、故障前的精确瞻望镌汰系统特地时的性能影响,以及干事的聚积性,同期强化数据保护与安全堤防才气,保证数据的完好意思、一致、抓续可拜谒。
目下国表里在建千卡集群、万卡集群,且改日可能还会出现更大范围的集群。想要达到同等算力,如果继承国产 GPU,可能需要不仅达到十万卡范围,而是更为重大的集群。
跟着集群范围的扩大,除了存储本人面对的挑战外,还将带来存储全体决策的挑战。这触及从存储到前端麇集,再到算力节点的通盘这个词链条。其中,麇集的遴选成为一个枢纽问题。国内之是以更多地使用 RoCE 麇集,是因为国内的集群范围需求更大,而 IB 麇集在扩展范围上有所收敛。RoCE 麇集与存储及表层之间的协同性,尤其是超大范围集群的协同性上,可能会成为新的温暖点。
钛媒体介意到,RDMA ( Remote Direct Memory Access ) 全称辛勤内存径直拜谒本事,是一种数据传输本事。目下算力集群对麇集的设立在 2022 年之前基本会遴选"二层臆造麇集",跟着 AI 应用的爆发,2023 年于今照旧在尝试智能无损麇集和以太网,而且经常围绕性能、资本、生态系统和兼容性等方面进行衡量。RoCE 即是一项基于以太网的 RDMA 本事。
甲骨文公司中国区本事商议部高档总监嵇小峰与钛媒体 APP 相易中不异指出,大范围集群除了 GPU 数目多以外,同期具备麇集低延时和高带宽的特质。从基础设施角度来看,大量 GPU 都集部署会带来供电和冷却方面的巨大挑战。同期,在磨真金不怕火经过中,对存储的需求不异至关进击。因为磨真金不怕火经常触及千千万万块 GPU 的协同功课,一朝有少数 GPU(如一块或两块)出现故障,通盘这个词磨真金不怕火进程可能会因此延误。
举例,本年 9 月亮相的 Oracle Zettascale 算力集群,目下可提供 13 万多颗 GPU,至极于可提供 2.4 ZFLOPS 的云霄算力。为进一步增强麇集的低蔓延和高带宽,Oracle 继承支抓两种麇集合同:InfiniBand 和 RoCEv2,这是一种增强版的以太网。这两种本事均具备一种中枢绕行机制,能让麇集流量覆没旧例旅途中必须穿越的某些组件,以罢了更迅速的传输至缠绵地。这么的想象促进了数据更快地抵达 GPU,进而升迁了处理服从。
跟着 AI 存储需求的不休流露,包括 GPU、模子架构、存储管束决策及麇集本事的各大厂商,正纷纷加快布局,勤苦在构建超大范围集群的波浪中霸占先机。(本文首发于钛媒体 APP,作家 | 杨丽开云(中国)Kaiyun·官方网站 - 登录入口,裁剪 | 盖虹达)
Powered by 开云(中国)Kaiyun·官方网站 - 登录入口 @2013-2022 RSS地图 HTML地图