Seperti TensorFlow, adakah monopoli CUDA NVIDIA akan dipecahkan?

​Dalam sepuluh tahun yang lalu, landskap pembangunan perisian pembelajaran mesin telah mengalami perubahan ketara. Banyak rangka kerja telah muncul, tetapi kebanyakannya sangat bergantung pada CUDA NVIDIA dan mendapatkan prestasi terbaik pada GPU NVIDIA. Walau bagaimanapun, dengan kedatangan PyTorch 2.0 dan OpenAI Triton, penguasaan Nvidia dalam bidang ini semakin dipecahkan.

Google mempunyai kelebihan hebat dalam seni bina model pembelajaran mesin, latihan dan pengoptimuman model pada zaman awal, tetapi kini sukar untuk menggunakan kelebihan ini sepenuhnya. Dari segi perkakasan, sukar bagi syarikat perkakasan AI lain untuk melemahkan penguasaan Nvidia. Sehingga PyTorch 2.0 dan OpenAI Triton muncul, timbunan perisian lalai untuk model pembelajaran mesin tidak lagi menjadi CUDA sumber tertutup Nvidia.

TensorFlow vs. PyTorch

Persaingan serupa berlaku dalam rangka kerja pembelajaran mesin. Beberapa tahun yang lalu, ekosistem rangka kerja agak berpecah-belah, tetapi TensorFlow adalah pendahulu. Di permukaan, Google nampaknya tegas dalam industri rangka kerja pembelajaran mesin Mereka mereka bentuk TPU pemecut khusus aplikasi AI dengan TensorFlow, sekali gus memperoleh kelebihan penggerak pertama.

Walau bagaimanapun, kini nampaknya PyTorch menang dan Google gagal memanfaatkannya yang pertama- kelebihan penggerak Terjemahkan kepada kedudukan dominan dalam industri ML yang sedang berkembang pesat. Google nampaknya agak terpencil dalam komuniti pembelajaran mesin hari ini, kerana ia tidak menggunakan PyTorch dan GPU, sebaliknya menggunakan tindanan perisian dan perkakasannya sendiri. Malah, Google telah membangunkan rangka kerja pembelajaran mesin kedua - JAX, yang bersaing secara langsung dengan TensorFlow Ini adalah "tingkah laku Google".

Sesetengah orang percaya bahawa disebabkan oleh peningkatan model bahasa yang besar, terutamanya model bahasa besar OpenAI dan pelbagai model bahasa yang dibina menggunakan OpenAI API, kemajuan Google dalam carian dan pemprosesan bahasa semula jadi Dominasi adalah semakin berkurangan. Mungkin pandangan ini terlalu pesimis, lagipun, infrastruktur kebanyakan model semasa masih merupakan pengubah yang dibangunkan oleh Google.

Jadi, mengapakah PyTorch pemenang besar? Sebab utama ialah PyTorch mempunyai fleksibiliti dan kebolehgunaan yang lebih tinggi berbanding TensorFlow. Perbezaan utama antara PyTorch dan TensorFlow ialah penggunaan mod Eager dan bukannya mod Graf.

Mod Eager boleh dikatakan sebagai kaedah pelaksanaan skrip standard, tidak berbeza dengan kod Python biasa. Ini menjadikan penyahpepijatan dan pemahaman kod lebih mudah kerana pengguna boleh melihat hasil operasi perantaraan dan cara model berjalan.

Sebaliknya, mod Graf dibahagikan kepada dua fasa. Peringkat pertama mewakili graf pengiraan yang mana operasi akan dilakukan, di mana nod mewakili operasi atau pembolehubah, dan tepi antara nod mewakili aliran data di antara mereka. Peringkat kedua ialah pelaksanaan tertunda bagi versi graf pengiraan yang dioptimumkan.

