Penyiapan infrastruktur dan skrip open source untuk melatih model 70B di bare metal

 (imbue.com)
1 poin oleh GN⁺ 2024-06-29 | 1 komentar | Bagikan ke WhatsApp
  • Imbue melatih model 70B parameter dari nol dengan tim kecil di infrastruktur bare metal miliknya sendiri, dan memublikasikan prosedur operasional serta skrip mulai dari pembangunan klaster hingga pemulihan kegagalan
  • Klaster terdiri dari 4.088 GPU H100 dan 511 server GPU; 8 GPU per server berpartisipasi dalam pelatihan sinkron skala besar melalui InfiniBand
  • Implementasi nyatanya merupakan proses berulang yang mencakup provisioning mesin individual, penataan fabric InfiniBand, health check host, diagnosis error pelatihan, dan peningkatan otomasi; mereka harus menangani sekitar 10% mesin yang gagal boot serta banyak peringatan port
  • Tool yang dirilis mencakup health check host, patch logging NCCL, stress test GPU, pengujian jaringan NVLink·InfiniBand, parser log event UFM, serta skrip pembuat workload burn-in InfiniBand
  • Dalam pelatihan LLM skala besar, satu host atau link yang tidak stabil bisa memperlambat seluruh run, sehingga health check otomatis·isolasi kegagalan·restart·penonaktifan port menjadi inti operasi berkelanjutan

Membangun klaster untuk melatih model 70B sendiri

  • Imbue selama beberapa bulan melatih model 70B parameter dari nol di infrastruktur miliknya sendiri, dan model ini mengungguli zero-shot GPT-4o pada tugas terkait penalaran
  • Cakupan yang dipublikasikan adalah prosedur infrastruktur end-to-end yang mencakup boot awal klaster, instalasi OS, hingga pemulihan error otomatis selama pelatihan
  • Tool infrastruktur yang turut dirilis adalah sebagai berikut
    • Host-level health checks: skrip untuk memastikan host dapat digunakan dalam pelatihan tanpa error yang diketahui
    • Patch NCCL: ditingkatkan agar meninggalkan lebih banyak log pada situasi error dan hang
    • GPU stress test: memverifikasi apakah GPU dapat mengalokasikan tensor besar dan menjalankan operasi standar
    • Networking tests: memeriksa komunikasi NVLink antar-GPU pada mesin yang sama dan komunikasi InfiniBand antar-GPU di mesin berbeda
    • UFM event log parser: mem-parse log event Unified Fabric Manager untuk menentukan port jaringan yang perlu dinonaktifkan
    • InfiniBand burn-in workload generator: membuat workload burn-in InfiniBand yang memberi stress pada semua link yang tersedia

Konfigurasi klaster dan jaringan

  • Klaster inti menempatkan 4.088 GPU H100 pada 511 server GPU, dengan masing-masing server memuat 8 GPU
  • Alasan jumlah server GPU 511 adalah karena sebagian koneksi harus dicadangkan untuk node Unified Fabric Manager(UFM) yang mengelola jaringan InfiniBand
  • Setiap GPU terhubung langsung ke kartu ConnectX-7, dan dapat mengirim serta menerima 400Gbps secara simultan dengan GPU lain di jaringan InfiniBand melalui kartu ConnectX-7 miliknya sendiri
  • Topologi InfiniBand adalah struktur fully non-blocking di mana secara teori semua GPU dapat berkomunikasi secara simultan dengan GPU lain pada kecepatan maksimum
    • Arsitektur switch InfiniBand 3 tahap menyediakan throughput jaringan keseluruhan
    • Komunikasi pelatihan dilakukan di InfiniBand, bukan Ethernet
  • Ethernet digunakan untuk dataset, checkpoint, dan transfer data lainnya
    • Jika komunikasi pelatihan dikirim melalui Ethernet, data harus berpindah dari GPU ke CPU lalu keluar lewat kartu Ethernet 100Gbps, sehingga jauh lebih lambat
    • Pelatihan melalui Ethernet juga dimungkinkan dengan RoCE, tetapi membutuhkan banyak pekerjaan tambahan di sisi hardware dan software, dan umumnya kurang andal dibandingkan InfiniBand
  • Jaringan Ethernet manajemen terpisah digunakan untuk akses ke BIOS, power supply, dan controller antarmuka mesin level rendah
    • Tanpa jaringan manajemen ini, ratusan mesin harus dikonfigurasi secara manual dengan USB drive, keyboard, dan monitor
  • Dalam pelatihan performa tinggi skala besar, InfiniBand, Ethernet, GPU, dan node harus bekerja hampir sempurna
    • Bahkan satu saja dari lebih dari 12.000 koneksi yang tidak stabil dapat memperlambat seluruh run pelatihan

