科技云报道:“存算一体”是大模型AI芯片的破局关键?

简介: 大算力下的新需求

科技云报道原创。

在AI发展历史上,曾有两次“圣杯时刻”。

第一次发生在2012年10月,卷积神经网络(CNN)算法凭借比人眼识别更低的错误率,打开了计算机视觉的应用盛世。

第二次是2016年3月,DeepMind研发的AI程序AlphaGo,战胜世界围棋冠军李世石,让全世界惊叹于“人工智能”的实力。

这两次“圣杯时刻”的幕后,都有芯片创新的身影。适配通用算法的英伟达GPGPU(通用图形处理单元)芯片,以及走专业化路线谷歌TPU(张量处理单元)芯片都在这两次大发展中大放异彩。

如今大模型的兴起,正在逼近第三次“圣杯时刻”。但随着模型参数越来越大,芯片在提供算力支持上逐渐陷入瓶颈。

数据显示,在GPT-2之前的模型时代,GPU内存还能满足AI大模型的需求。

近年来,随着Transformer模型的大规模发展和应用,模型大小每两年平均增长240倍,GPT-3等大模型的参数增长已经超过了GPU内存的增长。

在大算力激增的需求下,越来越多行业人士认识到,新的计算架构或许才是算力破局的关键。
16880.jpg

芯片发展面临“三座大山”

当前AI技术的快速更新迭代对芯片提出了多个挑战,尤其绕不过“存储墙”、“能耗墙”和“编译墙”三座大山。

首先,在传统冯·诺依曼架构下,芯片在执行计算密集型任务时面临“存储墙”问题,这导致计算芯片的功耗和性能都受限于处理器和存储器之间的数据搬运,严重限制了AI芯片在计算规模、密度、效率等方面的提升。

其次,由于“存储墙”的存在,数据需要频繁搬运,在存储、计算单元间来回转移,导致严重的功耗损失,撞到“能耗墙”上。

英特尔的研究表明,当半导体工艺达到 7nm 时,数据搬运功耗高达 35pJ/bit,占总功耗的63.7%。另有统计表明,在大算力的AI应用中,数据搬运操作消耗90%的时间和功耗,数据搬运的功耗是运算的650倍。

最后,“编译墙”隐于二者之中,极短时间下的大量数据搬运使得编译器无法在静态可预测的情况下对算子、函数、程序或者网络做整体的优化,手动优化又消耗了大量时间。

过去,凭借先进制程不断突破,这三座“大山”的弊病还能通过快速提升的算力来弥补。

但一个残酷的现实是,过去数十年间,通过工艺制程的提升改善芯片算力问题的“老办法”正在逐步失效——

摩尔定律正在走向物理极限,HBM、3D DRAM、更好的互联等传统“解法”也“治标不治本”,晶体管微缩越来越难,提升算力性能兼具降低功耗这条路越走越艰辛。

随着大模型时代来临,激增的数据计算,无疑进一步放大了“三道墙”的影响。

大模型呼唤“存算一体”

大模型的出现,促使AI对大规模芯片算力的需求更加强烈,按照传统技术路线简单堆砌芯片无法实现期待的算力规模增长。

同时,芯片能效问题变得更加突出。当前AI芯片能效依然低下,大模型每次训练和推断的电费成本昂贵,导致当前大模型的应用经济性较低。

虽然说现在很多大模型训练使用GPU,但GPU的架构演进并未解决大算力和大模型的挑战。

一方面,存储在GPU中所占比例越来越大。从GPU架构的演进趋势,可以看到存储在计算芯片中所占的比例越来越大。计算芯片从以计算单元为核心演变到以存储/数据流为核心的架构设计理念。

另一方面,数据传输功耗仍是提升算力和算力密度的瓶颈,本质上就是冯·诺依曼计算机体系结构计算与存储的分离设计所致。

总体而言,大模型对于算力的需求呈现指数型增长,但GPU又贵功耗又高,GPU集群的线性度也随规模增大而下降,探索非冯诺依曼架构已经非常火热。

AMD、特斯拉、三星、阿里巴巴等公司都曾在公开场合表示,下一代技术的储备和演进的方向是在“存算一体”技术架构中寻找新的发展动能。

例如,阿里达摩院就曾表示,相比传统CPU计算系统,存算一体芯片的性能可以提升10倍以上,能效提升超过300倍。

那么,“存算一体”技术到底有何优势?

存算一体与经典的冯诺依曼架构不同,它是在存储器中嵌入计算能力,将存储单元和计算单元合为一体,省去了计算过程中数据搬运环节,消除了由于数据搬运带来的功耗和延迟,从而进一步提升计算能效。

同时,由于计算编程模型被降低,编译器也可以感知每一层的数据状态,编译效率也将大幅度提升,“编译墙”的问题也得到了解决,具体而言:

首先,运算的性能更高

存算一体芯片的计算能力取决于存储器的容量规模。所有电子设备当中都会集成存储器,存储与计算相伴而行,有运算的地方就需要对数据进行存储。

如果采用存算一体芯片,随着存储容量规模的提高,其运算能力也会随之提高。

其次,功耗更低