Pendekatan dua peringkat ini menjadikan pemahaman dan penyahpepijatan kod lebih mencabar kerana pengguna tidak dapat melihat perkara yang berlaku sehingga pelaksanaan graf tamat. Ini serupa dengan bahasa "ditafsirkan" berbanding "disusun" seperti Python dan C++, menyahpepijat Python lebih mudah kerana ia adalah bahasa yang ditafsirkan.

Walaupun TensorFlow kini turut menggunakan mod Eager secara lalai, komuniti penyelidikan dan kebanyakan syarikat teknologi besar memilih untuk menggunakan PyTorch.

Komponen latihan pembelajaran mesin

Jika latihan model pembelajaran mesin dipermudahkan kepada bentuk yang paling mudah, faktor utama yang mempengaruhi latihan model pembelajaran mesin ialah : Dua mata:

• Pengiraan (FLOPS): jalankan pendaraban matriks padat dalam setiap lapisan
• lebar jalur memori.

Sebelum ini, faktor utama yang mempengaruhi masa latihan pembelajaran mesin ialah masa pengiraan, menunggu sistem melakukan pendaraban matriks. Memandangkan GPU Nvidia terus berkembang, ini tidak lagi menjadi isu utama.

Nvidia telah menggunakan Undang-undang Moore untuk menambah baik FLOPS mengikut urutan magnitud, tetapi perubahan seni bina utama ialah teras tensor dan format titik terapung ketepatan lebih rendah. Sebagai perbandingan, tidak banyak yang berubah pada bahagian storan.

Pada tahun 2018, model paling canggih ialah BERT, dan NVIDIA V100 ialah GPU paling maju pada masa itu. pendaraban matriks tidak lagi menjadi faktor utama dalam meningkatkan prestasi model. Selepas itu, model meningkat sebanyak 3 hingga 4 susunan magnitud dalam bilangan parameter, manakala GPU terpantas meningkat sebanyak 1 susunan magnitud dalam FLOPS.

Malah pada tahun 2018, beban kerja terikat pengiraan semata-mata menyumbang 99.8% daripada FLOPS tetapi hanya 61% daripada masa jalan. Berbanding dengan pendaraban matriks, normalisasi dan ops mengikut arah hanya menggunakan 1/250 dan 1/700 daripada FLOPS pendaraban matriks, tetapi ia menggunakan hampir 40% daripada masa jalan model.

Dinding Memori

Apabila skala model terus Melambung , model bahasa besar (LLM) memerlukan lebih 100 GB memori hanya untuk berat model. Rangkaian pengesyoran produk yang digunakan oleh Baidu dan Meta memerlukan berpuluh-puluh terabait memori untuk menyimpan jadual benam besar mereka. Kebanyakan masa dalam latihan/inferens model besar tidak digunakan untuk mengira pendaraban matriks, tetapi menunggu data dipindahkan. Jelas sekali, persoalannya ialah mengapa arkitek tidak meletakkan lebih banyak memori lebih dekat dengan pengiraan, dan jawapannya jelas - kos.

Kolam memori kongsi terdekat biasanya SRAM pada cip yang sama. Sesetengah ASIC pembelajaran mesin cuba memanfaatkan kumpulan SRAM yang besar untuk memegang berat model. Tetapi cip berskala wafer kira-kira $5,000,000 Cerebras hanya mempunyai 40GB SRAM. Kapasiti ingatan tidak mencukupi untuk menampung berat model parametrik 100B+.

Nvidia mereka bentuk cip dengan lebih sedikit memori pada cip – A100 mempunyai 40MB dan H100 mempunyai 50MB. SRAM 1GB pada cip 5nm TSMC memerlukan kira-kira 200 milimeter persegi silikon, dan melaksanakan logik/struktur kawalan yang berkaitan akan memerlukan lebih 400 milimeter persegi silikon. Memandangkan kos GPU A100 melebihi $10,000 dan H100 lebih hampir kepada $20,000, pendekatan ini tidak boleh dilaksanakan dari perspektif kewangan. Walaupun mengabaikan margin keuntungan Nvidia kira-kira 75% pada GPU pusat data, memori SRAM masih berharga sekitar $100/GB untuk produk pengeluaran sepenuhnya.