Provisioning mesin individual

  • Setelah membuat koneksi Ethernet ke klaster melalui jaringan manajemen awal, mereka memperoleh kredensial akses BMC(Baseboard Management Controller)
    • BMC adalah service processor untuk memantau host dari jarak jauh
    • BMC menyediakan status hardware, pengaturan BIOS, dan API manajemen daya
  • Server pertama diinstal Ubuntu 22.04 secara manual melalui iDRAC, BMC milik Dell
    • Mereka dapat me-mount image ISO dari komputer lokal untuk boot, dan iDRAC menyediakan konsol virtual berbasis browser
    • Tujuannya adalah menjadikan instalasi manual ini sebagai satu-satunya instalasi manual di seluruh proses

  • MAAS dan boot PXE

    • Setelah mesin pertama siap, mereka memasang Ubuntu MAAS(Metal-as-a-Service) untuk mem-provision server lainnya
    • Dengan boot PXE dan tool iDRAC otomatis, setiap mesin diperintahkan untuk boot dari jaringan
    • Server menerima IP dari MAAS melalui DHCP, mengunduh kernel awal, lalu secara otomatis melakukan instalasi OS permanen meskipun drive lokal masih kosong
    • Dalam praktiknya, integrasi MAAS dan BMC tidak stabil, sehingga mereka mengumpulkan terlebih dahulu alamat MAC semua mesin melalui API iDRAC
    • MAAS secara umum dapat diandalkan selama seluruh proses pelatihan, tetapi pada awalnya ada masalah yang spesifik pada konfigurasi
      • Perbedaan clock yang besar menyebabkan verifikasi sertifikat HTTPS gagal dan menghambat instalasi apt
      • Server MAAS sekaligus berperan sebagai DHCP, DNS, proxy HTTP, NTP, pengelola konfigurasi cloud-init, serta database acuan untuk MAC·IP·hostname·metadata, sehingga penelusuran penyebab menjadi sulit

  • Kegagalan boot dan observabilitas dasar

    • Seperti lazimnya dalam setup klaster GPU skala besar, sekitar 10% mesin gagal boot, dengan penyebab utama berupa masalah fisik pada server
      • Kabel Ethernet tidak tersambung atau salah wiring
      • Masalah hardware iDRAC
      • Kerusakan power supply
      • Drive NVMe bermasalah
      • Wiring internal hilang
      • Kartu jaringan atau GPU tidak terdeteksi
    • Imbue mengotomatiskan pemeriksaan untuk masalah-masalah ini, menyerahkan sebagian mesin untuk diperiksa ulang oleh Dell, dan membuat tiket yang diperlukan untuk staf data center
    • Karena menjalankan sendiri setup infrastruktur, mereka dapat langsung menggunakan mesin yang sehat sembari menunggu perbaikan
    • Di semua server, mereka memasang Docker, driver GPU data center, Prometheus node exporter, NVIDIA DCGM exporter, serta pool RAIDZ ZFS di seluruh drive selain OS
    • ZFS memungkinkan mesin tetap bertahan meski satu drive turun, dan kompresi transparannya secara signifikan mengurangi ruang penyimpanan untuk dataset teks biasa dan log berulang
    • Saat memasang paket software secara paralel di 400 node, terjadi bottleneck bandwidth
    • Peringatan suhu tinggi awalnya muncul di beberapa komponen deployment data center, dan masalah termal awal sebagian besar diredakan dengan pembaruan firmware

  • Verifikasi pelatihan GPU node tunggal

    • Mereka memastikan setiap mesin secara independen mampu menangani workload GPU nyata
    • Beberapa mesin gagal dalam pelatihan GPU node tunggal karena masalah berikut
      • Error terkait GPU sebagian besar diselesaikan dengan memasang ulang kartu pada slotnya
      • Di log server Ubuntu, koneksi PCIe muncul sebagai limited width: x4 < x16
      • Bahkan setelah pembaruan firmware bus PCIe switch, sekitar seperempat host di klaster harus dipasangi ulang kabel PCIe internalnya
      • Ada drive NVMe yang tidak ditandai rusak, tetapi mengunci seluruh mesin saat diakses
      • Urutan hard disk di Linux tampil acak, sehingga MAAS memasang OS ke drive yang salah
      • Pembacaan suhu yang salah membuat kipas selalu berputar 100%
      • Dynamic frequency scaling CPU membatasi core aktif ke 2GHz
      • Gagal menerapkan GDR, yaitu GPUDirect RDMA Peer Memory Client