由于数据传输路径的优化,存算一体技术在提高传输效率的同时,节省了数据传输的损耗,带来更好的能效比、低功耗。在相同算力下,AI部分能效比将有2-3个数量级的提升,更低散热成本,更高可靠性。

最后,成本更低

单位算力成本远低于传统计算芯片。同时,存算一体可以采用更成熟的制造工艺,大算力芯片往往需要采用先进工艺,这使存算一体芯片的晶圆成本低得多。

再考虑到配套的外围芯片、元器件等因素,整个系统成本将有5倍左右降低。

正是因为这些基于基础架构革新所带来的性能提升,存算一体技术有望在很大程度上解决AI大模型面临的算力挑战。

特别是针对大模型的推理,存算一体保持权重的特点与大模型中大规模的参数部署需求相匹配,可能是存算一体技术最先服务大模型应用的场景之一。

“存算一体”存在多条路径

目前,全球的存算一体玩家,主要可以划分为两大阵营:

一类是国际巨头,比如英特尔、IBM、特斯拉、三星、阿里等,巨头对存算技术布局较早,代表存储器未来趋势的磁性存储器(MRAM)、忆阻器(RRAM)等产品也相继在头部代工厂传出量产消息。

另一类是国内外的初创企业,比如Mythic、Tenstorrent、知存科技、后摩智能、千芯科技、亿铸科技、九天睿芯、苹芯科技等。

由于积淀不同、优势不同、目标场景不同,各家的存算一体方案也不尽相同,主要体现在三大差异上:技术路径、存储介质、以及采用的是模拟还是数字技术。

差异一:技术路径

根据存储单元与计算单元融合的程度,可以分为近存计算和存内计算两类:

近存计算,本质上仍是存算分离架构,只不过计算模块通常安放在存储阵列(memory cell array)附近,数据更靠近计算单元,从而缩小了数据移动的延迟和功耗。

近存计算的典型代表有AMD Zen系列CPU、特斯拉 Dojo、阿里达摩院使用混合键合3D堆叠技术实现的存算一体芯片等,还有国外创业公司Graphcore、芯片大神Jim Keller加入的创业公司Tenstorrent等,他们目前推出的存算一体芯片都属于近存计算的范畴。

存内计算,存储单元和计算单元完全融合,没有独立的计算单元:直接在存储器颗粒上嵌入算法,由存储器芯片内部的存储单元完成计算操作。

狭义上讲,这才是真正的存算一体,或者说,基于器件层面实现的存算一体才真正打破了存算分离架构的壁垒。

一般来看,近存计算是巨头的首选,因为符合“实用、落地快”的预期,而初创企业不存在路径依赖和历史包袱,反而可以另辟蹊径,直接选择存内计算,以期向更高性能、更通用的算力场景进行突围。

差异二:存储介质

存算一体依托的存储介质呈现多样化,比如以SRAM、DRAM为代表的易失性存储器、以Flash为代表的非易失性存储器等。综合来看,不同存储介质各有各的优点和短板。

发展较为成熟的有NOR Flash、DRAM、 SRAM等。

NOR FLASH属于非易失性存储介质,具有低成本、高可靠性优势,但工艺制程有瓶颈;DRAM成本低、容量大,但是速度慢,且需要电力不断刷新;SRAM在速度方面有优势,但容量密度小,价格高,在大阵列运算的同时保证运算精度具有挑战。

目前多数厂商当前倾向于技术成熟的SRAM设计存算一体芯片,但部分厂商也会采用“多驾马车”并驱的发展路线布局未来。

差异三:数字or模拟?

按照电路技术路径分类,存算一体计算有数字存算和模拟存算的区分,两者也有各自的优缺点:

数字存算,更适合大规模高计算精度芯片的实现,运算灵活性较好,更适合通用性场景,但要求存储单元内容必须以数字信号形式呈现。

模拟存算,在计算精度比较固定且较低的条件下,可以获得更高的能量效率,同时可以搭载任意存储单元实现。

但其关键模拟模块(如A/D转换器)的转换精度要求相对固定,且由于不同模拟计算方式可能具有不同的计算误差,因而这种技术路径的扩展性略显不足。

近些年来,学术界在存算一体的各个方面都进行了大量探索,提出了众多存算一体加速器架构,中科院微电子所、清华大学、斯坦福大学等单位制备出了存算一体芯片原型。

国内也涌现出了一批存算一体初创企业,包括知存科技、后摩智能、亿铸科技、苹芯科技等等,它们研发了基于SRAM、闪存、RRAM等存储器的存算一体芯片,且已有产品问世。

存算一体芯片面临多重挑战

虽然存算一体芯片被认为是下一代芯片,但目前还处于起步阶段,受限于成熟度,应用范围不够广泛,面临着诸多挑战,例如:

在芯片设计方面,架构设计的难度和复杂度要求很高,同时市面上也缺乏成熟的存算一体软件编译器的快速部署、专用EDA工具辅助设计和仿真验证。

在芯片测试方面,流片之后,同样缺乏成熟的工具协助测试。

在生态方面,缺乏相应的与之匹配的软件生态。

