(参考消息、作文、专家纪要、调研分享；提高认知及信息差)
分享市场、行业及公司动态，包括投资策略、行业数据库、专家调研、公司纪要；信息超越99%的投资者）微信扫码加入体验）
核心洞察
1.ROCm 当前核心痛点：
a. 兼容只能追赶，不可能超越，转译带来的性能损失难避免
b. 底层框架支持不足+算子库丰富度差距大
2. 生态圈主要用于训练+推理，提取/变形/加载/存储属于解决数据问题
3.CUDA 和 ROCm 核心区别：
a. 推出时间：CUDA 更早，积累更多，AMD 做为后发者起步晚+研发实力上 有所差距
b. 软件生态：在基础设施上，两者差不多，但丰富度(算子库+算子融合)+ 用户数是当前最大痛点
c. 框架迁移：在训练推理过程中，当开发者需要做框架迁移，CUDA这块 支持显著优于ROCm
d. 底层框架支持：ROCm 目前在底层框架支持上，只针对少数主流框架， CUDA 相对完整很多，且底层框架软件商会优先适配英伟达硬件
e. 开元跟闭源：ROCm 做为后发者使用开源生态抢占使用者， CUDA 则是全 闭源
f. 编译器：ROCm HCC 通用性更强， NVCC 只针对英伟达硬件去做的，在使 用上专家认为主要是用户习惯的差异，其余差异不大
4. 训练和推理对生态圈的依赖度差异：训练上，专家认为优先选择肯定是英伟达，
推理端则可能选择其他厂商，AMD这块做到全兼容CUDA会有一定优势 a. 训练：精度要求较高，包含前向记算+反向记算，反复验证修改参数
b. 推理：只需前向记算即可
5. CNN到Transformer对CUDA壁垒影响：专家认为架构迁移对CUDA壁垒影响 有限
a. 硬件端：核心基础都是卷积神经网络，但算子设计有所不同，对硬件端 提出计算单元核新的要求，从这个角度利好英伟达这类硬件设计能力 强的厂商
b. 软件生态端：架构转变对 ROCm 等后进生态圈有利，差距上有所缩小， 但专家认为实际上差距还是很大，架构迁移对CUDA 壁垒影响有限
6. 从生态圈角度出发，训练用英伟达，推理用AMD是否可行：专家认为是可行的， 针对大部份情况下，转换成本不高，主要原因是 ROCm 完全兼容 CUDA,
ROCm API 接口完全仿照 CUDA 做出来
7. ROCm兼容CUDA难点：转译带来性能损失+CUDA算子库更新后需重新适配
a. 当英伟达硬件更新，对应算子库更新，ROCm 需重新适配，适配过程中， ROCm 用户用不了相关功能
b. 在同等算力条件下，既使用 ROCm 转译后，上层还是 CUDA, 下层换成 ROCm 软件栈，这块操作系统的改变会带来性能上的受损，实测下来， ROCm相 对CUDA性能会差10%左右
Q:生态圈的建立流程?过程中芯片厂商和软件提供商之间的关系如何?
A:从 Al 生 态 圈 来 讲 ，Al 是由软件加硬件的系统组合而成，所以谈生态圈要结合软件和硬件两 者。硬件涉及到芯片供应商，国际上最著名的是英伟达。在硬件之上是 Al 的基础软件栈，涉 及到硬件在系统层的驱动，还有 GPU 硬件或者 Al 芯片的运行时库。再者是对用户暴露的 API 接口，还有 一 些其他相关库，比如基础数据库、 Al 算法、图像图形编解码等，这 一 系列构成 了整个 Al 的软件栈或者称作生态圈，这是针对底层的软件栈。在这之上还有深度学习的编译 框架。深度学习框架包含了训练和推理两个方向和应用场景。
训练框架更偏向于应用场景，类似于在操作系统之上的应用软件。训练框架更偏向于给做 Al 应用的科研机构、高校，提供 一个方便使用 Al 芯片、软件栈的深度学习框架，更专注于做 Al 模型或者 Al 的技术研究，而不是专注于技术软件栈或硬件方向。从下往上依次是硬件、操作 系统、驱动、运行时编程模型和外部工具、学习框架，构成了整个 Al 的软件栈或生态。在此 基础之上才有了在CV 领域内的 CNN, 以及现在流行的 Transformer 等 Al 模型和新技术的应用 发展。
从芯片厂商的角度来看，需要从底层 一直往上做，可以做到深度学习框架，也可以只做到Al 软件栈这一层，给用户提供编程模型和API 接口。从这个角度来看， Al 芯片厂商做的工作更 多 一 些。而深度学习框架则站在比较宏观和应用角度，所以他们所做的工作相对偏向于应用， 与具体的硬件会有一 定的差距。软件提供商范围相对宽泛，因为软件的定义很大，做基础软 件栈还是做框架，还是做 Al 模型和应用，大家所处的角色不同，要开发和建立生态圈的流程 也会有差别。
Q:横 向 对 比CUDA 和 ROCm, 开发者开发过程包括提取、变形、加载、存储、训练、推理，目
前生态圈在哪个环节差异最大?原因是?
A:提取，变形，再到存储加载，训练推理，这是从 Al 偏上层的模型研发或应用开发的角度来 讲。Al 的三大要素包括算力、算法和数据。提取、变形、加载、存储，更多的是解决数据问 题，即怎样获取海量的数据，并通过提取变形把数据转换成或脱离出所需要的信息，用于后 续的模型训练。这些过程不仅 Al 领域使用，包括五六年前的大数据领域，也涉及到提取、变 形、加载、存储等过程。
到 了Al 领域才有了训练，有数据、算法、Al 模型、 Al 芯片强大的算力，就可以实现 一个解决 特定领域的算法，在Al 芯片上通过收集和提取的数据把模型训练出来，训练出来之后再去做 后续的推理。推理相当于把模型训练出来之后，对这个模型做应用。
CUDA 和 ROCm 大同小异，从芯片供应商的角度来讲，都是为了给芯片使用者或者 Al 的开发 者，提供 一个更方便使用 Al 芯片、异构计算的计算机模型的软件栈，都是方便用户使用他的 CPU 或 DSA, 从这个角度来看，二者解决的需求相同。
二者的区别在于 CUDA 推出的时间比较早，在2006 年的时候，英伟达已经开始推 CUDA, 当 时 CUDA 比较难用。经过了10多年的发展，2015 年开始 Al 成为比较热门的发展方向。再加
上在图形图像和并行计算领域，英伟达本身就已经是国际上最著名的公司，所以不管是高校 还是企业，天然地就会选择 N 卡。从这个角度来讲，英伟达赶上了这一波风口浪潮，再加上 CUDA 做并行计算的研发时间要早很多，就带来了这种无与伦比的优势。再者，多年来英伟达 在这个方向上持续进行研发投入、高校和企业持续应用CUDA, 对其生态的发展都做出巨大贡 献，导致目前无论是做训练还是做推理，CUDA 都是最优选择。
至于ROCm, 在2015年Al 浪潮兴起之后，AMD才开始做并行计算、Al 计算领域的软件生态， 相对来说起步更晚一些。再加上AMD 的研发实力也不如英伟达强劲，所以软件栈的丰富度和 好用程度相比英伟达的 CUDA 来说要差很多。并且AMD 芯片本身的迭代速度和算力，与英伟 达的迭代速度和架构变化发展相比也有不小差距。这一系列因素导致无论是AMD 还是国内做 GPU 的芯片厂商，想用ROCm 开源软件栈兼容CUDA 方案去做 Al 技术软件栈都很困难。
总体来说，应该有的东西 ROCm 基本上都已经有了，比如软件生态中的硬件、Al 软件栈、驱 动、运行时间模型、加速库、开发环境和工具包，不过相对来说使用人群较少，导致没有那 么好用。国内做Android 手机操作系统的厂商，尤其是像华为的鸿蒙OS, 其实2010年Android 操作系统刚推出时也非常难用，现在这么好用是因为在使用中不断发现问题，并持续进行优 化，类似于这样一个过程。
ROCm 没有踩在合适的时间点，相对落后于 CUDA, 再加上 AMD 对ROCm 卡的支持欠缺。所 以目前使用AMD 这套来进行Al 模型的训练和推理并不是特别好的选择。
Q:训练和推理分开来看，推理部分ROCm 和 CUDA 会有非常大的使用体验差异吗?还是说差异
主要发生在训练端?
A:首先要明确训练是什么,推理是什么。训练是一个 AI 模型或算法，将数据输入给算法，算 法反复读取之前收集和整理的数据并进行学习，学习之后更新算法中的权重参数，优化损失 函数，使模型精度越来越高，最后使这个模型在解决特定问题时能满足精度要求和实际应用需求。在训练的阶段有前向计算和反向计算，前向计算是把数据让模型运算一遍，观察计算 结果是什么。反向计算是把模型前向计算得出的结果与真实模型数据的标签值进行对比，即与数据应该得出的结果对比，比较模型前向计算结果与真实结果的差距，并进行反向调整参 数。
推理相对简单，只是进行一次前向计算得出结果，在生产环节中用训练好的 Al 模型进行特定 领域的计算，通过推理可以得到想要的结果。从这个角度来看，训练和推理的计算复杂度不 同。ROCm 和 CUDA 在使用的层面还存在不小差距。比如在 PyTorch 上训练一个模型或者用 PyTorch 构建一个模型结构，发现他不能满足要求，想把他迁移到其他框架中进行训练，对于 CUDA 生态来说，有很多工具和方法可以实现模型在不同框架间的迁移。
在 PyTorch 训练好的模型，需要落地做推理， CUDA 也有很多丰富的工具和组件，即之前提到 的 Al 软件栈组件，可以帮助开发者在 N 卡上或国内其他专门做推理的芯片厂商的卡上运行核 型推理， CUDA 都有相应的工具来实现。而ROCm 对于目前主流的深度学习淮架来说确实存在
一定差距和代沟，在 PyTorch 、TensorFlow 有适配 ROCm 的工具，但在一些小众的深度学习框 架，像 MSI 以及百度、飞桨 PaddlePaddle 等都没有。
这导致高校或者公司在一些比较小众的场景时，没有使用PyTorch, 使用了 MSI 、百度、飞桨 PaddlePaddle 等小众学习框架，这时如果用ROCm 做训练或做云端、边缘端甚至终端的推理， 无形中就增加了很多门槛，甚至完全不可用。所以从生态的角度来讲，ROCm 还是有不少的 工作要做。
Q:PyTorch 和 TensorFlow 唯一差别就在功率?可否理解为算子库之类的要素，更多靠用户使用
积累成更多算子库，方便后续新开发者快速提取使用?
A:对，这是其中一部分。算子库一部分是芯片厂商自己针对硬件实现优化后的算子。比如 CUDA 中的 cuDNN 和 cuBLAS, 他们与特定的硬件有深度绑定和深度优化。你提到的是其中一 个主要原因，结合框架层面，当英伟达推出一个新的硬件时，他能够快速地将 CUDA 升级成 新的版本，以适配新的硬件，比如推出了H100, 可能会增加一些针对Transformer 特定算子的 硬件单元，整个算子库需要做调整，对 H100 的算法进行优化或增加新算法，用户在框架上看不到这些变化。
问题是框架层能否快速兼容新的硬件。比如PyTorch 和英伟达之间的关系是， PyTorch 最初做 出来时就是在N 卡上实现，所以他对 N 卡的支持最积极、最及时。但对于 ROCm,2023 年下
半年 AMD 发布了 MI300,ROCm 已经更新到6.0.0 和6.0.1,但 PyTorch 只适配到了 ROCm 的
5.4.2,连5.6.0都没有。而且算子库、数据库与软件栈有关联关系，导致框架无法及时适配最 新的软件栈或算法数据，所以ROCm 在这方面存在较大的风险。AMD 最新的790卡在 PyTorch 的2.0或2.1上不能用，而且无论是AMD还是PyTorch 官方，都没有提供一个兼容最新版本的 PyTorch 安装包。
Q:ROCm 更新后， PyTorch 要主动对应 ROCm 做适配，还是 ROCm 来做?
A:目前 PyTorch 只会适配 N 卡，和N 卡适配的积极性和及时性是最高的。对包含AMD 的其他 厂家都不是这么积极。PyTorch 官方不会主动适配 A 卡，需要 AMD 等芯片厂商主动去适配 PyTorch 最新的版本或者 TensorFlow 最新的版本。当新出硬件或者 PyTorch 新发布的版本，如 果变动比较大，芯片厂商主动要去适配PyTorch 。至于能不能在他的官方发布版本里面体现， 也取决于公司的实力。
Q:最近 AMD 和 Meta 的合作越来越多，减少适配是否不再是主要问题，因为 ROCm升级后可 能会出现 PyTorch 不支持的情况，给用户带来很大影响?
A:目 前 AMD 开始与 PyTorch 深度合作，协同开发其 A 卡，大概是在四五年前开始，到现在已 经取得了一定的阶段性成果。但是距 CUDA 的无差别体验还存在一定的差距。但是根据 AMD 目前的研发实力和在半导体市场的国际竞争能力来看，这只是时间问题，具体多长时间不矿 定。在2023年10月份和11月份，我自己用7600和7900的时候，使用的是 PyTorch1.8 和 1.9,最新版本2.0就不支持，需要自行将官方的2.0、2.1 版本的源码下载下来，与ROCm 最新版本的5.6、6.0 的源码一起编译，这给开发者带来了更大的挑战。希望未来能够像 N 卡一 样及时发布新版本。
Q:从 CNN 迁移到 Transformer 架构，对CUDA 边际壁垒的影响是?
A:首先 CNN (图像卷积神经网络)是在做 CV (图像处理)领域的最优选择，无论是从性能，
还是从内存占用、准确性、精度这几个角度来讲，CNN 在图像领域目前还是无法被替代。目 前一些科研机构和企业，也在研究利用 Transformer, 将这个新的 Al 技术推广到图像识别领域， 但距离能够商用还是有一些差距， Transformer 在一些特定的领域，像 NLP 自然语言处理这种 带有持续性问题，是最优的模型。图像的持续关联相对更弱一些，但是有一些领域会有持续 关联的问题，用 Transformer 会更好一些。
对 CUDA 和英伟达的影响，不能去看 CNN 和 Transformer 这种比较宏观的模型，应该拆分来 看。因为 CNN非常多，比较早的像 AlexNet、最后的 Faster R-CNN 再到 VGG, 再到 ResNet 残 差网络， CNN 在不断更新。最核心的一直是卷积，是矩阵乘再加上激活函数，构成了整个感 知神经网络去做图像的处理。把 Transformer 拆开到散布层面去看也是这样，也是用到了矩阵 乘以及做激活的全连接，像 ConvNeXt。 还有做多头的融合，做Al 或者做残差的规划等等，用 到的基础的算法是相似，只不过 Transformer 对于神经网络的卷积(也可以看为矩阵乘)有一 些特殊性，相对于矩阵乘或向量乘还是有差别的。
所以从CUDA 的角度来讲， Transformer影响不是很大，反而对CUDA 有利好。首先CUDA 的并 行计算本身就比较适合矩阵乘。英伟达的硬件设计能力比较强，像 H100 的 Hopper 架构就实 现了针对 Transformer 的矩阵乘的硬件计算单元，而不只是 Tensor Core,变相加强了 Transformer 出来之后他的芯片能力。
相比于国内的地平线、寒武纪、华为等，更多是在CNN 或者 RNN 模型里面抽象出基础算子， 去做向量或者矩阵乘的计算单元，因为芯片的架构不一样，寒武纪更多走的是电子的架构， 直接在芯片里面设计矩阵乘和计算单元，但是编程的通用性和指令的完备性相对于 GPU 来说 比较差，所以在某些特定的领域，像做归一化、池化、激光激活的全连接，他的计算能力就 比 N 卡差。所以对 CUDA 的影响不大，反而有利好，但是对于Al 计算的芯片架构，会有新的 挑战。
Q:有人认为，过去所有生态圈都是针对CNN架构，当转向Transformer 架构时，过去的积累无
法转化，所以对于ROCm 生态差距会缩小，您认同吗?
A:我认同。Transformer 这种比较特殊的模型，是对一些新兴的半导体、Al 芯片公司有利好的
机会。
Q:硬件端，AMD 和英伟达的单卡在技术水平、算力、性能方面的表现都没有太大落差。再上大模型底层架构改动带来的生态圈改变，差距会缩小，这对 CUDA 并不好?
A:是有这个影响，但是目前英伟达在人工智能领域的市场壁垒短时间内还是无法被撼动。再 加上英伟达超强的研发能力和芯片设计能力，对于国内初创的芯片公司来讲，虽然是一个机 会，但并不见得他们能够利用好这一次机会拉近和英伟达的距离。英伟达可能在3年前甚至5 年前就已经发现这个趋势了，英伟达目前生产一代，设计一代、预研一代，2024 年可能已经 在做2026 年、2027 年的芯片预研了，所以英伟达会充分地调研市场上可能出现的、新的 Al 技术和框架：
加上英伟达庞大的用户基数的反馈，所以其他公司想和英伟达拉近距离并不是那么容易。再 加上英伟达的软件栈和研发能力，单纯看可能有利好，但是整体对比，不见得对其他芯片公 司有利好。
Q:ROCm 作为一个全开源生态的主要逻辑，可否用开源的生态快速获取市场份额?现在 MI300 硬件的性能有提升， ROCm 能快速斩获市场份额吗?
A:第 一 ，ROCm 开源的目的，在一定程度上就是为了能够在市场上让客户快速去用，不一定要 用A 卡，但可以用到ROCm 的开源软件栈；
第二，AMD 想加强在 Al 领域的影响，毕竟他落后了10年，2015 年之前，AMD 并没有对 Al 领域有如此好的预期，导致他并不像英伟达，在2006 年就已经在做高性能计算领域了，再加 上英伟达正好赶上2015年Al 的爆发，所以AMD 开源是为了快速获取市场用户
第三， ROCm 对 AMD 自己卡的适配相对更好， 一些用户或科研会更多用到 AMD, 促进 AMD 在Al 领域的市场占有率提升。加上开源的各种好处，我个人比较看好AMD。
总结来看，开源还是为了能在英伟达有超高市场占有率的情况下，使AMD也拿到一定的市场 份额，对接下来Al 的布局有一些好处。
Q:现在大模型主要都以 pytroch 或 tensor flow 来训，在这种少数框架占据大部份Al 推训方式
的情况下，对生态圈的广泛性要求是否会下降?
A:只看训练确实是有这样的趋势。比如说之前做操作系统，最后也只剩下一两家。以及像 2015到2016年最火的时候互联网有几十家单车公司，现在整合后可能只剩几家，这是一个趋 势。这个趋势对做Al科研、Al应用、芯片的厂商都有好处。从训练角度来看，对AMD 来说， 如果只适配主流的 PyTorch 和TensorFlow 确实没有问题，但仅进行训练是不够的，因为训练之 后更多的是要使用，要进行模型部署，无论是在云端、边缘端还是移动终端进行部署，需要 让模型能够运行。这个时候只有训练框架不够，还需要模型的转换工具、推理引擎、推理框 架、推理系统等等这一系列。
这个不是要AMD 去做了，如果要用AMD 的卡去做推理，那是AMD 要做，如果在A 卡或者 N 卡上训练好了，在PyTorch 训练好的模型用其他家的卡去运行，或者要用其他家的芯片去推理， 这个时候是其他家提供推理或者模型转换的工具。所以单纯从训练角度来讲没有问题。
Q:现在很多大厂、海外头部CSP向 AMD下单，训练端用英伟达，推理端逐步替换一些AMD 。 ROCm 基本完全兼容CUDA, 还需要额外工作来帮助完成推理吗?这样配置是否可行，且为了 适配，边际投入的时间和成本很低?
A:首先，目前训练的市场上 N 卡确实占了无法撼动的市场地位，不管是大模型，还是传统 CNN 的 CV领域模型，甚至小众的语音识别领域、 自动驾驶小模型，在云端训练都会优先选择 用 N 卡，用其他的卡也能训练，但训练出来的精度不一定能达到要求，并且花费的时间和金 钱可能相对较高，可能会比用英伟达卡的成本更高，尤其是时间成本会更高，所以从训练角 度，普遍都是选择英伟达。推理阶段的选择就多了，根据市场需求或者产品需求选择一些比 较低端的卡，或者用边缘端可能选择比较低端的芯片，可以节约产品成本。
既然推理选择不同家的卡，就涉及到模型的转换和迁移的问题，在不同的卡上进行推理，都 需要卡供应商提供相应的软件栈，包括算子库、加速库以及调优和分析的工具。 一部分问题 可
以 用PyTorch 或 TensorFlow 解决，但是大部分还是需要推理端的芯片供应商或者板卡供应商 来解决推理的工具问题和软件栈问题。
Q:假设用英伟达的卡做训练，换成 AMD 的卡做推理，转换难度高吗?
A:如果用 N 卡去做训练，用A 卡去做推理，基于 ROCm 这一套的转换成本会低一些。如果只 讲云端推理，转换成本会低非常多，因为用N 卡做训练就是在 PyTorch 和 TensorFlow 上。推 理的时候可能也是用PyTorch 进行模型转换，或者 TensorFlow 本身就有推理引擎和工具，可以 直接把他迁移到A 卡上做推理。再加上 ROCm 兼 容CUDA, 因为其对外 API 接口是仿照 CUDA 做的，所以天然兼容。虽然不是完全兼容，但在大部分场景下，如果对性能没有过分要求， 那 么 用CUDA 训练，迁移到A 卡上做推理就没有问题。迁移成本或转换成本相对较低。
但是如果遇到用户自定义的算法，或者在CUDA 上用到了一些比较特殊的算法或者硬件，此 时 ROCm 不一定支持或者适配，会带来一些障碍，需要开发人员手动做产品，有一定难度。
Q:因 为ROCm在 API层面全面仿造CUDA 来实现兼容，痛点在于每推出一代新硬件，会有对应 的新算子库，需要快速适配，当中的时间差导致ROCm 用户没办法使用这些功能?
A:是，这是比较大的问题，毕竟 ROCm 是去兼容CUDA, 所以肯定会相对落后，不可能超越，
保持齐平都非常难，能和 CUDA 差一代就已经算比较好。再加上英伟达超强的研发实力和 CUDA 不开源的部分，比如有一些可能不兼容 PTS, 不是用 PTS 去写，针对特定版本特定芯片 直接用底层的汇编去写，就无法实现兼容，这就导致不一定能直接拿过来就用，即使能用，
性能也会较N 卡有比较大的波动，这是他不可避免的问题。
Q:兼容性主要通过转译方式实现， HIPIFY 做 CUDA 转 译 到ROCm 上的动作可能会导性能受损。
能否量化平均性能的受损程度，和主要原因?
A:在使用相同的算力的条件下，都是128P 或者256条，算力在一个数量级的情况下，用ROCm 转换后会遇到几个问题：
第 一个问题是用ROCm 转换后上层还是 CUDA, 或者是用 HIPIFY 将 CUDA 转换成 HIP 。下面运 是用 ROCm 软件栈，中间的软件栈和 CUDA 的软件栈有很大的差别。就好比从Windows 切换到 Android、Linux,操作系统改变，导致原本在 Windows 上运行良好的程序，在 Linux 或 Android 上运行就不一定好。这就和 ROCm 软件栈的实现有关系。根据实际测试结果来看，在 相同算力的情况下，ROCm 相对于CUDA 的性能差一些，大约差了10%。深层次的原因不是算 力，而是 ROCm的软件栈在实现方案和技术上与CUDA不同。
第二个问题是指令转换， CUDA 是这样的：将一个算子编译完成后，可执行程序一般分成两部 分， 一部分是虚拟指令集 PTS, 其目的是在编译完成后将这个程序拿到另一张卡上运行。PTS
在这方面起到了关键作用。另外一个是 COB 二进制文件里面，针对当前系统上的板卡，已经 编译成了最终的汇编指令了。这个时候如果发现板卡是编译成的板卡，就不用走 PTS 那一套， 因为 PTS 需要在虚拟机这一层做实时 DIP 指令的编译和转化，才能在具体的卡上转换成机器 码 。
如果已经识别到编译的卡，就不需要去用 PTS 编译了，直接就用编译好的机器码，这一部分 的性能损耗就会被抹掉。但是 ROCm 无法做到，只能基于 PTS 这一套做转换，把 PTS 虚拟指 令集转成 A 卡或者其他厂家的卡的指令，在转换的过程中，不可避免需要走虚拟机的实时指 令转换，这就会带来一定的性能损失。这两个加起来，严重的话可能会导致1/3 的性能损失。
Q:ROCm 用的 HCC 与英伟达用的NVCC, 差距主要在哪里?
A:首先 HCC 是 ROCm 自己实现的一套编译器，站在HCC 和 NVCC 的角度来讲， 一个是针对 AMD, 一个是针对英伟达。NVCC 底层是英伟达基于编译器技术，针对其 GPU 硬件，实现了 一整套的编译器的解决方案。HCC 底层依赖一个开源的编译器LLVM,LLVM 是为了解决编译的 问题， HCC 建立在LLVM 之上。NVCC 是英伟达针对自己的 GPU 硬件，实现了一个专用的编译 器，只能编译自己的程序，HCC 的底层依赖于LLVM,LLVM 可以编译像X86、ARM 和其他厂家 的指令，甚至可以编译成AMD 或者 CUDA 的 N 卡指令。只要LLVM 支持相应的后端或硬件， HCC 可以编译不同类型的后端或硬件。
HCC 为了解决ROCm 兼容CUDA的目标，在编译时会检查底层硬件是A卡、N 卡还是其他厂家 的卡，并调用相应的编辑器。例如，识别到ROCm 和 HIP接口上使用的算子，但发现底层是N 卡，这时调用的是 NVCC 进行编译，以实现 HCC 的兼容性。他们的目标不仅是兼容CUDA,N 卡和 A 卡硬件，未来还可能兼容其他芯片厂商的硬件。所以 HCC 能够编译不同的部分，以适 应不同硬件。
Q:HCC 整体通用性更强， NVCC 和 HCC对用户使用能力的要求有区别吗?
A:有一定的学习门槛，比如用户习惯了在 N 卡上面用 NVCC 和 CUDA 这一套去编译开发，对 NVCC 的编译器可能就会比较熟悉。如果要转到A 卡 用ROCm 和 HCC, 可能存在学习成本，对 用户或者开发者来讲，使用方式或者体验并没有太大差别，只不过一些编译的选项或者过程 有差别，需要开发者学习。
Q:目前 ROCm 只对部份Al 用 GPU 支持，要做全产品系列支持很难吗?
A:这里全产品指的是不同的芯片。 ROCm 自己去做全产品系列的支持比较难。因为 一个芯片厂 商不可能把 IP 设计等核心要素告诉 AMD 让 AMD 去做适配，如指令集、芯片架构、芯片的存 储层级、芯片里面指令的并行性和指令的发射等等。AMD 只会适配自己的硬件，而且也没有 全部适配自己的芯片。
Q:AMD 为什么不在ROCm 生态上适配自己的所有硬件?除了MI 系列， 一 些基本的(包括游
戏显卡)是不支持的。
A:N卡 做 Al 的人工智能的高性能计算，在2014到2015年的时候，也是 Pascal 架构，在这之 后，他针对 Al 领域做了专门的架构设计。当然也可以全部在图形图像的处理显卡上面运行， 这也没有问题。因为N 卡本身积累的时间比较长，但是 A 卡没有这样做，是因为他 一 直在做 图形图像处理 GPU 部分，再加上图形图像处理在芯片的设计上面有很多的硬是为了做图形渲 染而设计，并不是为了做 Al 通用计算去设计的，导致他做通用计算并不是那么理想。
第二个是 ROCm 本身推出时间不长，也没有大量用户使用和反馈，导致 ROCm 前些年并没有 特别积极推动。最近这几年 ROCm 才开始去做，所以目前并没有全产品系工作支持。从难易 程度来讲，对于 AMD 来说还是存在挑战，因为过去的芯片架构 一直在变，英伟达和 AMD 都 推出了一 系列的架构，所以从技术角度来讲，兼容性是一个比较难的问题。
比如在 MIO 中写了 一个人工智能的算子库，不 一 定能在比较早的老芯片上运行，这是比较难 的兼容问题。所以如果要做，就需要对 ROCm 整个框架做 一 些调整，或者对过去的产品做 一 些梳理，抽象出 一个类似于PTS 的虚拟指令集，来实现产品的兼容性，这样才能更好地适配 不同的产品系列。这部分还是有一 些阻碍的。
Q:CUDA 自定义的算子也需要在CUDA 生态上自己写吗?写起来跟 ROCm 比差距大吗?为什么
一 些特殊的自定义算子从CUDA 迁移到 ROCm 很费力?
A:首先从 CUDA 和 ROCm 编程的角度来讲，迁移成本比较低，因为HIP 本身是模仿的 CUDA 的 API去实现，所以他们的 API的接口和参数大部分x 相同。对于用户来说，无论是在 CUDA 上 面写，还是在HIP 上面写，或者说CUDA 写好了迁移到 HIP 上，都相对容易一 些。
Q:转译过程中平均耗损10%性能，如果在 CUDA 上写好，迁移到 ROCm 上，相同算子在 CUDA
上实现100%, ROCm 只能实现90%,会有这种情况吗?
A:会，这是很正常的情况。比如在CUDA上 面 针 对N 卡写了 一个算子，这个算子的优化都是针 对英伟达的硬件，也就是对存储层级、缓存、内部架构、指令发射做了深度的优化，具有特 殊性。这个特殊性并不完全能应用在 A 卡或者 ROCm 上面。这个时候直接从 API 的层面单纯 迁移过来实际可以运行，但需要针对底层的硬件架构、指令集和存储层级去做定制化的优化， 才能达到预期的性能，这是两个问题， 一个是能运行， 一个是性能。
举个例子，在 CUDA 上使用的是 N 卡。可以想象成找了32个小学生，同时让他们做 一 堆加法 计算，也就是说 N 卡的计算单位是32。但是在 ROCm 里面，有 一 部分卡是以32为单位，另一部分卡是以64 为单位。这就导致了以32 为单位在 N 卡上运行时，性能已经基本优化了， 但在ROCm中以64为单位运行性能就不一定良好，可能需要根据计算单位和任务规模以及使 用的卡来做调整，才能达到最优效果。
Q:ROCm 未来可能会通过扩充用户群、增加硬件销量、增加算子库和支持更多边缘小众框架和 软件来发展。您认为未来两三年中是否可能缩小差距?
A:长期来看会有这样的趋势，AMD 做 ROCm 的目的并不仅仅是为了兼容 CUDA 本身。兼容只 是不得已之举，因为当前Al 领域 CUDA 占据主导市场份额。如果不兼容，潜在用户就不会转 向A 卡和 ROCm 。因此兼容是为了降低终端用户的迁移成本。但ROCm 终极目标和野心更大。 首先他做开源以及 HIP 这一整套软件栈的技术实现，目标是实现统一的 Al 软件栈市场，让大 家都用 ROCm 组合。
就像深度学习框架主流是 PyTorch 和 TensorFlow, 有庞大的软件栈，我们可以将其视为一个操 作系统， ROCm希望大家统一使用ROCm 这个操作系统，而不是其他的操作系统。不同芯片厂 商可以在 ROCm 的全开源软件栈、生态中加入自己的硬件后端，这是他终极目标。但是目前 CUDA 在市场上占据主导地位，所以AMD 只能先兼容CUDA, 才能有后续的发展。
Q:CUDA 的优势之一是跟 PyTorch 形成了2,000多个优化的算子，但 PyTorch2.0 将算子缩减到 250个，是否会大幅降低 ROCm 跟 PyTorch 适配的速度?
A:目前 PyTorch 里面确实有将近2,000个算子，TensorFlow 也有1,000
多个算子，这也是目前 Al 领域发展比较重要的问题——算子在不断增多。这导致后续的芯片厂商，比如国内的芯片 厂商，他要去兼容CUDA 适配PyTorch 去做Al训练的难度比较大。他们首先面临着一个比较大 的门槛，2,000个算子要怎么实现，能做到什么程度。
所以目前有一些发展方向，第一个是把这2,000个算子公共部分抽出来，做成一个类似于小积 木的东西，用这些小的积木去拼出来以前的算法，这样就会导致整个项目的数量会下降。 PyTorch 和国际上的科研机构都在做这个事情。因此对于新兴的芯片公司，包括AMD, 是有利 好。他们可以针对公共抽出来的这些算子去实现，就能够满足适配PyTorch或者 TensorFlow 框 架的最低算子要求。
目前有另外一个新兴发展领域，很多科研机构在研究 Al 编译器，借助于传统编译器的思路去 做 Al 编译，把算子开发通过编译的方式去间接解决，这样的的好处是不用做很多算子，遇到 没有见过的算子，在底层通过编译的方式，可以把他转换成一个可实现的指令做适配。这就 降低了芯片厂商、科研机构实现算子的复杂度了。
Q:一种方向是把公共的先做出来、用起来，另一种发展 Al编译器，通过编译解决算子?
A:陈天奇负责的TVM 做得比较好。XLA 是TensorFlow自己做的一个类似于深度学习编译系统， PyTorch2.0 之后，在 PyTorch 框架里面也加了编译的工作，把2,000个算子的公共部分抽离出 来，加上Al 编译技术，就能更好应对未来新出现的 Al 模型对算子的需求。
Q:PyTorch 对 AMD 支持不足，是合作关系不够紧密，还是技术问题?
A:我个人不了解他们两家合作紧不紧密，这是一个市场问题。从技术角度来讲， ROCm 出现的 比较晚，并没有得到 PyTorch 的重视，让PyTorch 框架主动去适配 ROCm 软件核心的硬件。
Q:目前哪些推理框架用得比较多?
A:推理框架大多数都没有开源，各家芯片制造商都在自行开发。国外是 N 卡，有两个推理框 架， 一个是N 卡 RTX, 用 于 N 卡的推理加速，还有一个 Triton Inference Server 专门做推理服 务。这些都是非开源的，都是 N 卡为了自己的推理而做。从深度学习框架的角度来看， PyTorch 不太适合推理，因为他最初的设计目的并不是为了推理。而 TensorFlow 在推理上做了 很多工作，无论是在云端还是终端、边缘端，都有大量的支持，包括TensorFlow Lite 等都可以 很好地满足不同的云端、终端和边缘端的推理需求。当然核心部分也是非开源的。
至于芯片公司，有 N 卡 RTX, 国内寒武纪的 CNStream 也在做开发的推理引擎，这些都是非开 源的。目前也出现了许多开源方案，比如阿里发布 MNN 等，总体来说，目前有非常多开源或 闭源的解决方案。
Q:CUDA 的软件栈比较丰富， ROCm 也提供函数加速库，如CUDA 有 cuDNN,ROCm 有 MIOpen
做匹配， CUDA 软件生态更丰富体现在哪里?
A:第 一 ，CUDA 实现的算子丰富度相对于 MIOpen 更多；
第二，不管是在训练还是在推理，尤其是在推理阶段，需要做算子的融合。MIOpen 的算子融 合相对于CUDA 做得比较少，其实也是算子实现的问题。毕竟 MIOpen 的发展时间比较短，把 这些融合算子和独立算子加起来，数量非常庞大，所以还是需要花不少时间。另外一个是基 础的数学库相对比较少，相对会更容易实现一些。
-----------------------------------------------------------------------------
读完顺手点下“在看”，下次更新优先推送消息；欢迎点赞、在看；更多纪要：及时分享市场、行业及公司动态，包括投资策略、行业数据库、专家调研、公司纪要；信息超越99%的投资者；投资资料包括纪要音频会议、pdf及word纪要、行业及公司数据库、事件点评等；为您节省时间，提高效率，获取高质量的投研信息；有数万份一手纪要信息，可作为投资数据库使用。
欢迎点赞、在看；更多纪要：请加微信：value116688