Provisioning InfiniBand

  • Berkat desainnya yang tersentralisasi, InfiniBand memiliki satu entitas pengendali untuk seluruh jaringan, dan 320 switch jaringan dapat diperlakukan sebagai satu fabric
  • Tugas pertama adalah memahami switch mana yang terhubung ke mesin mana, lalu mencocokkannya dengan diagram pengkabelan dan mengganti nama switch berdasarkan lokasi fisiknya

  • Desain fabric yang keliru dan pengkabelan ulang

    • Pada awalnya, UFM tidak dapat mendeteksi 320 switch jaringan, dan juga tidak menemukan host yang seharusnya ada di fabric
    • Setelah dikonfirmasi dengan mitra data center, switch sudah menyala dan sudah dikabelkan, tetapi tidak terdeteksi
    • Saat daftar pengkabelan jaringan ditelusuri, fabric tingkat atas ternyata bukan satu fabric terpadu, melainkan terdiri dari 8 jaringan terpisah tanpa jalur routing bersama
    • Setelah pengkabelan ulang, ditambahkan pemeriksaan untuk memastikan semua koneksi fisik sesuai dengan desain baru

  • Peringatan suhu dan error port

    • Setelah masalah pengkabelan fisik diselesaikan, UFM terhubung ke semua switch InfiniBand, tetapi hampir semua port switch melaporkan suhu yang terlalu tinggi
    • Bahkan sebelum transfer data sebenarnya, beberapa port sudah melampaui 70 derajat Celsius; penyebabnya adalah struktur yang membuat udara panas bersirkulasi kembali ke sisi depan melalui ruang kosong di antara switch pada rack jaringan
    • Banyak port menunjukkan tingkat error yang tinggi atau mengalami link flapping, yaitu berpindah-pindah antara kondisi normal dan rusak; masalah ini hanya muncul saat port benar-benar digunakan sehingga sulit dideteksi sebelumnya
    • Seluruh fabric memiliki 10.000 link dan redundansi tinggi, tetapi ketika sekitar 10% fabric bermasalah, fitur seperti adaptive routing pun tidak cukup mampu menghindari link yang terputus-putus secara tidak teratur
    • Mitra data center membersihkan dan memasang ulang port yang memberi peringatan, sementara transceiver peringatan lainnya yang menunggu penggantian dinonaktifkan
    • Pada periode ini, pelatihan multinode dilakukan dengan 100–200 mesin untuk menemukan subset InfiniBand yang stabil

  • Burn-in InfiniBand dan GPUDirect RDMA

    • Untuk mendiagnosis masalah InfiniBand dengan lebih efisien, dibuat workload khusus yang secara bersamaan mendorong sebanyak mungkin data ke semua port di seluruh fabric
    • Ini berbeda dari menjalankan satu all-reduce besar di seluruh klaster
      • Karena NCCL mengoptimalkan komunikasi internal dalam satu node melalui jalur NVLink dan socket SXM
    • UFM mengirim notifikasi transfer data lebih dari 97% kapasitas teoretis pada sebagian besar port, dan beberapa switch sempat crash sementara
    • Port yang tetap bertahan hingga akhir hari dianggap cukup tangguh, sedangkan sisanya dinonaktifkan atau diteruskan untuk diperbaiki nanti
    • GPUDirect RDMA diaktifkan agar GPU dapat berkomunikasi tanpa overhead CPU

  • Kumpulan mesin stabil dan pemeliharaan

    • Sebagai aturan praktis dari pengalaman dengan klaster GPU hardware terbaru, perlu diasumsikan bahwa sekitar 3% mesin akan rusak setiap minggu
    • Bukan berarti semua mesin memiliki peluang rusak 3% secara merata; sebagian mesin yang banyak bermasalah mengalami kerusakan berulang dalam berbagai cara
    • Dengan menempatkan banyak mesin pada fabric yang sama, alih-alih terus mengejar masalah mesin acak, kumpulan mesin golden yang diketahui stabil dapat diperbesar
    • Pemeliharaan InfiniBand terutama terdiri dari respons terhadap peringatan UFM, penggantian kabel dan transceiver, serta diagnosis switch yang bermasalah
    • Regresi skala besar biasanya terjadi karena dua faktor
      • Upgrade firmware yang hanya diterapkan pada separuh klaster merusak status UFM sehingga UFM perlu direstart pada semua switch InfiniBand
      • Jika banyak GPU box direstart sekaligus, update status UFM membanjir sehingga layanan UFM perlu direstart