Selain itu, kos memori SRAM pada cip tidak akan berkurangan banyak kerana teknologi proses Undang-undang Moore tradisional mengecut. Memori 1GB yang sama menggunakan teknologi proses 3nm generasi akan datang TSMC, tetapi kosnya lebih tinggi. Walaupun SRAM 3D akan membantu mengurangkan kos SRAM sedikit sebanyak, ini hanya sementara.

Langkah seterusnya dalam hierarki memori ialah DRAM memori luar cip yang digandingkan rapat. DRAM mempunyai susunan magnitud kependaman yang lebih tinggi daripada SRAM (~100ns vs 10ns), tetapi ia juga jauh lebih murah. DRAM telah mengikuti Undang-undang Moore selama beberapa dekad. Apabila Gordon Moore mencipta istilah itu, perniagaan utama Intel ialah DRAM. Ramalan beliau untuk ketumpatan dan kos transistor secara amnya benar untuk DRAM sebelum 2009. Tetapi kos DRAM hampir tidak bertambah baik sejak 2012.

Walau bagaimanapun, permintaan orang ramai untuk ingatan hanya meningkat. DRAM kini menyumbang 50% daripada jumlah kos pelayan, secara beransur-ansur membentuk apa yang dipanggil "dinding memori." Membandingkan GPU P100 NVIDIA 2016 dengan GPU H100 terkini, kami melihat bahawa kapasiti memori meningkat kepada 5 kali (16GB → 80GB) dan prestasi FP16 meningkat kepada 46 kali ganda (21.2 TFLOPS → 989.5 TFLOPS).

Walaupun kapasiti memori merupakan halangan penting, satu lagi halangan - jalur lebar memori juga sangat kritikal. Peningkatan lebar jalur ingatan selalunya diperoleh melalui selari. Walaupun DRAM standard berharga hanya beberapa dolar/GB hari ini, untuk mendapatkan lebar jalur besar yang diperlukan untuk pembelajaran mesin, Nvidia menggunakan memori HBM — peranti yang terdiri daripada lapisan DRAM bertindan 3D yang memerlukan pakej yang lebih mahal. Kos HBM adalah lebih kurang $10-20/GB, termasuk kos pembungkusan dan volum.

Kekangan kos pada lebar jalur dan kapasiti memori amat ketara dalam GPU A100 Nvidia. Tanpa pengoptimuman yang meluas, A100 hanya boleh mempunyai penggunaan FLOPS yang sangat rendah.

Walaupun penyelidik telah melakukan banyak pengoptimuman, kadar penggunaan FLOPS bagi model bahasa besar hanya boleh mencapai kira-kira 60%. Sebahagian besar masa dihabiskan untuk menunggu data daripada pengiraan/ingatan lain, atau pengiraan semula menghasilkan keputusan tepat pada masanya untuk mengurangkan kesesakan memori.

Dari A100 ke H100, FLOPS meningkat kepada lebih daripada 6 kali ganda, tetapi lebar jalur memori hanya meningkat kepada 1.65 kali. Ini telah menyebabkan ramai bimbang bahawa penggunaan H100 akan menjadi rendah. A100 memerlukan banyak helah untuk mengelilingi dinding memori, dan H100 memerlukan lebih banyak helah untuk dicapai.

H100 membawa memori kongsi yang diedarkan dan multicast L2 kepada seni bina Hopper. Ideanya adalah untuk membenarkan data dalam satu SM ditulis terus ke dalam SRAM (memori kongsi/L1 Cache) SM lain. Ini secara berkesan meningkatkan saiz cache dan mengurangkan lebar jalur yang diperlukan untuk DRAM membaca/menulis. Seni bina masa hadapan akan mengurangkan bilangan operasi yang dihantar ke memori untuk meminimumkan kesan dinding memori. Perlu diingat bahawa model yang lebih besar cenderung untuk mencapai penggunaan yang lebih tinggi, kerana FLOPS perlu skala sebagai kiub bilangan parameter, manakala lebar jalur memori dan keperluan kapasiti cenderung untuk skala sebagai kuadratik.

