Hanya 1% daripada parameter Pembenaman diperlukan, kos perkakasan dikurangkan sebanyak sepuluh kali ganda dan penyelesaian sumber terbuka menggunakan GPU tunggal untuk melatih model besar yang disyorkan

Model Pengesyoran Dalam (DLRM) telah menjadi senario teknikal yang paling penting untuk penerapan pembelajaran mendalam dalam syarikat Internet, seperti pengesyoran video, carian beli-belah, tolakan pengiklanan dan perkhidmatan pengewangan trafik lain, yang telah meningkatkan pengguna dengan sangat baik. pengalaman dan nilai komersial perniagaan. Walau bagaimanapun, data pengguna dan perniagaan yang besar, keperluan kemas kini berulang yang kerap dan kos latihan yang tinggi semuanya menimbulkan cabaran yang teruk kepada latihan DLRM.

Dalam DLRM, anda perlu melakukan carian dalam jadual terbenam (EmbeddingBags) dahulu, dan kemudian lengkapkan pengiraan hiliran. Jadual terbenam selalunya menyumbang lebih daripada 99% keperluan memori dalam DLRM, tetapi hanya 1% daripada pengiraan. Dengan bantuan memori berkelajuan tinggi pada cip GPU (Memori Lebar Jalur Tinggi) dan kuasa pengkomputeran yang berkuasa, GPU telah menjadi perkakasan arus perdana untuk latihan DLRM. Walau bagaimanapun, dengan penyelidikan yang mendalam tentang sistem pengesyoran, saiz jadual benam yang semakin meningkat dan memori GPU yang terhad telah mencipta percanggahan yang ketara. Cara menggunakan GPU untuk melatih model DLRM yang sangat besar dengan cekap sambil menerobos batasan dinding memori GPU telah menjadi isu utama dalam medan DLRM yang perlu diselesaikan.

Colossal-AI sebelum ini telah berjaya menggunakan strategi heterogen untuk meningkatkan kapasiti parameter model NLP yang dilatih pada perkakasan yang sama sebanyak ratusan kali, dan telah baru-baru ini berjaya mengembangkannya Dalam sistem pengesyoran, jadual terbenam disimpan secara dinamik dalam memori CPU dan GPU melalui kaedah cache perisian (Cache). Berdasarkan reka bentuk Cache perisian, Colossal-AI juga menambah saluran paip prafetching untuk mengurangkan pengambilan Cache perisian dan pergerakan data overhed dengan memerhati data latihan yang akan dimasukkan pada masa hadapan. Pada masa yang sama, ia melatih keseluruhan model DLRM pada GPU dengan cara kemas kini segerak, yang digabungkan dengan kaedah latihan selari hibrid yang digunakan secara meluas, boleh diperluaskan kepada berbilang GPU. Percubaan menunjukkan bahawa Colossal-AI hanya perlu mengekalkan 1% daripada parameter pembenaman dalam GPU dan masih boleh mengekalkan kelajuan latihan hujung ke hujung yang sangat baik. Berbanding dengan penyelesaian PyTorch yang lain, keperluan memori grafik dikurangkan mengikut susunan magnitud, dan satu kad grafik boleh melatih model pengesyoran tahap terabait. Kelebihan kos adalah penting Contohnya, hanya 5GB memori video diperlukan untuk melatih DLRM yang menduduki Beg Benam 91GB Kos perkakasan latihan dikurangkan sepuluh kali ganda daripada dua A100 kira-kira 200,000 yuan kepada kad grafik peringkat permulaan seperti itu. sebagai RTX 3050 yang hanya berharga kira-kira 2,000 yuan .

Alamat sumber terbuka: https://github.com/hpcaitech/ColossalAI

Pembenaman Sedia Ada teknologi pengembangan jadual

