berita

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Dipilih dari imbue.com

Penulis: Tim Imbue

Kompilasi Jantung Mesin

Penyunting: panda

Kita tahu bahwa LLM dilatih pada cluster komputer skala besar menggunakan data yang sangat besar. Machine Heart telah memperkenalkan banyak metode dan teknologi untuk membantu dan meningkatkan proses pelatihan LLM. Hari ini, yang ingin kami bagikan adalah artikel yang mendalami teknologi yang mendasarinya dan memperkenalkan cara mengubah sekelompok "bare metal" yang bahkan tidak memiliki sistem operasi menjadi cluster komputer untuk pelatihan LLM.

Artikel ini berasal dari Imbue, sebuah startup AI yang berupaya mencapai kecerdasan umum dengan memahami cara berpikir mesin.

Tentu saja, mengubah sekumpulan "bare metal" tanpa sistem operasi menjadi cluster komputer untuk pelatihan LLM bukanlah proses yang mudah, penuh eksplorasi dan trial and error, namun Imbue akhirnya berhasil melatih LLM dengan 70 miliar parameter dan terakumulasi banyak pengalaman berguna dalam prosesnya.

Artikel ini akan memberikan pengenalan mendalam tentang seluruh proses tim dalam membangun infrastruktur pelatihan LLM mereka sendiri, dan akan berbagi banyak alat dan skrip yang mereka tulis untuk memfasilitasi pemantauan, inspeksi, dan koreksi kesalahan.

Jika Anda tertarik untuk membangun infrastruktur pelatihan LLM sendiri atau penasaran bagaimana cara LLM dibuat, maka artikel ini layak untuk dibaca dan dikoleksi.

Berikut teks asli artikel tim Imbue.

perkenalan

Tim kecil kami yang terdiri dari peneliti dan insinyur menghabiskan beberapa bulan untuk melatih model dengan 70 miliar parameter dari awal pada infrastruktur kami sendiri, dan model tersebut mengungguli model zero-shot pada tugas-tugas terkait inferensi.

Hari ini, kami berbagi proses penyiapan infrastruktur yang diperlukan: mulai dari menyusun cluster awal dan menginstal sistem operasi hingga menyiapkan pemulihan otomatis ketika terjadi kesalahan selama pelatihan. Kami merinci tantangan yang dihadapi dan solusi di setiap langkah. Selain pembelajaran ini, kami juga akan merilis banyak skrip yang telah kami kembangkan untuk memudahkan tim lain membuat infrastruktur yang stabil untuk pelatihan model mereka sendiri.

Sepanjang proses, tim teknisi kami bekerja dengan Tegangan Park untuk menyiapkan cluster komputer dan membangun fondasi untuk aplikasi produksi. Keseluruhan proses ini meliputi:

1. Konfigurasikan setiap mesin

2. Konfigurasikan InfiniBand

3. Pastikan mesin benar-benar sehat

4. Mendiagnosis masalah pelatihan yang umum

5. Meningkatkan sarana infrastruktur

Setiap langkah dijelaskan secara rinci di bawah ini.

Latar Belakang: Cara pembuatannya

Tujuan kami dalam melakukan komputasi adalah untuk memastikan eksperimen cepat dengan model bahasa besar. Untuk melakukan ini, kita memerlukan GPU berkecepatan tinggi dalam jumlah besar, dan komunikasi berkecepatan tinggi antar GPU tersebut.

Artikel ini akan fokus pada cluster yang berisi 4088 GPU H100 yang tersebar di 511 komputer, atau 8 GPU per komputer. Alasan mengapa terdapat 511 komputer dengan GPU adalah karena beberapa koneksi perlu dicadangkan untuk node Unified Fabric Manager, yang berperan untuk mengelola jaringan InfiniBand. Pada host yang dilengkapi GPU 511, setiap GPU terhubung langsung ke kartu jaringan ConnectX-7, yang dapat mengirimkan data dengan kecepatan 400 Gbps ke GPU mana pun di jaringan InfiniBand.

Topologi jaringan InfiniBand kami "sepenuhnya non-pemblokiran"; secara teori, hal ini memungkinkan GPU untuk berkomunikasi satu sama lain dengan kecepatan maksimum. Untuk melakukan ini, kami menggunakan arsitektur jaringan InfiniBand tiga lapis: sakelar InfiniBand tiga lapis. Dengan koneksi yang tepat, throughput tingkat tinggi ini dapat dicapai di seluruh jaringan. Gambar berikut menunjukkan gambaran umum jaringan InfiniBand ini:

Perhatikan bahwa komunikasi saat melatih jaringan terjadi melalui InfiniBand, bukan Ethernet. Meskipun mesin ini juga terhubung ke Ethernet, peran jaringan ini adalah untuk mengangkut data seperti kumpulan data dan pos pemeriksaan. Jika Anda menggunakan Ethernet untuk mengirim data, kecepatannya akan jauh lebih lambat karena data pertama-tama akan berpindah dari GPU ke CPU dan kemudian keluar melalui kartu Ethernet berkecepatan 100 Gbps. Meskipun pelatihan melalui Ethernet juga dapat dilakukan menggunakan teknologi yang disebut RDMA over Converged Ethernet (RoCE), hal ini memerlukan banyak kerja ekstra baik dari sisi perangkat keras maupun perangkat lunak, dan umumnya kurang dapat diandalkan dibandingkan InfiniBand. Untuk detailnya, silakan merujuk ke makalah ini: https://arxiv.org/pdf/2402.15627

Ada juga Ethernet sekunder yang hanya digunakan untuk konfigurasi dan manajemen, menyediakan akses ke BIOS (Basic Input Output System), catu daya, dan antarmuka kontrol lainnya untuk antarmuka mesin tingkat rendah. Tanpa jaringan manajemen ini, kita harus mengatur setiap node secara manual melalui driver USB, keyboard, dan monitor. Untuk situasi dengan ratusan mesin, ini bukanlah pendekatan yang berkelanjutan.

Untuk mencapai pelatihan kinerja tinggi pada klaster ini, setiap komponen (InfiniBand, Ethernet, GPU, dan node itu sendiri) harus bekerja hampir sempurna. Jika salah satu dari 12.000+ koneksi tersebut sedikit tidak stabil, hal ini dapat memperlambat jalannya pelatihan secara keseluruhan.

Sisa artikel ini adalah tentang bagaimana membuat semuanya berjalan dengan sempurna dan stabil.

Proses: Cara mengubah bare metal menjadi cluster yang beroperasi penuh

Konfigurasikan setiap mesin