Gabungan Operator

Jika semua masa dihabiskan untuk pemindahan memori (iaitu jalur lebar memori terhad), maka meningkatkan FLOPS GPU tidak akan membantu. Sebaliknya, jika semua masa anda dihabiskan untuk melaksanakan matmul besar, maka menulis semula logik model ke dalam C++ untuk mengurangkan overhed tidak akan membantu.

Sebab mengapa PyTorch boleh mengatasi TensorFlow adalah kerana mod Eager meningkatkan fleksibiliti dan kebolehgunaan, tetapi beralih ke mod Eager bukanlah satu-satunya faedah. Apabila berjalan dalam mod bersemangat, setiap operasi dibaca dari memori, dikira, dan kemudian dihantar ke memori sebelum memproses operasi seterusnya. Tanpa pengoptimuman yang meluas, ini boleh meningkatkan keperluan lebar jalur memori dengan ketara.

Jadi untuk model yang dilaksanakan dalam mod Eager, salah satu kaedah pengoptimuman utama ialah gabungan operator. Operasi gabungan mengira berbilang fungsi dalam satu laluan untuk meminimumkan bacaan/tulisan memori, dan bukannya menulis setiap hasil perantaraan ke ingatan. Gabungan operator menambah baik penjadualan operator, lebar jalur memori dan kos saiz memori.

Pengoptimuman jenis ini biasanya melibatkan penulisan kernel CUDA tersuai, tetapi ini lebih mudah daripada menggunakan skrip Python mudah adalah lebih sukar. Dari masa ke masa, semakin banyak pengendali telah dilaksanakan secara berterusan dalam PyTorch, kebanyakannya hanya menggabungkan berbilang operasi biasa ke dalam fungsi yang lebih kompleks.

Penambahan operator memudahkan untuk mencipta model dalam PyTorch, dan mod Eager berprestasi lebih pantas disebabkan memori kurang membaca/menulis. Kelemahannya ialah PyTorch telah meningkat kepada lebih 2000 pengendali dalam masa beberapa tahun.

Kita boleh katakan bahawa pembangun perisian terlalu malas, tetapi sejujurnya, siapa yang tidak malas. Sebaik sahaja mereka membiasakan diri dengan pengendali baharu dalam PyTorch, mereka terus menggunakannya. Pembangun mungkin tidak menyedari bahawa prestasi semakin meningkat tetapi terus menggunakan pengendali kerana ia menghapuskan keperluan untuk menulis lebih banyak kod.

Selain itu, tidak semua pengendali boleh digabungkan. Memutuskan operasi yang mana untuk digabungkan dan yang mana untuk diperuntukkan kepada sumber pengkomputeran tertentu pada peringkat cip dan kelompok memerlukan banyak masa. Walaupun strategi untuk tempat pengendali disepadukan secara amnya serupa, mereka boleh sangat berbeza disebabkan oleh seni bina yang berbeza.

NVIDIA adalah raja

Pertumbuhan dan status lalai pengendali adalah kelebihan untuk NVIDIA kerana setiap pengendali menyasarkan Seni binanya dioptimumkan untuk kelajuan , tetapi tidak dioptimumkan untuk sebarang perkakasan lain. Jika permulaan perkakasan AI ingin melaksanakan sepenuhnya PyTorch, itu bermakna menyokong senarai 2,000 pengendali yang semakin meningkat dengan prestasi tinggi.

Oleh kerana mengekstrak prestasi maksimum memerlukan begitu banyak kemahiran, melatih model besar dengan penggunaan FLOPS yang tinggi pada GPU memerlukan tahap bakat yang semakin tinggi. Pelaksanaan mod bersungguh-sungguh bagi gabungan operator aditif bermakna perisian, teknik dan model yang dibangunkan sentiasa didorong untuk menampung nisbah pengiraan dan memori yang dimiliki oleh GPU generasi semasa.