Pembenaman jadual memetakan ciri integer diskret ke dalam vektor ciri titik terapung berterusan Rajah berikut menunjukkan proses latihan jadual pembenaman dalam DLRM. Mula-mula, cari baris yang sepadan dengan Jadual Benam untuk setiap ciri dalam jadual pembenaman, dan kemudian gunakan operasi pengurangan, seperti operasi maks, min dan jumlah, untuk mengubahnya menjadi vektor ciri dan menghantarnya ke rangkaian saraf padat berikutnya. . Ia boleh dilihat bahawa proses latihan jadual terbenam DLRM adalah terutamanya operasi capaian memori yang tidak teratur, jadi ia sangat terhad oleh kelajuan capaian memori perkakasan.

Jadual terbenam DLRM gred industri mungkin mencapai ratusan GB atau bahkan tahap TB, jauh melebihi kapasiti memori video maksimum berpuluh GB daripada satu GPU. Terdapat banyak cara untuk menembusi dinding memori GPU tunggal untuk meningkatkan saiz jadual terbenam DLRM. Mengambil gambar rajah hierarki memori gugusan GPU yang ditunjukkan dalam rajah di bawah sebagai contoh, mari kita menganalisis kelebihan dan kekurangan beberapa penyelesaian biasa.

Selarian model GPU: Pisahkan jadual benam dan edarkannya dalam memori berbilang GPU Semasa latihan, hasil perantaraan disegerakkan melalui rangkaian sambung antara GPU . Kelemahan kaedah ini ialah beban pembahagian jadual tertanam tidak seragam, dan masalah kebolehskalaan sukar diselesaikan. Kedua, kos perkakasan awal untuk menambah GPU adalah tinggi, dan kuasa pengkomputeran GPU tidak digunakan sepenuhnya semasa latihan DLRM, tetapi hanya kelebihan lebar jalur HBM yang digunakan, menyebabkan penggunaan GPU yang rendah.

Latihan bahagian CPU: Pahasi jadual benam kepada dua bahagian, satu bahagian dilatih pada GPU dan bahagian lain dilatih pada CPU. Dengan mengambil kesempatan daripada kesan ekor panjang pengedaran data, kami boleh menjadikan perkadaran pengiraan CPU sekecil mungkin dan perkadaran pengiraan GPU sebesar mungkin. Walau bagaimanapun, apabila saiz kelompok meningkat, adalah sukar untuk semua data kumpulan mini untuk memukul CPU atau GPU Jika data mengenai CPU atau GPU pada masa yang sama, kaedah ini sukar dikendalikan. Di samping itu, memandangkan lebar jalur DDR dan HBM adalah satu magnitud data, walaupun 10% daripada data input dilatih pada CPU, keseluruhan sistem akan diperlahankan sekurang-kurangnya separuh. Di samping itu, CPU dan GPU perlu menghantar hasil perantaraan, yang juga mempunyai overhed komunikasi yang besar dan seterusnya memperlahankan kelajuan latihan. Oleh itu, penyelidik telah mereka kaedah seperti kemas kini tak segerak untuk mengelakkan kecacatan prestasi ini Walau bagaimanapun, kaedah tak segerak boleh menyebabkan ketidakpastian dalam keputusan latihan dan bukan pilihan pertama jurutera algoritma dalam amalan.

Cache Perisian: Pastikan semua latihan dilakukan pada GPU, dan jadual benam disimpan dalam ruang heterogen yang terdiri daripada CPU dan GPU kaedah cache perisian, Tukar bahagian yang diperlukan ke dalam GPU. Kaedah ini boleh mengembangkan sumber storan dengan murah untuk memenuhi keperluan jadual terbenam yang semakin meningkat. Lebih-lebih lagi, berbanding menggunakan CPU untuk pengiraan, keseluruhan proses latihan dengan cara ini selesai sepenuhnya pada GPU, dengan memanfaatkan sepenuhnya kelebihan lebar jalur HBM. Walau bagaimanapun, pertanyaan Cache dan pergerakan data akan menyebabkan kehilangan prestasi tambahan.

