AI芯片的软件挑战
本文是记录会议【ICPA联盟微课 | 第1期】燧原科技李彬:AI芯片的软件挑战内容。不得不说,什么叫高屋建瓴。
芯片软件的5个衡量指标:算力利用率、开发效率、生态兼容性、可移植性、用户友好型
算力利用率
JIT: just-in-time compilation 即时编译
AOT:Ahead Of Time,指运行前编译
-
在实际运算时,必须考虑数据的IO时间,IO效率又由带宽决定。算力利用率和带宽算力比往往会成正比关系
-
同样的带宽下,不同精度的计算,因为每次计算的数据长度的不同,所带来的的算力利用率也有明显的差别。
-
通常计算精度越低,带宽算力比越低,算力利用率也越低
-
要提高算字的算力利用率,就是要用一切方式将核心计算单元利用起来。
-
边编译边执行,那么硬件时而等待编译,时而等待指定运行。从模型执行层面观测到的算力利用率自然会降低。但实际上,进入每个算子的执行周期里面,硬件一直处于非空闲状态。那么算力周期内的算力利用率,肯定是高于模型层面观测出来的利用率。因此,如果要提高模型层面的算力利用率,尽量让算子在启动的间隔缩小。
-
同样往更上层的应用执行周期里,可能还会涉及到一些数据的前后处理的过程。这部分如果不被AI芯片加速,整体应用算力利用率会在模型的基础上进一步降低。要提高整个应用层面的利用率。就需要有更好的变性机制或流水线机制。让AI芯片与无关的而控制或者计算。在保证关键输入输出正确性同步的前提下,能流水线或者并行处理,从而使得芯片可以一直处于运转状态,提高算力利用率
开发效率
典型的,比如算子的开发效率。我们认为,编程模型是决定开发效率的基础。编程模型并不由软件单独决定。而是需要由于硬件架构系统系统性设计共同决定的。好的编程模型需要在硬件可实现性、开发效率、性能、完备性等几个方面进行权衡。傻瓜式的编程固然代码编写速度快,但是往往难以生成高性能的底层代码,发回不出硬件的算力。
直接提供硬件编程接口,能让编程者直接操控算力硬件,但是也意味着非常高的学习门槛,从而影响开发效率。
同样,手动的方法简单直接,但是开发效率低。同样,自动的方法效率高,但是确保自动生成高性能的代码,是非常关键的。
其次软件架构的泛化能力也会决定开发效率。以模型知识为例,如果针对数以万亿的模型和算子,一个个独立开发,工作量是巨大的。软件需要提供可泛化的知识能力。
最后,AI芯片本身会进行不断的迭代。但是没有哪一家芯片公司愿意为每一代硬件,重新进行软件开发设计。对客户而言,也希望芯片设计是向后兼容的。
用户友好性
我们把软件质量放在用户友好性的第一位。是因为实际上bug总是可以解决,但是会非常影响用户体验,尤其是针对数据中心的软件,质量直接影响到业务的稳定性。比如RAS这样的指标。
提供给用户的接口API,不管是基于什么样的原因,如果频繁的变动,会提高客户的学习成本和业务迁移成本,是非常糟糕的用户体验。调试和调优工具是否完善、调试手段是否丰富,是否能方便客户快速定位问题,是否能大大提高客户实际使用的体验。也都是用户友好性的关键的衡量标准。
可移植性
可移植性主要衡量平台横向迁移的适配能力。
首先AI芯片软件需要考虑适配不同的CPU架构主机。从服务不同场景平台的角度,除了最主流的X86CPU,还需要考虑ARM等其他CPU平台。软件需要从架构设计上就考虑这方面的知识。尤其是在驱动以及交叉编译环境等方面,否则支持新平台需要耗费非常大的代码修改代价。
其次,支持不同的操作系统,也同样需要从架构层面进行考量。不同的操作系统,首先对驱动的要求也有所不同,比如Windows和Linux两大阵营。定义了完全不同的驱动架构。如何从软件设计上就考虑跨操作系统架构支持是一个不小的挑战。
另外,各种软件依赖库,不同的操作系统会有不同。需要厘清AI软件栈实际的依赖库以及他们之间的关系。在工程构建系统里面进行多版本的支持。
框架方面,AI芯片尤其是训练芯片,通常会从某一个AI框架的支持开始。但是不同的AI框架之间往往差别很大。比如TensorFlow的1.0的版本和Pytorch之间,就从编译方式上是基于图还是基于算子,基于动态还是静态,对软件设计和实现都有巨大的差别。这对同一的软件架构形成了很大的考验。如果这部分设计缺乏弹性,那么多架构支持就会变得非常困难。
生态兼容性
首先,作为一个AI芯片的提供者,是自研AI框架,还是基于现有的流行的框架,值得思考。自研框架当然可以对自家的芯片量身定制,但是提高了用户的使用门槛和迁移成本。而适配现有的主流框架,能快速融入现有的开发生态,但是需要适应特定框架带来的约束。
AI框架作为绝大多数算法功能式的开发平台,如同AI操作系统一样的存在。AI芯片软件走兼容现有的框架的路线,更容易获得绝大多数用户的认可。
在编程模型方面,如在算子利用率和开发效率两个指标中我们讨论的,首先需要在两者之间进行平衡。其次需要考虑符合用户的习惯,兼容生态的一些普遍的做法。
尽管如此,我们不认为兼容性,就等于需要照搬某些特定架构下的编程语法。芯片架构的不同,所支撑的编程方式有天壤之别。在完全不同的架构下,生搬硬套某些编程语法或者API,最终必定称为东施效颦。与追求性能和效率的这样的主要目标背道而驰。
最后就是异构编程模式的兼容。到目前为止,主机加上加速器设备这种方式,仍然是异构计算的主流形式。计算产业生态决定了这种方式延续至今。作为AI芯片系统软件,不管使用用户习惯,还是上下游产业生态的现状,采取主机加设备,这种异构编程模式仍然是最好的方式。模糊化这种模式,从结构或者从一些另辟蹊径的做法,很难在整个计算产业生态上获得支持。
展望
期待AI生态全行业秉持开放的姿态,进行广泛的合作和交流。只有开放才会有共赢。其次,在人工智能产业生态高度繁荣的今天,希望所有的行业伙伴和友商。一起携手推进AI技术标准化,共同制定国人认可的AI技术标准。
硬科技没有捷径,需要脚踏实地的攻克挑战和难关,只有这样才能做出被用户真正接受的产品,也不负这个时代赋予我们的使命。
本文来自博客园,作者:miyan,转载请注明原文链接:https://www.cnblogs.com/xyjk1002-rejuvenation/p/16408976.html
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· 单线程的Redis速度为什么快?
· 展开说说关于C#中ORM框架的用法!
· Pantheons:用 TypeScript 打造主流大模型对话的一站式集成库
· SQL Server 2025 AI相关能力初探