Startup’ta Sıfırdan LLM Eğitimi
(yitay.net)- Reka, temiz bir başlangıçla büyük dil ve multimodal model eğitim altyapısı kurarken, compute bulmaktan çok küme kalite farkları ve operasyonel istikrarsızlığın daha büyük darboğaz olduğunu gördü
- Aynı H100 GPU’larda bile sağlayıcıya ve kümeye göre düğüm arızaları, kablolama sorunları, GPU hataları, I/O·dosya sistemi darboğazları, checkpoint silinmesi ve teslimat gecikmeleri üst üste binerek adeta bir donanım piyangosu yarattı
- Google’ın TPU ve dahili altyapı deneyiminin aksine, harici GPU ortamlarında çok düğümlü eğitim, kablolama ve destek kalitesindeki farklar nedeniyle MFU ve kesinti süreleri kümeler arasında büyük değişiklik gösterdi
- Birden fazla küme, büyük veri taşımaları ve harici kod tabanlarının kısıtlarıyla uğraşmak zorunda kaldılar; Reka da PyTorch tabanına geçerken izleme, verimli checkpoint alma ve özel dosya sistemi kurulumunu kendisi inşa etti
- Sınırlı compute nedeniyle Big Tech tarzı sistematik ölçekleme yerine az sayıda kısa ablation deneyi ve Yolo run yaklaşımına güvenmek zorunda kaldılar; bunun sonucunda 21B Reka Flash ve 7B edge modellerini geliştirebildiler
Temiz Bir Başlangıçla Eğitim Altyapısı Kurmak
- Reka, güçlü multimodal dil modelleri eğitirken, büyük dil ve multimodal modelleri sıfırdan eğitmek için gereken altyapıyı baştan kurdu
- Temel zorluk TPU ile GPU arasında seçim yapmak değil, harici altyapı ve kod ortamında gerçek eğitimi istikrarlı biçimde çalıştırabilecek kadar yüksek operasyon kalitesi sağlamaktı
LLM Çağının Donanım Piyangosu
- Model eğitiminin ilk şartı compute bulmak olsa da, pratikte en büyük değişken sağlayıcı, küme ve hızlandırıcı bağlantı kalitesindeki farklar oldu
- Aynı H100 GPU’lar kullanılsa bile toplam küme kalitesi büyük ölçüde değişiyordu; burada donanımdan kasıt, çipin kendisinden çok tüm kümenin kalitesiydi
- Reka, farklı compute sağlayıcılarından yüzlerce ile binlerce çip ölçeğinde kümeler kiraladı ve durumlar görece çözülebilir seviyeden birkaç saatte bir çöken ortamlara kadar uzanıyordu
- Bazı kümelerde kablolama sorunları veya GPU donanım hataları nedeniyle düğümler kısa aralıklarla arızalanıyordu
- Aynı sağlayıcının kümeleri arasında bile dayanıklılık ciddi biçimde farklıydı
- Düğümler kararlı olsa bile I/O ve dosya sistemi kötü olduğunda checkpoint kaydı zaman aşımına uğrayabiliyor veya küme kullanım oranı ciddi biçimde düşebiliyordu
- Bazı compute kaynakları çalıştırma için tamamen farklı bir yazılım katmanı gerektiriyordu; bu da kendi kod tabanını getiren ekipler için ek bir geçiş maliyeti anlamına geliyordu
- Önceden nasıl bir donanım alınacağını, bunun ne kadar dayanıklı olacağını ve arızalara ne kadar tolerans göstereceğini bilmek zordu
- Sağlayıcı zamanında teslim edemezse işler aylarca gecikebiliyor, başka kaynaklardan da haftalar ya da aylar boyunca tedarik yapılamayabiliyordu
- Bazı sağlayıcılar checkpoint’leri yanlışlıkla sildi
MFU ve Arıza Müdahalesi İçin Dahili Araçlar
- Her kümede Model Flop Utilisation (MFU) farklıydı ve yanlış kablolanmış düğümler ya da sağlayıcı sorunları yüzünden azımsanmayacak miktarda compute boşa gidiyordu
- Dosya sisteminin çok verimsiz olduğu ortamlarda, birinin kümeler arasında büyük veri aktarımı başlatması bile eğitim çalışmasının MFU’sunu sert biçimde düşürebiliyordu
- Sağlayıcı desteğinin seviyesi de büyük farklılık gösteriyordu
- Nazik destekten ilgisiz yaklaşıma kadar geniş bir yelpaze vardı
- “ChatGPT tarzı” kalıp yanıtlar veren veya tüm sorunları kullanıcıya yükleyen destekler de oluyordu
- Her kümenin kendine özgü sıkıntıları ve hata modları vardı; sanki her küme için ayrı bir hotfix gerekiyormuş gibi hissettirdi
- Reka, kullanılabilir bir ortam oluşturmak için çeşitli dahili araçlar geliştirdi
- İzleme araçları
- Verimli checkpoint mekanizmaları
- Çeşitli optimizasyonlar
- Ölçeklenebilir veri depolama için özel bir dosya sistemi kurulumu
- Bu araçların birleşimi, zayıf donanım koşullarında bile kesinti süresini azaltıp MFU’yu anlamlı şekilde artırdı
GPU ve TPU Deneyimi Arasındaki Fark
- Reka, modellerini çoğunlukla GPU ile eğitti
- Google’da büyük dil modelleri eğitmek için ağırlıklı olarak TPU kullandıkları dönemle kıyaslandığında, CUDA ve nccl daha yabancı bir ortamdı
- GPU arıza oranı, Google’da TPU kullanırken yaşadıkları deneyimden belirgin biçimde farklıydı
- Google’ın UL2 20B modeli yanlışlıkla bir ay boyunca çalışmaya devam etmiş ama başarısız olmamıştı
- GPU ortamında olsaydı ilk birkaç gün içinde çökeceğini düşünüyorlar
- Ancak bu fark, çipin kendisinden çok hızlandırıcıları yöneten donanım ekibinin yetkinliği ve sağlayıcı desteğinin kalitesiyle ilgili olabilir
- GPU ortamındaki çok düğümlü eğitim, TPU pod’larda olduğu gibi dağıtık eğitimin birinci sınıf vatandaş olduğu bir tasarım gibi değil, sonradan eklenmiş bir unsur gibi hissettirdi
- Sağlayıcıların çok düğümlü eğitimi mümkün kılan kablolama yöntemleri farklı görünüyordu ve bu da lokasyonlar arası farkı büyütüyordu
Çoklu Küme İşletmenin Yükü
- Google’ın dahili altyapısı Borg, Xmanager ve Colossus üzerinde her yerden erişilebilir bir ortamdı
- Harici ortamlarda ise birden çok kümede yeni ortamları doğrudan kurmak zorunda kaldılar; bu, önceki deneyimlerinden çok farklıydı
- Tek bir yerde büyük bir hızlandırıcı havuzu kurmadığınız sürece, birden fazla kümenin hızlandırıcı havuzlarını kullanmak kaçınılmaz görünüyor
- GPU arz kıtlığı, tedariki doğal olarak dağıtık kümeler biçimine dönüştürüyor
- Büyük ölçekli model eğitimi onlarca TB veri gerektirdiği için, veriyi taşımak başlı başına büyük bir yük haline geliyor
- Çok büyük ölçekte veri çoğaltmak da ne basit ne de ucuz
- İdeal yapı, işleri birden çok sunucuya gönderen bir orkestrasyon katmanı; ancak çevik ve yeni bir startup’ın başlangıçta böyle gelişmiş bir ML eğitim altyapısına sahip olması zor
- Reka, çeşitli dahili iş akışlarıyla bu sorunları hafifletti ve dünya standartlarında bir deney altyapısına doğru ilerlemeyi sürdürüyor
- Bu tür derme çatma yapıların, en üst düzey şirketler veya büyük kurumsal yapılar dışındaki yerlerde aslında oldukça yaygın olduğu söyleniyor
Harici Kod Tabanları ve PyTorch Tercihi
- Tercih ettikleri kod tabanları T5X ve Mesh Tensorflow idi, ancak Reka için bunlar pratik seçenekler değildi
- Google dışında fazla desteklenmiyorlar
- Kısmen deprecated durumdalar
- Ekipte Google kökenli olmayan kişiler için pek kullanıcı dostu değiller
- Reka, daha vanilla sayılabilecek, daha kararlı görünen ve yaygın kullanılan PyTorch’u seçti
- İlk dönemde pip, git ve docker gibi harici geliştirme ortamlarına uyum sağlamak zorunda kaldılar
- Google kod tabanlarını dışarıda kararlı ve kullanıcı dostu şekilde kullanmanın zor olması da muhtemel
- Harici kod tabanlarının kalitesinin, Google’da alıştıkları kod tabanlarının epey gerisinde olduğunu düşündüler
- Google içindeki kod tabanlarının çoğu, Noam Shazeer, Barret Zoph, Adam Roberts, Hyung Won Chung gibi ML araştırmacıları tarafından doğrudan yazılmıştı
- Başka şirketlerin yazdığı bazı kodlarda kalite özellikle tatmin edici değildi
- Bazı kod tabanlarında model paralelleştirme yapılandırmasını değiştirmek için ayrı dönüştürücüler yazmak gerekiyordu; paralelleştirme değişikliği otomatik gelmiyordu
- Büyük ölçekli encoder-decoder eğitimi veya prefixLM eğitimi desteği de yetersizdi
- flash attention, GitHub issue’larında makul talep olmasına rağmen prefixLM eğitimi yani özel mask desteğini sunmaya devam etmedi
- Jax kullanmanın avantajlı olduğuna dair bir algı vardı, ancak startup ortamında hızlı hareket edebilmek için PyTorch’u seçtiler
Sınırlı Compute ve Yolo Run
- Sistematik model ölçekleme genelde 1B → 8B → 64B → 300B şeklinde küçük modelden büyüğe giden çok aşamalı deneyler yapıp kazananı seçerek büyütme yaklaşımını izler
- Startup ortamında hiperparametreleri doğrulamak için geniş çaplı sweep’ler yapacak compute çok daha sınırlıydı
- Reka çok sayıda Yolo run yaptı ve sonuçta bunun işe yaradığını düşünüyor
- Az sayıda, daha küçük ölçekli ve daha kısa ablation deneyiyle güçlü 21B Reka Flash, 7B edge modeli ve planlanan en büyük core modele kadar ilerleyebildiler
- Sınırlı sayıda çalıştırmayla iyi bir recipe bulmak zordu; arama alanı çok genişti ve aynı anda birçok değişkeni değiştirmek gerekiyordu
- Big Tech tarzı sistematiklik yerine Yolo, his ve sezgiye daha çok güvenmek zorunda kaldılar
- Ekip üyelerinin önceki ML kariyerlerinden gelen sezgileri, az sayıda denemeyle doğru ayarı bulmalarına yardımcı oldu
- Önceki işlerde iyi model eğitmiş olmak bile, eğitim altyapısı, veri, yeni fikirlerin entegrasyonu ve ortam sorunlarındaki farklar nedeniyle sonuçta kayda değer fark yaratabiliyor
- Güçlü ön deneyim, arama alanını büyük ölçüde daralttı ve az deneme, az kaynak ve az deneyle güçlü modeller eğitebilmelerini açıklayan en makul nedenlerden biri olabilir
1 Yıldan Kısa Sürede Alınan Sonuçlar ve Kalan Zorluklar
- Compute eksikliği ve istikrarsız compute sağlayıcıları, beklenenden çok daha büyük zorluklar yarattı
- Reka, şirketi kurup fon topladıktan ve çip satın aldıktan sonra her şeyi sıfırdan inşa etti
- Bir yıldan kısa sürede Gemini Pro/GPT-3.5 düzeyine ulaştıklarını ve birçok modeli geride bıraktıklarını söylüyorlar
- Veri hattı ve insan değerlendirmesi gibi konular ise hâlâ ayrıca ele alınmayı bekliyor
1 yorum
Hacker News görüşleri
Bu bağlamda startup, sonuçta az sayıda kişi ve eğitim kümesine harcayacak büyük bir bütçesi olan bir organizasyon gibi görünüyor
Yazı, birden fazla sunucu kiralama sağlayıcısı olduğunu ve bu sunucuların çeşitli startup'lara ya da mevcut şirketlere gittiğini varsayıyor
Sonuçta birden fazla LLM üreticisi, benzer donanım ve benzer verilerle metin ve görsel eğitimi yapıyor, büyük ölçüde aynı işi yürütüyor ve her biri kendi “gizli sosuyla” farklılaşmaya çalışıyor
Bu tür bir gizli sos LLM çıktısının kalitesinde fark yaratabilir, ama genel tablo çok enerji tüketen devasa bir tekrar çalışması gibi görünüyor
Sonunda çok küçük bir oranı makul bir başarı bile elde edecek olsa da, ilerlemenin en ön cephesinde ödenen bedel bu
Planlı bir tekel daha verimli olabilir, ama böyle bir yapının inovasyonda piyasayı geçtiği pek sık görülmez
Kurucular sanki sadece “neredeyse son teknoloji” bir LLM eğitebildikleri için satın alınmayı umuyor, ve bu seviyedeki yetenek ile altyapı bunun üstüne bir şey inşa etmeye yetecek kadar değerli olabilir
Yalnız bunu yatırımcılara anlatmak çok daha zor
Gerçekte birçok startup'ın yazarlar ve fotoğrafçılar çalıştırarak kirlenmemiş ve etiketlemesi son derece iyi yapılmış eğitim verileri ürettiğini düşünüyorum
civitai tarafına bakınca, küçük bir hesaplama bütçesiyle bile yalnızca sıkı etiketleme sayesinde ne kadar ileri gidilebildiği görülebiliyor
LLM'nin kullanım örneklerinin çoğu, mevcut temel modellerin ince ayarıyla desteklenebilir
Bir temel modeli sıfırdan eğitiyorsanız, para kazanmanın zor olduğu bir pazara giriyorsunuz demektir ve büyük bir şirket yeni tek bir temel model çıkardığında, benim modelimin yaptığı işin %95'inden fazlasını yapabilir
Bağlam açısından Yi Tay, Google PaLM, UL2, Flan, Bard gibi projelerde teknik liderdi ve şimdi Reka'nın kurucu ortaklarından biri
Reka, burada da daha önce paylaşılmış olan ilginç küçük multimodal modeller yayımladı
Google çıkışlı biri olarak bağımsız bir startup'ta LLM eğiten tarafta olduğu için, bu yazıyı yazması özellikle istenmiş: https://twitter.com/YiTayML/status/1765105066263052718
Sohbet kaydı burada: https://sub.thursdai.news/p/thursdai-feb-15-2024-openai-chan...
Bu yazı sayesinde reka.ai'yi öğrendim ve HN'de Reka'nın LLM'leri henüz çok fazla ele alınmamış gibi görünüyor [1]
Meraktan son bir saattir sohbet arayüzü [2] üzerinden ChatGPT 4, Gemini Advanced, Claude 3 ve Mistral Large ile karşılaştırmalı prompt testleri yaptım ve sonuçları [3]e koydum
Genel olarak Reka Flash, diğer modellere kıyasla belirgin biçimde daha kötü ya da daha iyi görünmüyor
Elbette bundan emin olmak için çok daha fazla test gerekir
[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
Yazarın, okurların “vahşi doğa”yı Google dışı yerler olarak anlayacağını doğrudan varsayması da dikkat çekici
Bu yazı Google'ın altyapı ve donanım ekiplerine çokça paye veriyor; içeride bulunmuş birinin daha sonra başka yerlerde benzer işler yaparken oluşan bakış açısını da okumak isterdim
Daha doğrusu bu, “kariyerim boyunca Google içinde Google TPU'ları kullandım ve onların arıza biçimlerine alışkındım, ama GPU'ların arıza biçimleri hakkında hiçbir fikrim yoktu” demeye daha yakın
GPU ağırlıklı çalıştıktan sonra TPU kullandığımda, işler debug etmesi zor nedenlerle sürekli başarısız oluyordu
x86 çipleri ile TPU cihazları arasındaki dolaylı katman yüzünden saatlerce saç baş yolduran durumlar yaşanıyordu; x86+NVIDIA+PyTorch tarafında karşılaşmadığım türden sorunlardı bunlar
10-15 yıl önce Google, değeri 10 milyon doların üzerinde veri bilimcileri, yani Sawzall mühendislerini çok sayıda yetiştirdi; onlar da “vahşi doğa”ya çıktıklarında benzer tepkiler verdi
Bu yazı topluluğa faydalı bir kayıt bırakmaktan çok, yazarın şirketini ve kişisel markasını öne çıkarma amacı taşıyor gibi görünüyor
Bana kalırsa büyük ölçekli eğitimde bile GPU arızası yaşamadım
Şu anki eğitim batch işi, yalnızca yüklenmesi 6 saat süren 20GB'lık bir JSON dosyası ve 15 günden uzun süredir sorunsuz çalışıyor; üstelik daha eski Tesla T4 kullanıyorum
GPU'ların bellek kısıtı sorunları var, ama bunları planlayıp etrafından dolaşabiliyorsanız pratikte hiç crash görmedim
Oldukça açık bir mecaz gibi duruyor ve büyük ölçekli altyapı projeleri yapan bir startup'sanız, gerçekten vahşi doğada kamp kurar gibi lojistik sistemini kendiniz inşa etmeniz gerekiyor
Seven of Nine'ın Collective'ten kopup sıradan insan kapasitesine güvenmek zorunda kaldığını fark ettiği bir sahne gibi okunuyor
Tedarikçilere dair içgörüler faydalıydı
Herhalde eğitimin o ana kadarki ilerlemesi tamamen kaybolmuyordur; yani asıl acı daha çok sorunu teşhis etmek ve kümeyi yeniden ayağa kaldırmakta mı, veri kaybı konusunda çok endişelenmemek mi gerekir?
Ama bunların sattığı ürün tam olarak ne?
Reka.AI ana sayfası, token başına ücret alınan sıradan bir ChatGPT klonu gibi görünüyor.
Diğer şirketlerden ne farkı olduğunu anlayamıyorum ve fiyatı da ChatGPT 3.5-Turbo’ya benzer görünüyor.
Bir LLM’i sıfırdan eğitme meselesi, yapay zekadaki yineleme hızını ve kapsamını, ham donanım iyileştirmeleri kadar etkileyen çok önemli bir konu.
Yazı ilgi çekici ama biraz yüzeysel; yıllardır herhangi bir biçimde GPU kümesiyle çalıştıysanız teknik olarak derin ya da şaşırtıcı gelmez.
Eski bir Googler’ın bakış açısı güzeldi ama Google dışında LLM yaparken eski çalışma arkadaşlarının neden PyTorch yerine JAX önerdiğini pek bilmiyorum.
Umarım bu yeni şirket ileride eğitim yolculuğu hakkında daha teknik bir rapor yayımlar. Mesela şu PDF gibi: https://github.com/facebookresearch/metaseq/tree/main/projec...
Muhtemelen biraz Google önyargısı da vardır.
Asıl büyük soru, doğru geçmiş ve soydan gelmeyen küçük bir startup’ın LLM ürünüyle finansmanı nasıl sağlayacağı.
LLM startup dünyası, hedge fund ve private equity dünyasına benzemeye başlıyor.
Tohum yatırım ve fon toplamanın ön koşulu sanki A) prestijli bir kariyer ve doğru soy ağacı, B) ürün daha başlamadan atlamaya hazır güçlü bir yatırımcı ağı gibi görünüyor.
VC’lerin bu tür şirketlere yatırım yapmasının nedeni de muhtemelen bu.
Dünya genelinde fon toplayabilecek doğru deneyime sahip insan sayısı çok sınırlı ve fon toplayabilenler ancak o tür deneyimi kazanabildiği için doğal bir giriş engeli oluşuyor.
En azından hesaplama maliyetleri yeterince ucuzlayana kadar öyle görünüyor.
“Bir şirket kurduk, para topladık, çip aldık ve bir yıldan kısa sürede her şeyi sıfırdan inşa ederken Gemini Pro/GPT 3.5 seviyesine ulaşıp birçok modeli geçtik” kısmını görünce, GPT 3.5 düzeyinde bir LLM’e ulaşmak için çiplere ya da bulut GPU’larına ne kadarlık bir bütçe harcandığını merak ediyorum.
Kabaca bir büyüklük mertebesi olarak 2 ila 5 milyon dolar mıydı?
Başlık “ground zero” yerine “from the ground up” olmalıymış gibi geliyor: https://en.wikipedia.org/wiki/Hypocenter
Deyim olarak tamamen kabul edilebilir bir kullanım.
LLM’nin teknoloji sektöründe mecazi bir nükleer bomba olduğu anlamına gelmesi amaçlanmış olabilir ama açıkçası ben de kafamı karıştırdım.
O tür bir yazardan bir şey öğrenmek istemezdim.
Google sistemlerinin istikrarlı olmasının nedeni, Google’ın 25 yıl boyunca veri merkezi donanımı, yazılımı ve süreç geliştirmeye on milyarlarca dolar yatırım yapmış olması.
Daha küçük ve daha az olgun organizasyonlardaki çok yetkin ekipler bile her zaman çok daha düşük kaliteli sonuçlar üretmek zorunda kalır.
Dikkate alınması gereken bir diğer şey de öncelikler.
Google istikrarı önceliklendirir ve görece seyrek arızalansa bile tekrar tekrar sorun çıkaran parçaları kullanımdan kaldırır.
Daha küçük ve daha az sofistike veri merkezleri ise sık bozulan parçaları kullanmaya devam eder ya da belirli parçaların arıza oranlarını hiç izlemeyebilir.
Küçük veri merkezleri bazen Google’ın eski parçalarını ve güvenilirliği daha düşük parçaları satın alıp kullanır.
Bu yüzden makinelerin kararsız olması, donanım ekibinin yetkinliği hakkında bir şey söylemez.
Donanımın düşük kararlılığı işleri yavaşlatıyorsa, yazılımı kararsız donanıma dayanabilecek şekilde iyileştirebilir ya da daha istikrarlı ama daha pahalı bir donanım sağlayıcısına geçebilirsiniz.