Sudah ada beberapa penyelesaian Cache perisian yang sangat baik untuk membenamkan jadual, tetapi mereka sering menggunakan pelaksanaan EmbeddingBags Kernel tersuai, seperti fbgemm, atau menggunakan rangka kerja pembelajaran mendalam pihak ketiga. Colossal-AI tidak membuat sebarang perubahan peringkat Kernel berdasarkan PyTorch asli, dan menyediakan set pelaksanaan Cache EmbeddingBags yang luar biasa. Ia juga mengoptimumkan latihan DLRM proses dan mencadangkan prefetching untuk mengurangkan lagi overhed Cache.

Hierarki Memori

Colossal-AI Cache perisian jadual terbenam

Colossal-AI melaksanakan Cache perisian dan merangkumnya ke dalam nn.Module untuk digunakan oleh pengguna dalam model mereka sendiri. Jadual benam DLRM biasanya EmbeddingBags terdiri daripada berbilang Embeddings dan berada dalam memori CPU. Bahagian ruang memori ini dinamakan Berat CPU. Sebahagian kecil data EmbeddingBags disimpan dalam memori GPU, yang termasuk data yang akan digunakan untuk latihan. Bahagian ruang memori ini dinamakan CUDA Cached Weight. Semasa latihan DLRM, anda perlu terlebih dahulu menentukan baris jadual terbenam yang sepadan dengan input data ke dalam kumpulan mini untuk lelaran ini Jika beberapa baris tiada dalam GPU, ia perlu dipindahkan daripada Berat CPU ke CUDA Berat Cache. Jika tidak ada ruang yang mencukupi dalam GPU, ia menggunakan algoritma LFU untuk mengusir data yang paling kurang digunakan berdasarkan kekerapan sejarah mengakses cache.

Untuk mencapai pengambilan Cache, beberapa struktur data tambahan diperlukan untuk membantu: cached_idx_map ialah tatasusunan satu dimensi yang menyimpan surat-menyurat antara nombor baris dalam Berat CPU dan CUDA Berat Cached, dan baris yang sepadan dalam Maklumat tentang kekerapan GPU diakses. Nisbah saiz Berat Cached CUDA kepada saiz Berat CPU dinamakan cache_ratio, dan lalai ialah 1.0%.

Cache dijalankan sebelum setiap lelaran ke hadapan untuk melaraskan data dalam CUDA Weight, khususnya dalam tiga langkah.

Langkah1: Indeks CPU: Dapatkan semula nombor talian yang perlu dicache dalam Berat CPU

Ia perlu input mini Ambil persimpangan input_ids dan cached_idx_map -batch untuk mencari nombor baris dalam Berat CPU yang perlu dialihkan dari CPU ke GPU.

Langkah2: Indeks GPU: Cari baris yang boleh dikeluarkan dalam CUDA Weight mengikut kekerapan penggunaan

Ini memerlukan kami Mengikut kekerapan, dari rendah ke tinggi, lakukan operasi top-k (ambil nombor k maksimum) pada bahagian selepas set perbezaan cache_idx_map dan input_id.

Langkah3: Pemindahan data:

Alihkan baris yang sepadan dalam CUDA Cached Weight ke CPU Weight, dan kemudian Alihkan baris yang sepadan dalam Berat CPU kepada Berat CUDA.

Modul penghantaran data bertanggungjawab untuk penghantaran dua arah data antara CUDA Cached Weight dan CPU Weight. Berbeza daripada penghantaran baris demi talian yang tidak cekap, ia menggunakan cache dahulu dan kemudian penghantaran terpusat untuk meningkatkan penggunaan lebar jalur PCI-e. Baris terbenam yang bertaburan dalam memori dikumpulkan ke dalam blok data bersebelahan dalam memori tempatan peranti sumber, dan blok itu kemudiannya dipindahkan antara CPU dan GPU dan bertaburan ke lokasi yang sepadan dalam memori sasaran. Mengalihkan data dalam blok boleh meningkatkan penggunaan lebar jalur PCI-e, dan operasi cantum dan serakan hanya melibatkan akses memori pada cip untuk CPU dan GPU, jadi overhed tidak terlalu besar.

