Melatih LLM dari Nol di Startup
(yitay.net)- Reka membangun infrastruktur pelatihan untuk model bahasa dan multimodal berskala besar dari kondisi bersih, dan yang menjadi bottleneck lebih besar daripada mengamankan compute adalah variasi kualitas klaster serta ketidakstabilan operasional
- Bahkan untuk GPU H100 yang sama, tergantung penyedia dan klasternya, kegagalan node, masalah kabel, error GPU, bottleneck I/O dan filesystem, penghapusan checkpoint, serta keterlambatan pengiriman bisa menumpuk hingga menciptakan situasi seperti lotre hardware
- Berbeda dari pengalaman dengan TPU dan infrastruktur internal Google, di lingkungan GPU eksternal terdapat perbedaan besar dalam pelatihan multinode, pengkabelan, dan kualitas dukungan, sehingga MFU dan downtime sangat bervariasi antar-klaster
- Mereka harus menanggung penggunaan beberapa klaster, pemindahan data berukuran besar, dan keterbatasan codebase eksternal; Reka berpindah ke basis PyTorch sambil membangun sendiri monitoring, checkpoint yang efisien, dan filesystem kustom
- Karena compute terbatas, alih-alih scaling sistematis ala Big Tech, mereka harus mengandalkan sedikit eksperimen ablasi yang singkat dan terkendali serta Yolo run; hasilnya, mereka mampu membuat Reka Flash 21B dan model edge 7B
Membangun infrastruktur pelatihan dari kondisi bersih
- Saat melatih model bahasa multimodal yang kuat, Reka membangun ulang infrastruktur yang dibutuhkan untuk melatih dari nol model bahasa dan multimodal berskala besar
- Tantangan utamanya bukan soal memilih TPU atau GPU, melainkan memastikan kualitas operasional yang cukup agar pelatihan nyata dapat berjalan stabil di lingkungan infrastruktur dan kode eksternal
Lotre hardware di era LLM
- Syarat pertama pelatihan model adalah mengamankan compute, tetapi dalam praktiknya variasi kualitas penyedia, klaster, dan koneksi akselerator menjadi variabel terbesar
- Bahkan untuk GPU H100 yang sama, kualitas keseluruhan klaster sangat berbeda; hardware yang dimaksud di sini lebih dekat ke kualitas klaster secara keseluruhan daripada chip itu sendiri
- Reka menyewa klaster berskala ratusan hingga ribuan chip dari beberapa penyedia compute, dengan kondisi yang bervariasi dari relatif dapat diatasi hingga gagal setiap beberapa jam
- Sebagian klaster mengalami kegagalan node dalam interval pendek karena masalah kabel atau error hardware GPU
- Bahkan antar-klaster dari penyedia yang sama, tingkat ketangguhannya sangat berbeda
- Meski ada node yang stabil, jika I/O dan filesystem buruk, penyimpanan checkpoint bisa timeout atau utilisasi klaster turun tajam
- Sebagian sumber compute menuntut lapisan software yang sepenuhnya berbeda agar bisa menjalankan pekerjaan, sehingga tim yang membawa codebase sendiri menanggung tambahan biaya migrasi
- Sulit mengetahui sebelumnya hardware seperti apa yang akan diterima, serta seberapa tangguh dan toleran terhadap kegagalan pengalaman yang akan didapat
- Jika penyedia gagal mengirim tepat waktu, penundaan bisa berlangsung berbulan-bulan, dan situasi dapat terjadi ketika sumber lain pun tidak bisa memasok selama berminggu-minggu atau berbulan-bulan
- Sebagian penyedia bahkan tidak sengaja menghapus checkpoint
Tool internal untuk MFU dan penanganan kegagalan
- Model Flop Utilisation (MFU) berbeda-beda di tiap klaster, dan jika menemui node yang salah dikabelkan atau masalah dari penyedia, compute dalam jumlah yang tidak bisa diabaikan terbuang percuma
- Di lingkungan dengan filesystem yang sangat tidak efisien, hanya dengan seseorang memulai transfer data massal antar-klaster, MFU dari eksekusi pelatihan bisa anjlok
- Tingkat dukungan penyedia juga sangat bervariasi
- Mulai dari dukungan yang sopan hingga respons yang acuh tak acuh
- Ada juga respons formal bergaya “ChatGPT” atau respons yang menyalahkan pengguna atas semua masalah
- Setiap klaster memiliki kesulitan dan mode kegagalannya sendiri, dan rasanya seolah setiap klaster membutuhkan hotfix terpisah
- Untuk membuat lingkungan yang dapat digunakan, Reka membangun berbagai tool internal
- Tool monitoring
- Checkpoint yang efisien
- Berbagai optimasi
- Instalasi filesystem kustom untuk penyimpanan data yang dapat diskalakan
- Kombinasi tool ini mengurangi downtime bahkan pada hardware yang buruk dan meningkatkan MFU secara bermakna
Perbedaan pengalaman GPU dan TPU
- Reka melatih sebagian besar modelnya dengan GPU
- Dibandingkan pengalaman menggunakan TPU terutama untuk pelatihan model bahasa berskala besar di Google, CUDA dan nccl adalah lingkungan yang asing
- Tingkat kegagalan GPU sangat berbeda dari pengalaman menggunakan TPU di Google
- UL2 20B milik Google sempat terus berjalan selama sebulan akibat kesalahan, tetapi tidak gagal
- Dalam lingkungan GPU, mereka memperkirakan pekerjaan itu akan gagal dalam beberapa hari pertama
- Namun perbedaan ini bisa jadi lebih berkaitan dengan kapabilitas tim hardware yang mengelola akselerator dan kualitas dukungan penyedia daripada chip itu sendiri
- Pelatihan multinode di lingkungan GPU tidak terasa seperti pelatihan terdistribusi yang menjadi konsep kelas satu seperti pada TPU pod, melainkan seperti elemen yang ditambahkan belakangan
- Cara pengkabelan untuk memungkinkan pelatihan multinode tampak berbeda-beda di tiap penyedia, dan perbedaan ini memperbesar variasi antar-lokasi
Beban operasional multi-klaster
- Infrastruktur internal Google adalah lingkungan yang dapat diakses dari mana saja di atas Borg, Xmanager, dan Colossus
- Di lingkungan eksternal, mereka harus menyusun sendiri lingkungan baru di beberapa klaster, dan ini sangat berbeda dari pengalaman sebelumnya
- Kecuali membangun sendiri pool akselerator berskala besar di satu lokasi, penggunaan pool akselerator dari beberapa klaster tampaknya tak terhindarkan
- Kekurangan pasokan GPU secara alami membuat pengadaan berbentuk klaster terdistribusi
- Pelatihan model berskala besar membutuhkan data berukuran puluhan TB, sehingga memindahkan data itu sendiri menjadi beban besar
- Pada skala yang sangat besar, replikasi data pun tidak sederhana dan biayanya besar
- Bentuk idealnya adalah lapisan orkestrasi yang mengirim pekerjaan ke berbagai server, tetapi bagi startup yang ringan dan baru, sulit memiliki infrastruktur pelatihan ML secanggih itu sejak awal
- Reka meredakan masalah dengan beberapa workflow internal, dan terus bergerak menuju infrastruktur eksperimen kelas dunia
- Mereka mengatakan mendengar bahwa konfigurasi scrappy seperti ini pada umumnya lazim di tempat yang bukan pemain papan atas atau perusahaan besar
Codebase eksternal dan pilihan PyTorch
- Codebase yang sebelumnya disukai adalah T5X dan Mesh Tensorflow, tetapi bagi Reka itu bukan pilihan yang realistis
- Tidak banyak dukungan di luar Google
- Sudah dalam kondisi cukup deprecated
- Tidak ramah bagi anggota tim yang bukan eks-Google
- Reka memilih PyTorch, yang lebih mendekati vanilla, tampak stabil, dan digunakan luas
- Pada tahap awal, mereka harus beradaptasi dengan lingkungan pengembangan eksternal seperti pip, git, dan docker
- Ada kemungkinan codebase Google sulit digunakan secara stabil dan ramah pengguna dari luar
- Kualitas codebase eksternal terasa jauh tertinggal dibanding codebase yang biasa mereka gunakan di Google
- Mereka menilai codebase internal Google sering kali ditulis langsung oleh peneliti ML seperti Noam Shazeer, Barret Zoph, Adam Roberts, dan Hyung Won Chung
- Di antara kode yang dibuat perusahaan lain, ada beberapa kasus yang kualitas kodenya terasa sangat mengecewakan
- Di sebagian codebase, untuk mengubah konfigurasi paralelisasi model, mereka harus menulis converter terpisah, dan perubahan paralelisasi tidak disediakan secara otomatis
- Dukungan untuk pelatihan encoder-decoder berskala besar atau pelatihan prefixLM juga kurang
- Flash attention disebut terus tidak menyediakan dukungan pelatihan prefixLM, yaitu dukungan mask kustom, meskipun ada permintaan yang wajar di GitHub issues
- Ada kesadaran bahwa mereka seharusnya memakai Jax, tetapi untuk bergerak cepat sebagai startup, mereka memilih PyTorch
Compute terbatas dan Yolo run
- Scaling model secara sistematis biasanya menjalankan eksperimen dalam beberapa tahap dari model kecil ke besar, seperti 1B → 8B → 64B → 300B, lalu memilih pemenang dan terus memperbesarnya
- Di startup, compute yang tersedia untuk melakukan sweep besar guna memeriksa hyperparameter jauh lebih sedikit
- Reka banyak mengandalkan Yolo run, dan menilai hasilnya pada akhirnya berjalan baik
- Hanya dengan sedikit eksperimen ablasi berskala lebih kecil dan singkat, mereka berhasil mencapai Reka Flash 21B yang kuat, model edge 7B, serta model core terbesar yang akan datang
- Menemukan recipe yang baik dengan jumlah run terbatas itu sulit, dan karena ruang pencariannya sangat besar, mereka harus mengubah banyak variabel sekaligus
- Alih-alih sistematika ala Big Tech, mereka harus banyak mengandalkan Yolo, feeling, dan intuisi
- Intuisi yang dibangun anggota tim dari karier ML sebelumnya membantu mereka tepat sasaran dalam sedikit percobaan
- Meski pernah berpengalaman melatih model yang baik di tempat kerja sebelumnya, perbedaan pada infrastruktur pelatihan, data, integrasi ide baru, dan isu lingkungan dapat membuat perbedaan hasil yang tidak kecil
- Pengalaman awal yang kuat sangat mempersempit ruang pencarian, dan bisa dilihat sebagai salah satu penjelasan sederhana mengapa mereka dapat melatih model yang kuat dengan sedikit percobaan, sumber daya, dan eksperimen
Hasil dalam kurang dari 1 tahun dan tugas yang tersisa
- Kekurangan compute dan pasokan compute yang tidak stabil menciptakan kesulitan yang jauh lebih besar dari perkiraan
- Reka memulai perusahaan, menggalang dana, membeli chip, lalu membangun semuanya dari nol
- Dalam waktu kurang dari satu tahun, mereka mengatakan telah menyamai Gemini Pro/GPT-3.5 dan melampaui banyak model
- Pipeline data dan evaluasi manusia masih menjadi topik yang tersisa untuk dibahas lebih lanjut
1 komentar
Komentar Hacker News
Dalam konteks ini, startup pada akhirnya tampak seperti organisasi yang punya segelintir orang dan dana besar untuk klaster pelatihan
Tulisan ini mengasumsikan ada beberapa penyedia sewa server, dan server-server itu mengalir ke berbagai startup atau perusahaan yang sudah ada
Pada akhirnya, berbagai pembuat LLM melakukan hal yang kurang lebih sama: melatih teks dan gambar dengan hardware serupa dan data serupa, lalu masing-masing mencoba membedakan diri lewat “saus rahasia”
Saus rahasia semacam itu memang bisa membuat perbedaan pada kualitas keluaran LLM, tetapi secara keseluruhan ini tampak seperti pekerjaan duplikatif raksasa yang menghabiskan banyak energi
Pada akhirnya hanya persentase yang sangat kecil yang akan mencapai bahkan keberhasilan yang layak, tetapi itu adalah biaya yang harus dibayar di garis depan kemajuan
Monopoli yang direncanakan mungkin bisa lebih efisien, tetapi struktur seperti itu jarang mengalahkan pasar dalam inovasi
Para pendiri tampaknya berharap diakuisisi hanya karena mereka bisa melatih LLM yang “hampir mutakhir”, dan tingkat kemampuan serta infrastruktur seperti itu mungkin cukup bernilai untuk membangun sesuatu di atasnya
Namun cerita seperti itu jauh lebih sulit dijelaskan kepada investor
Dalam praktiknya, saya rasa banyak startup mempekerjakan penulis dan fotografer untuk membuat data pelatihan yang tidak terkontaminasi dan diberi label dengan sangat baik
Kalau melihat sisi civitai, kita bisa tahu sejauh apa anggaran komputasi kecil bisa melangkah hanya dengan pelabelan yang rapat
Sebagian besar use case LLM bisa didukung dengan fine-tuning model fondasi yang sudah tersedia
Jika melatih model fondasi dari nol, berarti masuk ke pasar yang sulit dimonetisasi, dan satu model fondasi baru dari pemain besar saja bisa melakukan lebih dari 95% hal yang dilakukan modelmu
Dalam konteksnya, Yi Tay adalah tech lead untuk Google PaLM, UL2, Flan, Bard, dan lainnya, dan sekarang merupakan salah satu pendiri Reka
Reka telah merilis beberapa model multimodal kecil yang menarik dan pernah juga muncul di sini
Karena ia berasal dari Google dan kini berada di posisi melatih LLM di startup independen, saya memintanya menulis artikel ini: https://twitter.com/YiTayML/status/1765105066263052718
Rekaman percakapannya ada di sini: https://sub.thursdai.news/p/thursdai-feb-15-2024-openai-chan...
Lewat tulisan ini saya jadi tahu reka.ai, dan sepertinya LLM dari Reka belum banyak dibahas di HN [1]
Karena penasaran, selama satu jam terakhir saya menguji prompt lewat antarmuka chat [2] dan membandingkannya dengan ChatGPT 4, Gemini Advanced, Claude 3, serta Mistral Large, lalu mengunggah hasilnya di [3]
Secara umum, Reka Flash tampaknya tidak jauh lebih buruk atau lebih baik dibanding model lain
Tentu saja perlu pengujian yang jauh lebih banyak untuk memastikannya
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
[2] https://chat.reka.ai/chat
[3] https://gally.net/temp/20240307llmcomparison.html
Patut dicatat bahwa penulis begitu saja mengasumsikan pembaca memahami “alam liar” sebagai tempat di luar Google
Tulisan ini memberi banyak kredit pada tim infrastruktur dan hardware Google, dan saya juga ingin membaca perspektif orang yang pernah berada di dalamnya lalu mengerjakan hal terkait di tempat lain
Lebih tepatnya, itu mendekati “sepanjang karier saya memakai Google TPU di dalam Google dan terbiasa dengan pola kegagalannya, tetapi sama sekali tidak tahu pola kegagalan GPU”
Ketika saya yang terutama memakai GPU mencoba TPU, pekerjaan terus gagal karena alasan yang sulit di-debug
Lapisan tidak langsung antara chip x86 dan perangkat TPU sering membuat saya frustrasi selama berjam-jam, jenis masalah yang tidak saya alami di x86+NVIDIA+PyTorch
10–15 tahun lalu Google menghasilkan banyak data scientist bernilai lebih dari 10 juta dolar, yaitu para engineer Sawzall, dan ketika mereka keluar ke “alam liar” mereka menunjukkan reaksi serupa
Tulisan ini lebih terasa sebagai upaya penulis mengangkat perusahaan dan personal brand-nya daripada meninggalkan catatan yang berguna bagi komunitas
Menurut saya, bahkan dalam pelatihan skala besar saya belum pernah mengalami kegagalan GPU
Batch job pelatihan saya saat ini memakai file JSON 20GB yang memerlukan 6 jam hanya untuk load, sudah berjalan lebih dari 15 hari tanpa masalah, dan menggunakan Tesla T4 yang lebih tua
GPU memang punya masalah batasan memori, tetapi jika bisa direncanakan dan diakali, dalam praktiknya saya belum pernah melihat crash
Tampaknya seperti metafora yang cukup jelas, dan bagi startup yang mengerjakan proyek infrastruktur skala besar, mereka harus membangun sistem logistik sendiri seperti mendirikan kamp di alam liar sungguhan
Rasanya seperti adegan Seven of Nine terputus dari Collective dan menyadari bahwa ia harus mengandalkan kemampuan manusia yang remeh
Wawasan tentang pemasoknya berguna
Rasanya tidak mungkin seluruh progres pelatihan hilang, jadi apakah penderitaannya terutama pada mendiagnosis masalah dan menyalakan kembali klaster, sementara kehilangan data tidak perlu dikhawatirkan?
Tapi apa sebenarnya produk yang mereka jual?
Halaman utama Reka.AI terlihat seperti klon ChatGPT biasa yang membebankan biaya per token
Saya tidak tahu apa bedanya dengan perusahaan lain, dan harganya juga tampak mirip dengan ChatGPT 3.5-Turbo
Masalah melatih LLM dari awal adalah topik yang sangat penting, yang berdampak pada kecepatan dan luasnya iterasi AI sebesar peningkatan hardware mentah itu sendiri
Artikelnya menarik, tetapi agak dangkal; jika Anda pernah menangani klaster GPU dalam bentuk apa pun selama beberapa tahun, secara teknis ini tidak terlalu mendalam atau mengejutkan
Sudut pandang mantan Googler itu bagus, tetapi saya tidak begitu paham mengapa mantan rekan mereka merekomendasikan JAX dibanding PyTorch saat mengerjakan LLM di luar Google
Akan bagus jika perusahaan baru ini kelak menerbitkan laporan yang lebih teknis tentang perjalanan pelatihannya. Misalnya PDF seperti ini: https://github.com/facebookresearch/metaseq/tree/main/projec...
Bias Google mungkin juga ikut tercampur di sana
Pertanyaan besarnya adalah bagaimana startup kecil tanpa latar belakang dan silsilah yang tepat bisa mendapatkan pendanaan untuk produk LLM
Dunia startup LLM makin mirip dengan dunia hedge fund dan private equity
Prasyarat untuk investasi seed dan penggalangan dana tampaknya adalah A) riwayat karier bergengsi dan silsilah yang tepat, B) jaringan investor kuat yang siap masuk bahkan sebelum produknya dimulai
Mungkin itu juga alasan VC berinvestasi di perusahaan semacam ini
Di seluruh dunia, orang dengan pengalaman yang tepat untuk menggalang dana sangat terbatas, dan hanya orang yang bisa menggalang dana yang dapat memperoleh pengalaman seperti itu, sehingga secara alami terbentuk hambatan masuk
Setidaknya sampai biaya komputasi menjadi cukup murah, tampaknya begitu
Saat membaca bagian “mendirikan perusahaan, mengumpulkan uang, membeli chip, dan dalam waktu kurang dari setahun membangun semuanya dari nol hingga setara Gemini Pro/GPT 3.5 dan mengungguli banyak model”, saya penasaran berapa besar anggaran yang mereka habiskan untuk chip atau GPU cloud agar mencapai LLM setingkat GPT 3.5
Apakah kira-kira di kisaran 2 juta–5 juta dolar AS, setidaknya secara orde besaran?
Sepertinya judulnya seharusnya “from the ground up”, bukan “ground zero”: https://en.wikipedia.org/wiki/Hypocenter
Sebagai ungkapan idiomatis, pemakaian itu sepenuhnya bisa diterima
Mungkin maksudnya LLM adalah bom nuklir secara kiasan bagi industri teknologi, tapi jujur saya juga bingung
Saya tidak ingin belajar dari penulis semacam itu
Sistem Google stabil karena Google telah menginvestasikan puluhan miliar dolar selama 25 tahun untuk mengembangkan hardware, software, dan proses datacenter
Bahkan tim yang sangat kompeten di organisasi yang lebih kecil dan kurang matang pun mau tidak mau akan selalu menghasilkan keluaran dengan kualitas yang jauh lebih rendah
Hal lain yang perlu dipertimbangkan adalah prioritas
Google memprioritaskan stabilitas, dan memensiunkan komponen yang gagal berulang kali meski kerusakannya relatif jarang
Datacenter yang lebih kecil dan kurang canggih tetap memakai komponen yang sering rusak, atau bahkan tidak memantau tingkat kerusakan komponen tertentu
Datacenter kecil juga kadang membeli dan memakai komponen lama Google serta komponen dengan keandalan rendah
Jadi mesin yang tidak stabil bukan berarti menunjukkan kemampuan tim hardware
Jika keandalan hardware yang rendah memperlambat pekerjaan, perbaikilah software agar dapat menoleransi hardware yang tidak stabil, atau pindahlah ke penyedia hardware yang lebih stabil dan lebih mahal