Sistem pemeriksaan kesehatan host

  • Imbue menemukan berbagai kegagalan pada mesin tunggal yang membuat proses pelatihan gagal atau lambat, lalu menulis health check untuk menentukan host yang cukup sehat untuk pelatihan
  • Kodenya dipublikasikan di cluster-health
  • Banyak pemeriksaan bersifat spesifik untuk lingkungan runtime Imbue, tetapi tujuannya adalah mengembalikan jawaban yes/no dari satu titik masuk terkait kesiapan pelatihan

  • Health check cepat

    • GPU Health Check: memeriksa jumlah GPU, aktivasi ECC, error ECC, serta topologi dan error NVLink
    • Disk Space Health Check: memeriksa apakah penggunaan disk host tidak melebihi 95%
    • Docker Health Check: memeriksa apakah container yang terhubung ke GPU berjalan serta izin container monitoring dan profiling
    • Dmesg Health Check: mencari error Xid dan SXid dari GPU NVIDIA atau switch NVIDIA, serta memeriksa apakah baris log dmesg dapat diklasifikasikan ke daftar log yang dapat diperkirakan
    • iDRAC Health Check: memeriksa error iDRAC pada mesin Dell dan mengabaikan pesan error yang tidak fatal
      • Pemeriksaan ini bukan target publikasi open source
    • Disk Health Check: memeriksa mount zpool, koneksi Docker, dan apakah CPU hang saat mengakses disk
    • InfiniBand Health Check: memeriksa kenaikan tingkat error InfiniBand dan firmware driver yang lama
    • Nvlink Health Check: memeriksa error NVLink pada mesin
      • Secara empiris tidak menyebabkan kegagalan pelatihan, tetapi dapat memperlambatnya
    • GDR Health Check: memeriksa apakah GDR aktif pada mesin
    • VBIOS Health Check: memeriksa apakah versi VBIOS GPU dan firmware baseboard H100 sudah terbaru
    • Flint Health Check: dengan flint dan hca_self_test, memeriksa versi driver Mellanox OFED, firmware kartu, firmware transceiver, serta status kompilasi driver NVIDIA
    • PSB Health Check: menelusuri perangkat PCIe untuk memeriksa apakah kecepatan dan lebar koneksi antara GPU, PSB, dan kartu jaringan sesuai dengan yang diharapkan
      • Karena ini skrip yang dikembangkan Dell, saat ini tidak dapat dibagikan

  • Health check yang lebih panjang

    • Menginisialisasi komputasi matriks dengan PyTorch untuk mengukur bandwidth NVLink, kecepatan komputasi GPU, dan memori
    • Mengatur flag GDR untuk menguji InfiniBand dan NVLink sekaligus
    • Mengirim data ke kartu IB dengan ib_write_bw dan --use_cuda untuk mengukur bandwidth kartu PCIe dan InfiniBand
    • Dijalankan selama sekitar 15 menit untuk menangkap link InfiniBand yang flapping
    • Dengan menjalankan diagnosis multinode, memeriksa apakah NCCL dapat diinisialisasi dan apakah terjadi hang acak
      • Jika hang, kode NCCL yang di-fork meninggalkan log tambahan
    • Karena deteksi masalah dapat memerlukan 12–24 jam, ini terutama dijalankan pada node baru atau situasi yang mencurigakan
    • Memeriksa event throttle clock GPU dari DCGM exports, tetapi mengecualikan gpu_idle dan power_cap yang memang diperkirakan
    • Pelatihan multinode yang menggunakan semua GPU, kartu InfiniBand, CPU, dan disk secara bersamaan paling baik dalam menampakkan event daya

Mendiagnosis kesalahan umum selama pelatihan

  • Crash segera setelah mulai

    • Crash segera setelah mulai adalah kesalahan yang paling mudah ditangani karena relatif mudah direproduksi dan diulang
    • Pertama, periksa apakah versi kode, konfigurasi, dan variabel lingkungan sudah benar
    • Abstraksi perantara seperti caching image Docker atau konfigurasi secrets yang tidak transparan dapat mengaburkan identifikasi penyebab
    • Periksa juga apakah semua mesin online, serta apakah stack trace dan log dapat diagregasi dan diperiksa dengan mudah
      • Imbue menggunakan stack Loki, Prometheus, Grafana
    • Dalam eksekusi terdistribusi sinkron, kesalahan pertama sering memicu rangkaian kesalahan lanjutan yang tidak terkait
    • Saat membangun sistem eksekusi ulang otomatis, agregasi log dan kesalahan menjadi semakin penting agar log dan kesalahan dari eksekusi ulang yang berbeda tidak tercampur
    • Kesalahan yang sering terlihat adalah sebagai berikut
      • Forward order differs across ranks...: karena karakteristik implementasi PyTorch FSDP, dapat diselesaikan dengan eksekusi ulang
      • CUDA out of memory...: diselesaikan dengan memeriksa konfigurasi dan kode, serta melakukan rollback perubahan kode terbaru
      • CPU/RAM OOM: lebih baik dideteksi dari log dmesg host di luar container melalui pemanggilan OOM Killer

  • Crash di tengah pelatihan

    • Setelah hardware mulai berjalan, yang pertama dibutuhkan adalah sistem yang menjalankan ulang semua pemeriksaan kesehatan diagnostik dan melakukan restart otomatis dengan mengecualikan host yang tidak sehat
    • Kesalahan hardware acak seperti Xid dan SXid dapat membuat eksekusi crash tanpa stack trace Python yang bermakna
    • Sebagian instance seperti row remapping dapat dipulihkan dengan restart, tetapi kesalahan uncorrectable ECC biasanya membutuhkan pemeliharaan hardware atau penggantian komponen
    • Data pelatihan dengan format yang sangat buruk juga memicu crash
      • Satu dokumen yang sangat besar dalam korpus dapat menyebabkan GPU atau CPU OOM
      • Gunakan data loader yang sepenuhnya deterministik agar nomor epoch atau step mudah dikaitkan dengan crash
      • Untuk memastikan apakah data adalah penyebabnya, matikan pemuatan data atau gantikan dengan data palsu yang hanya berisi 0
    • Putusnya Ethernet sesaat atau kehabisan ruang disk mungkin tidak muncul sebagai pesan kesalahan yang berguna, sehingga metrik status jaringan dan node dicatat untuk memeriksa korelasinya

  • Macet tanpa stack trace

    • Kesalahan yang macet atau timeout tanpa stack trace sangat sulit di-debug karena informasinya kurang dan sulit direproduksi secara andal
    • Pesan representatif berbentuk Watchdog caught collective operation timeout...
    • Jika satu atau lebih host gagal menyelesaikan operasi NCCL atau terputus dari koneksi NCCL/InfiniBand, semua host lain akan terblokir secara sinkron pada operasi tensor tersebut hingga NCCL_TIMEOUT
    • Karena karakteristik library NCCL, sulit menemukan host mana yang menjadi penyebabnya
    • Imbue menambahkan perubahan logging ke fork NCCL untuk lebih menampilkan pesan atau operasi in-flight saat crash dan mengidentifikasi host atau GPU yang bermasalah
    • Untuk menemukan host yang berperilaku salah, sering kali perlu memeriksa host yang tidak menghasilkan pesan log tertentu
    • Dengan Py-Spy dan GDB, proses yang berhenti di-debug secara real time untuk membedakan antara NCCL yang macet, driver yang macet, serta race condition atau deadlock pada kode Python

