无须英伟达，AMD本地可跑CUDA？惊现极客团队开发三方编程工具包，网友群议指责AMD无作为：已经晚了，CUDA已经是事实标准了
为了缓解“英伟达”焦虑，市场上浮现出了不可思议的事情。 就在今天，一个“可以让AMD GPUs上跑CUDA的编程工具包”不胫而走，引起业界的注意。
不需要修改 CUDA 程序，也不需要构建系统，通过一个编程工具包，就可以把CUDA应用程序进行AMD GPU的本地编译。这个工具包就是Spectral Compute推出的SCALE。
关键是，SCALE的制作方还是个“AI芯片大一统的野心家”，表示：“当然，AMD 只是开始，对更多 GPU 供应商和 CUDA API 的支持正在开发中。”
据介绍，SACALE有以下几个部分组成：一个nvcc兼容编译器，能够为 AMD GPU 编译 nvcc-dialect CUDA，包括 PTX asm；针对 AMD GPU 的 CUDA 运行时和驱动程序 API 的实现；开源包装器库通过委托给相应的 ROCm 库来提供“CUDA-X”API。这就是和等库的cuBLAS处理cuSOLVER方式。
测试了哪些项目？
SCALE 团队通过编译开源 CUDA 项目并运行其测试来验证 SCALE。并且完全通过的开原项目包括：NVIDIA Thrust、Blender Cycles、AMGX、llama-cpp、stdgpu等。
目前支持哪些 GPU？据介绍，AMD gfx1030（Navi 21、RDNA 2.0）、AMD gfx1100（Navi 31、RDNA 3.0）已经通过测试，AMDgfx1010、AMDgfx1101临时测试后似乎有效。
那么SCALE是如何做到的？
市面上有不少跨平台的GPGPU解决方案，比如受到英伟达官方支持的HIP方案，可以避免使用CUDA的模糊功能（如内联PTX）的代码，而AMD自己，本身就有一种转换工具：hipfy，可以将CUDA代码转换为hip。
那么与其他跨平台 GPGPU 解决方案相比，SCALE 有几个关键创新：
- SCALE 接受原样的 CUDA 程序。无需将它们移植到其他语言。即使您的程序使用内联 PTX 也是如此asm。
- SCALE 编译器接受与 相同的命令行选项和 CUDA 方言nvcc，可作为替代品。
- “模拟” NVIDIA CUDA 工具包的安装，因此现有的构建工具和脚本就可以cmake正常工作。
当然在某些领域，SCALE对NVIDIA CUDA中某些功能的实现也有不同的行为。比如，SCALE尚不支持每个线程的默认流行为，虽然这不会破坏程序，但可能会降低性能。而在NVIDIA GPU上运行时，则有一种也会略微提高程序性能的解决方法：即显式使用非阻塞CUDA流，而不是依赖于隐式CUDA流。
整体上看，与其他方案有这些不同：
（1）SCALE并不提供编写 GPGPU 软件的新方法，而是允许使用广受欢迎的 CUDA 语言编写的程序直接为 AMD GPU 进行编译。
（2）SCALE 旨在与 NVIDIA CUDA 完全兼容。我们认为用户不必维护多个代码库或牺牲性能来支持多个 GPU 供应商。
（3）SCALE 的语言是NVIDIA CUDA 的超集，它提供了一些可选的 语言扩展 ，可以让那些希望摆脱的用户更轻松、更高效地编写 GPU 代码nvcc。
当然，SCALE 尚在开发中。可能会缺少部分 API 而导致无法使用 ，不过团队会根据用户提的需求加速开发。
神奇的极客团队
Specrtral Compute 是一个致力于加速GPGPU和HPC工作负载的全球团队，这个团队很神奇。小编翻了一下他们官网，可谓是一群AI极客的玩法。
官网显示，他们推出了一种1秒内向全球传送视频的直播解决方案，还针对高吞吐量的GPU加速应用程序后台和低延迟CPU执行进行优化，推出了最快的正则表达式引擎，而且性能不受影响；此外，这个团队队员还擅长优化你在用AI软件，使其要么跑得更快，要么服务免费。
万能的网友：为什么不是AMD？但代替不了英伟达
首先，一部分人争议的焦点是“怒AMD不争”——“如果AMD采取任何行动就好了，支持这个，任何一项都会话费几百万美元，但对AMD股东来说却价值一万亿美元。”
然而也有人认为AMD正在努力，正如上文提到的HIP解决方案。
然而，也有部分网友认为如果AMD支持这样的编程工具或者转换层，会是一个坏主意。
据悉，CUDA 的设计并不与供应商无关，而 Nvidia 可以在技术和法律上任意制造困难。“我认为在此上运行 cuDNN 或 cuBLAS 违反了许可协议。因此，这些和其他 Nvidia 库将成为 AMD 需要重新实现和支持的 API 边界的一部分。”
“追求 bug-for-bug 兼容性是愚蠢的行为。CUDA 的重要用户是开源。AMD 可以直接在上游项目（如 pytorch 或 llama.cpp）中实现支持。一旦获得支持，社区就可以对其进行维护。”
指责 AMD 而不是 Nvidia，这很奇怪吗？
事实并非如此。
一位网友已经被CUDA征服了，“即便AMD有一些努力，我也不相信 HIP 或 RocM 是 Cuda 的可行替代品。”
George Hotz 做了很多工作，试图将各种 ML 架构移植到 AMD，并遇到了无数的驱动程序错误。问题不在于英伟达不会构建开放平台——问题在于 AMD 不会投资竞争平台。
即使 CUDA 是开放的， 你是否希望 nvidia 也为 AMD 编写驱动程序？我不相信第三方会编写“兼容层”，因为 AMD 自己的 GPU 并未针对类似 CUDA 的工作负载进行优化或测试。
99%的ML工程师不会写CUDA
99% 的 ML 工程师不会编写 CUDA。一位业内人士表示，对于绝大多数工作负载，Meta 可能有 20 名工程师为 Pytorch 编写 Cuda 后端，其他每个工程师都会使用。Meta 可以再雇佣 20 名工程师来支持 AMD 拥有的一切（他们确实这样做了，但它不如 CUDA 那么强大）。
真正擅长CUDA的工程师是金子一样的贵，所以他们能做的项目远远超出了自己的精力和时间。甚至又网友爆料称：自己认识一位CUDA工程师配有一个滑雪屋，价值超过180镑黄金（约532万美元）。
也有人延伸出了对现有芯片编程的建议，希望赶紧加入互操作性，开发人员太需要互操作性技术了。互操作性技术可以帮助目前仅支持NVIDIA GPU的软件在未来快速添加对Intel和AMD GPU的支持。
写在最后：英伟达的CUDA已经成为事实上的标准
作为 NVIDIA 发明的一种并行计算平台和编程模型，CUDA已经凭借大模型时代成功完成了蝶变，目前基于 CUDA 的 GPU 销量已经达到无法完全统计，软件开发商、科学家以及研究人员正在各个领域中运用 CUDA。
——好文推荐——
恒生电子首席科学家白硕：长文本和多模态是生成式AI落地金融的两大利器