Colossal-AI menggunakan penimbal terhad saiz untuk memindahkan data antara CPU dan GPU. Dalam kes yang paling teruk, semua id input terlepas cache, dan sejumlah besar elemen perlu dipindahkan. Untuk mengelakkan penimbal daripada mengambil terlalu banyak memori, saiz penimbal adalah terhad. Jika data yang dipindahkan lebih besar daripada penimbal, pemindahan akan diselesaikan dalam beberapa kali.

Aliran Kerja Beg Benam Cache

Analisis Prestasi Cache Perisian

Kendalian Cache Step1 dan Step2 di atas adalah kedua-duanya intensif akses memori. Oleh itu, untuk memanfaatkan lebar jalur GPU HBM, ia dijalankan pada GPU dan dilaksanakan menggunakan API yang dirangkumkan oleh rangka kerja pembelajaran mendalam. Walau bagaimanapun, overhed operasi Cache amat ketara berbanding dengan operasi latihan pada GPU untuk membenamkan jadual.

Sebagai contoh, dalam tugas latihan yang berjumlah 199 saat, overhed operasi Cache ialah 99 saat, menyumbang hampir 50% daripada jumlah masa pengkomputeran . Selepas analisis, overhed utama Cache disebabkan terutamanya oleh Step1 dan Step2. Kedudukan asas dalam rajah di bawah menunjukkan pecahan masa overhed Cache pada masa ini Tahap merah dan jingga Cache langkah 1 dan 2 menyumbang 70% daripada jumlah overhed Cache.

Pecahan masa operasi Cache

Sebab bagi masalah di atas ialah strategi Cache tradisional agak "rabun" dan hanya boleh melaraskan Cache mengikut situasi kumpulan mini semasa, jadi kebanyakan masa terbuang untuk operasi pertanyaan.

Cache Pipeline Prefetch

Untuk mengurangkan overhed Cache, Colossal-AI telah mereka satu set “Foresight” Mekanisme Cache . Daripada hanya melaksanakan operasi cache pada kumpulan mini pertama, Colossal-AI mendahului beberapa kelompok mini yang akan digunakan kemudian dan melaksanakan operasi pertanyaan cache dengan cara yang bersatu.

Seperti yang ditunjukkan dalam rajah di bawah, Colossal-AI menggunakan prefetching untuk menggabungkan berbilang data kumpulan mini untuk operasi cache bersatu, dan juga menggunakan pendekatan saluran paip untuk menindih overhed bacaan data dan pengiraan. Dalam contoh, nombor kumpulan mini prefetch ialah 2. Sebelum memulakan latihan, data kumpulan mini 0,1 dibaca dari cakera ke memori GPU, kemudian operasi Cache dimulakan, dan kemudian perambatan ke hadapan dan ke belakang serta kemas kini parameter bagi dua kelompok mini dilakukan. Pada masa yang sama, bacaan data awal untuk kumpulan mini 2 dan 3 boleh dilakukan, dan overhed ini boleh bertindih dengan pengiraan.

Berbanding dengan kaedah pelaksanaan Cache garis dasar, angka [Pecahan masa operasi Cache] membandingkan masa cache prefetch 8 mini-batch dan baseline rosak. Jumlah masa latihan menurun daripada 201 saat kepada 120 saat, dan bahagian masa operasi fasa Cache yang ditunjukkan dalam rajah juga menurun dengan ketara. Dapat dilihat bahawa berbanding dengan setiap kumpulan mini yang menjalankan operasi cache secara bebas, masa setiap bahagian dikurangkan, terutamanya dua langkah pertama operasi cache.

Ringkasnya, prefetching saluran paip Cache membawa dua faedah.

a. Cairkan indeks Cache di atas kepala