现阶段各厂商开发的存算一体芯片均基于自行定义的编程接口,缺乏统一的编程接口,造成了存算一体软件生态的分散,不同厂商开发的上层软件无法互相通用,极大的影响了存算一体芯片的大规模使用。

总体而言,现阶段的存算一体研发多数以零散的技术攻关为主,缺乏面向大算力方向的整体布局,也缺乏主导的应用需求牵引,因此距离大规模进入市场还有一定距离。

不过,大模型的到来,必将极大推动存算一体的技术落地,其未来应用潜力和部署规模都让人期待。

面向大模型部署,从业者需要对存算一体进行体系化布局,从算法、框架、编译器、工具链、指令集、架构、电路等跨层次协同设计,形成全栈式体系、工具链及生态链。

长期来看,设计方法论、测试、量产、软件、场景的选择等全方位竞争,将是各大厂商存算一体芯片发展和落地的关键。

【关于科技云报道】

专注于原创的企业级内容行家——科技云报道。成立于2015年,是前沿企业级IT领域Top10媒体。获工信部权威认可,可信云、全球云计算大会官方指定传播媒体之一。深入原创报道云计算、大数据、人工智能、区块链等领域。

相关实践学习
基于阿里云DeepGPU实例,用AI画唯美国风少女
本实验基于阿里云DeepGPU实例,使用aiacctorch加速stable-diffusion-webui,用AI画唯美国风少女,可提升性能至高至原性能的2.6倍。
相关文章
|
1天前
|
机器学习/深度学习 人工智能 算法
AI大模型学习理论基础
本文探讨了AI大模型学习的理论基础,包括深度学习(模拟神经元工作原理,通过多层非线性变换提取特征)、神经网络结构(如前馈、循环和卷积网络)、训练方法(监督、无监督、强化学习)、优化算法(如SGD及其变种)、正则化(L1、L2和dropout防止过拟合)以及迁移学习(利用预训练模型加速新任务学习)。这些理论基础推动了AI大模型在复杂任务中的应用和人工智能的发展。
|
4天前
|
人工智能 搜索推荐 决策智能
【AI Agent系列】【阿里AgentScope框架】1. 深入源码:详细解读AgentScope中的智能体定义以及模型配置的流程
【AI Agent系列】【阿里AgentScope框架】1. 深入源码:详细解读AgentScope中的智能体定义以及模型配置的流程
35 0
|
4天前
|
数据采集 存储 人工智能
【AI大模型应用开发】【LangChain系列】实战案例4:再战RAG问答,提取在线网页数据,并返回生成答案的来源
【AI大模型应用开发】【LangChain系列】实战案例4:再战RAG问答,提取在线网页数据,并返回生成答案的来源
29 0
|
4天前
|
数据采集 存储 人工智能
【AI大模型应用开发】【LangChain系列】实战案例2:通过URL加载网页内容 - LangChain对爬虫功能的封装
【AI大模型应用开发】【LangChain系列】实战案例2:通过URL加载网页内容 - LangChain对爬虫功能的封装
14 0
|
4天前
|
人工智能 Python
【AI大模型应用开发】【LangChain系列】实战案例1:用LangChain写Python代码并执行来生成答案
【AI大模型应用开发】【LangChain系列】实战案例1:用LangChain写Python代码并执行来生成答案
9 0
|
4天前
|
人工智能 监控 数据处理
【AI大模型应用开发】【LangSmith: 生产级AI应用维护平台】1. 快速上手数据集与测试评估过程
【AI大模型应用开发】【LangSmith: 生产级AI应用维护平台】1. 快速上手数据集与测试评估过程
18 0
|
4天前
|
人工智能 监控 数据可视化
【AI大模型应用开发】【LangSmith: 生产级AI应用维护平台】0. 一文全览Tracing功能,让你的程序运行过程一目了然
【AI大模型应用开发】【LangSmith: 生产级AI应用维护平台】0. 一文全览Tracing功能,让你的程序运行过程一目了然
8 0
|
4天前
|
人工智能 API 开发者
【AI大模型应用开发】0.2 智谱AI API接入详细步骤和简单应用
【AI大模型应用开发】0.2 智谱AI API接入详细步骤和简单应用
16 0
|
4天前
|
数据采集 人工智能 数据可视化
【AI大模型应用开发】【LangChain系列】4. 从Chain到LCEL:探索和实战LangChain的巧妙设计
【AI大模型应用开发】【LangChain系列】4. 从Chain到LCEL:探索和实战LangChain的巧妙设计
17 0
|
4天前
|
存储 人工智能 JSON
【AI大模型应用开发】【LangChain系列】3. 一文了解LangChain的记忆模块(理论实战+细节)
本文介绍了LangChain库中用于处理对话会话记忆的组件。Memory功能用于存储和检索先前的交互信息,以便在对话中提供上下文。目前,LangChain的Memory大多处于测试阶段,其中较为成熟的是`ChatMessageHistory`。Memory类型包括:`ConversationBufferMemory`(保存对话历史数组)、`ConversationBufferWindowMemory`(限制为最近的K条对话)和`ConversationTokenBufferMemory`(根据Token数限制上下文长度)。
13 0