Perlambatan pelatihan dilihat dari MFU

  • Perlambatan umum atau MFU (Model FLOPs Utilization) yang lebih rendah daripada level yang sebelumnya diamati dapat terjadi karena berbagai penyebab
  • Pertama, memeriksa ulang konfigurasi, kode, dan variabel lingkungan akan membantu
    • Model yang salah
    • Ukuran batch yang salah
    • Konfigurasi UFM atau NCCL yang salah
    • CUDA_DEVICE_MAX_CONNECTIONS yang salah
  • Mengukur MFU langsung per batch lebih berguna untuk mendiagnosis jenis masalah daripada rata-rata yang dihaluskan

  • Penyebab berdasarkan pola MFU

    • Jika segera setelah pelatihan dimulai MFU stabil di bawah 1/10 dari ekspektasi, biasanya penyebabnya adalah masalah hardware InfiniBand seperti switch mati pada lapisan T2 atau T3
      • Masalah hardware antara GPU dan NIC juga dapat menjadi penyebab, dan muncul di dmesg sebagai PCIe x16 lanes limited by ...
    • Jika segera setelah mulai MFU stabil di 30% dari ekspektasi, konfigurasi GDR atau variabel lingkungan GDR pada salah satu host mungkin salah
    • Jika segera setelah mulai MFU stabil di 60–80% dari ekspektasi, biasanya penyebabnya adalah link InfiniBand yang menurun performanya atau rusak
      • Jika NIC InfiniBand yang terhubung ke GPU tertentu rusak, NCCL mencoba menggunakan NIC GPU lain pada host yang sama melalui NVLink lokal
      • CPU throttling juga dapat menjadi penyebab, sehingga perlu menyesuaikan pengaturan BIOS pada host tertentu
    • Jika penurunan 10x terjadi secara teratur pada satu batch, itu hampir selalu terkait dengan checkpointing atau evaluasi, dan dapat diperiksa dengan membandingkannya terhadap jumlah epoch/step
      • Jika membuat peringatan otomatis hanya berdasarkan anomali MFU, false positive akan banyak terjadi
    • Jika penurunan 10x pada satu batch jarang dan acak, lalu segera pulih, penyebab umum adalah workload intensif CPU yang dijadwalkan pada salah satu host yang sedang berjalan
      • Masalah jaringan intermiten atau bottleneck data loader juga bisa menjadi penyebab
    • Jika grafik MFU turun secara bertahap seiring eksekusi berjalan dan kembali ke 100% saat restart, Python dan profiler NVIDIA digunakan untuk memverifikasi bahwa penyebabnya adalah garbage collection otomatis
      • Setelah garbage collection otomatis dimatikan dan garbage collection dilakukan pada interval tertentu di semua host, penurunan throughput hilang
    • Jika performa awal bagus tetapi kemudian sering jatuh ke 70% dari ekspektasi, hal ini berkorelasi dengan NVIDIA GPU clock throttle reasons
      • Penyebabnya adalah suhu GPU, kegagalan atau penurunan performa kipas pendingin host, serta kegagalan unit catu daya
    • Jika performa bagus tetapi ada noise frekuensi tinggi yang besar antara 90–100% dari MFU yang diharapkan, biasanya ini adalah masalah hardware InfiniBand seperti penurunan tingkat sedang pada lapisan jaringan atas atau link flapping

  • Pertanyaan pemeriksaan regresi throughput

    • Periksa apakah sebelumnya pernah berjalan normal
    • Periksa apakah ada perubahan seperti merge kode terbaru atau pembaruan driver
    • Periksa apakah berjalan di host yang sehat dan apakah layanan dependensi seperti Docker Hub dan GitHub berfungsi
    • Periksa apakah eksekusi dilakukan dengan kode, lingkungan, konfigurasi, versi, daftar host, urutan rank, dan random seed yang sama dengan eksekusi normal terakhir
    • Periksa apakah dapat direproduksi
    • Periksa apakah ada korelasi dengan proses lain, crontab harian, serta metrik host, DCGM, dan UFM
    • Periksa apakah alat pengukuran metrik sudah benar
    • Periksa apakah masalah juga terjadi pada kode yang diperkecil, seperti model yang lebih kecil, data palsu, atau penghapusan penyimpanan/pemuatan checkpoint