Faedah yang paling jelas daripada pengambilan awal adalah untuk mengurangkan overhed Langkah1 dan Step2 , menjadikan operasi dua langkah ini menyumbang kurang daripada 5% daripada jumlah proses latihan. Seperti yang ditunjukkan dalam [Pecahan Masa Operasi Cache], dengan mengambil awal 8 data kelompok mini, overhed pertanyaan Cache dikurangkan dengan ketara berbanding garis dasar tanpa pra-pengambilan.

b. Meningkatkan jalur lebar pergerakan data CPU-GPU

Dengan menumpukan lebih banyak data, butiran penghantaran data dipertingkatkan untuk menggunakan sepenuhnya CPU- Jalur lebar penghantaran GPU. Untuk contoh di atas, lebar jalur CUDA->CPU ditingkatkan daripada 860MB/s kepada 1477 MB/s, dan lebar jalur CPU->CUDA ditingkatkan daripada 1257 MB/s kepada 2415 MB/s, yang hampir menggandakan keuntungan prestasi.

Mudah digunakan

Penggunaan adalah konsisten dengan Pytorch EmbeddingBag Apabila membina model pengesyoran, hanya baris kod berikut diperlukan untuk pemulaan, yang boleh meningkat dengan ketara kapasiti jadual benam Mencapai latihan model pengesyoran tahap terabait pada kos rendah.

Bashfrom colossalai.nn.parallel.layers.cache_embedding import CachedEmbeddingBag
emb_module = CachedEmbeddingBag(num_embeddings=num_embeddings,embedding_dim=embedding_dim,mode="sum"include_last_offset=True,sparse=True,_weight=torch.randn(num_embeddings, embedding_dim),warmup_ratio=0.7,cache_ratio = 0.01,)

Ujian prestasi

Pada platform perkakasan NVIDIA A100 GPU (80GB) dan AMD EPYC 7543 32-Core Processor (512GB), Colossal-AI menggunakan model DLRM Meta sebagai sasaran ujian, dan menggunakan set data ultra-besar Cretio 1TB dan dlrm_datasets Meta untuk menjana set data sebagai model ujian. Dalam percubaan, kelajuan latihan PyTorch untuk menyimpan semua jadual benam pada GPU digunakan sebagai garis dasar.

Cretio 1TB

Jadual terbenam Cretio 1TB mempunyai sejumlah 177944275 baris, set pembenaman malap=128 dan memori jadual terbenamnya Keperluan 91.10 GB. Malah NVIDIA A100 80GB paling canggih tidak dapat memenuhi keperluan memori untuk menyimpan semua EmbeddingBeg dalam memori GPU tunggal.

Walau bagaimanapun, menggunakan Colossal-AI, latihan masih diselesaikan pada satu GPU Apabila nisbah cache=0.05, penggunaan memori hanya 5.01 GB, yang dikurangkan secara langsung sebanyak kira-kira 18 kali. , dan boleh dikembangkan lagi kepada GPU tunggal Melaksanakan latihan model sistem pengesyoran tahap terabait pada GPU Zhang. Dari segi kelajuan latihan, seperti yang ditunjukkan dalam rajah di bawah, ia menunjukkan kelewatan latihan 100M sampel di bawah saiz kelompok yang berbeza. Prefetch1 hijau ialah kelewatan tanpa prefetch, dan Prefetch8 biru ialah kelewatan menggunakan prefetch (prefetch mini-batch=8 Dapat dilihat bahawa pengoptimuman saluran paip prefetch memainkan peranan penting dalam meningkatkan prestasi keseluruhan). Bahagian gelap setiap lajur dalam rajah ialah overhed Cache Selepas menggunakan prefetching, overhed Cache dikawal dalam 15% daripada jumlah masa latihan.

Skalabiliti berbilang GPU