Semua orang yang membangunkan cip pembelajaran mesin dikekang oleh dinding memori yang sama. ASIC dihadkan dengan menyokong rangka kerja yang paling biasa digunakan, kaedah pembangunan lalai, kod PyTorch yang dioptimumkan GPU, dan gabungan NVIDIA dan perpustakaan luaran. Dalam kes ini, tidak masuk akal untuk mempunyai seni bina yang mengetepikan pelbagai bagasi bukan pengiraan GPU yang memihak kepada lebih banyak FLOPS dan model pengaturcaraan yang lebih ketat.

Walau bagaimanapun, kemudahan penggunaan diutamakan. Satu-satunya cara untuk memecahkan kitaran ganas ialah menjadikannya semudah dan lancar yang mungkin untuk perisian yang menjalankan model pada GPU Nvidia untuk beralih ke perkakasan lain. Apabila seni bina model menjadi stabil dan abstrak daripada syarikat PyTorch 2.0, OpenAI Triton dan MLOps seperti MosaicML menjadi lalai, seni bina dan ekonomi penyelesaian cip mula menjadi pemacu pembelian terbesar, dan bukannya kemudahan penggunaan yang disediakan oleh jantina perisian canggih Nvidia. .

PyTorch 2.0

Beberapa bulan lalu, Yayasan PyTorch telah ditubuhkan dan dipisahkan daripada Meta. Sebagai tambahan kepada perubahan kepada model pembangunan dan tadbir urus terbuka, 2.0 telah dikeluarkan pada awal beta dan tersedia secara umum pada bulan Mac. PyTorch 2.0 membawa banyak perubahan, tetapi perbezaan utama ialah ia menambahkan penyelesaian kompilasi yang menyokong model pelaksanaan grafik. Peralihan ini akan memudahkan untuk menggunakan pelbagai sumber perkakasan dengan betul.

PyTorch 2.0 meningkatkan prestasi latihan sebanyak 86% pada NVIDIA A100 dan prestasi inferens pada CPU sebanyak 26%. Ini dengan ketara mengurangkan masa pengiraan dan kos yang diperlukan untuk melatih model. Faedah ini diberikan kepada GPU dan pemecut lain daripada AMD, Intel, Tenstorrent, Luminous Computing, Tesla, Google, Amazon, Microsoft, Marvell, Meta, Graphcore, Cerebras, SambaNova dan banyak lagi.

PyTorch 2.0 mempunyai ruang yang lebih besar untuk peningkatan prestasi pada perkakasan yang tidak dioptimumkan pada masa ini. Meta dan syarikat lain membuat sumbangan yang begitu besar kepada PyTorch kerana mereka mahu mencapai penggunaan FLOPS yang lebih tinggi dengan usaha yang kurang pada kluster latihan GPU berbilion dolar mereka. Dengan cara ini mereka juga mempunyai insentif untuk menjadikan susunan perisian mereka lebih mudah alih kepada perkakasan lain, memperkenalkan persaingan ke dalam ruang pembelajaran mesin.

Dengan bantuan API yang lebih baik, PyTorch 2.0 juga boleh menyokong keselarian data, sharding, keselarian saluran paip dan keselarian tensor, membawa kemajuan kepada latihan teragih. Selain itu, ia menyokong bentuk dinamik secara asli merentas timbunan, yang antara banyak contoh lain menjadikannya lebih mudah untuk menyokong panjang jujukan yang berbeza untuk LLM. Gambar di bawah ialah kali pertama pengkompil utama menyokong Bentuk Dinamik daripada latihan hingga inferens:

PrimTorch

Menulis bahagian belakang berprestasi tinggi untuk PyTorch yang menyokong sepenuhnya semua 2000+ pengendali bukanlah perkara remeh untuk setiap ASIC pembelajaran mesin kecuali GPU NVIDIA. PrimTorch mengurangkan bilangan operator kepada kira-kira 250 operator asal sambil mengekalkan kebolehgunaan yang sama untuk pengguna akhir PyTorch. PrimTorch menjadikan pelaksanaan bahagian belakang bukan NVIDIA yang berbeza bagi PyTorch lebih mudah dan lebih mudah diakses. Vendor perkakasan dan sistem tersuai boleh melancarkan tindanan perisian mereka dengan lebih mudah.