Alat otomatisasi dan peningkatan operasional

  • Pelatihan mungkin bisa dimulai dengan performa yang baik, tetapi pada akhirnya akan ada sesuatu yang rusak, sehingga diperlukan alat dan sistem yang meminimalkan intervensi manusia
  • Karena Imbue adalah tim kecil, mereka tidak memiliki cukup personel untuk terus melakukan perbaikan manual, sehingga mengotomatiskan sebanyak mungkin proses
  • Sebagian besar masalah saat menjalankan pelatihan dipersempit ke mesin yang bermasalah atau komponen jaringan

  • Mengecualikan mesin bermasalah secara otomatis

    • Mengembangkan sistem yang otomatis memulai ulang run yang crash dari checkpoint terbaru
    • Proses restart menjalankan health check pada semua mesin yang tersedia, lalu mengklasifikasikan kondisi kesehatan mesin berdasarkan check yang lolos
    • Setelah itu, job pelatihan dijalankan kembali pada mesin yang paling sehat

  • Respons otomatis terhadap komponen jaringan

    • Semua kegagalan komponen jaringan yang diamati terdeteksi oleh UFM dan tercatat di log event UFM
    • Event yang benar-benar bermasalah hanya sebagian dari puluhan jenis event, dan sebagian besar terkait dengan link down atau jumlah symbol error yang tinggi
    • Skrip mem-parse log event UFM untuk menonaktifkan link dan port yang terkait dengan event terbaru, membuat tiket pemeliharaan, lalu mengaktifkannya kembali setelah perbaikan selesai

  • Mirror sistem file lokal

    • Kecepatan Ethernet di dalam dan di luar cluster bisa menjadi bottleneck untuk pelatihan terdistribusi skala besar
    • Koneksi Ethernet bersama sekitar 10Gbit/s cepat jenuh ketika ratusan worker mengunduh dataset dan checkpoint model secara bersamaan
    • Imbue membangun sistem file lokal yang me-mirror cloud storage di dalam cluster untuk mengurangi jumlah file yang harus diambil dari S3
    • Untuk menangani churn, ketika mesin sering dinonaktifkan atau diganti, setiap file direplikasi tiga kali
    • Menggunakan consistent hashing untuk mendistribusikan beban secara merata dan meminimalkan perpindahan file saat terjadi churn
    • Karena ruang disk terbatas, mereka juga mengembangkan alat untuk melacak siklus hidup file dan menghapus file yang tidak diperlukan

  • Docker registry terdistribusi lokal

    • Untuk transfer image Docker, mereka menggunakan Kraken
    • Kraken adalah software open source yang memungkinkan image Docker ditransfer secara peer-to-peer, dan Imbue menyatakan hampir tidak mengalami masalah dengannya

  • Pemantauan performa dan identifikasi host bermasalah

    • Menyiapkan Torch profiler dan NVIDIA Nsight Systems
    • Nsight Systems berguna untuk memahami berapa lama forward/backward pass dan komunikasi NCCL berlangsung
    • Membantu menentukan apakah bottleneck berasal dari komunikasi atau komputasi berdasarkan ukuran model dan jumlah worker
    • Penggunaannya agak sulit karena membutuhkan Docker privileged mode, penonaktifan pemeriksaan keamanan terkait event pemantauan performa, serta penghentian pelatihan untuk menyimpan profil
    • Mereka juga menulis alat untuk mendeteksi batch pelatihan yang lambat dan mengidentifikasi penyebabnya
      • Alat yang paling berguna memantau waktu tiap batch, lalu pada batch yang luar biasa lambat men-dump stack trace dari semua worker
      • Ini memudahkan identifikasi host tertentu yang memiliki masalah hardware atau software yang subtil
    • Sebelum health check cukup matang, ketika pelatihan gagal pada kumpulan mesin tertentu, belum jelas mesin mana yang menjadi penyebabnya
      • Misalnya, jika grup berisi 48 mesin gagal, mereka menjalankan eksperimen lebih kecil dalam 6 grup masing-masing 8 mesin, dan 8 grup masing-masing 6 mesin
      • Mesin yang termasuk dalam grup gagal pada kedua tahap dinilai sebagai mesin bermasalah dengan tingkat keyakinan tinggi

Prinsip operasional yang diperoleh selama proses pembangunan

  • Jika memiliki 10–20% lebih banyak mesin daripada yang dibutuhkan untuk run pelatihan tertentu, run dapat diulang dengan mudah saat terjadi kegagalan mesin
  • Jika jaringan cluster dikonfigurasi agar semua mesin terhubung dekat satu sama lain, subset mana pun yang berfungsi dapat digunakan
  • Kegagalan hardware dan software yang ditemui selama pelatihan akan terjadi lagi, sehingga layak membuat pengujian dan solusi otomatisasi untuk setiap jenis kegagalan
  • Untuk setiap pesan error yang tidak transparan, membuat alat yang lebih mudah diinterpretasikan sangat berguna
  • Demi reproduksibilitas, mereka mengadopsi aturan untuk mengubah bahkan perubahan paling sederhana sekalipun hanya satu per satu
  • Saat memperkenalkan alat eksternal atau ketika orang baru terlibat dalam proses, validasi ulang klaim, terutama jika langkah berikutnya bergantung pada hasil tersebut
  • Seluruh proses membutuhkan banyak pengawasan dan iterasi, tetapi kemampuan untuk sepenuhnya mengendalikan infrastruktur dan men-debug masalah di semua lapisan abstraksi menjadi faktor penentu