Setelah membuat koneksi Ethernet awal ke cluster melalui jaringan manajemen, kredensial akses ke pengontrol manajemen alas tiang (BMC) diperoleh. BMC adalah prosesor layanan khusus yang memonitor sistem host dari jarak jauh dan biasanya terhubung ke jaringan terpisah. Hal ini memungkinkan kami mengoperasikan mesin seolah-olah kami berada di sana secara langsung, dan juga menyediakan API untuk kesehatan perangkat keras, pengaturan BIOS, dan manajemen daya.

Dengan adanya komponen-komponen ini, kita dapat menyingsingkan lengan baju dan mulai menyiapkan cluster.

Langkah 0: Konfigurasikan mesin terlebih dahulu

Kami memulai dengan menginstal Ubuntu 22.04 di server menggunakan iDRAC (Dell's Baseboard Management Controller) dan kemudian mengatur semuanya berdasarkan sistem operasi ini. Salah satu kemampuan iDRAC adalah memungkinkan instalasi dan boot image ISO dari komputer lokal dan menyediakan konsol virtual melalui browser. Idealnya, ini adalah satu-satunya langkah instalasi manual dalam proses tersebut.

Langkah 1: Instal sistem operasi pada setiap mesin

Setelah mengkonfigurasi mesin pertama, lanjutkan untuk menginstal perangkat lunak Metal-as-a-Service (MAAS) Ubuntu untuk membantu mengkonfigurasi server yang tersisa. Alat boot dan otomatisasi iDRAC menggunakan Preboot Execution Environment Protocol (PXE) untuk menginstruksikan setiap mesin untuk melakukan booting dari jaringan dan mengonfigurasi MAAS untuk merespons permintaan boot PXE. Saat melakukan boot jaringan awal, server memperoleh IP dan kernel awal dari MAAS melalui Dynamic IP Allocation Protocol DHCP tanpa harus menginstal apa pun di drive lokal. Ini adalah lingkungan dasar untuk mengotomatisasi instalasi sistem operasi berulang. Secara teoritis, kita hanya perlu menunggu booting pertama dan semuanya akan beres. Namun dalam praktiknya, integrasi MAAS dengan BMC tidak dapat diandalkan, jadi kami menggunakan API iDRAC untuk mengumpulkan alamat MAC setiap mesin (pengidentifikasi perangkat keras fisik unik) terlebih dahulu.

Sepanjang seluruh proses pelatihan ini, MAAS sering kali merupakan komponen tumpukan tulang belakang yang lebih andal. Namun, kami mengalami beberapa masalah di awal yang unik pada penyiapan kami. Misalnya, ketika mengonfigurasi beberapa mesin pertama, saya tidak dapat menginstal apa pun melalui apt karena masalah verifikasi sertifikat HTTPS karena jamnya sangat berbeda. Terkait, karena server MAAS harus bertanggung jawab atas banyak hal (server DHCP, server DNS untuk menyelesaikan nama host menjadi IP, proxy HTTP antara host dan server paket resmi Ubuntu, server NTP, manajemen konfigurasi cloud-init, dan ground database kebenaran digunakan untuk menghubungkan alamat MAC ke IP ke nama host ke metadata khusus), sehingga sulit bagi kami untuk menyelesaikan masalah ini dari akar masalahnya. Selain itu, ada masalah kurva pembelajaran siklus hidup konfigurasi MAAS, karena tujuan desainnya adalah untuk menangani kompleksitas pengelolaan penerapan greenfield dan migrasi node secara bertahap serta berbagai status perantara debug/tidak sehat.

Langkah 2: Diagnosis Mesin Rusak

Kami menemukan bahwa sekitar 10% mesin gagal melakukan booting, sebagian besar disebabkan oleh masalah fisik pada server. Ini adalah skenario umum untuk menyiapkan cluster GPU besar. Situasi yang kami temui meliputi: kabel jaringan hilang atau salah, masalah perangkat keras di iDRAC, unit catu daya rusak, driver NVME (non-volatile memory fast) rusak, jalur internal hilang, kartu jaringan atau GPU tidak ditampilkan. Kami secara otomatis memeriksa masalah ini, mengembalikan beberapa mesin ke Dell untuk diuji ulang, dan mengirimkan perintah kerja yang sesuai untuk staf pusat data. Salah satu keuntungan dari melakukan konfigurasi cluster sendiri adalah kita dapat langsung menggunakan mesin yang sehat sambil menunggu maintenance pada beberapa mesin.

Langkah 3: Mesin Minimum yang Dapat Diamati

Kami melanjutkan dengan pengaturan berikut di setiap server:

1.Docker (untuk memudahkan menjalankan layanan dan pekerjaan pelatihan)

2. Driver GPU pusat data

3. Alat ekspor node Prometheus (digunakan untuk mengekspor aliran data indikator perangkat keras/sistem operasi yang stabil)

4. Alat ekspor DCGM (digunakan untuk mengekspor data indikator tambahan dari GPU NVIDIA, seperti status GPU, jam, pemanfaatan)

5. Kumpulan RAIDZ ZFS untuk semua driver non-sistem operasi, yang memungkinkan mesin untuk terus bekerja meskipun driver gagal, sekaligus menyediakan kompresi transparan secara gratis (ini sangat berguna untuk kumpulan data teks biasa dan log berulang - relatif Menggunakan ini alat ini biasanya meningkatkan ruang yang dapat digunakan hingga 10 kali lipat dibandingkan dengan tidak menggunakan alat ini)

Kami kemudian menjalankan diagnostik GPU dasar untuk menentukan apakah GPU secara umum berfungsi dengan baik - jika tidak, biasanya akan menyebabkan masalah perangkat keras dalam beberapa jam.

Selama ini, kami mengalami hambatan bandwidth saat mencoba menginstal paket di 400 node secara bersamaan. Ini adalah pertama kalinya kami menerima peringatan panas berlebih pada suhu tinggi pada beberapa komponen yang ditempatkan di pusat data kami. Masalah pemanasan gelombang pertama ini sebagian besar telah diselesaikan melalui pembaruan firmware.

Langkah 4: Pelatihan GPU node tunggal

Langkah selanjutnya adalah memastikan bahwa setiap mesin dapat menangani beban kerja GPU yang sebenarnya secara mandiri. Banyak mesin tidak mampu melakukan hal ini, dan masalahnya meliputi:

Kesalahan terkait GPU, yang umumnya dapat diatasi dengan memasukkan kembali kartu GPU ke dalam slot kartu: Geser server seberat 200 pon keluar dari rak, lepaskan semua kabel antara penutup dan GPU, dan lepaskan GPU, pasang kembali GPU, lalu sambungkan kembali kabel dan dorong server kembali ke rak.

Menurut log server Ubuntu, banyak kabel antara GPU dan bus PCIe atau kartu jaringan mengeluarkan kesalahan ini: "lebar terbatas: x4 <x16". Setelah memperbarui firmware bus saklar PCIe, kami menemukan bahwa sekitar seperempat host memerlukan pemasangan ulang kabel PCIe internal - mungkin karena kabel antara casing dan GPU cukup rapuh, artinya setiap kali pemeliharaan dilakukan pada GPU, kabel ini akan didorong atau ditarik keluar.

Ada beberapa pemadaman lain-lain yang juga berdampak pada beberapa host. Dell membantu kami mengatasi beberapa masalah dengan peningkatan firmware:

Drive NVMe tidak menunjukkan gangguan tetapi mengunci seluruh mesin saat disentuh.

Hard drive muncul secara acak di Linux, menyebabkan kebingungan di MAAS dan menyebabkan sistem operasi diinstal pada drive yang salah.

Pembacaan suhu salah, menyebabkan kipas terus bekerja dengan kecepatan penuh. Alasannya mungkin karena masalah dengan driver NVIDIA, yang diselesaikan dengan menurunkan versi driver.

Penskalaan dinamis CPU menjadi tidak terkendali, membatasi inti yang bekerja hingga 2 GHz.

Komunikasi GPU-GPU langsung (GDR atau GPUDirect RDMA Peer Memory Client) tidak berhasil diterapkan.

Konfigurasikan InfiniBand

Langkah 0: Instal UFM

Salah satu keunggulan InfiniBand adalah desainnya yang terpusat, sehingga seluruh jaringan memiliki satu otak. Oleh karena itu, kita hanya perlu menangani satu contoh dari 320 switch jaringan di seluruh struktur jaringan. Tugas pertama kami adalah mencari tahu saklar mana yang menghubungkan mesin mana, lalu mengaitkannya dengan diagram pengkabelan dan mengganti namanya berdasarkan lokasi fisik saklar tersebut.

Langkah 1: Mengkabelkan Ulang

Awalnya, UFM tidak dapat mendeteksi 320 switch tersebut, apalagi host yang seharusnya ada di dalam fabric. Setelah berkonsultasi dengan mitra pusat data kami, kami mengonfirmasi bahwa sakelar telah dihidupkan dan dihubungkan dengan kabel, namun masih tidak dapat mendeteksinya. Setelah memeriksa daftar pengkabelan jaringan, kami melihat bahwa desain struktur jaringan tingkat atas salah: alih-alih disatukan, struktur tersebut dibagi menjadi delapan jaringan terputus tanpa jalur perutean yang sama. Setelah pemasangan ulang kabel, kami menambahkan langkah pemeriksaan untuk memverifikasi bahwa semua koneksi fisik konsisten dengan desain baru.

Langkah 2: Sepuluh ribu alarm suhu (peringatan)

Setelah masalah pengkabelan fisik teratasi, InfiniBand berhasil membuat koneksi ke semua switch InfiniBand di struktur jaringan. Namun, hampir setiap port switch mulai melaporkan suhu yang berlebihan, terkadang melebihi 70°C, meskipun mereka tidak mengirimkan data. Kami menemukan bahwa masalahnya berasal dari ruang terbuka di antara sakelar di rak yang sama, yang menyebabkan udara panas mengalir kembali ke depan. Mitra pusat data kami membantu kami mendiagnosis masalah dengan cepat dan mengembangkan resolusi yang tepat.

Langkah 3: 1800 alarm

Banyak port juga memiliki tingkat kesalahan yang tinggi, atau bolak-balik antara kondisi normal dan rusak, yang disebut "flapping". Masalah ini hanya muncul ketika port benar-benar digunakan, sehingga sulit dideteksi terlebih dahulu karena seluruh struktur kami terdiri dari 10.000 tautan yang sangat berlebihan. Mitra pusat data kami membantu membersihkan dan memasang ulang port alarm, dan kami menonaktifkan transceiver alarm yang tersisa sambil menunggu penggantian.

Meskipun InfiniBand tahan terhadap kegagalan perangkat keras, ketika sekitar 10% jaringan mulai rusak, fitur seperti perutean adaptif tidak berfungsi dengan baik untuk memperhitungkan hilangnya tautan yang sesekali terjadi.

Selama ini, kami berhasil menjalankan pelatihan multi-node menggunakan 100 hingga 200 mesin. Proses kami agak improvisasi: terkadang kami memutar sekumpulan node secara acak, mengamati kinerjanya, dan kemudian mencoba menjaga agar node tersebut tetap berjalan sebanyak mungkin. Metode ini memungkinkan kita menemukan subset struktur jaringan InfiniBand yang andal, namun sangat sulit karena setiap kali kita perlu mengubah kumpulan node yang digunakan untuk pelatihan, sehingga mengubah tautan default InfiniBand.

Langkah 4: InfiniBand terbakar hebat

Untuk mendiagnosis masalah InfiniBand dengan lebih efisien, kami merancang beban kerja untuk seluruh cluster yang mendorong data sebanyak mungkin melalui setiap port di fabric secara bersamaan. Hal ini berbeda dengan menjalankan beban kerja all-reduce yang besar di seluruh cluster, yang memerlukan penggunaan NCCL untuk mengoptimalkan komunikasi antar node individual dengan menggunakan NVLink untuk komunikasi GPU melalui slot Server PCIe Module (SXM).

Sebaliknya, kami memilih pendekatan brute force dan berhasil dengan mudah. UFM akan mulai mengeluarkan peringatan ketika volume transfer data pada sebagian besar port melebihi 97% dari kapasitas teoritis, dan beberapa switch akan mati untuk sementara. Setiap port yang kami pikir berhasil sampai pada akhirnya cukup kuat, dan sisanya dinonaktifkan atau dihapus sambil menunggu perbaikan.

Langkah 5: GPUDirect RDMA

Untuk memungkinkan komunikasi GPU tanpa menimbulkan overhead komputasi CPU, kami mengaktifkan fitur yang disebut GPUDirect RDMA, yang memungkinkan komunikasi langsung antara kartu jaringan InfiniBand. Ini melibatkan dua langkah utama:

1. Mulai modul kernel tambahan

2. Pastikan PCIe Access Control Service (ACS) dinonaktifkan untuk mencegah hang langsung (immediate hang)

Langkah 6: Perluas server “emas”.

Untuk membangun cluster GPU menggunakan perangkat keras terbaru, aturan praktisnya adalah bersiap menghadapi sekitar 3% mesin Anda yang gagal setiap minggunya.

Namun, perlu diperhatikan: tidak setiap mesin memiliki peluang kegagalan sebesar 3%, namun sejumlah kecil mesin yang tidak dirawat akan mengalami berbagai masalah berulang kali hingga diperbaiki dengan benar. Hal ini menyoroti keuntungan memiliki sejumlah besar mesin dalam struktur jaringan yang sama. Jadi, daripada hanya mencari mesin secara acak untuk menjalankan pelatihan skala besar, seperti whack-a-mole untuk melihat apa yang rusak, pendekatan kami adalah fokus pada penskalaan server yang dikenal dapat diandalkan, yaitu server “emas”.

Langkah 7: Pemeliharaan

Pemeliharaan InfiniBand terutama mencakup respons terhadap alarm UFM, penggantian kabel dan transceiver yang rusak, dan terkadang mendiagnosis kesalahan yang lebih sulit (seperti kegagalan sakelar). Biasanya ada dua faktor yang menyebabkan pemeliharaan skala besar:

1. Pembaruan firmware, terutama ketika hanya setengah dari klaster yang telah menyelesaikan pembaruan, dapat mengakibatkan status UFM rusak dan memerlukan restart UFM pada semua sakelar InfiniBand.

2. Kotak GPU dihidupkan ulang secara besar-besaran pada saat yang sama, yang mungkin memasukkan sejumlah besar pembaruan ke status UFM dan juga memerlukan memulai ulang layanan UFM.

Pastikan mesin benar-benar sehat

Selama proses tersebut, kami menemukan berbagai cara di mana masing-masing mesin dapat mengalami kegagalan fungsi atau memperlambat pelatihan. Banyak dari mode kegagalan ini tidak langsung terlihat, jadi kami menulis sejumlah skrip pemeriksaan kesehatan untuk memeriksa apakah host cukup sehat. Kami memublikasikan kodenya di sini: https://github.com/imbue-ai/cluster-health

Perhatikan bahwa banyak dari pemeriksaan kesehatan ini khusus untuk lingkungan runtime kami dan belum tentu terkait dengan perangkat keras yang mendasarinya, juga tidak mudah untuk diperbaiki atau diotomatisasi. Hal ini memang disengaja: untuk mencapai tujuan keseluruhan dalam mempersiapkan alat berat kami untuk pelatihan, kami menginginkan satu titik masuk yang dapat menjawab pertanyaan ya atau tidak secara langsung, dan dapat meringkas sejumlah detail penting.

Pemeriksaan kesehatan GPU

Kami memeriksa apakah jumlah GPU sudah benar, pemeriksaan ECC (Error Correction Code) diaktifkan, dan tidak ada kesalahan ECC. Kami juga memeriksa apakah topologi NVLink (yang menghubungkan GPU satu sama lain) aktif dan berjalan tanpa kesalahan.

Pemeriksaan kesehatan ruang disk

Kami memeriksa apakah pemanfaatan ruang disk host melebihi 95%.

Pemeriksaan kesehatan Docker

Kami memeriksa bahwa Docker dapat menjalankan container dengan GPU terhubung (yaitu, NVIDIA Container Runtime berfungsi dengan baik) dan bahwa container Docker yang terkait dengan pemantauan/analisis diaktifkan dan memiliki izin host yang benar.

Periksa kesehatan Dmesg

Kami memeriksa dmesg untuk kesalahan perangkat keras Xids atau SXid (kesalahan yang disebabkan oleh GPU NVIDIA atau sakelar antar-GPU NVIDIA). Kami juga membaca semua baris log dmesg untuk memverifikasi bahwa semuanya dapat diklasifikasikan ke dalam daftar Garis Log Umum/yang Diharapkan.

Pemeriksaan Kesehatan iDRAC

Kami memeriksa kesalahan iDRAC pada mesin, yang mengabaikan pesan kesalahan non-fatal. Ini adalah pemeriksaan khusus untuk komputer Dell, sehingga tidak disertakan dalam kode sumber terbuka kami.

Pemeriksaan kesehatan disk

Kami memeriksa apakah zpool telah terinstal, Docker terhubung dengan benar, dan ia benar-benar dapat menjangkaunya tanpa mengunci CPU.

Pemeriksaan Kesehatan InfiniBand

Kami memeriksa apakah tingkat kesalahan InfiniBand meningkat dan/atau apakah firmware driver sudah kedaluwarsa.

Pemeriksaan kesehatan Nvlink

Kami memeriksa kesalahan NVLink pada mesin. Dalam praktiknya, hal ini tampaknya tidak menyebabkan kegagalan pelatihan, namun mungkin memperlambat pelatihan.

Pemeriksaan kesehatan GDR

Kami memeriksa apakah GDR diaktifkan di mesin.

Pemeriksaan kesehatan VBIOS

Kami memeriksa apakah versi GPU VBIOS dan firmware alas tiang H100 sudah yang terbaru.

Pemeriksaan kesehatan batu api

Kami menggunakan flint dan hca_self_test untuk memeriksa apakah driver Mellanox OFED, firmware kartu jaringan, dan firmware transceiver memiliki versi yang benar, dan apakah semuanya dikompilasi dengan benar untuk driver NVIDIA.

Pemeriksaan kesehatan PSB

Kami menanyakan perangkat PCIe untuk memeriksa apakah kecepatan dan lebar koneksi antara GPU, PSB (PCIe Switch Bus) dan kartu jaringan sesuai dengan yang kami harapkan. Kami juga memeriksa apakah firmware sakelar sudah yang terbaru. Skrip ini dikembangkan oleh Dell, bukan Imbue, jadi kami tidak dapat membagikannya saat ini.

Selain pemeriksaan kesehatan cepat tersebut, kami juga menjalankan beberapa pemeriksaan kesehatan yang lebih kompleks, antara lain:

Inisialisasi penghitungan matriks melalui PyTorch, dan ukur bandwidth NVLink serta kecepatan penghitungan GPU dan memori. Kami menetapkan flag GDR yang sesuai untuk menguji InfiniBand dan NVLink.

Gunakan ib_write_bw dan –use_cuda untuk mengirim data melalui kartu IB dan mengukur bandwidth kartu PCIe dan InfiniBand. Proses ini memakan waktu lama (sekitar 15 menit) untuk memastikan link InfiniBand yang berkibar ditemukan.

Jalankan proses diagnostik multi-node untuk memeriksa kemampuan inisialisasi NCCL dan apakah terhenti secara acak. Jika ada jeda, kode NCCL bercabang kami menambahkan logging tambahan. Proses ini memerlukan waktu 12 hingga 24 jam untuk mendeteksi masalah, jadi kami biasanya hanya menjalankannya pada node baru atau saat kami mencurigai adanya masalah.

Periksa ekspor DCGM untuk mengetahui adanya peristiwa pembatasan jam GPU (tidak termasuk gpu_idle dan power_cap yang diharapkan). Untuk memeriksa peristiwa daya ini, cara terbaik adalah dengan menjalankan pelatihan multi-node yang memeriksa semua GPU, kartu InfiniBand, serta CPU dan disk secara bersamaan.

Diagnosis masalah pelatihan umum

Setelah perangkat keras berfungsi dengan baik, pelatihan dapat dimulai.

Bagian ini akan membagikan beberapa langkah dan wawasan debugging spesifik berdasarkan pengalaman kami menjalankan pelatihan model bahasa besar di cluster kami.

Kecelakaan saat startup

Di satu sisi, ini adalah bug terbaik yang dapat Anda temui karena (secara teoritis) mudah untuk direproduksi dan diulangi.

Kami pertama kali memeriksa apakah kode kami berjalan pada versi, konfigurasi, dan variabel lingkungan yang benar. Meskipun mendasar, kami menganggap hal ini penting: memastikan bahwa proses pelatihan startup dapat direproduksi dan mudah diperiksa. Salah satu alasannya adalah abstraksi perantara seperti cache image Docker atau konfigurasi rahasia buram dapat menyebabkan kebingungan.

Pemeriksaan dasar lainnya yang kami lakukan adalah memastikan bahwa semua mesin sedang online dan jejak tumpukan atau log yang dikeluarkan dapat dengan mudah dikumpulkan dan diperiksa. Kami menggunakan tumpukan perangkat lunak Loki, Prometheus, dan Grafana, tetapi agregasi log atau alat SaaS pelacakan apa pun bisa digunakan. Karena proses pelatihan ini bersifat sinkron dan terdistribusi, kesalahan pertama sering kali menyebabkan serangkaian kesalahan yang tidak terkait. Di sini, pemeriksaan kesehatan juga dapat membantu mendeteksi kesalahan dengan segera seperti hard drive yang rusak atau GPU yang hilang atau tidak valid.

Kami membangun sistem yang secara otomatis memulai ulang jika terjadi kegagalan, yang menjadikan agregasi log dan kesalahan menjadi lebih penting untuk menghindari kesalahan yang membingungkan dari permulaan ulang yang berbeda. Beberapa kesalahan umum yang kami temui meliputi:

1. Kesalahan seperti "Urutan maju berbeda antar peringkat: peringkat 0 mengumpulkan 43 parameter, sedangkan peringkat 1228 mengumpulkan 1 parameter". Kami menemukan ini sebagai fitur aneh dari implementasi Fully Sharded Data Parallel (FSDP) PyTorch, yang diselesaikan dengan restart.

2. Kesalahan GPU kehabisan memori (OOM), yang terlihat seperti ini: "CUDA kehabisan memori. Mencoba mengalokasikan..." Dengan memeriksa konfigurasi dan kode kami beberapa kali dan membatalkan modifikasi kode terbaru (karena spesifikasi perangkat PyTorch yang salah selama startup dan mengakibatkan penggunaan GPU #0 yang berlebihan), kami memperbaiki masalah ini.

3. Kesalahan CPU/RAM Out of Memory (OOM). Kesalahan ini tidak mudah ditemukan di log kesalahan dan biasanya dapat dideteksi melalui log dmesg host di luar wadah Docker. Ketika OOM Killer memanggil untuk menghentikan proses bercabang atau rekan jaringan, kita dapat melihat bahwa mereka terutama bermanifestasi sebagai CalledProcessError atau ConnectionError. Ketika panggilan OOM Killer terdeteksi dari dmesg, kami memilih untuk mengabaikan pemeriksaan kesehatan dan mem-boot ulang kotak tersebut. Kami juga memeriksa jalur kode kami untuk pengumpulan sampah manual yang memadai (ada bagian di bawah tentang cara menonaktifkannya), dan juga memeriksa setiap upaya tak terduga untuk melakukan komputasi atau memindahkan tensor ke CPU.

Kecelakaan saat latihan

Prioritas pertama adalah mengotomatiskan sistem sehingga dapat menjalankan kembali semua pemeriksaan kesehatan secara otomatis dan kemudian memulai ulang jika tidak ditemukan host yang tidak sehat. Kami menemukan beberapa kesalahan perangkat keras acak, termasuk kesalahan Xid dan SXid; kesalahan ini dapat menyebabkan proses terhenti tanpa mengeluarkan jejak tumpukan Python yang berarti. Beberapa masalah, seperti pemetaan ulang baris, dapat dipulihkan dengan melakukan boot ulang. Masalah lain, seperti kesalahan ECC yang tidak dapat diperbaiki, sering kali memerlukan pemeliharaan perangkat keras atau penggantian suku cadang.

Selain itu, kami mengamati bahwa format data pelatihan yang salah juga dapat menyebabkan error. Misalnya, jika ada satu dokumen yang sangat besar di korpus, hal ini dapat menyebabkan kesalahan kehabisan memori pada GPU atau CPU. Untuk mencegah masalah ini, kami menggunakan pemuat data yang sepenuhnya deterministik - membuat setiap error dapat direproduksi dengan mudah dengan dikaitkan pada suatu periode atau nomor langkah. Kami menemukan bahwa menonaktifkan pemuatan data atau mengganti data palsu (seperti data yang semuanya nol) membantu mengonfirmasi apakah akar penyebab kesalahan adalah data.

Terakhir, mencatat statistik kesehatan jaringan dan node umum melalui metode agregasi metrik juga dapat membantu. Masalah seperti terputusnya koneksi Ethernet dalam waktu singkat atau ruang disk yang rendah mungkin tidak muncul sebagai pesan kesalahan yang berguna, namun dapat dengan mudah dihubungkan dengan data yang dikumpulkan.

Hang tanpa jejak tumpukan (mungkin akan mengalami masalah batas waktu nanti)

Karena kurangnya informasi bermanfaat mengenai masalah ini dan sulitnya mereproduksi masalah tersebut secara andal, melakukan debug pada jenis kesalahan ini dapat membuat frustasi.

Salah satu jenis kesalahan yang paling berkesan disertai dengan pesan kesalahan seperti ini:

Pengawas menangkap batas waktu operasi kolektif: WorkNCCL (SeqNum=408951, OpType=_ALLGATHER_BASE, … , Batas Waktu (ms)=600000) berjalan selama 600351 milidetik sebelum batas waktu habis

Dan semua pekerja GPU yang sedang menjalankan pelatihan mengeluarkan pesan kesalahan seperti itu.

Ini berarti satu atau lebih host gagal menyelesaikan operasi NCCL atau koneksi NCCL dan InfiniBand terhenti, menyebabkan semua host lain terjebak pada operasi tensor pada saat yang sama hingga batas waktu NCCL_TIMEOUT tercapai. Sayangnya, karena sifat dari perpustakaan perangkat lunak NCCL, sulit untuk menemukan host mana yang mengalami masalah.

Kami telah melakukan beberapa modifikasi pada pencatatan perpustakaan perangkat lunak NCCL, lihat versi bercabang kami: https://github.com/boweiliu/nccl. Hal ini mungkin dapat mengungkapkan pesan atau operasi yang dilakukan ketika terjadi kerusakan dengan lebih baik, dan dengan demikian menentukan host atau GPU mana yang mungkin mencegahnya berjalan.

Perhatikan bahwa untuk mengidentifikasi host yang berperilaku buruk, kita sering kali perlu mencari tahu host mana yang tidak menghasilkan pesan log tertentu. Tidak adanya pesan tersebut menunjukkan bahwa pekerja di host ini tertinggal atau mengalami crash.

Situasi tidak responsif lainnya tanpa pesan kesalahan yang tersedia biasanya terkait dengan masalah terkait perangkat keras, seperti kesalahan Xid/SXid/ECC yang disebutkan sebelumnya yang menyebabkan driver NVIDIA atau driver komunikasi NVIDIA Docker terkunci. Untuk membedakan NCCL hang dari driver hang dan kondisi balapan atau kebuntuan dalam kode Python, kami menggunakan alat seperti Py-Spy dan GNU Project Debugger (GDB) untuk men-debug proses yang terhenti secara real-time. Satu masalah spesifik ditemukan menggunakan pendekatan ini: karena kesalahan konfigurasi dalam pengaturan thread Python, kami tidak dapat meluncurkan dengan benar delapan proses GPU NCCL multi-thread pada beberapa host, yang mengalami kondisi balapan pada tahap kode inisialisasi sebelum PyTorch.

Perlambatan latihan (diukur dengan MFU)

Kurangnya alat membuat masalah seperti ini lebih membuat frustrasi dibandingkan masalah sebelumnya. Selain menggunakan Py-Spy, inspeksi pelacakan tumpukan, dan GDB, kami juga menggunakan NVIDIA Nsight dan alat pembuatan profil, beberapa di antaranya sulit digunakan dalam pengaturan yang sangat terdistribusi.

Sayangnya, ada banyak alasan yang menyebabkan perlambatan umum atau kecepatan lebih rendah dibandingkan model pemanfaatan floating point (MFU) yang ditunjukkan sebelumnya.

Pertama, memeriksa konfigurasi, kode, dan variabel lingkungan beberapa kali ternyata berguna. Kesalahan yang kami alami antara lain menjalankan model yang salah, ukuran batch yang salah, pengaturan UFM atau NCCL yang salah, kesalahan CUDA_DEVICE_MAX_CONNECTIONS. Hal ini akan mengakibatkan kinerja kurang optimal.

Kami juga merasa berguna untuk mengukur MFU sesaat (yaitu, per batch) (daripada rata-rata yang dihaluskan atau dijendelakan), karena kurva MFU yang tidak dihaluskan sering kali membantu mendiagnosis kelas masalah. Masalah yang menyebabkan pelatihan melambat antara lain:

Mulai pelatihan segera dari MFU yang sangat rendah (kurang dari sepersepuluh dari yang diharapkan) dan tetap stabil

Kemungkinan besar ini adalah masalah perangkat keras pada koneksi jaringan InfiniBand, seperti sakelar lapisan T2 atau T3 yang mogok. Masalah perangkat keras antara GPU dan NIC juga dapat menyebabkan situasi ini, sehingga dmesg akan melaporkan kesalahan seperti ini: Jalur PCIe x16 dibatasi oleh…

Mulai pelatihan segera dari 30% MFU yang diharapkan dan pertahankan

Hal ini dapat disebabkan oleh pengaturan GDR yang salah pada satu host (memori rekan NVIDIA) atau variabel lingkungan GDR yang salah.

Mulai pelatihan segera dari sekitar 60-80% MFU yang diharapkan dan pertahankan dengan stabil

Penyebab paling umum adalah kualitas tautan InfiniBand yang buruk atau salah, khususnya kegagalan terkait NIC InfiniBand pada satu GPU, menyebabkan NCCL mencoba merutekan lalu lintas melalui NVLink asli dan menggunakan NIC pada GPU lain di host yang sama. Pelambatan CPU juga dapat menyebabkan masalah ini, yang memerlukan penyesuaian pengaturan BIOS pada beberapa host.

Terjadi perlambatan besar secara tiba-tiba (turun 10x) saat memproses kumpulan data tertentu, dan ini cukup sering terjadi

Pada dasarnya ini semua tentang pos pemeriksaan atau evaluasi - ini dapat diverifikasi dengan memeriksa jumlah zaman atau langkah. Yang menjengkelkan, jika Anda mengatur alarm otomatis ketika MFU tidak normal, banyak alarm palsu yang akan muncul.

Perlambatan besar secara tiba-tiba (penurunan 10x) saat memproses kumpulan data tertentu

Hal ini terjadi secara acak dan cukup jarang (kira-kira sekali setiap 15 menit), dan segera diikuti dengan pengembalian penuh ke MFU yang baik.

Penyebab paling umum tampaknya adalah beban kerja intensif CPU lainnya dijadwalkan ke host yang sedang berjalan. Kami menemukan bahwa daripada membuat alat pembuatan profil untuk mengidentifikasi host tertentu, lebih mudah untuk memantau CPU secara kasar dengan PID. Penyebabnya mungkin adalah masalah konektivitas jaringan yang terjadi sesekali, seperti kemacetan pemuat data. Kami memantau pemuatan data, pos pemeriksaan, dan metrik untuk kode non-NCCL apa pun dan menambahkan log waktu kode Python, yang terbukti sangat andal.

MFU secara bertahap melambat selama pengoperasian, tetapi kembali ke 100% setelah setiap reboot

Secara teori, penyebabnya mungkin adalah penumpukan panas pada saklar, namun kita belum pernah melihat hal ini terjadi. Namun, kami menggunakan profiler Python dan NVIDIA untuk menentukan bahwa penyebab penurunan kinerja tampaknya adalah pengumpulan sampah otomatis.

Saat men-debug pelambatan ini, kami menemukan bahwa throughput hampir pasti turun secara berkala. Seiring berjalannya pelatihan, penurunan ini akan berdampak semakin besar pada komputasi terdistribusi. Hal ini membuat kami curiga bahwa penyebab penurunan tersebut mungkin terkait dengan pengumpulan sampah otomatis - sebuah dugaan yang kami verifikasi melalui analisis dan pengujian. Ketika kami menonaktifkan pengumpulan sampah otomatis dan mengatur pengumpulan sampah hanya pada interval tertentu di semua host, "penurunan" throughput ini menghilang.

Kami menggunakan algoritma pelatihan terdistribusi sinkron FSDP berdasarkan ZeRO-3. Selama operasi pemblokiran, satu proses pekerja yang menjalankan pengumpulan sampah mungkin memperlambat semua pekerja lainnya. Jika Anda memiliki ratusan proses pekerja, hal ini dapat menyebabkan perlambatan yang signifikan.

Performanya bagus pada awalnya, kemudian turun secara tiba-tiba (hingga 70% dari yang diharapkan) dan berlanjut pada frekuensi tinggi (setiap 15 detik)

Kami mengamati hal ini terkait dengan "alasan pelambatan jam" pada GPU NVIDIA, yang dapat diatasi dengan pengaturan yang sesuai untuk NVIDIA DCGM. Masalah termal (suhu GPU tinggi atau kegagalan kipas pendingin host/efektivitas berkurang) atau kegagalan catu daya dapat menyebabkan masalah ini. Selain itu, saat kami memaksimalkan 8 penggunaan GPU dan 8x penggunaan NIC InfiniBand bersama dengan CPU/RAM/disk, beberapa host kami dengan perangkat keras catu daya tertentu mengalami masalah voltase, namun hanya menggunakan semuanya (biasanya hanya pada saat ini. Ini hanya terjadi selama latihan sebenarnya).

Performa bagus namun lebih banyak noise dari biasanya (variasi white noise frekuensi tinggi antara 90% dan 100% dari MFU yang diharapkan)

Hal ini juga terkait dengan perangkat keras InfiniBand, namun biasanya disebabkan oleh penurunan kinerja atau jitter pada tingkat tertentu pada tautan yang lebih tinggi dalam jaringan, dibandingkan host yang tidak terlalu berlebihan pada lapisan T2.

Sayangnya, banyak dari masalah ini sulit untuk ditentukan pada host tertentu, dan masalah terkait InfiniBand sangat sulit untuk ditentukan karena sifat teknologi switch InfiniBand yang sadar akan topologi. InfiniBand tampaknya lebih menyukai host yang berdekatan dalam desain pohon lemak InfiniBand, sementara UFM dapat merutekan paket dengan kecepatan tautan asimetris.

Berikut ini adalah ringkasan sederhana/diagram alur/daftar periksa kelengkapan untuk men-debug masalah throughput:

Apakah sistem ini berfungsi dengan baik sebelumnya?

Perubahan apa yang baru-baru ini Anda lakukan (seperti menggabungkan kode, memperbarui driver)?

Apakah tuan rumah yang Anda jalankan sehat? Apakah semua layanan dependen Anda berjalan normal, termasuk SaaS pihak ketiga, seperti Docker Hub, GitHub, dll.?

Dapatkah Anda yakin bahwa kode, lingkungan, konfigurasi, versi, daftar host, urutan peringkat, dan benih acak yang Anda jalankan sekarang sama persis dengan yang terakhir kali? (Jika pemeriksaan seperti itu dapat diterapkan.)

Apakah masalahnya dapat direproduksi?

Bagaimana hubungannya dengan hal lain? Proses lainnya? Tugas terjadwal crontab harian? Indikator host atau DCGM atau UFM?

Apakah alat Anda mengukur metrik ini dengan benar?

Apakah masalah tetap ada saat menjalankan versi kode yang disederhanakan (menggunakan model yang lebih kecil, data palsu, tidak ada titik pemeriksaan penyimpanan atau pemuatan)?

Meningkatkan alat infrastruktur

Setelah Anda menyelesaikan langkah-langkah di atas, Anda akan segera mencapai performa yang baik saat melatih model Anda... setidaknya sampai ada yang rusak.

Bagian ini memperkenalkan beberapa alat dan sistem yang digunakan untuk memastikan pelatihan yang konsisten, dan idealnya memerlukan intervensi manusia sesedikit mungkin. Karena kami adalah tim kecil, kami tidak memiliki cukup tenaga untuk melakukan perbaikan manual, jadi kami juga ingin mengotomatiskan proses ini semaksimal mungkin.

Hampir semua masalah yang kita temui selama pelatihan dapat disebabkan oleh kegagalan komponen mesin atau jaringan. Jenis kegagalan ini umum terjadi pada klaster besar, jadi pendekatan kami adalah menonaktifkan mesin dan komponen jaringan yang gagal secara otomatis dan mengirimkan permintaan perbaikan.

kerusakan mesin

Kami mengembangkan sistem yang secara otomatis memulai ulang dari pos pemeriksaan terbaru jika proses terhenti. Pada proses restart ini, setiap mesin yang tersedia terlebih dahulu diperiksa kesehatannya, kemudian setiap mesin diklasifikasikan berdasarkan hasil pemeriksaan kesehatan yang dilewatinya, kemudian dilakukan upaya untuk memulai kembali pelatihan pada mesin yang paling sehat.

Kegagalan komponen jaringan

Semua kegagalan jaringan yang kami amati terdeteksi oleh UFM dan dicatat ke log peristiwa UFM, sehingga responsnya sederhana: parsing log UFM dan ambil tindakan yang sesuai.

Sistem acara UFM sangat kompleks dan berisi lusinan jenis acara. Namun dalam praktiknya, kami menemukan bahwa hanya sedikit kejadian yang bermasalah, terutama terkait dengan kegagalan tautan atau teknik kesalahan simbol yang tinggi. Setelah mengidentifikasi peristiwa ini, kita dapat menulis skrip untuk mengurai log peristiwa UFM, menonaktifkan tautan dan port yang terkait dengan peristiwa terkini, meminta perintah kerja pemeliharaan untuk komponen jaringan ini, dan mengaktifkan kembali komponen ini setelah pemeliharaan selesai.

sistem file cermin lokal

Untuk pelatihan terdistribusi besar ini, telah lama diketahui bahwa kecepatan pertukaran data antara cluster dan Ethernet merupakan hambatan. Bandwidth koneksi Ethernet bersama kira-kira 10Gbit/s; bandwidth ini dapat menjadi jenuh dengan cepat jika ratusan pekerja mengunduh kumpulan data dan memodelkan pos pemeriksaan secara bersamaan.

Untuk tujuan ini, kami memutuskan untuk membangun sistem file lokal di dalam cluster kami sebagai cermin untuk penyimpanan cloud, yang pada dasarnya adalah ruang cache yang dapat mengurangi jumlah file yang dibaca dari S3. Untuk memperhitungkan churn cluster (yaitu, ketika mesin dinonaktifkan atau diganti karena alasan pemeliharaan), kami memiliki tiga salinan dari setiap file dan menggunakan hashing yang konsisten untuk mendistribusikan beban secara merata guna memaksimalkan kinerja selama churn cluster. Karena cluster memiliki ruang disk yang terbatas, kami harus mengembangkan alat untuk melacak siklus hidup file dan membersihkan file yang tidak lagi berguna.

Registri Docker terdistribusi lokal

Kami menggunakan Kraken, yang merupakan perangkat lunak sumber terbuka yang bagus untuk mentransfer gambar Docker secara point-to-point. Kami hampir tidak mengalami masalah dengan perangkat lunaknya, dan hal ini cukup mengejutkan kami, mengingat kompleksitas tugas dan implementasi kami. Alamat alat: https://github.com/uber/kraken

Berbagai alat pemantauan kinerja

Kami menyiapkan penganalisis Torch default dan Sistem Nsight NVIDIA. Hal terakhir ini membantu kami memahami waktu pasti yang diperlukan untuk jalur maju/mundur dan komunikasi NCCL, dan selanjutnya membantu kami menentukan apakah ukuran model dan jumlah pekerja tertentu akan menjadi hambatan. Namun, Nsight Systems agak sulit digunakan karena memerlukan menjalankan Docker dalam mode istimewa, yang mengharuskan penonaktifan pemeriksaan keamanan terkait dengan peristiwa pemantauan kinerja, dan menyimpan konfigurasinya sering kali memerlukan penghentian seluruh proses pelatihan.

Selain itu, kami telah menulis alat untuk mendeteksi kumpulan pelatihan yang lambat dan memahami kemungkinan penyebabnya. Kami menemukan ini berguna. Alat yang paling berguna memantau berapa lama waktu yang dibutuhkan setiap batch dan membuang jejak tumpukan pekerja jika batch terlalu lambat - sehingga lebih mudah untuk menemukan host dengan masalah kecil pada perangkat keras atau perangkat lunak.

Bagilah mesin menjadi beberapa kelompok untuk menemukan host yang gagal

Dalam beberapa bulan pertama penggunaan cluster (saat pemeriksaan kesehatan belum selengkap sekarang), kami sering menghadapi situasi di mana terjadi kegagalan saat melakukan pelatihan pada sekelompok mesin, namun tidak jelas mesin mana yang bermasalah. . pertanyaan. Untuk menemukan host yang salah, kami mengembangkan alat yang memudahkan untuk membagi sekumpulan mesin ke dalam kelompok yang berbeda dan menjalankan pelatihan yang lebih kecil pada setiap kelompok mesin.

Misalnya, jika pelatihan yang dijalankan pada 48 mesin gagal, jalankan pelatihan yang lebih kecil pada 6 grup yang masing-masing terdiri dari 8 mesin, lalu jalankan pelatihan yang lebih kecil pada 8 grup yang masing-masing terdiri dari 6 mesin. Biasanya, hanya satu kali pengoperasian dari dua fase yang akan gagal, sehingga memberikan kita keyakinan untuk menyimpulkan bahwa mesin yang gagal pada kedua fase tersebut adalah mesin yang rusak.

Refleksi dan pembelajaran

Selama proses menyiapkan dan memelihara infrastruktur, kami memperoleh beberapa pembelajaran bermanfaat:

Salah satu pendekatan yang berguna adalah menukar lokasi mesin. Saat runtime, sebaiknya gunakan mesin 10-20% lebih banyak dari yang diperlukan sehingga pelatihan dapat dengan mudah dimulai ulang jika terjadi kegagalan mesin. Menyiapkan jaringan cluster sehingga setiap mesin terhubung erat ke setiap mesin lainnya memungkinkan kita menggunakan subset apa pun yang berfungsi dari mesin tersebut.

Ada gunanya menulis tes dan solusi otomatis untuk setiap kegagalan perangkat keras atau perangkat lunak yang Anda temui, karena setiap masalah yang ditemui dalam pelatihan akan terulang kembali. Demikian pula, untuk setiap pesan kesalahan yang ambigu, ada baiknya menulis alat yang dapat menjelaskan kesalahan tersebut dengan lebih baik.

Reproduksibilitas adalah kunci penelitian ilmiah yang baik. Salah satu prinsip besar yang langsung kami adopsi adalah: "Ubahlah satu hal saja dalam satu waktu," bahkan dalam hal yang paling sederhana.

Percaya, tetapi juga verifikasi. Setiap kali kami mendatangkan alat eksternal atau merekrut orang baru (baik dari dalam atau luar perusahaan), kami memeriksa ulang klaim mereka, terutama jika langkah selanjutnya bergantung pada klaim tersebut.

Meringkaskan

Melatih model bahasa besar memerlukan infrastruktur yang kompleks sejak awal. Kami memilih untuk terlibat secara mendalam dalam detail penyiapan infrastruktur karena kami yakin penting untuk memahami sepenuhnya sistem yang kami operasikan, dan karena kami yakin akan lebih efisien jika melakukannya.

Kini, setelah melalui prosesnya, kami senang telah mengambil pendekatan ini - memiliki kendali penuh atas infrastruktur kami dan kemampuan untuk melakukan debug dengan mudah di setiap tingkat abstraksi telah terbukti memiliki nilai yang sangat penting. Meskipun proses ini memerlukan banyak pengawasan dan pengulangan, hal ini memungkinkan kami memperoleh pemahaman mendalam tentang alur kerja yang mendasarinya, membangun seperangkat alat untuk memastikan kesehatan host, mempelajari cara mengotomatisasi sistem untuk memastikan kelancaran pelatihan yang berkelanjutan, dan pada akhirnya membangun sebuah Seperangkat infrastruktur yang memungkinkan kami melatih model bahasa mutakhir dengan cepat dan berulang.

Proses pembangunan infrastruktur ini mencerminkan metodologi dasar kami dalam meneliti dan membangun agen AI: mengeksplorasi detailnya, terus meningkatkan proses yang ada, dan membangun alat dan sistem yang berguna untuk memungkinkan tim kami termotivasi dalam mengatasi tantangan yang lebih besar.