本文是记录会议【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技术标准。
硬科技没有捷径，需要脚踏实地的攻克挑战和难关，只有这样才能做出被用户真正接受的产品，也不负这个时代赋予我们的使命。
Original: https://www.cnblogs.com/xyjk1002-rejuvenation/p/16408976.html
Author: miyan
Title: AI芯片的软件挑战
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/581763/
转载文章受原作者版权保护。转载请注明原作者出处！