Bacaan terkait

1 komentar

 
GN⁺ 2024-06-29
Komentar Hacker News
  • Selama beberapa bulan, tim riset dan engineering kecil melatih model 70 miliar parameter dari nol di infrastruktur sendiri, dan mengungguli GPT-4o zero-shot pada tugas terkait penalaran
    Untuk menggunakan klaster sendiri bagi pelatihan berperforma tinggi, semua komponen mulai dari InfiniBand, Ethernet, GPU, hingga node harus berfungsi sempurna, dan jika hanya satu dari lebih dari 12.000 koneksi tidak stabil, seluruh pelatihan bisa melambat
    Mereka merilis skrip open source dan panduan end-to-end untuk penyiapan infrastruktur, dan ini adalah salah satu dari trilogi toolkit pelatihan model 70 miliar. Alat evaluasi dan optimasi hyperparameter CARBS bisa dilihat di sini: https://imbue.com/research/70b-intro/
    • Detailnya sangat bagus, dan ini pertama kalinya saya melihat tulisan yang menunjukkan pekerjaan engineering di balik model seperti ini sedetail ini dari dalam
      Saya punya dua pertanyaan. Pertama, saya penasaran apa yang akan berbeda jika melatih model 400 miliar parameter. Secara keseluruhan klaster, memori video tampaknya cukup, tetapi saya ingin tahu penilaian nyatanya
      Kedua, saya penasaran apakah arsitektur seperti ini dianggap sebagai bentuk akhir pelatihan model. Ini terlihat terlalu rapuh, jadi saya ingin tahu apakah ada mekanisme pelatihan terdistribusi atau arsitektur yang lebih baik, atau struktur klaster yang lebih baik
    • Saya penasaran bagaimana nasib dunia 3D mirip Minecraft yang sedang dibuat tim itu. Apakah mereka beralih arah?
    • Bagian “mengungguli GPT-4o zero-shot” menarik. Saya penasaran apakah model ini sudah sampai RLHF, atau baru pretraining saja
      Jika yang kedua, saya ingin tahu bagaimana mereka bisa mengalahkan GPT-4
    • Kalimat bahwa hanya satu koneksi tidak stabil dari lebih dari 12.000 koneksi bisa memperlambat seluruh pelatihan terasa cukup khas, jadi saya sempat berpikir, “sepertinya saya pernah melihat kalimat ini sebelumnya”
      Ternyata kalimat ini dan sebagian besar tulisannya tampak telah diposting hampir kata demi kata di Twitter, LinkedIn, dan Reddit; apakah ini cuma spam?
      https://x.com/imbue_ai/status/1805629547473518695
      https://reddit.com/r/learnmachinelearning/comments/1dobgbs/t...
      https://www.linkedin.com/posts/mattboulos_training-a-70b-mod...
  • Kalau disebut “511 komputer dengan 4.092 GPU H100, 8 per komputer”, apakah benar artinya GPU saja bernilai lebih dari 100 juta dolar?
    Saya penasaran seberapa besar bagian dari ini yang suatu saat akan masuk ke ranah pengembang hobi dengan anggaran PC gaming
    • Menarik bahwa sambil menghabiskan 100 juta dolar untuk GPU, mereka tetap berkutat dengan box Dell dengan port Ethernet rusak
      Seru mendengar masalah-masalah yang mereka alami
    • Kelihatannya benar. Mereka menggalang 200 juta dolar dari NVIDIA, dan mungkin itu diberikan murni dalam bentuk GPU: https://news.crunchbase.com/ai-robotics/new-ai-unicorn-imbue...
    • Jika GPU saja bernilai lebih dari 100 juta dolar, kebanyakan pembaca independen tanpa dana sebesar itu mungkin sebaiknya lanjut ke posting HN berikutnya
  • Keren sekali. Cisco baru berkolaborasi dengan NVIDIA dan merilis perangkat yang menyediakan 800G per port, meski saya tidak ingat apakah itu RoCE
    Di sini tampaknya GPU memiliki akses ke InfiniBand, dan itu indah. Ini salah satu tulisan yang benar-benar berguna secara langsung
  • Beberapa hari lalu podcast Latent Space juga membahas ini: https://www.latent.space/p/llm-training-2024
    Episodenya bagus, dan layak didengar untuk memahami alasan di balik keputusan-keputusan ini
    • Saya tidak terbiasa dengan wawancara seperti ini jadi merasa ini di luar kapasitas saya. Kalau ada pertanyaan yang seharusnya ditanyakan tetapi terlewat, akan bagus kalau ada yang mengusulkannya
  • Saya penasaran dengan total penggunaan daya untuk membuat model ini. Saya ingin tahu apakah ada angka yang juga mencakup listrik dan pendinginan
    Zuckerberg mengatakan di sebuah podcast bahwa mereka merencanakan model 1GW berikutnya, yang pada dasarnya berarti pusat data dengan pembangkit listrik skala menengah menempel padanya, jadi saya makin penasaran
  • Ini tulisan yang sangat berharga dan saya banyak belajar saat membacanya. Kode open source yang mereka rilis juga luar biasa
    Saya punya beberapa pertanyaan. Saya penasaran mengapa mereka membangun klaster sendiri, dan bagaimana pengalaman bekerja dengan mitra cloud saat menangani perangkat atau switch yang cacat
    Selain itu, di luar komunikasi all-to-all, apa yang paling mereka prioritaskan saat memilih arsitektur klaster dan apa yang paling bernilai dalam praktiknya, seperti apa infrastruktur logging-nya selain fakta bahwa itu berbasis Loki, mengapa registry Docker lokal diperlukan, dan apakah mereka menggunakan image lain selain nvidia-container-runtime
  • Pertanyaan jujur, mengapa ada begitu banyak hardware PC yang tercampur di sini?
    Saya penasaran apakah tidak bisa cukup menempelkan GPU ke backend PCI dan InfiniBand, lalu hanya menyisakan pengendali orkestrasi ARM yang sangat kecil untuk mengoordinasikan semuanya. Saya tidak tahu apakah ini karena inersia desain lama, atau karena pasar pengendali GPU khusus masih kurang
    • Jika yang ditanyakan adalah mengapa tetap membayar biaya tambahan untuk CPU dan RAM, tidak semua pekerjaan bisa dilakukan di GPU. Contohnya dekompresi .png
      Jika kode pelatihan benar-benar dianalisis dan data banyak dipraproses, mungkin ini bisa dilakukan hanya dengan sumber daya CPU/RAM yang sangat ringan, tetapi karena GPU mahal, CPU/RAM hanya bagian kecil dari biaya total sistem, jadi belum tentu layak menghabiskan waktu pengembangan untuk optimasi sebesar itu

