Daripada logam kosong kepada model besar dengan 70 bilion parameter, berikut ialah tutorial dan skrip sedia untuk digunakan

Kami tahu bahawa LLM dilatih pada kelompok komputer berskala besar menggunakan data besar-besaran Tapak ini telah memperkenalkan banyak kaedah dan teknologi yang digunakan untuk membantu dan menambah baik proses latihan LLM. Hari ini, perkara yang ingin kami kongsikan ialah artikel yang mendalami teknologi asas dan memperkenalkan cara menukar sekumpulan "logam kosong" tanpa sistem pengendalian pun menjadi gugusan komputer untuk latihan LLM. Artikel ini datang daripada Imbue, sebuah syarikat permulaan AI yang bekerja untuk mencapai kecerdasan am dengan memahami cara mesin berfikir. Sudah tentu, mengubah sekumpulan "logam kosong" tanpa sistem pengendalian menjadi kelompok komputer untuk latihan LLM bukanlah proses yang mudah, penuh dengan penerokaan dan percubaan dan kesilapan, tetapi Imbue akhirnya berjaya melatih LLM dengan 70 bilion parameter Dan terkumpul banyak pengalaman berguna dalam proses tersebut. Artikel ini akan memberikan pandangan yang mendalam tentang proses pasukan membina infrastruktur latihan LLM mereka sendiri, dan berkongsi banyak alat dan skrip yang mereka tulis untuk memudahkan pemantauan, pemeriksaan dan penyahpepijatan. Jika anda berminat untuk membina infrastruktur latihan LLM anda sendiri atau ingin tahu tentang cara LLM dibuat, maka artikel ini patut dibaca dan dikumpulkan. Berikut ialah artikel asal daripada pasukan Imbue. Pengenalan Pasukan kecil penyelidik dan jurutera kami menghabiskan beberapa bulan melatih model parameter 70 bilion dari awal pada infrastruktur kami sendiri, dan model itu mengatasi prestasi sifar pada tugas berkaitan inferens. Hari ini, kami berkongsi proses menyediakan infrastruktur yang diperlukan: daripada menyusun kluster awal dan memasang sistem pengendalian kepada menyediakan pemulihan automatik apabila ralat ditemui semasa latihan. Kami akan memperincikan cabaran yang dihadapi dan penyelesaian pada setiap langkah. Sebagai tambahan kepada pembelajaran ini, kami juga akan mengeluarkan banyak skrip yang telah kami bangunkan sepanjang perjalanan untuk memudahkan pasukan lain mencipta infrastruktur yang stabil untuk latihan model mereka sendiri. Sepanjang proses itu, pasukan jurutera kami bekerja dengan Voltage Park untuk menyediakan kelompok komputer dan membina asas untuk aplikasi pengeluaran. Keseluruhan proses ini termasuk: 1. Mengkonfigurasi setiap mesin 2. Mengkonfigurasi InfiniBand 3. Memastikan mesin sihat sepenuhnya 4. Mendiagnosis isu latihan biasa 5. Memperbaiki alatan infrastruktur Setiap langkah diterangkan secara terperinci di bawah. Latar Belakang: Cara ia berfungsi Matlamat kami dalam melaksanakan pengiraan adalah untuk memastikan kami boleh mencuba dengan cepat model bahasa yang besar. Untuk melakukan ini, kami memerlukan sejumlah besar GPU berkelajuan tinggi yang boleh berkomunikasi antara satu sama lain pada kelajuan tinggi. Artikel ini akan memfokuskan pada gugusan dengan 4088 H100 GPU tersebar di 511 mesin atau 8 GPU setiap mesin. Sebab terdapat 511 komputer dengan GPU adalah kerana beberapa sambungan perlu dikhaskan untuk nod Pengurus Fabrik Bersepadu, yang berperanan mengurus rangkaian InfiniBand. Pada hos 511 dengan GPU, setiap GPU disambungkan terus ke kad rangkaian ConnectX-7, yang boleh memindahkan data pada 400 Gbps ke mana-mana GPU pada rangkaian InfiniBand. Topologi rangkaian InfiniBand kami adalah "tidak menyekat sepenuhnya", yang secara teorinya membenarkan GPU berkomunikasi antara satu sama lain pada kelajuan maksimum. Untuk melakukan ini, kami menggunakan seni bina rangkaian InfiniBand tiga lapisan: suis InfiniBand tiga lapisan. Dengan sambungan yang betul, tahap daya pengeluaran yang tinggi ini boleh dicapai di seluruh rangkaian. Imej di bawah menunjukkan gambaran keseluruhan rangkaian InfiniBand ini:

Sila ambil perhatian bahawa komunikasi semasa melatih rangkaian berlaku melalui InfiniBand, bukan Ethernet. Walaupun mesin ini juga disambungkan ke Ethernet, peranan rangkaian ini adalah untuk mengangkut data seperti set data dan pusat pemeriksaan. Jika anda menggunakan Ethernet untuk menghantar data, ia akan menjadi lebih perlahan kerana data dipindahkan daripada GPU ke CPU dan kemudian keluar melalui kad Ethernet pada kelajuan 100 Gbps. Walaupun mungkin untuk melatih melalui Ethernet menggunakan teknologi yang dipanggil RDMA over Converged Ethernet (RoCE), yang memerlukan banyak kerja tambahan pada kedua-dua bahagian perkakasan dan perisian dan secara amnya kurang dipercayai daripada InfiniBand. Butiran boleh didapati dalam kertas ini: https://arxiv.org/pdf/2402.15627
Terdapat juga Ethernet sekunder yang digunakan hanya untuk konfigurasi dan pengurusan, membenarkan akses kepada BIOS (Sistem Output Input Asas), bekalan kuasa dan rendah lain mesin peringkat Antara muka kawalan antara muka. Tanpa rangkaian pengurusan ini, kami perlu menyediakan setiap nod secara manual melalui pemacu USB, papan kekunci dan monitor. Untuk situasi dengan ratusan mesin, ini bukan pendekatan yang mampan.
Mencapai latihan berprestasi tinggi pada kluster ini memerlukan setiap komponen (InfiniBand, Ethernet, GPU dan nod itu sendiri) berfungsi dengan hampir sempurna. Jika mana-mana daripada 12,000+ sambungan itu sedikit tidak stabil, ia boleh melambatkan keseluruhan larian latihan.
Kandungan seterusnya artikel ini adalah untuk memperkenalkan cara membuat semuanya berjalan dengan sempurna dan stabil.
Prosedur: Cara menukar logam kosong kepada kluster yang beroperasi sepenuhnya
Mengkonfigurasi setiap mesin
Selepas mewujudkan sambungan Ethernet awal kepada kluster melalui rangkaian pengurusan, akses kepada pengawal pengurusan papan alas (BMC/pengawal pengurusan papan alas) diperolehi sijil. BMC ialah pemproses perkhidmatan khusus yang memantau sistem hos dari jauh dan biasanya disambungkan ke rangkaian berasingan. Ia membolehkan kami mengendalikan mesin seolah-olah kami hadir secara fizikal, dan juga menyediakan API untuk kesihatan perkakasan, tetapan BIOS dan pengurusan kuasa.
Selepas melengkapkan komponen ini, kami boleh menyingsing lengan baju kami dan mula menyediakan kluster.
Langkah 0: Konfigurasi Mesin Dahulu
Kami mulakan dengan memasang Ubuntu 22.04 pada pelayan menggunakan iDRAC (pengawal pengurusan papan dasar Dell), dan kemudian sediakan semua yang lain berdasarkan sistem pengendalian ini. Salah satu keupayaan iDRAC ialah membenarkan pemasangan dan but imej ISO daripada komputer tempatan dan menyediakan konsol maya melalui penyemak imbas. Sebaik-baiknya, ini adalah satu-satunya langkah pemasangan manual dalam proses.
Langkah 1: Pasang sistem pengendalian pada setiap mesin
Selepas mengkonfigurasi mesin pertama, teruskan memasang perisian Metal-as-a-Service (MAAS) Ubuntu untuk membantu mengkonfigurasi pelayan yang tinggal. Gunakan alat but dan automasi iDRAC Preboot Execution Environment Protocol (PXE) untuk mengarahkan setiap mesin untuk but daripada rangkaian dan mengkonfigurasi MAAS untuk bertindak balas kepada permintaan but PXE. Apabila melakukan but rangkaian awal, pelayan memperoleh IP dan kernel awal daripada MAAS melalui Dynamic IP Allocation Protocol DHCP tanpa perlu memasang apa-apa pada pemacu tempatan. Ini adalah persekitaran asas untuk mengautomasikan pemasangan sistem pengendalian boleh ulang. Secara teorinya, kita hanya perlu menunggu but pertama dan semuanya akan diuruskan. Tetapi dalam praktiknya, penyepaduan MAAS dengan BMC tidak boleh dipercayai, jadi kami menggunakan API iDRAC untuk mengumpul alamat MAC setiap mesin (pengecam perkakasan fizikal unik) terlebih dahulu.
Semasa keseluruhan proses latihan ini, MAAS biasanya merupakan komponen susunan vertebra yang lebih dipercayai. Walau bagaimanapun, kami menghadapi beberapa isu pada mulanya yang unik untuk persediaan kami. Sebagai contoh, semasa mengkonfigurasi beberapa mesin pertama, saya tidak dapat memasang apa-apa melalui apt disebabkan isu pengesahan sijil HTTPS kerana jam berada jauh. Berkaitan, kerana pelayan MAAS perlu bertanggungjawab untuk banyak perkara (pelayan DHCP, pelayan DNS untuk menyelesaikan nama hos kepada IP, proksi HTTP antara hos dan pelayan pakej rasmi Ubuntu, pelayan NTP, pengurusan konfigurasi cloud-init , asas pangkalan data kebenaran yang digunakan untuk menyambungkan alamat MAC ke IP kepada nama hos kepada metadata tersuai), jadi sukar untuk kami menyelesaikan masalah ini daripada punca utama. Selain itu, terdapat isu keluk pembelajaran kitaran hayat konfigurasi MAAS, kerana matlamat reka bentuk adalah untuk mengendalikan kerumitan mengurus penempatan medan hijau dan penghijrahan nod secara beransur-ansur dan pelbagai keadaan perantaraan nyahpepijat/tidak sihat.
Langkah 2: Diagnosis Mesin Rosak
Kami mendapati bahawa kira-kira 10% mesin gagal untuk but, kebanyakannya disebabkan oleh masalah fizikal dengan pelayan. Ini adalah senario biasa untuk menyediakan kluster GPU yang besar. Situasi yang kami hadapi termasuk: kabel rangkaian hilang atau salah, isu perkakasan dalam iDRAC, unit bekalan kuasa rosak, pemacu NVME (memori tidak meruap) rosak, pendawaian dalaman hilang, kad rangkaian atau GPU tidak dipaparkan. Kami menyemak isu ini secara automatik, mengembalikan beberapa mesin kepada Dell untuk ujian semula dan menyerahkan pesanan kerja yang sesuai untuk kakitangan pusat data. Satu kelebihan mengkonfigurasi kluster itu sendiri ialah kita boleh menggunakan mesin yang sihat dengan segera sementara menunggu penyelenggaraan pada beberapa mesin.
Langkah 3: Mesin Boleh Diperhatikan Minimum Berdaya maju
Kami meneruskan dengan menyediakan yang berikut pada setiap pelayan:
1.Docker (untuk memudahkan untuk menjalankan perkhidmatan dan kerja latihan)

2. Pemacu GPU pusat data
   3. Alat eksport nod Prometheus (digunakan untuk mengeksport aliran data penunjuk perkakasan/sistem pengendalian)
   4 Alat eksport DCGM (digunakan untuk mengeksport data penunjuk tambahan daripada GPU NVIDIA, seperti status GPU, jam , penggunaan)