TorchDynamo

TorchDynamo memerlukan definisi graf yang boleh dipercayai. Meta dan PyTorch telah cuba membuat anjakan ini selama kira-kira 5 tahun, tetapi setiap penyelesaian yang mereka hasilkan mempunyai kelemahan yang ketara. Akhirnya, mereka menyelesaikan masalah menggunakan TorchDynamo. TorchDynamo akan menelan mana-mana skrip pengguna PyTorch, termasuk skrip yang memanggil perpustakaan pihak ketiga luaran dan menjana graf FX.

Dynamo mengurangkan semua operator kompleks kepada ~250 operator primitif dalam PrimTorch. Sebaik sahaja graf dibentuk, pengendali yang tidak digunakan akan dibuang dan graf menentukan pengendali perantaraan yang perlu disimpan atau ditulis ke ingatan, dan yang mana mungkin digabungkan. Ini sangat mengurangkan overhed dalam model sambil menjadi "lancar" kepada pengguna.

Daripada 7000 model PyTorch yang diuji, TorchDynamo telah digunakan pada lebih daripada 99% model, termasuk model daripada OpenAI, HuggingFace, Meta, NVIDIA, Stability.AI, dsb., tanpa perlu Buat sebarang perubahan pada kod asal. 7000 model yang diuji telah dipilih secara rawak daripada projek paling popular menggunakan PyTorch pada GitHub.

TensorFlow/Jax Google dan talian paip pelaksanaan mod graf lain sering memerlukan pengguna memastikan model mereka sesuai dengan seni bina pengkompil, Supaya gambar dapat ditangkap. Dynamo mengubahnya dengan mendayakan tangkapan graf separa, tangkapan graf dilindungi dan tangkapan semula segera.

Tangkapan graf separa membolehkan model mengandungi binaan yang tidak disokong/bukan python. Apabila graf tidak boleh dijana untuk bahagian model, pemisah graf akan dimasukkan dan pembinaan yang tidak disokong akan dilakukan dalam mod bersemangat antara graf bahagian.

Tangkapan graf yang dilindungi menyemak sama ada graf yang ditangkap itu sah untuk dilaksanakan. "Perlindungan" bermaksud perubahan yang memerlukan penyusunan semula. Ini penting kerana menjalankan kod yang sama beberapa kali tidak akan menyusun semula beberapa kali. Tangkapan semula secara on-the-fly membolehkan graf ditangkap semula jika graf yang ditangkap tidak sah untuk dilaksanakan.

Matlamat PyTorch adalah untuk mencipta bahagian hadapan bersatu dengan UX lancar yang memanfaatkan Dynamo Hasilkan graf. Pengalaman pengguna penyelesaian tidak berubah, tetapi prestasi boleh dipertingkatkan dengan ketara. Tangkap graf boleh dilaksanakan dengan lebih cekap selari pada jumlah sumber pengkomputeran yang besar.

Dynamo dan AOT Autograd kemudian menghantar graf FX yang dioptimumkan kepada TorchInductor peringkat pengkompil asli PyTorch. Syarikat perkakasan juga boleh memasukkan graf ini ke dalam penyusun bahagian belakang mereka sendiri.

TorchInductor

TorchInductor ialah pengkompil pembelajaran mendalam asli Python yang boleh menjana kod pantas untuk berbilang pemecut dan hujung belakang. Induktor akan mengambil graf FX dengan kira-kira 250 operator dan mengurangkannya kepada kira-kira 50 operator. Seterusnya, Induktor memasuki fasa penjadualan, di mana operator digabungkan dan perancangan memori ditentukan.

