扫码打开虎嗅APP
本文来自微信公众号:半导体行业观察 (ID:icbank),作者:编辑部,头图来自:视觉中国
外媒HPCwire之前也曾直言,GenAI和GPU与Nvidia的合作并非偶然。Nvidia一直认识到需要工具和应用程序来帮助其市场增长。他们为Nvidia硬件创建了非常低的获取软件工具(例如CUDA)和优化库(例如cuDNN)的门槛。
确实,Nvidia被称为一家硬件公司。但正如Nvidia应用深度学习研究副总裁Bryan Catanzaro所说,“很多人不知道这一点,但Nvidia的软件工程师比硬件工程师还多。”Nvidia围绕其硬件建立了强大的软件“护城河”。
虽然CUDA不是开源的,但它是免费提供的,并且由Nvidia牢牢控制。虽然这种情况让Nvidia受益(理所当然。他们在CUDA上投入了时间和金钱),但对于那些希望通过替代硬件抢占部分HPC和GenAI市场的公司和用户来说,这带来了困难。
不过,最近又有一个方案跃跃欲试。
SCALE,横空出世
如Phoronix所说,为了突破CUDA护城河,现在已经有各种努力,比如HIPIFY帮助将CUDA源代码转换为适用于AMD GPU的可移植C++代码,然后是之前由AMD资助的ZLUDA,允许CUDA二进制文件通过CUDA库的直接替换在AMD GPU上运行。
但现在又出现了一个新的竞争者:SCALE。SCALE现已作为GPGPU工具链公开,允许CUDA程序在AMD图形处理器上本地运行。
据介绍,SCALE由英国公司Spectral Compute历时七年打造。SCALE是CUDA的“洁净室”(clean room)实现,它利用一些开源LLVM组件,同时形成一种解决方案,无需修改即可本地编译适用于AMD GPU的CUDA源代码。
与其他仅通过转换为另一种“可移植”语言或涉及其他手动开发人员步骤来帮助代码转换的项目相比,这是一个巨大的优势。
SCALE可以按原样使用CUDA程序,甚至可以处理依赖于NVPTX汇编的CUDA程序。SCALE编译器也是NVIDIA nvcc编译器的替代品,并且具有“模拟”(impersonates)NVIDIA CUDA工具包的运行时。
SCALE已成功通过Blender、Llama-cpp、XGboost、FAISS、GOMC、STDGPU、Hashcat甚至NVIDIA Thrust等软件的测试。Spectral Compute一直在RDNA2和RDNA3 GPU上测试SCALE,并在RDNA1上进行基本测试,而Vega支持仍在进行中。
从本质上讲,SCALE是一个兼容nvcc的编译器,它可以编译AMD GPU的CUDA代码、AMD GPU的CUDA运行时和驱动程序API的实现,以及开源包装器库,后者又与AMD的ROCm库交互。
例如,虽然ZLUDA是由AMD悄悄资助的,但Spectral Compute表示,他们自2017年以来一直通过其咨询业务资助这一开发。SCALE唯一直接的缺点是它本身不是开源软件,但至少有一个可供用户使用的免费版本许可证。
据官方的文件介绍,SCALE是一个GPGPU编程工具包,允许CUDA应用程序为AMD GPU进行本地编译。SCALE不需要修改CUDA程序或其构建系统,而对更多GPU供应商和CUDA API的支持正在开发中。
从构成上看,SCALE包括:
1. 一个nvcc兼容编译器,能够为AMD GPU编译nvcc-dialect CUDA,包括PTX asm。
2. 针对AMD GPU的CUDA运行时和驱动程序API的实现。
3. 开源包装器库(wrapper libraries)通过委托给相应的ROCm库来提供“CUDA-X”API。这就是和等库的cuBLAS处理cuSOLVER方式。
与其他解决方案不同的是,SCALE并不提供编写GPGPU软件的新方法,而是允许使用广受欢迎的CUDA语言编写的程序直接为AMD GPU进行编译。同时,SCALE旨在与NVIDIA CUDA完全兼容,因为他们认为用户不必维护多个代码库或牺牲性能来支持多个GPU供应商。
最后,开发方表示,SCALE的语言是NVIDIA CUDA的超集,它提供了一些可选的语言扩展,可以让那些希望摆脱的用户更轻松、更高效地编写GPU代码nvcc。
总结而言,与其他跨平台GPGPU解决方案相比,SCALE有几个关键创新:
1. SCALE接受原样(as-is)的CUDA程序。无需将它们移植到其他语言。即使您的程序使用内联PTX也是如此asm。
2. SCALE编译器接受与相同的命令行选项和CUDA方言nvcc,可作为替代品。
3. “模拟”NVIDIA CUDA工具包的安装,因此现有的构建工具和脚本就可以cmake正常工作。
具体到硬件支持方面,在特定硬件支持方面,以下GPU现在会得到支持和测试:
AMD GFX1030(Navi 21、RDNA 2.0)
AMD GFX1100(Navi 31、RDNA 3.0)
以下GPU目标已经过临时手动测试并且“似乎有效”:
AMD GFX1010
AMD GFX1101
Spectral Compute正在致力于支持AMD gfx900(Vega 10、GCN 5.0),并且可能会针对其他GPGPU。
当然,如前所说,他们会支持更多的GPU。
突破CUDA,AMD和Intel的做法
作为GPU的另一个重要玩家,AMD也正在通过各种各样的办法跨越CUDA护城河。
在HPCwire看来,替换Nvidia硬件意味着其他供应商的GPU和加速器必须支持CUDA才能运行许多模型和工具。AMD也已通过HIP CUDA转换工具实现了这一点。据了解,这是一种C++运行时API和内核语言,可让开发人员从单一源代码为AMD和NVIDIA GPU创建可移植的应用程序。需要强调一下的是,HIP不是CUDA,它原生基于AMD ROCm,即AMD的Nvidia CUDA等效产品。
AMD还提供了开源HIPIFY转换工具。HIPIFY可以获取CUDA源代码并将其转换为AMD HIP,然后可以在AMD GPU硬件上运行。当然,这同样是其ROCm堆栈的一部分。
AMD同时还和第三方开发者共同合作,推出了ZLUDA项目,从而让AMD的GPU也可以在英伟达CUDA应用上运行。ZLUDA在AMD GPU上运行未经修改的二进制CUDA应用程序,性能接近原生。ZLUDA被认为是alpha质量,已确认可与各种原生CUDA应用程序(例如LAMMPS、NAMD、OpenFOAM等)配合使用。直到最近,AMD还悄悄资助了ZLUDA,但赞助已经结束。该项目仍在继续,因为最近有人提交了代码库。
来到英特尔方面,他们也做了很多尝试。
在2023年9月的一个演讲中,英特尔首席技术官Greg Lavender建议,我们应该构建一个大型语言模型(LLM),将其转换为可以在其他AI加速器上运行的东西——比如它自己的Gaudi2或GPU Max硬件。“我向所有开发人员提出一个挑战。让我们使用LLM和Copilot等技术来训练机器学习模型,将所有CUDA代码转换为SYCL”,Greg Lavender说。
据介绍,SYCL在异构框架中跨CPU、GPU、FPGA和AI加速器提供一致的编程语言,其中每个架构都可以单独或一起使用进行编程和使用。SYCL中的语言和API扩展支持不同的开发用例,包括开发新的卸载加速或异构计算应用程序、将现有的C或C++代码转换为与SYCL兼容的代码,以及从其他加速器语言或框架迁移。
具体而言,SYCL(或者更具体地说是SYCLomatic)是一个免版税的跨架构抽象层,为英特尔的并行C++编程语言提供支持。
简而言之,SYCL处理了大部分繁重的工作(据称高达95%),即将CUDA代码移植到可以在非Nvidia加速器上运行的格式。但正如您所预料的那样,通常需要进行一些微调和调整才能让应用程序全速运行。
“如果你想要充分利用英特尔GPU(而不是AMD GPU或Nvidia GPU),那么你就必须采取一些措施,无论是通过SYCL的扩展机制,还是简单地构建代码,”英特尔软件产品和生态系统副总裁Joe Curley解释道。
与此同时,由英特尔、谷歌、Arm、高通、三星和其他科技公司组成的一个团体正在开发一款开源软件套件,以防止人工智能开发人员被Nvidia的专有技术所束缚,从而使他们的代码可以在任何机器和任何芯片上运行。
这个名为“统一加速基金会”(UXL:Unified Acceleration Foundation)的组织告诉路透社,该项目的技术细节应该会在今年下半年达到“成熟”状态,但最终发布目标尚未确定。该项目目前包括英特尔开发的OneAPI开放标准,旨在消除对特定编码语言、代码库和其他工具的要求,避免开发人员必须使用特定架构,例如Nvidia的CUDA平台。(具体可以参考之前的文章《打破CUDA霸权》。)
但是,这似乎还不够,更多厂商也在行动。
还有更多方案
如大家所知,在HPC领域,支持CUDA的应用程序统治着GPU加速的世界。使用GPU和CUDA时,移植代码通常可以实现5-6倍的加速。(注意:并非所有代码都能实现这种加速,有些代码可能无法使用GPU硬件)
然而,在GenAI中,情况却大不相同。
最初,TensorFlow是使用GPU创建AI应用程序的首选工具。它既适用于CPU,也可通过GPU的CUDA加速。这种情况正在迅速改变。TensorFlow的替代品是PyTorch,这是一个用于开发和训练基于神经网络的深度学习模型的开源机器学习库。Facebook的AI研究小组主要开发它。
AssemblyAI的开发者教育者Ryan O'Connor在一篇博客文章中指出,热门网站HuggingFace(用户只需几行代码即可下载并把经过训练和调整的最新模型合并到应用程序管道中)中92%的可用模型都是PyTorch独有的。
此外,如图一所示,机器学习论文的比较显示出了明显的倾向于使用PyTorch而远离TensorFlow的趋势。
当然,PyTorch的底层是CUDA调用,但这不是必需的,因为PyTorch将用户与底层GPU架构隔离开来。还有一个使用AMD ROCm的PyTorch版本,AMD ROCm是用于AMD GPU编程的开源软件堆栈。跨越AMD GPU的CUDA护城河可能和使用PyTorch一样简单。在之前的文章《CUDA正在被赶下神坛》中,有谈了PyTorch对CUDA的影响,
对于这些方案,大家都是怎么看啊?
参考链接:
https://www.hpcwire.com/2024/07/18/scaleing-the-cuda-castle/
https://www.phoronix.com/news/SCALE-CUDA-Apps-For-AMD-GPUs