Penyedia cloud hyperscale kemungkinan besar juga akan mengejar efisiensi biaya 0,x% seperti itu. Misalnya, mereka mungkin ingin memproses .png terlebih dahulu menjadi .webp (lossless multithread) atau .jpeg (lossy), tetapi mengubahnya ke format yang bisa didekompresi GPU mungkin mengurangi biaya CPU saat pelatihan namun justru menambah biaya penyimpanan dan transfer, sehingga besar kemungkinan tidak cocok
Lebih tepatnya, jika pekerjaan CPU menjadi bottleneck pelatihan, maka prapemrosesan data dan penyesuaian skrip pelatihan harus dioptimalkan semaksimal mungkin. Yang dimaksud di sini adalah jarak antara “cukup cepat” dan “lebih cepat”: CPU tidak cukup cepat untuk pelatihan < CPU pas cukup cepat untuk pelatihan < CPU lebih cepat daripada yang dibutuhkan pelatihan

  • Jika tiap mesin berisi GPU senilai 250 ribu dolar, memikirkan penghematan beberapa ribu dolar pada perangkat keras kontrol adalah hal yang bodoh. Risiko memakai konfigurasi perangkat keras baru terlalu besar
    Masalah lainnya adalah perangkat keras terkait GPU, driver, dan pengalaman operasional semuanya ada di sisi PC. Jika dijalankan di ARM, hampir semuanya harus dimulai lagi dari awal, dan juga perlu banyak pekerjaan tambahan untuk stabilisasi. Pada akhirnya, demi menghemat sedikit biaya prosesor, harus membayar biaya yang jauh lebih besar
  • Menyuplai data ke GPU secara terus-menerus adalah pekerjaan yang cukup rumit dalam pelatihan deep learning
    Saya tidak punya pengalaman LLM/NLP, tetapi pada beban kerja gambar dan audio, bahkan GPU RTX 2/3/4xxx kadang sulit dimanfaatkan sepenuhnya hanya dengan CPU 4~8 core biasa. CPU atau I/O menjadi bottleneck bukanlah hal yang sulit terjadi
  • 4.092 GPU H100 benar-benar skala yang besar
    Mereka bilang sedang melakukan “self-coding”, jadi saya penasaran apakah ini lebih dekat ke solusi no-code atau low-code
    Ada juga cukup banyak tulisan menarik di situs web mereka: https://imbue.com/our-work/
  • Saya penasaran berapa biayanya. Jika dijumlahkan biaya perangkat keras, waktu pengembangan, serta biaya listrik dan pendinginan, kira-kira berapa totalnya dari kondisi tanpa apa-apa sampai menjadi file model yang siap dipakai?
  • Saya penasaran apakah banyak pengembang hobi bisa ikut melatih model secara terdistribusi seperti seti@home atau folding@home
    Proyek-proyek semacam itu punya karakteristik bahwa pekerjaan bisa dipecah menjadi paket kerja yang cukup independen, tetapi saya tidak yakin apakah pelatihan model juga bisa dibagi seperti itu
    • Kemungkinan besar tidak bisa. Hampir tidak ada, atau mungkin sama sekali tidak ada, pengembang hobi yang bisa menyediakan throughput jaringan 400Gbps di antara GPU mereka