3. Semua kumpulan RAIDZ ZFS didorong bukan OS, yang membolehkan mesin terus berfungsi walaupun pemacu gagal, sambil turut menyediakan pemampatan telus secara percuma (terutamanya untuk set data teks biasa dan log berulang) Berguna - menggunakan alat ini biasanya meningkat ruang yang boleh digunakan dengan faktor 10 berbanding tidak menggunakan alat)
   Kami kemudian menjalankan diagnostik GPU asas untuk menentukan sama ada GPU secara amnya berfungsi - jika tidak, ia biasanya berlaku dalam beberapa saat Isu perkakasan berlaku dalam beberapa jam.
   Pada masa ini, kami mengalami kesesakan lebar jalur apabila cuba memasang pakej pada semua 400 nod secara serentak. Ini adalah kali pertama kami menerima makluman kepanasan suhu tinggi pada berbilang komponen yang digunakan dalam pusat data kami. Kumpulan pertama isu pemanasan ini sebahagian besarnya telah diselesaikan melalui kemas kini perisian tegar.
   Langkah 4: Latihan GPU nod tunggal
   Langkah seterusnya ialah memastikan setiap mesin boleh mengendalikan beban kerja GPU sebenar sendiri. Banyak mesin tidak dapat melakukan ini penutup kes dan GPU, kemudian keluarkan GPU, pasang semula GPU, kemudian pasang semula kabel dan tolak pelayan kembali ke dalam rak.
   Menurut log pelayan Ubuntu, banyak kabel antara GPU dan bas PCIe atau kad rangkaian mengeluarkan ralat ini: "lebar terhad: x4 Terdapat juga beberapa gangguan pelbagai yang menjejaskan beberapa hos. Dell membantu kami menyelesaikan beberapa isu dengan peningkatan perisian tegar:
   Pemacu NVMe tidak menunjukkan gangguan, tetapi mengunci seluruh mesin apabila disentuh.
   Pemacu keras muncul dalam susunan rawak di bawah Linux, menyebabkan kekeliruan untuk MAAS dan menyebabkan sistem pengendalian dipasang pada pemacu yang salah.
   Bacaan suhu yang salah, yang menyebabkan kipas berjalan pada kelajuan penuh sepanjang masa. Sebabnya mungkin masalah dengan pemacu NVIDIA, yang diselesaikan dengan menurunkan versi pemacu.
   Penskalaan dinamik CPU di luar kawalan, mengehadkan teras yang berfungsi kepada 2 GHz.
   Komunikasi GPU-GPU langsung (GDR atau GPUDirect RDMA Peer Memory Client) tidak boleh digunakan dengan jayanya.
   Konfigurasikan InfiniBand
   Langkah 0: Pasang UFM
   Salah satu kelebihan InfiniBand ialah reka bentuknya yang berpusat, supaya keseluruhan rangkaian mempunyai satu otak. Oleh itu, kita hanya perlu berurusan dengan satu contoh daripada 320 suis rangkaian dalam keseluruhan rangkaian rangkaian. Tugas pertama kami adalah untuk mengetahui suis yang menyambungkan mesin mana, kemudian mengaitkannya dengan gambar rajah pendawaian dan menamakan semula mereka berdasarkan lokasi fizikal suis.
   Langkah 1: Pendawaian Semula
   Pada mulanya, UFM tidak dapat mengesan 320 suis tersebut, apatah lagi hos yang sepatutnya ada dalam fabrik. Selepas berunding dengan rakan kongsi pusat data kami, kami mengesahkan bahawa suis telah dihidupkan dan berwayar, tetapi masih tidak dapat mengesannya. Selepas memeriksa senarai kabel rangkaian, kami mendapati bahawa reka bentuk peringkat atas struktur rangkaian adalah tidak betul: bukannya disatukan, struktur itu dibahagikan kepada lapan rangkaian terputus tanpa laluan penghalaan biasa. Selepas pendawaian semula, kami menambah langkah semak untuk mengesahkan bahawa semua sambungan fizikal adalah konsisten dengan reka bentuk baharu.
   Langkah 2: Sepuluh ribu penggera suhu (makluman)
   Selepas menyelesaikan masalah pendawaian fizikal, InfiniBand berjaya mewujudkan sambungan dengan semua suis InfiniBand dalam struktur rangkaian. Walau bagaimanapun, hampir setiap port suis mula melaporkan suhu yang berlebihan, kadangkala melebihi 70°C, walaupun ia tidak menghantar data. Kami mendapati bahawa isu ini berpunca daripada ruang terbuka antara suis dalam rak yang sama, yang menyebabkan udara panas mengalir kembali ke hadapan. Rakan kongsi pusat data kami membantu kami mendiagnosis isu dengan cepat dan membangunkan penyelesaian yang sesuai.
   Langkah 3: 1800 Penggera
   Banyak port juga mempunyai kadar ralat yang tinggi, atau turun naik antara keadaan biasa dan rosak, yang dipanggil "flapping." Isu ini hanya timbul apabila port sebenarnya sedang digunakan, jadi ia sukar untuk dikesan lebih awal kerana keseluruhan fabrik kami terdiri daripada 10,000 pautan yang sangat berlebihan. Rakan kongsi pusat data kami membantu membersihkan dan memasang semula port penggera, dan kami melumpuhkan transceiver penggera yang tinggal sementara kami menunggu penggantian.
   Walaupun InfiniBand berdaya tahan terhadap kegagalan perkakasan, apabila kira-kira 10% fabrik mula gagal, ciri seperti penghalaan adaptif tidak berfungsi dengan pasti untuk mengambil kira pautan yang hilang sekali-sekala.
   Sepanjang masa ini, kami berjaya menjalankan latihan berbilang nod menggunakan 100 hingga 200 mesin. Proses kami agak diubah suai: kami kadangkala memutar set rawak nod, memerhati prestasinya, dan kemudian cuba memastikan seberapa banyak daripada nod tersebut berjalan mungkin.Kaedah ini membolehkan kami mencari subset yang boleh dipercayai bagi struktur rangkaian InfiniBand, tetapi ia amat sukar kerana setiap kali kami perlu menukar set nod yang digunakan untuk latihan, dan oleh itu pautan InfiniBand lalai.
   Langkah 4: Pembakaran InfiniBand
   Untuk mendiagnosis isu InfiniBand dengan lebih cekap, kami mereka bentuk beban kerja untuk keseluruhan kluster yang mendorong sebanyak mungkin data melalui setiap port dalam keseluruhan fabrik secara serentak. Ini berbeza daripada menjalankan beban kerja pengurangan semua yang besar merentas keseluruhan kluster, yang memerlukan penggunaan NCCL untuk mengoptimumkan komunikasi antara nod individu dengan menggunakan NVLink untuk komunikasi GPU melalui slot Server PCIe Module (SXM).
   Sebaliknya kami memilih pendekatan brute force dan berjaya dengan mudah. UFM akan mula mengeluarkan makluman apabila volum pemindahan data pada kebanyakan port melebihi 97% daripada kapasiti teori, dan beberapa suis akan turun buat sementara waktu. Setiap pelabuhan yang kami fikir berjaya sampai ke penghujung hari adalah cukup teguh, dan selebihnya telah dilumpuhkan atau dialih keluar menunggu pembaikan.
   Langkah 5: GPUDirect RDMA
   Untuk membenarkan komunikasi GPU tanpa menanggung overhed pengiraan CPU, kami mendayakan ciri yang dipanggil GPUDirect RDMA, yang membolehkan komunikasi terus antara kad rangkaian InfiniBand. Ini melibatkan dua langkah utama:
4. Mulakan modul teras tambahan
5. Pastikan Perkhidmatan Kawalan Akses PCIe (ACS) dinyahdayakan untuk mengelakkan hang segera
   Langkah 6: Perkuat pelayan "emas"
   Untuk digunakan Apabila membina kluster GPU dengan perkakasan terkini, peraturan biasa ialah: kira-kira 3% daripada mesin akan menghadapi masalah setiap minggu, jadi bersiaplah.
   Namun, ia perlu dijelaskan: bukan setiap mesin mempunyai 3% peluang kegagalan yang seragam, tetapi sebilangan kecil mesin yang tidak dirawat mempunyai pelbagai masalah berulang kali sehingga ia dibaiki dengan betul. Ini menyerlahkan kelebihan mempunyai sejumlah besar mesin dalam struktur rangkaian yang sama. Oleh itu, daripada hanya mencari mesin rawak untuk menjalankan latihan berskala besar, seperti whack-a-mole untuk melihat apa yang rosak, pendekatan kami adalah untuk memfokuskan pada pelayan skala yang diketahui boleh dipercayai, pelayan "emas".
   Langkah 7: Penyelenggaraan
   Penyelenggaraan InfiniBand terutamanya melibatkan tindak balas kepada penggera UFM, menggantikan kabel dan transceiver yang rosak, dan kadangkala mendiagnosis ralat yang lebih sukar (seperti kegagalan suis). Biasanya terdapat dua faktor yang membawa kepada penyelenggaraan berskala besar:
