发布日期:2024-12-19 23:55 点击次数:93
着手:至顶网白丝 足交
英伟达正面对着多年以来最热烈的竞争态势,英特尔及AMD的新款加快器试图在内存容量、性能以及价钱等多个方面对其芯片产物发起猛攻。
可是,单纯打造一款有竞争力的产物还远远不够:厂商还必须开发出大致充分发掘算力资源的软件——英伟达花了近二十年时刻,才构建起精深的CUDA运转时生态。
英伟达在开发者社区中享有殊荣。不少代码库都特意针对这家特定品牌的硬件所编写和优化,而其他相通面向底层GPU编程的竞争框架则远远不够练习。这样的早期模式,经常被东说念主们称为“CUDA护城河”。
那么,让英伟达引以为傲的这条护城河到底有多深?
其实不错思见,这个问题的谜底取决于咱们思要完了的贪图。如果正面向GPU进行底层编程,那么CUDA护城河就越过真实具体,意味着必须对现存代码进行移植、重构和优化能力在其他替代硬件上运转。
这并不难长入,毕竟CUDA和英伟达芯片中的某些硬件调用在英特尔或者AMD硬件当中压根不存在——反之亦然。也即是说要思把三年、四年以致是十年之前为CUDA开发的代码引入AMD ROCm或者英特尔OneAPI,最初需要劝服也曾习尚于英伟达平台的开发者们。
伸开剩余91%也正因为如斯,英特尔和AMD才参加巨资开发器具,但愿完了将CUDA源代码改动为各自平台不错运转的自动化历程。比如说AMD的HIPIFY,就能匡助自动将CUDA改动为HIP C++代码。
AMD公司AI部门高档副总裁Vamsi Boppana在采访中暗示,“关于那些负责编写内核的开发者而言,他们也曾相配习尚用CUDA来完成,至少多年以来也曾积聚下大宗CUDA代码。我以为咱们是独一大致匡助其顺利完成迁徙的替代有筹画,因为咱们提供HIPIFY以提供不错编译的HIP C++代码。”
天然如实在很猛进度上惩办了问题,但HIPIFY也还远称不上圆善。字据期间媒体的观察,HIPIFY面对的一大挑战即是其莫得议论纹理内存中的开荒端模板参数或者多个CUDA头文献的情况,这些都需要由开发东说念主员手动干预。
另一方面,英特尔则领有SYCL。它与HIPIFY近似,大致承担起大部分贫穷的迁徙办事(据称高达95%),高效将CUDA代码移植至不错在非英伟达加快器(包括AMD偏激他厂商的加快器)上运转的格式。
临了需要防卫提到的,还有AMD偷偷资助开发的款式,堪称大致将未经转译的CUDA代码径直在其硬件上原生运转。但就在本年早些时候,可能是惦记违背英伟达的CUDA服务条件规定、也可能出于其他议论,AMD方面拔除了这一起劲,并选用步履压制了开发东说念主员的进一步尝试。
但天然CUDA护城河关于但愿扩大对替代硬件平台的支抓范围的开发者来说是铁一般的事实,但至少在英特尔和AMD的高管们看来,真实需要在内核级别编写代码的开发东说念主员其实并不太多。
英特尔公司数据中心与AI软件副总裁Bill Pearson在最近一次采访中指出,“几年之前通盘阛阓就只须CUDA,东说念主们也习尚于径直编程。但现时,咱们看到大多数开发东说念主员都也曾在PyTorch或者其他框架上编程。”
AMD公司的Boppana也讲解说念,该公司在其Instinct加快器上也看到了近似的情况,即昔时一年间该款加快器的选用率迎来飙升。“现实情况是,东说念主们但愿在更高档的详细层上进行编程。”
由PyTorch构建起的路子
在这波趋势之下,PyTorch尤其成为各大兜销英伟达替代产物的AI芯片厂商的首选。天然并不是面向当代加快器的独一高档编程言语,毕竟还有TensorFlow、JAX以偏激他多种选项,但PyTorch无疑是最受迎接的言语之一。
多年以来,AMD的ROCm一直得到PyTorch的原生支抓,而对英特尔GPU的支抓也在本年早些时候庄重推出。咱们在后文中会具体聊聊PyTorch关于IPEX和Gaudi的支抓,但在此之前,不妨先对PyTorch本色作念一番阐述。毕竟它并不一定真像芯片厂商们宣传的那样,足以成为弥合不同加快器间领域的灵丹灵药。
PyTorch的基本逻辑即是成立在CUDA、ROCm或者OneAPI等框架之上,同期字据系统民履行装配的硬件径直调用合适的后端。表面上,这意味着为PyTorch编写的代码应该不错运转在职何大致支抓该框架的平台之上。
Boppana指出,“关于使用PyTorch等当代框架并配合一系列受支抓轨范库的开发者来说,我以为这是一条极为浅显且摩擦较少的路子,大致顺畅对接咱们的GPU。”
但在履行期骗中,仍然存在着不少问题。即使PyTorch大致在这些加快器上运转,也并不代表不会出现故障缺欠。
事实上,用于构建PyTorch期骗设施的不少库和模块在添加对替代架构的支抓方面一直进展逐渐。因此,平常需要进行一定进度的重构能力运转现存剧本。
BitsandBytes即是其中一例。这款量化库平常用于推理及QLORA微调,旨在减少大言语模子(LLM)的内存占用量,以便这些办事负载大致在单个GPU或者节点之上完成。
缺憾的是,直到最近,BitsandBytes仍无法原生支抓英特尔或者AMD家的硬件。也即是说,开发者无法像在英伟达硬件上那样径直运转pip install bitsandbytes并指望它正常运转。相背,英特尔和AMD用户必须找到特定于厂商的代码分支,并祷告它能跟最新版块的PyTorch以及Python相兼容。
需要明确的是,这不单是是BitsandBytes我方的问题——许多库在支抓智商方面都存在近似的局限。
Pearson讲解称,“开发东说念主员但愿能有更多的库可供采纳。毕竟市面上也曾有现成且经过性能优化的GEMM,咱们必须保证我方也提供GEMM和库的相应版块。”
一般来讲,这要求芯片制造商与社区和谐以分叉代码库、对其进行修改、在自家硬件之上运转,并在保证一切顺利之后将调治恶果孝顺回干线分支。
Boppana强调,“如果咱们以为阛阓关于特定库或者一组期间有筹画具有明确需求,那就会倾向于加以鼓吹。更病笃的是,咱们本人的智商是有限的,更需要通盘社区的参与和支抓。只须社区景观为其作念出孝顺,但咱们就完全会协助何况跟进。”
音问是,这种趋势正在发生。
Pearson提到,“那些专有且依附于底层架构的依赖项天然在某些场景下仍然存在,但也曾是越来越少,而且还在极少点散失。”
自从最早遇到BitsandBytes的兼容性问题以来,咱们也真的不雅察到关于AMD及英特尔家GPU的支抓,也曾通过实验性的“多后端”版块得到了膨胀。可是哪怕是在庄重发布之后,通盘装配过程仍然不像在英伟达硬件上那么方便易行。
简言之即是,天然支抓效果正在改善,但仍有许多问题需要惩办。
软件兼容性的“雷区”
人人不错重逢,兼容库的碎屑化势必会形成一定进度的软件兼容性“雷区”。除非找到了正确版块的Python、PyTorch、BitsandBytes(以偏激他一大堆库),不然开发者动不动就会遇到剧本无语其妙出错的逆境。
公说念地讲,英伟达客户也无法完全幸免这类情况。但由于需要追踪以致时常编译多样流行库的兼容版块,AMD和英特尔GPU客户面对的情况只会愈加复杂。
英特尔、AMD以及英伟达也曾在选用步履派遣其中部分挑战,具体主义即是提供行为开发环境的预配置容器镜像。正如前文也曾提到,这些容器镜像不错浅显被预配置为ROCm、OneAPI或者CUDA环境,也不错包含完整的PyTorch装配。
Pearson讲解称,“比喻说,当咱们有了PyTorch容器,那么接下来只需要获取Gaudi运转需要的总共库即可。”
恰是因为对PyTorch的具体支抓在各家硬件供应商之间各有不同,这些容器的出现才显得异常病笃。
关于英特尔来说尤其如斯,他们提供面向其GPU及Gaudi3加快器进行调治的定制版PyTorch。走访PyTorch网站、向下振荡,人人就会很快判辨到这里压根不提供OneAPI或者Gaudi选项。这是因为Gaudi加快器上的PyTorch支抓,履行上依赖于英特尔开发的自界说库版块。
直到最近添加对PyTorch的原生支抓之前,英特尔GPU的情况也基本近似。好在天然这项原生支抓智商尚处于预览阶段,是以还莫得庄重登陆PyTorch官方主页,但其如实存在而且咱们也切身进行了测试。
而且在英特尔GUP添加原生PyTorch支抓智商之前,这种兼容性主淌若依靠名为Intel Extension for PyTorch(即英特尔PyTorch膨胀,简称IPEX)的自界说版块完了的。该软件包含一系列性能优化和库,旨在以愈加无缝的样子让代码运转在英特尔的加快器之上。
Pearson讲解说念,“咱们也曾完成了优化办事,先是构建库、之后优化GEMM和这些库的具体内容,由此匡助开发东说念主员消弱使用咱们提供的模板编写PyTorch代码,或者使用咱们的现存代码以完了从CUDA向Gaudi的迁徙。”
他同期补充称,“这种样子的开发体验总体上如故比较消弱的,天然还够不上零办事,但通盘过程如实不需要太多迥殊调治。约莫的操作即是将指向贪图从英伟达变更为Gaudi,然后将输出也调治至兼并贪图。”
巨乳porn天然咱们还莫得测试过英特尔的Gaudi平台,但基本不错认定,许多PyTorch剧本只需稍加调治就不错在IPEX之下运转。
跟着各家芯片制造商鼓吹关于主流框架和库的原生支抓,最大的问题也曾不在于其是否大致运转,而是运转性能何如。
跌跌撞撞的开发历程
为x86或者Arm CPU构建期骗设施之是以如斯浅显,最病笃的原因之一即是所需的硬件无处不在、大致消弱获取。人人不错在札记本电脑、台式机或者办事站上入辖下手构建,并在改良练习之后通过CI/CD(抓续集成/抓续部署)管线将其膨胀至专用构建环境。
关于在英伟达硬件上构建款式的开发者来说,情况也差未几。除了少数例外,CUDA在移动GPU上的运转样子跟在3万好意思元的H100 GPU上完全疏导。也即是说,只须你的系统配备有英伟达GPU,那么开发前的一切准备办事就果决就绪。
但在竞争敌手这边,事情就没这样顺利了。在台式机和办事站领域,AMD领有Radeon和Radeon Pro GPU,它们使用的是自家RDNA微架构,而其专注于数据中心的Instinct芯片则使用其CDNA架构。尽管存在诸多各异,AMD仍然将ROCm支抓膨胀到了部分7000系列Radeon卡之上,以期自若其在开发者群体中的认同度。
在大多数情况下,咱们发现一切如实大致正常运转。可话虽如斯,咱们在Flash Attention 2上如故遇到了费劲——这是一套越过病笃的库,负责在更大的高下文长度之下保证生成式AI模子永久领有可控的内存占用量。履行上Instinct家眷关于Flash Attention 2的支抓也曾落实了一段时刻,但将该库引入Radeon的起劲却仍在进行当中。
如故以Flash Attention为例,之前出现的Triton内核库就能有用动用内存,以在某些情况下克服这方面局限。比如咱们在最近的Axolotl微调指南中就使用了一款实验性的AoT Triton内核。
但这在很猛进度也跟阛阓的举座倾向相关。其实不难思象,相较于那些专科构建考研集群并依托领有万亿以上参数的大体量模子运转推理的用户比较,思要使用游戏GPU编写机器学习期骗设施的群体在限度上如实相对更小。
Boppana也承认,“咱们仍然将主要元气心灵皆集在保险Instinct的兼容性身上,这亦然咱们诸多款式的考量要点。”尽管MI300X一年多之前才初次亮相,但该部件也曾在云霄得到平凡部署,包括通过耐久条约以及按需调用等体式。
但Boppana也判辨到了阛阓关于办事站级硬件的需求。他不雅察到,“我个东说念主以为云不能能是独一的方法,开发东说念主员都但愿在我方的办公桌下摆一台办事站,这样他们就不错大肆探索尝试、无用太多议论运转资本。”
关于英特尔来说,情况则愈加复杂。英特尔的旗舰级AI加快器是Gaudi 3——而至少到现时,这款硬件还不提供任何办事站版块。
更病笃的是,Gaudi加快器履行上并不支抓OneAPI,反而依赖于Habana自家的SynapseAI软件期间栈。也即是说,策画在Gaudi之上构建期骗设施的开发东说念主员,履行只可使用英特尔的Tiber开发者云。
天然,英特尔家的GPU(包括其Arc游戏显卡)倒是都能支抓OneAPI。因此如果思要编写不错膨胀至Datacenter Flex或者GPU Max显卡集群的代码,笃信是莫得问题。可话虽如斯,字据咱们的不雅察,各样软件支抓永远是先在Datacenter Flex这边完了,之后才被推向Arc。
另一个阻截无情的问题,即是GPU Max(笔名Ponte Vecchio)也曾过期。因此除了阿贡国度实验室(其Aurora系统中装配有6万多张这款GPU)以外,我概略情还有若干东说念主会在分娩场景中为其编写代码。
跟着来岁Falcon Shores的推出,这种情况可能会改变,其将选用GPU架构以及一系列接收自Gaudi的设想元素。据臆测,这款加快器也将支抓OneAPI。
绕过护城河
天然CUDA护城河关于开发者和芯片制造商来说仍是一大现实挑战,但关于只是思大限度构建大言语模子的用户,这其实并不需要诸位太过惦记。
非论人人采纳哪种硬件——包括英特尔、AMD、Cerebras、SambaNova、高通或者其他厂商——总共这些供应商都开发或者孝顺了大致让大模子顺利生成token所需的必要代码。
简直每家厂商都有我方的框架,用于简化在其硬件上部署聊天机器东说念主式期骗有筹画(举例检索增强生成RAG)的具体历程。
天然,在某些情况下,开发东说念主员也如实但愿赢得与OpenAI相兼容的API服务器。毕竟当下的许多AI期骗设施履行上即是围绕着OpenAI、Anthropic或者Mistral AI API服务器构建的打包器——也即是说,其代码从来不需要径直跟GPU或者AI加快器奉行交互。
也即是说其代码相对易于移植。举例,不错使用Anthropic的Claude构建见地考据,尔后出于安全或者合规议论,在参加分娩之后将API服务器及密钥更换成vLLM或者TensorRT-LLM的土产货实例。
可是,尽管简直任何AI加快器都不错复古起大言语模子,但这并不代表其性能或者运转着力都能称心开发者们的需求。
在最近的MLPerf推理测试当中,AMD暗示其MI300X加快器在性能上也曾与英伟达家备受真贵的H100简直越过。从表面上讲,MI300X加快器领有更高的内存带宽和更精深的浮点性能,领有这些上风完全在料到之中。但这毕竟是AMD的初次公开比较,背后有着极其要紧的现实真理。
而且自此之后,咱们又迎来了ROCm的一系列更新,旨在擢升各样主流模子运转器(包括vLLM和S-Lang)的性能发达。信赖在这些更新的加抓之下,MI300X将迸发出更强劲的性能发达。
比较之下,Gaudi 3尚未庄重在MLPerf考研或者推理测试中亮相。耐久以来,英特尔大致拿来与英伟达竞争的就只须Gaudi 2加快器。
是以也不错这样回顾:尽管或然像许多一又友思象中那般坚不能摧白丝 足交,但仍比英特尔或者AMD所但愿的更深。
发布于:北京市