Gunakan 8192 sebagai saiz kelompok global , Gunakan sharding mengikut jadual sebagai EmbeddingBags pada 8 kad GPU untuk melatih DLRM secara selari dan melatih sampel 100M. Pada masa ini, tetapkan saiz Prefetch kepada 4, ColossalAI-mem-cr0.05 ialah nisbah cache=0.05 dan ColossalAI-mem-cr0.5=0.5. Rajah di bawah menunjukkan kependaman latihan untuk senario GPU yang berbeza. Kecuali PyTorch OOM tidak boleh dilatih apabila menggunakan 1 GPU, masa latihan PyTorch dan Colossal-AI adalah serupa dalam kes lain. Dapat diperhatikan bahawa menggunakan 4 dan 8 GPU tidak membawa peningkatan prestasi yang ketara Ini kerana, 1. Menyegerakkan keputusan memerlukan overhed komunikasi yang besar. 2. Sharding mengikut jadual akan menyebabkan ketidakseimbangan beban sharding. Ia juga menunjukkan bahawa menggunakan berbilang GPU untuk mengembangkan kebolehskalaan latihan jadual pembenaman adalah tidak begitu baik.

Gambar di bawah menunjukkan penggunaan memori video berbeza pada kad yang berbeza Nilai memori video maksimum ditunjukkan di sini. Apabila hanya satu GPU digunakan, hanya kaedah Cache perisian Colossal-AI boleh dilatih, dan memori yang diduduki oleh berbilang kad secara selari juga berkurangan dengan ketara beberapa kali.

Dataset sintetik dlrm_datasets Meta Research meniru gelagat akses latihan jadual terbenam dalam industri, jadi ia sering digunakan sebagai sistem pengesyoran dalam penyelidikan Rujukan ujian untuk reka bentuk perisian dan perkakasan yang berkaitan. Pilih 500 juta baris item jadual terbenam sebagai sub-dataset dan bina dua EmbeddingBeg 256GB dan 128GB untuk ujian.

PyTorch tidak boleh dilatih pada satu kad A100 kerana memori video tidak mencukupi. Sebaliknya, cache perisian Colossal-AI akan mengurangkan keperluan memori GPU dengan ketara, cukup untuk melatih jadual pembenaman sebesar 256GB, dan boleh dikembangkan lagi ke tahap TB. Selain itu, prafetch talian paip juga boleh menunjukkan kesan pecutan Apabila bilangan prefetch ialah 32, jumlah masa dikurangkan sebanyak 60% berbanding tanpa prefetch, dan permintaan untuk storan GPU tidak meningkat.

Satu Perkara Lagi

Colossal, sistem pembelajaran mendalam umum untuk era model besar- AI menggunakan beberapa teknologi terkemuka yang dibangunkan sendiri seperti selari automatik berbilang dimensi yang cekap, pengurusan memori heterogen, perpustakaan pengoptimuman berskala besar, penjadualan tugas adaptif, dll. untuk mencapai penggunaan AI yang cekap dan pantas latihan model besar dan penaakulan, dan mengurangkan kos aplikasi model besar AI.

Penyelesaian berkaitan AI kolosal telah berjaya dilaksanakan oleh pengeluar terkenal dalam pemanduan autonomi, pengkomputeran awan, runcit, perubatan, cip dan industri lain, dan telah dipuji secara meluas.

Colossal-AI memfokuskan pada pembinaan komuniti sumber terbuka, menyediakan tutorial bahasa Cina, membuka komuniti dan forum pengguna, menjalankan komunikasi yang cekap dan kemas kini berulang untuk maklum balas pengguna, dan terus menambah teknologi canggih seperti sebagai aplikasi PaLM, AlphaFold dan OPT.

Sejak sumber terbuka semula jadinya, Colossal-AI telah menduduki tempat pertama di dunia pada senarai hangat GitHub dan Papers With Code berkali-kali, dan telah popular di kalangan banyak projek sumber terbuka bintang dengan berpuluh ribu bintang Beri perhatian di dalam dan di luar!

Alamat sumber terbuka projek: https://github.com/hpcaitech/ColossalAI

Atas ialah kandungan terperinci Hanya 1% daripada parameter Pembenaman diperlukan, kos perkakasan dikurangkan sebanyak sepuluh kali ganda dan penyelesaian sumber terbuka menggunakan GPU tunggal untuk melatih model besar yang disyorkan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!