6. Kemas kini perisian tegar, terutamanya apabila hanya separuh daripada kluster telah menyelesaikan kemas kini, ini boleh membawa kepada rasuah negeri UFM dan memerlukan UFM dimulakan semula pada semua suis InfiniBand.
   2. But semula besar-besaran kotak GPU secara serentak, yang mungkin membanjiri sejumlah besar kemas kini ke dalam keadaan UFM dan juga memerlukan memulakan semula perkhidmatan UFM.
   Memastikan Mesin Sihat Sepenuhnya
   Semasa proses ini, kami menemui pelbagai cara di mana mesin individu boleh tidak berfungsi atau memperlahankan latihan. Kebanyakan mod kegagalan ini tidak kelihatan serta-merta, jadi kami menulis beberapa skrip pemeriksaan kesihatan untuk menyemak sama ada hos cukup sihat. Kami menerbitkan kod di sini: https://github.com/imbue-ai/cluster-health
   Sila ambil perhatian bahawa kebanyakan pemeriksaan kesihatan ini adalah khusus untuk persekitaran masa jalan kami dan tidak semestinya berkaitan dengan perkakasan asas, juga tidak semestinya mudah dibaiki atau diautomatikkan. Ini adalah dengan reka bentuk: untuk mencapai matlamat keseluruhan untuk menyediakan mesin kami untuk latihan, kami mahukan satu titik masuk yang boleh menjawab ya atau tidak secara langsung, dan yang boleh meringkaskan sebarang butiran terperinci.
   Pemeriksaan Kesihatan GPU
   Kami menyemak sama ada bilangan GPU adalah betul, semakan ECC (Kod Pembetulan Ralat) didayakan dan tiada ralat ECC. Kami juga menyemak bahawa topologi NVLink (yang menghubungkan GPU antara satu sama lain) adalah siap dan bebas ralat.
   Pemeriksaan Kesihatan Ruang Cakera
   Kami menyemak sama ada penggunaan ruang cakera hos melebihi 95%.
   Pemeriksaan Kesihatan Docker
   Kami menyemak sama ada Docker boleh menjalankan bekas dengan GPU disambungkan (iaitu sama ada NVIDIA Container Runtime berfungsi dengan betul), dan juga menyemak sama ada bekas Docker yang berkaitan dengan pemantauan/analisis telah diaktifkan dan memperoleh kebenaran hos yang betul .
   Pemeriksaan Kesihatan Dmesg
   Kami menyemak dmesg untuk ralat Xids atau SXid perkakasan (kesalahan yang disebabkan oleh GPU NVIDIA atau suis NVIDIA antara GPU). Kami juga membaca semua baris log dmesg untuk mengesahkan bahawa mereka semua boleh diklasifikasikan ke dalam senarai "garis log biasa/jangkaan".
   Pemeriksaan Kesihatan iDRAC
   Kami menyemak ralat iDRAC pada mesin, yang mengabaikan mesej ralat yang tidak membawa maut. Ini adalah semakan khusus untuk komputer Dell, jadi ia tidak disertakan dalam kod sumber terbuka kami.
   Pemeriksaan Kesihatan Cakera
   Kami telah menyemak bahawa zpool telah dipasang, bahawa Docker disambungkan dengan betul kepadanya, dan ia sebenarnya boleh mencapainya tanpa mengunci CPU.
   Pemeriksaan Kesihatan InfiniBand
   Kami menyemak sama ada kadar ralat InfiniBand meningkat dan/atau perisian tegar pemacu sudah lapuk.
   Pemeriksaan Kesihatan Nvlink
   Kami menyemak ralat NVLink pada mesin. Dalam amalan, ini nampaknya tidak menyebabkan kegagalan latihan, tetapi ia mungkin melambatkan latihan.
   Pemeriksaan Kesihatan GDR
   Kami menyemak sama ada GDR didayakan pada mesin.
   Pemeriksaan Kesihatan VBIOS
   Kami telah menyemak bahawa versi VBIOS GPU dan perisian tegar papan tapak H100 adalah terkini.
   Pemeriksaan Kesihatan Flint
   Kami menggunakan flint dan hca_self_test untuk menyemak sama ada pemacu Mellanox OFED, perisian tegar kad rangkaian dan perisian tegar transceiver adalah versi yang betul dan ia disusun dengan betul untuk pemacu NVIDIA.
   Pemeriksaan Kesihatan PSB
   Kami menanyakan peranti PCIe untuk memeriksa sama ada kelajuan dan lebar sambungan antara GPU, PSB (Bus Suis PCIe) dan kad rangkaian adalah seperti yang kami jangkakan. Kami juga menyemak bahawa perisian tegar suis adalah terkini. Skrip ini dibangunkan oleh Dell, bukan Imbue, jadi kami tidak dapat berkongsinya buat masa ini.
   Selain pemeriksaan kesihatan pantas ini, kami juga melakukan beberapa pemeriksaan kesihatan yang lebih kompleks, termasuk:
   Memulakan pengiraan matriks melalui PyTorch, dan mengukur lebar jalur NVLink serta kelajuan pengiraan GPU dan memori. Kami menetapkan bendera GDR yang sesuai untuk menguji InfiniBand dan NVLink.
   Gunakan ib_write_bw dan –use_cuda untuk menghantar data melalui kad IB dan mengukur lebar jalur kad PCIe dan InfiniBand. Proses ini berlangsung untuk tempoh masa yang panjang (kira-kira 15 minit) untuk memastikan pautan InfiniBand yang berkibar dikenal pasti.
   Jalankan larian diagnostik berbilang nod untuk menyemak keupayaan pemula NCCL dan sama ada ia terhenti secara rawak. Jika terdapat gerai, kod NCCL bercabang kami menambah pembalakan tambahan. Ini mengambil masa 12 hingga 24 jam untuk mengesan masalah, jadi kami biasanya hanya menjalankan ini pada nod baharu atau jika kami mengesyaki masalah.
   Semak eksport DCGM untuk sebarang acara pendikitan jam GPU (tidak termasuk jangkaan gpu_idle dan power_cap). Untuk menyemak peristiwa kuasa ini, cara terbaik ialah menjalankan latihan berbilang nod yang menyemak semua GPU, kad InfiniBand dan CPU serta cakera secara serentak.
   Diagnosis masalah latihan biasa
   Setelah perkakasan berfungsi dengan betul, anda boleh mula berlatih.
   Bahagian ini akan berkongsi beberapa langkah penyahpepijatan dan cerapan khusus berdasarkan pengalaman kami menjalankan latihan model bahasa yang besar pada kelompok kami.
   Ranap semasa permulaan
   Dalam satu cara, ini adalah pepijat terbaik yang boleh anda hadapi kerana ia (secara teorinya) mudah untuk menghasilkan semula dan berulang.
   Kami mula-mula menyemak bahawa kod kami berjalan pada versi, konfigurasi dan pembolehubah persekitaran yang betul. Walaupun asas, kami mendapati ini penting: memastikan proses latihan permulaan boleh dihasilkan semula dan mudah untuk diperiksa. Satu sebab besar ialah abstraksi perantaraan seperti caching imej Docker atau konfigurasi rahsia legap boleh menyebabkan kekeliruan.
   Satu lagi pemeriksaan asas yang kami lakukan adalah untuk memastikan semua mesin berada dalam talian dan kesan tindanan atau log yang dipancarkan boleh diagregatkan dan diperiksa dengan mudah. Kami menggunakan tindanan perisian Loki, Prometheus dan Grafana, tetapi sebarang pengagregatan log yang sesuai atau alat SaaS penjejakan akan berjaya. Oleh kerana larian latihan ini bersifat segerak dan diedarkan, ralat pertama selalunya membawa kepada rangkaian ralat yang tidak berkaitan. Di sini, pemeriksaan kesihatan juga boleh membantu mengesan ralat seperti cakera keras yang rosak atau GPU yang hilang atau tidak sah serta-merta.
   Kami membina sistem yang dimulakan semula secara automatik sekiranya berlaku kegagalan, yang menjadikan log dan pengagregatan ralat lebih penting untuk mengelakkan ralat mengelirukan daripada mula semula yang berbeza. Beberapa ralat biasa yang kami hadapi termasuk:
   1. "Pesanan hadapan berbeza mengikut peringkat: kedudukan 0 ialah 43 parameter yang mengumpulkan semua manakala peringkat 1228 ialah 1 parameter". Kami mendapati ini adalah ciri pelik bagi pelaksanaan Selari Data Berkongsi Penuh (FSDP) PyTorch, yang telah diselesaikan dengan dimulakan semula.
   2. Ralat GPU Out of Memory (OOM), yang kelihatan seperti ini: "CUDA out of memory. Cuba untuk memperuntukkan..." Dengan menyemak konfigurasi dan kod kami beberapa kali dan membuat asal pengubahsuaian kod terkini (disebabkan oleh spesifikasi peranti PyTorch yang tidak konsisten semasa permulaan Dengan betul menyebabkan penggunaan GPU #0 yang berlebihan), kami membetulkan isu ini.
   3.Ralat CPU/RAM Out of Memory (OOM) Ralat ini tidak mudah ditemui dalam log ralat dan biasanya boleh dikesan melalui log dmesg hos di luar bekas Docker. Apabila OOM Killer dipanggil untuk menghentikan proses bercabang atau rakan rangkaian, kita dapat melihat bahawa ia terutamanya nyata sebagai CalledProcessError atau ConnectionError. Apabila panggilan OOM Killer dikesan daripada dmesg, kami lebih suka meninggalkan pemeriksaan kesihatan dan but semula kotak. Kami juga menyemak laluan kod kami untuk pengumpulan sampah manual yang mencukupi (terdapat bahagian di bawah tentang cara untuk melumpuhkan ini), dan juga menyemak sebarang percubaan yang tidak dijangka untuk mengira atau memindahkan tensor ke CPU.
   Ranap semasa latihan
   Tugas pertama adalah untuk membolehkan sistem berjalan secara automatik, supaya ia boleh menjalankan semula semua pemeriksaan kesihatan secara automatik, dan kemudian mulakan semula apabila tiada hos yang tidak sihat ditemui. Kami menghadapi beberapa ralat perkakasan rawak, termasuk ralat Xid dan SXid ini boleh ranap larian tanpa mengeluarkan surih tindanan Python yang bermakna. Sesetengah isu, seperti pemetaan semula baris, boleh dipulihkan dengan but semula. Lain-lain, seperti ralat ECC yang tidak boleh dibetulkan, selalunya memerlukan penyelenggaraan perkakasan atau alat ganti.
   Selain itu, kami mendapati bahawa data latihan yang salah juga boleh menyebabkan ranap. Contohnya, jika terdapat satu dokumen yang sangat besar dalam korpus, ia mungkin menyebabkan ralat kehabisan ingatan pada GPU atau CPU.Untuk mengelakkan masalah ini, kami melaksanakan pemuat data yang menentukan sepenuhnya - menjadikan setiap ranap sistem mudah dihasilkan semula dengan terikat pada nombor epok atau langkah. Kami mendapati bahawa melumpuhkan pemuatan data atau menggantikan data palsu (seperti data semua-sifar) membantu mengesahkan sama ada punca ralat ialah data.
   Akhir sekali, adalah berguna untuk merekodkan statistik kesihatan rangkaian dan nod am melalui kaedah pengagregatan metrik. Isu seperti putus sambungan Ethernet ringkas atau ruang cakera yang rendah mungkin tidak muncul sebagai mesej ralat yang berguna, tetapi boleh dikaitkan dengan mudah dengan data yang dikumpul.
   Digantung tanpa kesan tindanan (dan mungkin tamat masa kemudian)
   Menyahpepijat jenis ralat ini boleh mengecewakan kerana kekurangan maklumat yang berguna dan kesukaran untuk menghasilkan semula ralat tersebut dengan pasti.
   Salah satu jenis ralat yang paling diingati disertakan dengan mesej ralat seperti ini:
   

   Watchdog caught collective operation timeout:WorkNCCL (SeqNum=408951, OpType=_ALLGATHER_BASE, … , Timeout (ms)=600000) ran for 600351 milliseconds before timing out

   
   dan mesej ralat ini dikeluarkan oleh semua pekerja GPU dalam latihan.

Ini bermakna satu atau lebih hos gagal menyelesaikan operasi NCCL atau sambungan NCCL dan InfiniBand ranap, menyebabkan semua hos lain tersekat pada operasi tensor pada masa yang sama sehingga tamat masa NCCL_TIMEOUT dicapai. Malangnya, disebabkan sifat perpustakaan perisian NCCL, sukar untuk mencari hos mana yang menyebabkan masalah.

Kami telah membuat beberapa pengubahsuaian pada pengelogan perpustakaan perisian NCCL, lihat versi bercabang kami: https://github.com/boweiliu/nccl. Ini mungkin mendedahkan mesej atau operasi yang sedang dijalankan dengan lebih baik apabila ranap sistem berlaku, dan dengan itu menentukan hos atau GPU yang mungkin menyekat pelaksanaan.

Sila ambil perhatian bahawa untuk mengenal pasti hos yang tidak berkelakuan, kami selalunya perlu memikirkan hos yang tidak menjana mesej log tertentu. Ketiadaan mesej sedemikian menunjukkan bahawa pekerja pada hos ini telah ketinggalan atau terhempas.

Situasi tidak responsif lain tanpa mesej ralat tersedia biasanya berkaitan dengan isu berkaitan perkakasan, seperti ralat Xid/SXid/ECC yang dinyatakan sebelum ini yang menyebabkan pemandu NVIDIA atau pemandu komunikasi NVIDIA Docker terkunci. Untuk membezakan hang NCCL daripada hang pemandu dan keadaan perlumbaan atau kebuntuan dalam kod Python, kami menggunakan alat seperti Py-Spy dan GNU Project Debugger (GDB) untuk nyahpepijat yang menemui proses terhenti dalam masa nyata. Satu isu khusus ditemui menggunakan pendekatan ini: disebabkan ralat konfigurasi dalam tetapan benang Python, kami tidak dapat melancarkan lapan proses GPU NCCL berbilang benang dengan betul pada sesetengah hos, yang menghadapi keadaan perlumbaan dalam peringkat kod permulaan sebelum PyTorch.

• Latihan Kelembapan (diukur oleh MFU)

Ketiadaan alatan menjadikan masalah jenis ini lebih mengecewakan daripada yang sebelumnya. Selain menggunakan Py-Spy, pemeriksaan surih tindanan dan GDB, kami juga menggunakan NVIDIA Nsight dan alatan pemprofilan, beberapa daripadanya sukar digunakan dalam tetapan teragih tinggi.

Malangnya, terdapat banyak sebab untuk kelembapan umum atau kelajuan yang lebih perlahan daripada penggunaan titik terapung model (MFU) yang ditunjukkan sebelum ini.

Pertama sekali, ternyata berguna untuk menyemak konfigurasi, kod dan pembolehubah persekitaran beberapa kali. Ralat yang kami alami termasuk menjalankan model yang salah, saiz kelompok yang salah, tetapan UFM atau NCCL yang salah, ralat CUDA_DEVICE_MAX_CONNECTIONS. Ini akan menghasilkan prestasi yang tidak optimum.

Kami juga mendapati ia berguna untuk mengukur MFU serta-merta (iaitu setiap kelompok) (daripada purata terlicin atau bertingkap), kerana lengkung MFU yang tidak licin sering membantu mendiagnosis kelas masalah. Isu yang menyebabkan latihan menjadi perlahan termasuk:

• Memulakan latihan serta-merta daripada MFU yang sangat rendah (kurang daripada satu persepuluh daripada jangkaan) dan kekal stabil

Ini berkemungkinan besar isu perkakasan dengan sambungan rangkaian InfiniBand, seperti lapisan T2 atau T3 Suis ranap. Isu perkakasan antara GPU dan NIC juga boleh menyebabkan keadaan ini, yang mana dmesg akan melaporkan ralat seperti ini: lorong PCIe x16 dihadkan oleh…

• Mulakan latihan segera daripada 30% daripada MFU yang dijangkakan dan kekal stabil

Sebab mungkin satu Hos mempunyai tetapan GDR yang salah (memori rakan sebaya NVIDIA) atau pembolehubah persekitaran GDR yang salah.

• Mulakan latihan segera daripada kira-kira 60-80% daripada MFU yang dijangkakan dan kekal stabil

Sebab yang paling biasa ialah kualiti atau kegagalan pautan InfiniBand yang lemah, terutamanya kegagalan GPU tunggal yang berkaitan dengan NIC InfiniBand, mengakibatkan penghalaan NCCL Try trafik melalui NVLink tempatan dan menggunakan NIC pada GPU lain pada hos yang sama. Pendikitan CPU juga boleh menyebabkan isu ini, yang memerlukan pelarasan tetapan BIOS pada sesetengah hos.

• Kelambatan besar secara tiba-tiba (turun sebanyak 10x) semasa memproses kumpulan data tertentu, dan ini berlaku agak kerap

Ini pada asasnya adalah mengenai pemeriksaan atau penilaian - ini boleh ditentukan dengan menyemak bilangan zaman atau langkah pengesahan. Yang menjengkelkan, jika anda menyediakan makluman automatik apabila MFU tidak normal, terdapat banyak positif palsu.

• Penurunan besar secara tiba-tiba (turun sebanyak 10x) semasa memproses kumpulan data tertentu

Ini berlaku secara rawak dan agak jarang (mungkin sekali setiap 15 minit) dan dipulihkan sepenuhnya kepada baik serta-merta selepas itu MFU.

Punca paling biasa nampaknya ialah beban kerja intensif CPU yang lain dijadualkan ke hos yang sedang berjalan. Kami mendapati bahawa daripada membina alat pemprofilan untuk mengenal pasti hos tertentu, lebih mudah untuk memantau CPU secara kasar oleh PID. Puncanya mungkin isu sambungan rangkaian sekali-sekala, seperti kesesakan pemuat data. Kami memantau data metrik untuk beban data, pusat pemeriksaan dan sebarang kod bukan NCCL dan menambahkan log pemasaan kod Python, yang terbukti sangat boleh dipercayai.

• MFU secara beransur-ansur perlahan semasa berlari, tetapi kembali kepada 100% selepas setiap but semula

Secara teorinya, puncanya mungkin terkumpul haba pada suis, tetapi kami tidak pernah melihat perkara ini berlaku. Walau bagaimanapun, menggunakan pemprofil Python dan NVIDIA kami menentukan bahawa punca kemerosotan prestasi nampaknya adalah pengumpulan sampah automatik.

Nyahpepijat menurun

Semasa menyahpepijat untuk menyelesaikan kelembapan ini, kami mendapati bahawa daya pemprosesan hampir pasti menurun secara berkala. Semasa latihan berlangsung, penurunan ini akan memberi kesan yang semakin meningkat pada pengkomputeran teragih. Ini menyebabkan kami membuat spekulasi bahawa punca penurunan itu mungkin berkaitan dengan kutipan sampah automatik - syak wasangka yang kami sahkan melalui analisis dan ujian. Apabila kami melumpuhkan kutipan sampah automatik dan menetapkan kutipan sampah hanya pada selang waktu tertentu pada semua hos, "penurunan" pemprosesan ini hilang.

Kami menggunakan FSDP, algoritma latihan teragih segerak berdasarkan ZeRO-3. Semasa operasi menyekat, satu proses pekerja yang menjalankan kutipan sampah mungkin melambatkan semua pekerja lain. Jika anda mempunyai ratusan proses pekerja, ini boleh menyebabkan kelembapan yang ketara.

Prestasi pada mulanya bagus, kemudian turun secara tiba-tiba (sehingga 70% daripada jangkaan) dan berterusan pada frekuensi tinggi (setiap 15 saat)

Kami memerhatikan bahawa ini berkaitan dengan "sebab pendikitan jam" GPU NVIDIA, yang boleh diselesaikan oleh NVIDIA DCGM menyelesaikan masalah ini dengan tetapan yang sesuai. Isu terma (suhu GPU tinggi atau kegagalan/mengurangkan keberkesanan kipas penyejuk konsol) atau kegagalan bekalan kuasa boleh menyebabkan isu ini. Selain itu, apabila kami memaksimumkan semua penggunaan 8 GPU dan penggunaan 8x NIC InfiniBand bersama-sama dengan CPU/RAM/cakera, sesetengah hos kami dengan perkakasan bekalan kuasa tertentu mempunyai masalah voltan, tetapi hanya menggunakan kesemuanya (biasanya hanya pada Ini hanya berlaku semasa larian latihan sebenar). . kemerosotan prestasi atau kegelisahan disebabkan oleh pautan pada lapisan yang lebih tinggi dalam rangkaian, dan bukannya hos yang kurang berlebihan kepada lapisan T2.

Malangnya, kebanyakan isu ini sukar untuk ditentukan kepada hos tertentu, dan isu berkaitan InfiniBand amat sukar untuk ditentukan disebabkan sifat teknologi suis InfiniBand yang sedar topologi. InfiniBand nampaknya memihak kepada hos bersebelahan dalam reka bentuk pokok lemak InfiniBand, manakala UFM boleh menghalakan paket pada kelajuan pautan tidak simetri.

Senarai Semak Kelengkapan untuk Isu Keupayaan Penyahpepijatan

• Berikut ialah ringkasan/carta alir/senarai semak kesempurnaan untuk menyahpepijat isu throughput:

Adakah sistem ini berfungsi dengan baik sebelum ini?

Apakah perubahan yang telah anda buat baru-baru ini (seperti menggabungkan kod, mengemas kini pemacu)?

Adakah tuan rumah yang anda jalani sihat? Adakah semua perkhidmatan bergantung anda berjalan dengan betul, termasuk SaaS pihak ketiga, seperti Docker Hub, GitHub, dsb.?

Adakah anda pasti bahawa kod, persekitaran, konfigurasi, versi, senarai hos, susunan kedudukan dan benih rawak yang dijalankan sekarang adalah sama seperti kali terakhir? (Jika semakan sebegini boleh dilaksanakan.)

Bolehkah masalah itu diulang? Bagaimanakah

• berkaitan dengan perkara lain? Proses lain? Tugas berjadual crontab harian? Hos atau penunjuk DCGM atau UFM?
• Adakah alat anda mengukur metrik ini dengan betul?
• Adakah masalah masih wujud apabila menjalankan versi kod yang dikurangkan (menggunakan model yang lebih kecil, data palsu, tiada simpanan atau pemuatan pusat pemeriksaan)?
• Alat Infrastruktur yang Diperbaiki
• Selepas melengkapkan langkah di atas, anda akan dapat mencapai prestasi yang baik apabila melatih model anda... sekurang-kurangnya sehingga sesuatu rosak.
• Bahagian ini akan memperkenalkan beberapa alat dan sistem untuk memastikan latihan yang konsisten dan stabil, sementara idealnya memerlukan campur tangan manusia sesedikit mungkin. Memandangkan kami adalah pasukan kecil, kami tidak mempunyai tenaga kerja yang mencukupi untuk melakukan pembaikan manual, jadi kami juga ingin mengautomasikan proses ini sebanyak mungkin.
• Hampir semua masalah yang kami hadapi semasa proses ini boleh dikaitkan dengan kegagalan komponen mesin atau rangkaian. Jenis kegagalan ini adalah biasa dalam kelompok besar, jadi pendekatan kami adalah untuk melumpuhkan komponen mesin dan rangkaian yang gagal secara automatik dan menghantar permintaan pembaikan.

Kegagalan mesin

Kami membangunkan sistem yang dimulakan semula secara automatik dari pusat pemeriksaan terkini jika larian ranap. Dalam proses restart ini, setiap mesin yang tersedia diperiksa kesihatannya terlebih dahulu, dan kemudian setiap mesin diklasifikasikan berdasarkan hasil pemeriksaan kesihatan yang dilaluinya, kemudian percubaan dibuat untuk memulakan semula latihan pada mesin yang paling sihat. Kegagalan komponen rangkaian

Sistem acara UFM sangat kompleks dan mengandungi berpuluh-puluh jenis acara. Walau bagaimanapun, dalam amalan, kami mendapati bahawa hanya beberapa peristiwa yang bermasalah, kebanyakannya berkaitan dengan kegagalan pautan atau teknik ralat simbol tinggi. Selepas mengenal pasti peristiwa ini, kami boleh menulis skrip untuk menghuraikan log peristiwa UFM, melumpuhkan pautan dan port yang dikaitkan dengan peristiwa terbaharu, meminta pesanan kerja penyelenggaraan untuk komponen rangkaian ini dan mendayakan semula komponen ini apabila penyelenggaraan selesai.

Sistem fail imej tempatan

Untuk latihan teragih berskala besar ini, telah lama didapati bahawa kelajuan pertukaran data antara kluster dan Ethernet merupakan halangan utama. Lebar jalur sambungan Ethernet yang dikongsi adalah kira-kira 10Gbit/s ini boleh tepu dengan cepat jika ratusan pekerja memuat turun set data dan pusat pemeriksaan model secara serentak.

Untuk tujuan ini, kami memutuskan untuk membina sistem fail tempatan di dalam kelompok kami sebagai cermin storan awan, yang pada asasnya adalah ruang cache yang boleh mengurangkan jumlah fail dibaca daripada S3. Untuk mengambil kira gugusan gugusan (iaitu, apabila mesin dilumpuhkan atau diganti atas sebab penyelenggaraan), kami mempunyai tiga salinan bagi setiap fail dan menggunakan pencincangan yang konsisten untuk mengagihkan beban secara sama rata untuk memaksimumkan prestasi semasa pergerakan gugusan dengan ketara. Memandangkan kluster mempunyai ruang cakera yang terhad, kami terpaksa membangunkan alatan untuk menjejaki kitaran hayat fail dan membersihkan fail yang tidak lagi berguna.

Registry Docker Teragih Tempatan

Kami menggunakan Kraken, perisian sumber terbuka yang hebat untuk pemindahan imej Docker rakan ke rakan. Kami hampir tidak mempunyai masalah dengan perisian, yang agak mengejutkan kami, memandangkan kerumitan tugas dan pelaksanaan kami. Alamat alatan: https://github.com/uber/kraken

Pelbagai alatan pemantauan prestasi

Kami menyediakan penganalisis Obor lalai dan Sistem Nsight NVIDIA. Yang terakhir membantu kami memahami masa tepat yang diperlukan untuk hantaran ke hadapan/balik dan komunikasi NCCL, dan seterusnya membantu kami menentukan sama ada saiz model dan bilangan pekerja tertentu akan menjadi halangan. Walau bagaimanapun, Sistem Nsight agak sukar untuk digunakan kerana ia memerlukan menjalankan Docker dalam mod istimewa, yang memerlukan melumpuhkan semakan keselamatan yang berkaitan dengan acara pemantauan prestasi dan menyimpan konfigurasinya selalunya memerlukan menghentikan keseluruhan proses latihan.

Selain itu, kami mempunyai alatan bertulis untuk mengesan kumpulan data latihan yang perlahan dan memahami kemungkinan puncanya. Kami mendapati ini berguna. Salah satu alat yang paling berguna memantau tempoh masa setiap kumpulan dan membuang jejak tindanan pekerja jika kumpulan terlalu perlahan - menjadikannya lebih mudah untuk mencari hos dengan masalah perkakasan atau perisian kecil.

Bahagikan mesin kepada kumpulan yang berbeza untuk mencari hos yang rosak

Dalam beberapa bulan pertama menggunakan kluster ini (apabila pemeriksaan kesihatan tidak begitu teliti seperti sekarang), kami sering menghadapi situasi ini: dalam kumpulan A berlaku kerosakan semasa latihan pada mesin, tetapi tidak jelas mesin yang mempunyai masalah. Untuk mencari hos yang rosak, kami membangunkan alatan yang memudahkan untuk memisahkan set mesin kepada kumpulan yang berbeza dan menjalankan latihan yang lebih kecil pada setiap kumpulan mesin.

Sebagai contoh, jika latihan yang dijalankan pada 48 mesin gagal, kemudian jalankan latihan yang lebih kecil pada 6 kumpulan 8 mesin setiap satu, dan kemudian jalankan latihan yang lebih kecil pada 8 kumpulan 6 mesin setiap satu. Biasanya, hanya satu larian daripada dua fasa akan gagal, memberikan kita keyakinan untuk membuat kesimpulan bahawa mesin yang gagal dalam kedua-dua fasa adalah rosak.

Refleksi dan Pengajaran

Dalam proses menyediakan dan menyelenggara infrastruktur, kami mendapat beberapa pengajaran berguna:

• Amalan yang berguna ialah menukar kedudukan mesin. Pada masa jalanan, penggunaan mesin 10-20% lebih banyak daripada yang diperlukan boleh membantu supaya latihan boleh dimulakan semula dengan mudah sekiranya berlaku kegagalan mesin. Menyediakan rangkaian kluster supaya setiap mesin disambungkan rapat dengan setiap mesin lain membolehkan kami menggunakan mana-mana subset yang berfungsi bagi mesin tersebut.
• Menulis ujian dan penyelesaian automatik untuk setiap kegagalan perkakasan atau perisian yang anda hadapi, kerana setiap masalah yang dihadapi dalam latihan akan berulang. Begitu juga, untuk setiap mesej ralat yang samar-samar, ia patut menulis alat yang menerangkan ralat dengan lebih baik.
• Kebolehulangan adalah kunci kepada penyelidikan saintifik yang cemerlang. Salah satu prinsip yang kami pakai serta-merta ialah: "Hanya ubah satu perkara pada satu masa," walaupun dalam perkara yang paling mudah.
• Percaya, tetapi juga sahkan. Setiap kali kami membawa masuk alat luaran atau membawa orang baharu (sama ada dari dalam atau luar syarikat), kami menyemak semula perkara yang mereka dakwa, terutamanya jika langkah seterusnya bergantung pada tuntutan tersebut.

Ringkasan

Melatih model bahasa yang besar memerlukan infrastruktur yang kompleks dari awal. Kami memilih untuk melibatkan diri secara mendalam dalam butiran penyediaan infrastruktur kami kerana kami percaya adalah penting untuk memahami sepenuhnya sistem yang kami kendalikan, dan kerana kami percaya ia adalah lebih cekap untuk berbuat demikian.

Kini, setelah melalui proses tersebut, kami gembira kami mengambil pendekatan ini - mempunyai kawalan penuh ke atas infrastruktur kami dan keupayaan untuk menyahpepijat dengan mudah pada setiap peringkat pengabstrakan telah terbukti mempunyai nilai kritikal . Walaupun proses ini memerlukan banyak penyeliaan dan lelaran, ia membolehkan kami memperoleh pemahaman yang mendalam tentang aliran kerja yang mendasari, membina satu set alat untuk memastikan kesihatan hos, mempelajari cara mengautomasikan sistem untuk memastikan latihan lancar yang berterusan, dan akhirnya membina Set infrastruktur yang membolehkan kami melatih model bahasa canggih dengan cepat dan berulang.

Proses pembinaan infrastruktur ini mencerminkan metodologi asas kami untuk menyelidik dan membina ejen AI: meneroka butiran,

Atas ialah kandungan terperinci Daripada logam kosong kepada model besar dengan 70 bilion parameter, berikut ialah tutorial dan skrip sedia untuk digunakan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!