GPU行业市场分析研究

GPU行业市场分析研究国产GPU发展窗口期已至，生态构筑核心优势AI发展已经带动GPU行业高速发展，国产AI也为国产GPU的发展提供契机。在国际供应链不确定性背景下，我们认为，未来三年可能是国产GPU发展的关键窗口期，这一段时期，国产GPU有望取得长足发展，有可能是较好的投资时期。目前，国内GPU领域公司数量较多，从性能指标方面来看，已有部分公司能够在理论硬件性能方面接近国际主流水平，理论算力指标较高。同时，在芯片对外带宽方面，英伟达也并非完全高不可攀。例如，根据AMD官网，其MI系列产品的带宽就经历了快速进化，从MI50到MI100再到MI250，其InfinityFabric通道就从2个提升到8个，对外带宽从184GB/s提升到800GB/s。国内产品在通信方面也进行了尝试，例如壁仞科技的BR100芯片，其BLink技术就实现了8通道，合计512GB/s的对外带宽，技术定位类似于英伟达的NVLink。但尽管国产芯片的理论算力和理论带宽均能够做到较为良好的水平，理论性能却往往面临软件生态的限制，即便集成GPU领域的领先企业Intel也无法摆脱这一规律。Intel新发布的独显Arc系列在使用了更多晶体管的前提下，具备更高的理论性能，但实际使用性能相比友商的基础型显卡有一定差距。我们从软件测试中可以看见，3Dmark测试所代表的GPU理论性能测试中，Intel的Arc系列均有亮眼表现，而到了实际使用场景中，IntelArc系列产品的实际帧率相比同样的友商产品则有一定差距，重要原因在于驱动程序，而驱动程序正是生态的核心组成部分之一。另外生态在数据中心与开发者场景中起到更重要的作用，能够重塑整个数据科学/AI工作流程，加强开发者黏性，形成正反馈。在开发者的日常流程中，首个环节是数据管理，包括数据从数据来源的提取（Extraction）、变形（Transform）、加载到应用端（Load），合并称为ETL，随后还有数据的存储等。其次是数据训练、验证（可视化）、部署（推理）等多个环节。足够良好的GPU生态能够极大影响上述工作流，首先可以将模型训练环节迁移到GPU，随后还可以将ETL环节（传统上由CPU完成）也迁移到GPU上，让整个数据科学/AI工作流几乎全部在GPU上完成。通过发达的GPU软件支持实现工作流迁移，能够极大提高效率，从而重塑开发者的软件使用习惯，让开发者的黏性极大增加，形成正反馈，持续提高软件生态的壁垒。形成上述正反馈的前提是在每个环节中都必须有足够丰富、可靠、易于使用的工具供开发者使用，且最好是开发者熟悉、拥有成熟社区的，由此可见生态的重要性。CUDA：GPU生态先驱，AI时代基础设施提及生态，GPU生态的奠基者CUDA是无法绕过的。如今整个科学计算、AI的软件生态大多构建在CUDA的基础之上。CUDA也是软件生态的标杆，从软件库的覆盖面、AI框架和算子库的支持程度两方面来讲，都是目前最完善的。CUDA的诞生：实现从GPU到GPGPU的转变。在CUDA问世之前，想要调用GPU的计算能力必须编写大量的底层语言代码或借用图形API，对使用高级语言为主的程序员十分不便。英伟达公司的首席技术官DavidKirk以及CEO黄仁勋主导推出了CUDA。2006年CUDA发布，2007年正式推出CUDA1.0公测版本。此后程序员无需再通过图形API来调用GPU，而是可以直接采用类似C语言的方式直接操控GPU。2008-2010年，CUDA平台进一步发展，拓展了新局域的同步指令、扩充全速常量内存并且支持递归，NVIDIA向各软件厂商免费提供开发工具，使得CUDA生态初具规模。发展：十年苦坐冷板凳，与AI生态深度绑定。在CUDA系统诞生之初，英伟达大量投入研发对CUDA进行不断更新与维护，但并没有立即得到市场的认可，CUDA用户不多但大量研发却直接影响利润，英伟达市值长期不振，直到2016年市值才超过2007年的水平。但CUDA对科学计算领域的渗透一直在进行，2012年深度学习革命开始以来更是一直在渗透AI领域，2012年ImageNet挑战赛冠军使用的就是英伟达GTX580GPU。此后CUDA持续迭代，2023年CUDA已经推出最新的12.0版本API。如今整个HPC与AI生态都已经与CUDA形成了深度绑定，CUDA已经成功塑造了用户习惯，成为了AI时代开发者最熟悉的工具箱。CUDA生态：组件庞杂、取代难度高。CUDA所包含的生态组分众多，包含编程语言和API、开发库、分析和调试工具、数据中心和集群管理工具，以及GPU硬件等多个大类。每一大类中都包含了大量的组件，是英伟达以及开源生态开发者们在二十年间日积月累所形成，如今要将其取代难度较大，需要巨量的时间和资源投入。CUDA生态虽已成为AI和HPC几乎不可分割的一部分，但英伟达占据了绝大部分市场份额，对下游用户来说，其使用成本也不低（根据英伟达财报，近5年来其毛利率基本维持在60%上下），用户有意愿寻求低成本替代。且在当前国际局势下，中国本土企业面临一定的供应链不确定性。因此，对于诸多企业而言，在CUDA之外寻找一个第二选项，是对于企业经营可行的选择，要做到这一点，就需要尽可能跨越CUDA的护城河。CUDA的两大生态护城河：软件库覆盖率、AI框架支持度。对于后来者而言，关键是采取切实可行的措施向CUDA学习靠拢，进行自身生态建设。我们认为，CUDA的第一个壁垒是软件库覆盖率，既包含了基础的并行计算软件库，也包含了细分行业软件库，还有配套的辅助软件等；第二个壁垒则是针对AI领域而言的AI框架支持率。对于我国芯片公司而言，中短期内可以尽可能投入资源实现的是并行计算软件+辅助软件库开发，以及对AI框架的完善支持，而对于细分行业的支持，则需要较长的时间和积累。并行计算软件库覆盖度：以ROCm为例目前，有望替代CUDA的选项已经存在，即ROCm。ROCm是AMD开发的对标CUDA的软件平台。ROCm全称为RadeonOpenComputingplatforM，是基于AMD系列GPU设计的开源计算生态，同时也能够相当大程度上兼容CUDA、支持NVIDIAGPU，其目标是建立有望替代NVIDIACUDA生态的平台。以下我们将以ROCm为例，分析生态的第一个核心要素——并行计算软件库覆盖度，包括软件支持覆盖范围的变化及其影响，未来的演变趋势等。ROCm前为何没有能挑战CUDA者？OpenCL自身不足，AMD旧产品性能待提升ROCm出现之前，AMD也意识到GPU在AI计算领域的潜力。根据五二电子工作室网站信息，AMD曾经尝试利用OpenCL打入深度计算领域，先是尝试移植cuda-convnet，后转向Caffe，最后的成果是OpenCLCaffe，虽然是有益的尝试，但这项努力并没有引起很多的关注，其成果也局限在单一工具，并未构建起有效的平台。此前尝试失败的一个重要原因在于AMD此前一直使用OpenCL，而OpenCL本身具有不足之处：语言支持少（2015年以前只支持C），更多面向底层软件而非上层软件。另外硬件层面，主导ROCm生态的AMD此前在计算卡系列仍然采用GCN架构，产品性能相对不足。软件不足：OpenCL对HPC支持有限，产品节奏长期滞后OpenCL最早提出是为了应对单核性能极限与多核并行计算的发展，最初由苹果开发，并与AMD、Intel、英伟达、高通、IBM的团队合作完成API方案，各家公司在2008年合作成立Khronos计算工作组，并于当年发布OpenCL标准，各公司采用统一的API，但各自完成实现方式。需要注意的是，这时GPU的算力价值还没有被广泛认知，Khronos成员除了英伟达外均以CPU为主业，OpenCL也更多考虑了多核CPU计算，导致OpenCL更多考虑底层硬件驱动/操作系统支持，对高层的科学计算库等支持则相对有限。这一点从支持的语言也可以看出，OpenCL长期以来仅支持C语言（底层驱动、操作系统等多使用C），而科学计算库常用的C++支持直到2015年的OpenCL2.1版本才得以推出。与之相对比，英伟达早在2010年的CUDA3.0版本就已经添加C++和Fortran支持，2011年的4.0版本更通过GPUDirect2.0等技术在HPC领域站稳脚跟，2013年的GTC13上，CUDA添加了Python支持，易学易用水平再度提升，到OpenCL发布C++支持的2015年，CUDA已经迭代到7.0版本，形成了相对稳定的护城河。可见二者在科学计算领域的统治力完全不可同日而语。根据AnandTech，OpenCL始终没有在HPC领域获得大规模应用，遑论后续的AI。硬件不足：早期MI产品性能待提高，对数据中心用户吸引力有限ROCm诞生前以及诞生早期，CUDA以外的计算生态推广也有硬件方面的原因。如果仅是软件支持不足，那么如果硬件性能占优或具备明显的性价比优势，硬件产品仍然有可能在一些对生态要求不高的细分领域得到销售，例如虚拟货币市场，AMD桌面显卡曾经依靠较高的浮点性能占据较高的份额。但根据AMD官网发布的信息可以看到，早期AMD的计算卡在性能表现方面并不占优。在2020年CDNA架构面世前，AMD的数据中心GPU一直使用的是GCN系列架构，搭载GCN系列架构的产品在2012年就已推出，虽然在游戏机等场景获得较高市场份额，但在数据中心市场并未取得显著成果，这与其性能表现有关。AMD在2017和2018年曾经两次推出InstinctMI系列数据中心GPU，但第一批推出的MI6、MI8、MI25在算力表现上与同期的NVIDIAV100具有一定差距，这三款GPU的FP64算力均未超过1TFLOPS，而V100的两个版本均在7TFLOPS以上，FP32算力也仅采用GCN5架构的MI25与V100相对接近。到了2018Q4批次推出的MI50/MI60，AMD终于在算力表现上接近2017年推出的V100。而在显存与带宽等方面，2017年批次的MI系列显存容量与带宽仅有V100的约一半水平，而GPU互联方面尚未配备InfinityFabric，带宽与V100SXM的NVLink也有差距。到2018Q4批次的MI50/MI60，AMD为其配备了初代InfinityFabric，单通道92GB/s，共计双通道184GB/s，有所提升，在显存与外部带宽方面向V100靠拢。从上述性能对比可见，早期的InstinctMI系列GPU性能与V100相比仍有差距，也在一定程度上影响了ROCm生态的推广。这一现象随着AMDCDNA架构的推出有所改观，2020年Q4，MI100与NVIDIAA100在相近的时间推出，其FP64、TF64、FP32算力指标全面超越A100，但在AI常用的低精度张量计算（TF32、TF16、INT8等）方面仍与A100存在较大的算力差距。到了CDNA这一代，AMD在数据中心GPU硬件算力方面可以说已经与NVIDIA互有优劣，不再是被全方位包围的态势。到了CDNA2这一代，MI250/250X在FP64、TF64、FP16计算方面取得了相对H100的优势，但FP32、TF32、TF16算力方面弱于H100，在张量计算方面仍然不及NVIDIA，但可以说维持住了与NVIDIA主力产品各有优势的局面。显存方面，MI250/MI250X在容量与带宽方面超越了H100SXM版本。在外部带宽方面也凭借8通道InfinityFabric实现了800GB/s的带宽，接近H100SXM的900GB/s。综上所述，ROCm的推广缓慢受到硬件性能发展滞后的影响，但硬件方面的掣肘随着2020年CDNA架构产品的发布已经有所改善，在可见的未来，硬件方面可能不再对ROCm构成限制。AMD系算力走向实用化的转折点：重建基础平台，从OpenCL转向HIPOpenCL的发展迟缓导致了AMD多年未能在GPU计算领域有所作为，更多局限在游戏卡领域，而神经网络、区块链等技术在2010s的发展让英伟达获取了大量市场份额，CUDA生态的护城河愈发强大。AMD也希望能够改变自身市场地位，因而进行了完全的战略转向，不再基于OpenCL仅仅提供单体工具，而是开始全面拥抱现有CUDA生态，并构造软件平台，实现开发者的低成本迁移，这一过程持续至今，并且在可见的未来仍将持续。具体而言，AMD首先在2015年11月的SC15超算会议上提出Boltzman计划（得名于奥地利物理学家玻尔兹曼，其在统计物理学领域的成果对科学计算中的流体模拟、AI中的随机RNN等都有重要作用）。Boltzman计划的主要内容在于将标准C++引入AMD计算生态，并为其提供HCC编译器（HeterogeneousComputeCompiler，对标英伟达NVCC），同时提供HIP（Heterogeneous-computeInterfaceforPortability）套装来拥抱现有的CUDA生态。AMD官方对于这一战略也赋予了较高期待，希望能够给GPU计算生态带来变化，这从AMD在玻尔兹曼计划开始一年后的SC16大会上的相关表态可以得以体现。落实到具体执行层面，如何真正在GPU生态立足？我们认为，第一要与CUDA生态融合，做到低成本迁移；第二要在保证可迁移性的前提下优化体验，追求更广的函数库覆盖、更佳的易用性以及性能；第三需要有足够的迭代速度，才能在市场上形成正循环。以下我们分别对这几方面进行分析。ROCm如何融入CUDA生态：HIP通用前端代码+Hipify转换工具ROCm首先需要融入CUDA生态，这一点主要通过HIP系列函数库完成。具体而言有两种兼容方式，第一种针对存量程序，即将已有的CUDA代码运行在AMD或类似的GPU上，这一方式可以通过Hipify工具来实现，将CUDA代码转化为等效的HIP代码，再经过ROCm的编译器，即可运行；第二种针对增量程序，即希望新写的代码能够同时在NVIDIA或AMD的GPU上运行，这一方式较为简单，HIP代码通常扮演与用户交互的“前端”角色，而真正执行任务的“后端”既可以是ROCm生态的各种roc开头的函数库，也可以是CUDA生态的cu开头的函数库，可以由HIP函数库在运行时自动检测、自动选择，所以HIP代码可以一次写作多平台部署。此处一个值得注意的点在于，Hipify工具是否能够真正实现CUDA代码的完美转换？ROCm生态中提供了两种Hipify工具，第一种是一个编译器，将CUDA代码编译成HIP代码，采用的是目前较为成熟的clang编译器前端，只要CUDA代码正确、引入的外部信息均可获得，那么代码就能够得到妥善翻译；第二种是一个简单的脚本，采用Perl语言，其功能就是文本替换，按照一定规则将CUDA代码中的各种函数名称替换成HIP中的对应函数，但这个脚本在面对较为复杂的代码结构时有一定局限性。由上述内容可见，如今的ROCm在融入CUDA生态方面基本具备一定能力。ROCm可以多大程度上替代CUDA：支持日渐完整，体验仍需进步在能够基本融入CUDA生态的基础上，接下来的问题就在于使用体验。具体而言，可以分为软件库支持、基础软硬件硬件支持、性能、易用性等方面。软件库支持：支持范围持续扩大，基本支持AI与HPC生态软件库支持是可用性的核心，2015年以来ROCm生态持续丰富组件。2016年，ROCm1.0阶段，基本的数据格式、基本运算指令、常用的基础线性代数库、部分常用AI框架已经得到初步支持在随后的年份中，ROCm生态继续得到优化，2018年开始开发容器支持以及系统管理工具；2019年ROCm3.0版本中基本将系统/集群管理工具、集群通信工具、容器工具开发完成，AI框架支持基本实现；2020年ROCm4.0版本中，HPC生态已实现初步可用，各类核心基础库基本完成初步搭建。此后ROCm也持续更新到2023年4月已经推出ROCm5.6版本，形成了底层驱动/运行时、编程模型、编译器与测试调试工具、计算库、部署工具等相对清晰的软件架构。在当前AI领域最常用的AI框架与并行计算算法库方面，ROCm5.0及以后的框架始终保持着紧密跟踪支持，为其在AI领域渗透提供了基础。目前从完成度上来看，ROCm对比CUDA已经在开发、分析工具、基础运算库、深度学习库与框架、系统软件方面做到相对完整的支持，但对于DPU、物理模拟、细分领域、用户界面等支持还存在一定不足，例如用于GIS和空间运算的cuSpatial、用于产生GUI的cuxfilter、用于材料物理模拟的Modulus等，ROCm尚未在这些领域提供完善的支持。基础软硬件支持：Windows支持或将面世，CDNA与RDNA架构支持提升仅支持AI的核心框架与算法库对于GPU而言仍然不够，往往需要全面的软硬件支持才能触及大量用户，在使用中获得反馈、进行快速迭代，从而构建生态护城河。操作系统方面，目前ROCm的现状仍以支持Linux为主，未来计划添加Windows支持。当前版本ROCm支持的操作系统主要是3类Linux发行版：RHEL(RedHatEnterpriseLinux)、SLES(SUSELinuxEnterpriseServer)、Ubuntu。对Windows的官方支持不足是ROCm目前的一个短板，而早在2007年的CUDA1.0时代，CUDA就已经明确支持Windows，这也让CUDA的用户群体更加广泛。但面对CUDA的优势，ROCm也在跟进，根据AnandTech的文章，尽管AMD尽量避免对Windows支持上线日期做出承诺，但其工作日志显示AMD仍在进行Windows方面的开发。硬件支持方面，目前ROCm支持的GPU型号主要集中在计算卡领域，图形卡的ROCm支持已经有所进步但仍需扩展。目前Instinct计算卡方面，从MI50（GCN5.1架构）以后（CDNA系列架构）均实现了ROCm完整支持（仅需使用ROCm自带的驱动），但只能在Linux环境下使用。专业图形显卡方面，目前支持的型号还较为有限，在使用RadeonPro驱动的情况下，部分基于GCN5.1架构以及RDNA/RDNA2架构的专业显卡（用于工作站等场景的RadeonPro系列）也进行了适配，其中RadeonProW6800实现了Windows支持，其余诸如W6600、W5000系列等型号并未在文档中提及。图形卡/游戏卡方面，目前支持的型号也较为有限，官方提供完整支持的仅有RadeonVII，另有RX6600获得了HIPRuntime在Linux/Windows的支持，RX6900XT获得了HIPSDK（包含HIPRuntime以及一组GPU计算库）在Linux/Windows的支持，其余绝大多数普通游戏卡并未在文档支持列表中被提及。据快科技和AnandTech消息，2023Q3版本的ROCm有望首次支持RDNA3架构，包括RadeonProW790048GB专业显卡、RadeonRX7900XTX24GB游戏显卡等。与之相比，NVIDIA目前全产品线支持CUDA，能够获得更广阔的市场空间。尤其是对于图像生成等算力消耗较小的应用，用户往往只需购买一张NVIDIA游戏卡，并在CUDA支持下进行部署即可，这一张游戏卡还能支持其他日常工作与娱乐，对于小用户具有较强的吸引力。而同样的工作（StableDiffusion），在ROCm生态内部，现在是由开源社区自发支持的（docker_sd_webui_gfx1100项目）。硬件支持还包括CPU方面，目前只需IntelHaswell架构（2013年）以后或AMDZen架构以后的产品即可。虚拟化支持对于数据中心给客户按需分配算力较为重要，目前ROCm生态在此处的支持水平尚可，已经能够支持VMWareESXi7/8版本。综合来看，ROCm生态在软硬件支持领域目前已经有一定可用性，但Windows支持和GPU产品的全线支持仍需继续推进。性能表现与易用性：ROCm在AI框架领域性能无短板，易用性尚需提升软硬件与库决定可用范围，而在可用范围内更多比较的是优化水平（性能水平）与易用性。性能层面，在进行了完善优化的情况下，ROCm与CUDA的差距并不大。以Pytorch为例，Meta与北卡州立大学的研究人员进行了较为全面的测试，使用NVIDIAA100与AMDMI210测试模型运行所需时间，如果比值小于1则说明模型在A100上表现更佳，反之则说明在MI210上表现更佳。研究人员得出结论，最终模型运行的时间表现与TensorCore有关，如果模型能够使用TensorCore的部分更多，则通常在A100上的表现更好。但并非所有模型都能使用TF32数据格式，如果模型使用了更多的“按对应位置的运算”（在两个矩阵中位于相同位置的元素进行加减乘除），那么就无法调用TensorCore，此时MI200FP32算力更高的优势就能够得以体现。同时，按照训练和推理分类页可见，在大多数推理场景中A100性能更好，因为推理场景中使用TensorCore的比例更高。通过上述研究结果可见，Pytorch模型性能基本准确反映了A100与MI210的性能区别，从而也说明ROCm在支持完善的框架领域相比CUDA并无明显性能损失。易用性方面，对于个人用户而言，ROCm与CUDA相比还存在一定差距。目前CUDAToolkit已经可以在英伟达官网直接下载安装包，如同其他应用程序一样快速安装完成。如果要在CUDAToolkit的基础上添加功能，例如添加深度学习功能，只需在官网下载cuDNN对应的zip压缩包（或其他格式压缩包）并解压即可，其内部就包含了所需使用的C语言头文件、动态链接库、lib文件等，操作十分简便。与之对比，ROCm由于只支持Linux，其使用命令行形式或脚本形式安装门槛比CUDA的图形化操作要更高，对于开发人员或算法工程师等专业人士尚可，但对于并非以AI为核心专业的用户仍有一定门槛。总结：张量计算待提升，基础软硬件与软件库支持需完善综上所述，ROCm生态已经能够一定程度上对CUDA进行替代，尤其在核心的AI领域已经具备较为完善的支持和可用性，但要更进一步仍需利用AMD以及开源社区的力量，对张量算力、易用性、Windows支持、硬件支持范围等方面进行优化。ROCm的未来：开源是后发者的合理选择，或可参照Python与MATLAB综上所述，如今的ROCm已经逐渐具备了枝干，仍待枝繁叶茂。为了在整体研发投入不及CUDA的情况下让后发者的生态逐步茂盛，开源并借助外界的社区力量是一个可行的选择。目前整个ROCm项目的源代码基本已经全部公布于GitHub，在众多组件当中，只有AMD私有的编译器AOCC（在开源LLVM的基础上修改而来，针对AMD硬件进行优化）属于闭源项目，其余均通过不同形式的开源许可证进行开源，整个开源社区的开发者力量均可为ROCm项目的完善做出贡献。开源是否能真正促进生态的完善甚至帮助ROCm超越CUDA？这一问题的答案并不是非黑即白，开源能够聚集社区开发力量，而商业闭环则能够实现有效的经济激励，可谓各有优势。但对于处在后发位置的ROCm来说，采用开源模式或许更为合适。其原因在于，商业闭环的能量与商业生态的规模直接相关，如果ROCm与CUDA同样闭源，则受限于收入与利润规模，AMD的研发资源大概率不如NVIDIA多，难以取得竞争优势。那么如何对趋势进行更具体的判断？可以参考以往的案例，例如iOS/Android、Windows/Linux、MATLAB/Python等。其中前两对都是操作系统，用户群体较为广泛，生态的力量也强大很多；或许更可以类比的是Python与MATLAB，二者同为编程语言，各有自身的生态，用户都是软件开发者或科学计算等领域的专业人士，其生态的强度或许与ROCm/CUDA更为接近，且软件生态的构成也都是中心化的常规软件库与细分专业库相结合，因此在生态构成方面也具有较高的可比性。Python作为开源的代表，凭借开源能够获取相当大一部分市场。由于其简洁易用免费的特性已经成为AI和数据科学领域首选语言，根据TIOBE的统计，Python语言的市占率近年来快速上升，屡居第一，达到15%左右。目前AI领域的Pytorch、TensorFlow以及数据处理领域的pandas以及各类爬虫库乃至金融科技等领域均有大量Python库在生态中居于领先地位。这与生态规模相对较大、需求相似度高、可标准化程度高有关，投入产出比较高，因此能够聚集足够多的开发者，迅速建立起足够强大的生态，并凭借开源免费易用的优势牢牢把持优势地位。而MATLAB则凭借全面优质的simulink支持，把控大多数细分场景。在各种电力、机械仿真模拟等领域，simulink依靠商业循环推出了大量工具箱，完成了大量细分领域的覆盖与支持，并形成较强的用户粘性。这些领域由于用户规模较少，且用户大多不是专业的程序开发人员，往往生态形成速度较慢，MATLAB能够以此在相当长的时间内维持相对稳定的市场地位。因此我们认为，在长期来看，ROCm生态有望凭借开源的特性，在一些较大的生态领域（如AI领域）迅速形成软件的全面覆盖，逐步占据更多份额，至于一些较为细分的领域（如材料物理模拟等），ROCm或许还需要更长的时间才能具备竞争力。AI框架支持：以昇腾为例，算法库+配套软件基建对于GPU/GPGPU而言，通用并行算法（通常为向量计算）的广泛支持是软件生态的核心优势，然而对于AI专用芯片（NPU等）而言，其本身的硬件架构（专注强化矩阵计算，而矩阵计算单元并不能进行向量运算）决定了其难以真正全面支持并行计算需求。因此，对于此类芯片，重点在于实现AI框架支持，发挥其在AI领域的高效性。以NPU领域较为领先的华为昇腾为例。其采用自主开发的CANN软件体系，适配的计算库主要是神经网络（NeuralNetwork，NN）库、线性代数计算库（BasicLinearAlgebraSubprograms，BLAS），这两类库以矩阵类运算为主，与其硬件架构相合，而其余常规的向量计算库，支持则并不十分完备。尽管全面支持通用并行计算有一定困难，但如果将适用领域局限在AI范围，NPU仍然可以提供相对完善的支持，其主要原因在于大多数AI程序都利用了成熟的AI框架，如果能对AI框架提供足够完善的支持，则仍然是在AI领域的可用选择。当前在诸多AI框架中，全球使用率最高的当属Pytorch，随后是TensorFlow等。据AssemblyAI等数据，当前GitHub新AI项目当中，有近70%使用的AI框架是Pytorch；在HuggingFace平台上最受欢迎的30个模型当中，有7个仅使用Pytorch，23个同时支持Pytorch和TensorFlow。从AI框架的使用情况可见，对于AI芯片的生态构建，并行计算库的全面覆盖并非唯一路径，实现对AI框架的良好支持是另一条路径。能够完善支持Pytorch、TensorFlow等，即可满足相当一部分AI需求。当前国内已有AI芯片在此方面取得显著进步，举例来说，昇腾CANN提供AI框架适配器FrameworkAdaptor用于兼容Tensorflow、Pytorch等主流AI框架。华为昇腾NPU团队通过长期投入适配工作，已于2023年10月4日的Pytorch2.1版本中被纳入第三方设备原生支持列表，在国内进度领先，有望借此形成生态优势并保持。但将适配工作拆开来看，要实现AI框架的完善支持，其工作量仍然较大，核心工作之一就是实现算子库的支持，各家的实际支持度不一定完全相同。所谓算子即实现特定功能的运算操作。对于通常的AI框架来说，其所需支持的算子数量较为庞大，因此需要大量资源和时间进行软件支持。考虑到Pytorch自定义算子较多，支持的操作较为庞杂，因此我们可以在其他AI框架中大致了解算子库的内容。比如ONNX框架，其中包含了上百种不同的计算操作，硬件开发商需在其硬件指令集的基础上实现诸多算子，其中不乏相对复杂的算子。map、reduce等经典的大数据处理操作、分类器常用的OneHot编码、各类激活函数、超越函数等都包括在内。参考前文AMD的相关历史，ROCm对各类算子和工具库的初步适配经过了约3-5年时间，与昇腾从2019年发布到2023年获得原生支持经过的时间类似。在这样的资源与工作量投入下，昇腾才得以在国内NPU芯片领域占据强势地位，根据昇腾官网ModelZoo页面显示，其提供的神经网络模型样例有200余个，涵盖了视觉的分割、分类、生成，语音和声纹识别，NLP、机器翻译、推荐系统、LLM、扩散模型、多模态模型等类型，下载量靠前的包括了YOLO、BERT、ChatGLM、ResNet、LLaMA等经典模型。国内厂商生态进展：或复刻CUDA，或兼容框架目前国产GPU公司均在通过不同方式对CUDA进行兼容，提高各类计算库的覆盖率，同时实现对AI框架的支持。而AI芯片产品由于硬件架构限制，往往不一定追求兼容CUDA，而是尝试通过增加自行开发的方式，直接与AI框架进行兼容。GPU方面，各公司的软件生态架构、兼容CUDA的思路大多与ROCm类似。例如摩尔线程官网显示，其自主构建了MUSA生态来兼容CUDA，其生态组成与英伟达CUDA极为接近，基本所有组件都有与CUDA的对应关系，例如采用muDNN代替cuDNN、muBLAS代替cuBLAS等，另外自行开发MCC编译器等。根据摩尔线程官网显示，摩尔线程兼容CUDA的手段与ROCm是基本一致的，可以通过MUSIFY工具将CUDA代码迁移到MUSA平台，正如ROCm生态中的Hipify；通过自行实现MUSA-X计算库（类似rocBLAS、rocFFT等），来实现CUDAAPI的一对一替换；通过MUSAToolkit来进行编译、调用MUSA程序后端，实现CUDA代码兼容。但MUSA生态与ROCm的不同在于，MUSA的大部分组件并不开源。在摩尔线程的GitHub官方页面可见，其名下仅有3个开源库，其中qtbase和installer-framework均与可视化界面有关，仅有torch_musa库与实际的运算有关，用来兼容Pytorch。而其中，Qt本身属于开源项目，Pytorch作为基于Python的项目，同样也是开源的，可见MUSA生态除开源社区项目外均采用闭源方式构建。这一方式的弊端在于，摩尔线程作为创业公司，其资源未必能与AMD等成熟大型公司相当，构建生态、形成规模效应的难度更大，在GPU生态的竞争中取得先发优势也更困难。与之类似，壁仞科技也开发了BIRENSUPA平台试图兼容CUDA，但并非开源项目，需要自行构建各类计算库与工具，也同样受到资源限制。目前从结果来看，其生态构建确实也需要进一