Induktor kemudian memasuki "Wrapper Codegen", yang menjana kod yang dijalankan pada CPU, GPU atau pemecut AI yang lain. Pembalut Codegen menggantikan bahagian penterjemah susunan pengkompil dan boleh memanggil kernel dan memperuntukkan memori. Bahagian penjanaan kod bahagian belakang memanfaatkan OpenAI Triton untuk GPU dan mengeluarkan kod PTX. Untuk CPU, pengkompil Intel menjana C++ (juga berfungsi pada CPU bukan Intel).

Mereka akan menyokong lebih banyak perkakasan pada masa hadapan, tetapi yang penting ialah Induktor mengurangkan jumlah kerja yang perlu dilakukan oleh pasukan penyusun semasa membuat penyusun untuk pemecut perkakasan AI mereka. Di samping itu, kod ini lebih dioptimumkan untuk prestasi, dan lebar jalur memori serta keperluan kapasiti dikurangkan dengan ketara.

Penyelidik bukan sahaja memerlukan penyusun yang hanya menyokong GPU, tetapi mahu menyokong pelbagai bahagian belakang perkakasan.

OpenAI Triton

OpenAI Triton ialah kehadiran yang mengganggu untuk perisian pembelajaran mesin sumber tertutup Nvidia. Triton mengambil data terus daripada Python atau melalui timbunan PyTorch Inductor, yang terakhir adalah penggunaan yang paling biasa. Triton bertanggungjawab untuk menukar input kepada perwakilan perantaraan LLVM dan kod penjanaan. GPU NVIDIA akan menjana kod PTX secara langsung, melangkau perpustakaan CUDA sumber tertutup NVIDIA (seperti cuBLAS) dan sebaliknya menggunakan perpustakaan sumber terbuka (seperti cutlass).

CUDA popular dalam dunia pengkomputeran dipercepatkan, tetapi kurang dikenali dalam kalangan penyelidik pembelajaran mesin dan saintis data. Menggunakan CUDA boleh memberikan cabaran dan memerlukan pemahaman mendalam tentang seni bina perkakasan, yang boleh melambatkan proses pembangunan. Akibatnya, pakar pembelajaran mesin mungkin bergantung pada pakar CUDA untuk mengubah suai, mengoptimumkan dan menyelaraskan kod mereka.

Triton menebus kelemahan ini, membolehkan bahasa peringkat tinggi ​​mencapai prestasi yang setanding dengan bahasa peringkat rendah. Inti Triton itu sendiri sangat jelas kepada penyelidik ML biasa, yang sangat penting untuk kebolehgunaan. Triton mengautomasikan penyatuan memori, pengurusan memori dikongsi dan penjadualan dalam SM. Triton tidak begitu berguna untuk pendaraban matriks mengikut unsur, tetapi pendaraban matriks sudah boleh dilakukan dengan sangat cekap. Triton berguna untuk operasi titik demi titik yang mahal dan mengurangkan overhed operasi yang kompleks.

OpenAI Triton pada masa ini hanya menyokong GPU NVIDIA secara rasmi, tetapi ini akan berubah dalam masa terdekat untuk menyokong berbilang vendor perkakasan lain. Pemecut perkakasan lain boleh disepadukan terus ke dalam IR LLVM Triton, yang sangat mengurangkan masa untuk membina tindanan pengkompil AI untuk perkakasan baharu.

Sistem perisian NVIDIA yang besar tidak mempunyai pandangan jauh untuk memanfaatkan kelebihan besarnya dalam perkakasan dan perisian ML, dan dengan itu gagal menjadi pengkompil lalai untuk pembelajaran mesin. Mereka kurang fokus pada kebolehgunaan yang membenarkan OpenAI dan Meta mencipta tindanan perisian yang mudah alih kepada perkakasan lain.

Pautan asal: https://www.semianalysis.com/p/nvidiaopenaitritonpytorch​

Atas ialah kandungan terperinci Seperti TensorFlow, adakah monopoli CUDA NVIDIA akan dipecahkan?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!