- Imbue, küçük bir ekiple kendi bare metal altyapısında 70B parametreli bir modeli sıfırdan eğitti ve küme kurulumundan arıza kurtarmaya kadar uzanan operasyon prosedürleri ile betikleri paylaştı
- Küme, 4.088 adet H100 GPU ve 511 GPU sunucusundan oluşuyordu; sunucu başına 8 GPU, büyük ölçekli eşzamanlı eğitime InfiniBand üzerinden katıldı
- Gerçek kurulum; tek tek makine provizyonu, InfiniBand fabric bakımı, ana makine sağlık kontrolleri, eğitim hatası teşhisi ve otomasyon iyileştirmelerinin tekrarlandığı bir süreçti; yaklaşık %10 oranındaki makine önyükleme başarısızlığı ve çok sayıdaki port uyarısının ele alınması gerekti
- Paylaşılan araçlar arasında ana makine sağlık kontrolleri, NCCL günlükleme yaması, GPU stres testi, NVLink·InfiniBand ağ testleri, UFM olay günlüğü ayrıştırıcısı ve InfiniBand burn-in iş yükü üretim betiği yer alıyor
- Büyük ölçekli LLM eğitiminde tek bir kararsız ana makine veya bağlantı tüm çalıştırmayı yavaşlatabildiğinden, otomatik sağlık kontrolü·arıza izolasyonu·yeniden başlatma·port devre dışı bırakma sürekli operasyonun temel unsuru haline geliyor
Kendi 70B modelini eğitmek için küme kurma
- Imbue, birkaç ay boyunca kendi altyapısında 70B parametreli bir modeli sıfırdan eğitti ve bu model, muhakeme odaklı görevlerde zero-shot GPT-4o'yu geride bıraktı
- Paylaşılan kapsam, ilk küme açılışından OS kurulumuna ve eğitim sırasında hata sonrası otomatik kurtarmaya kadar uzanan uçtan uca altyapı prosedürünü kapsıyor
- Birlikte paylaşılan altyapı araçları şunlar:
- Host-level health checks: Bir ana makinenin bilinen hatalar olmadan eğitime alınmaya uygun olup olmadığını kontrol eden betikler
- NCCL yaması: Hata ve takılma durumlarında daha fazla günlük bırakacak şekilde iyileştirildi
- GPU stress test: GPU'nun büyük tensörler ayırıp standart işlemleri gerçekleştirebildiğini doğruluyor
- Networking tests: Aynı makinedeki GPU'lar arasında NVLink iletişimini ve farklı makinelerdeki GPU'lar arasında InfiniBand iletişimini kontrol ediyor
- UFM event log parser: Unified Fabric Manager olay günlüklerini ayrıştırarak devre dışı bırakılması gereken ağ portlarını belirliyor
- InfiniBand burn-in workload generator: Kullanılabilir tüm bağlantıları strese sokan bir InfiniBand burn-in iş yükü üretiyor
Küme ve ağ yapısı
- Ana küme, 4.088 adet H100 GPU'yu 511 GPU sunucusuna dağıtmıştı ve her sunucuda 8 GPU bulunuyordu
- GPU sunucularının 511 adet olmasının nedeni, bazı bağlantıların InfiniBand ağ yönetimi için Unified Fabric Manager(UFM) düğümüne ayrılması gerektiğiydi
- Her GPU doğrudan bir ConnectX-7 karta bağlıydı ve InfiniBand ağındaki diğer GPU'larla kendi ConnectX-7 kartı üzerinden aynı anda 400Gbps gönderim ve alım yapabiliyordu
- InfiniBand topolojisi, tüm GPU'ların teorik olarak azami hızda aynı anda diğer GPU'larla iletişim kurabildiği fully non-blocking bir yapıdaydı
- 3 aşamalı InfiniBand anahtar mimarisi toplam ağ bant genişliğini sağlıyordu
- Eğitim iletişimi Ethernet yerine InfiniBand üzerinden yapılıyordu
- Ethernet, veri setleri, checkpoint'ler ve diğer veri aktarımları için kullanılıyordu
- Eğitim trafiği Ethernet üzerinden gönderilirse verinin GPU'dan CPU'ya taşınıp ardından 100Gbps Ethernet kartından çıkması gerektiği için çok daha yavaştı
- RoCE ile Ethernet üzerinden eğitim de mümkün, ancak hem donanım hem yazılım tarafında çok daha fazla ek çalışma gerektiriyor ve genellikle InfiniBand'den daha düşük güvenilirlik sunuyor
- Ayrı bir yönetim Ethernet ağı; BIOS, güç kaynağı ve düşük seviyeli makine arayüz denetleyicilerine erişim için kullanıldı
- Bu yönetim ağı olmasaydı yüzlerce makinenin USB sürücü, klavye ve monitörle elle kurulması gerekecekti
- Büyük ölçekli yüksek performanslı eğitimde InfiniBand, Ethernet, GPU ve düğümlerin neredeyse kusursuz çalışması gerekiyor
- 12.000'den fazla bağlantıdan yalnızca birinin bile kararsız olması, tüm eğitim çalıştırmasını yavaşlatabiliyor
Tek tek makine provizyonu
- İlk yönetim ağıyla kümeye Ethernet bağlantısı kurulduktan sonra BMC(Baseboard Management Controller) erişim kimlik bilgileri elde edildi
- BMC, ana makineyi uzaktan izleyen bir servis işlemcisidir
- Donanım durumu, BIOS ayarları ve güç yönetimi API'leri sağlar
- İlk sunucuya, Dell'in BMC'si olan iDRAC üzerinden Ubuntu 22.04 elle kuruldu
- Yerel bilgisayardaki ISO imajı bağlanarak önyükleme yapılabiliyor ve tarayıcı tabanlı sanal konsol sunuyordu
- Hedef, bu manuel kurulumu tüm süreçteki tek manuel kurulum haline getirmekti
-
MAAS ve PXE önyükleme
- İlk makine hazırlandıktan sonra kalan sunucuları provizyonlamak için Ubuntu MAAS(Metal-as-a-Service) kuruldu
- PXE önyükleme ve otomatik iDRAC araçlarıyla her makineye ağ üzerinden önyükleme yapması talimatı verildi
- Sunucular DHCP ile MAAS'tan IP alıyor, ilk çekirdeği indiriyor ve yerel sürücüler boş olsa bile kalıcı OS kurulumunu otomatik olarak gerçekleştiriyordu
- Pratikte MAAS ile BMC entegrasyonu yeterince kararlı olmadığından tüm makinelerin MAC adresleri iDRAC API ile önceden toplandı
- MAAS, tüm eğitim süreci boyunca genel olarak güvenilir olsa da başlangıçta kurulumlara özgü sorunlar vardı
- Saat farkı çok büyük olduğunda HTTPS sertifika doğrulaması başarısız oluyor ve apt kurulumu engelleniyordu
- MAAS sunucusu aynı anda DHCP, DNS, HTTP proxy, NTP, cloud-init yapılandırma yönetimi ve MAC·IP·ana makine adı·meta veri için temel veritabanı rolünü üstlendiğinden kök neden takibi zordu
-
Önyükleme başarısızlıkları ve temel gözlemlenebilirlik
- Büyük GPU kümesi kurulumlarında sık görüldüğü gibi makinelerin yaklaşık %10'u önyükleyemedi ve ana nedenler sunuculardaki fiziksel sorunlardı
- Ethernet kablosunun takılmamış ya da yanlış bağlanmış olması
- iDRAC donanım sorunları
- Güç kaynağı arızası
- Arızalı NVMe sürücüleri
- Eksik iç kablolama
- Ağ kartı veya GPU'nun algılanmaması
- Imbue bu sorunlara yönelik kontrolleri otomatikleştirdi, bazı makineleri Dell yeniden incelemesine yönlendirdi ve veri merkezi personeline gerekli ticket'ları açtı
- Altyapı kurulumunu doğrudan kendileri yaptıkları için onarım beklenirken bile sağlıklı makineleri hemen kullanabildiler
- Tüm sunuculara Docker, veri merkezi GPU sürücüsü, Prometheus node exporter, NVIDIA DCGM exporter ve OS dışındaki tüm sürücüler üzerinde RAIDZ ZFS havuzu kuruldu
- ZFS, tek bir sürücü arızalansa bile makinenin çalışmaya devam etmesini sağladı ve şeffaf sıkıştırma sayesinde düz metin veri setleri ile tekrar eden günlüklerin depolama alanını büyük ölçüde azalttı
- 400 düğüme paralel olarak yazılım paketleri kurulurken bant genişliği darboğazı yaşandı
- Veri merkezi yerleşimindeki çeşitli bileşenlerde ilk başta yüksek sıcaklık uyarıları görüldü ve ilk termal sorunların çoğu firmware güncellemeleriyle hafifletildi
- Büyük GPU kümesi kurulumlarında sık görüldüğü gibi makinelerin yaklaşık %10'u önyükleyemedi ve ana nedenler sunuculardaki fiziksel sorunlardı
-
Tek düğüm GPU eğitiminin doğrulanması
- Her makinenin bağımsız olarak gerçek GPU iş yüklerini kaldırabildiği doğrulandı
- Birden fazla makine, şu sorunlar nedeniyle tek düğümlü GPU eğitiminde başarısız oldu
- GPU ile ilgili hataların çoğu kartların yuvalarına yeniden oturtulmasıyla çözüldü
- Ubuntu sunucu günlüklerinde PCIe bağlantısı
limited width: x4 < x16olarak görünüyordu - PCIe switch bus firmware güncellemesinden sonra bile kümedeki ana makinelerin yaklaşık dörtte birinde iç PCIe kablolarının yeniden takılması gerekti
- Arızalı olarak işaretlenmeyen, ancak erişildiğinde tüm makineyi kilitleyen NVMe sürücüleri vardı
- Linux'ta disk sırası rastgele göründüğünden MAAS, OS'yi yanlış sürücüye kuruyordu
- Hatalı sıcaklık okumaları nedeniyle fanlar sürekli %100 hızda dönüyordu
- CPU dinamik frekans ölçeklemesi, etkin çekirdekleri 2GHz ile sınırlıyordu
- GDR, yani GPUDirect RDMA Peer Memory Client uygulanamadı
InfiniBand sağlama
- InfiniBand, merkezi tasarımı sayesinde tüm ağ üzerinde tek bir kontrol otoritesine sahipti ve 320 ağ anahtarı tek bir fabric olarak yönetilebiliyordu
- İlk iş, hangi anahtarın hangi makineye bağlı olduğunu belirlemek ve kablolama şemasıyla karşılaştırarak anahtar adlarını fiziksel konuma göre değiştirmek oldu
-
Hatalı fabric tasarımı ve yeniden kablolama
- Başlangıçta UFM, 320 ağ anahtarını algılayamadı ve fabric içinde olması gereken host'ları da bulamadı
- Veri merkezi partneriyle kontrol edildiğinde anahtarların açık ve kablolanmış olduğu, ancak algılanmadığı görüldü
- Ağ kablolama listesini inceleyince üst fabric'in tek bir birleşik fabric değil, ortak yönlendirme yolu olmayan 8 ayrı ağdan oluştuğu ortaya çıktı
- Yeniden kablolamadan sonra tüm fiziksel bağlantıların yeni tasarımla uyumlu olduğunu doğrulayan bir kontrol eklendi
-
Sıcaklık uyarıları ve port hataları
- Fiziksel kablolama sorunları çözüldükten sonra UFM tüm InfiniBand anahtarlarına bağlandı, ancak neredeyse tüm anahtar portları aşırı yüksek sıcaklık bildirdi
- Gerçek veri aktarımı başlamadan önce bile bazı portlar 70 santigrat derecenin üzerine çıktı; bunun nedeni, ağ rack'lerindeki anahtarlar arasındaki boşluktan sıcak havanın ön tarafa yeniden dolaşmasına yol açan yapıydı
- Birçok port yüksek hata oranı gösteriyor veya normal ve arızalı durumlar arasında gidip gelen link flapping sergiliyordu; bu sorun yalnızca port gerçekten kullanıldığında ortaya çıktığı için önceden tespit edilmesi zordu
- Tüm fabric 10.000 link ve yüksek yedekliliğe sahipti, ancak fabric'in yaklaşık %10'unda sorun görüldüğünde adaptive routing gibi özellikler de düzensiz biçimde kopan link'leri yeterince dolaşamıyordu
- Veri merkezi partneri uyarı veren portları temizleyip yeniden taktı; değişim bekleyen diğer uyarılı transceiver'lar ise devre dışı bırakıldı
- Bu dönemde 100~200 makineyle çok düğümlü eğitim çalıştırılarak kararlı bir InfiniBand alt kümesi bulundu
-
InfiniBand burn-in ve GPUDirect RDMA
- InfiniBand sorunlarını daha verimli teşhis etmek için tüm fabric'teki bütün portlara aynı anda mümkün olduğunca fazla veri yükleyen özel bir iş yükü oluşturuldu
- Bu, küme genelinde tek bir büyük all-reduce çalıştırma yaklaşımından farklıydı
- Çünkü NCCL, tek düğüm içi iletişimi NVLink ve SXM soket yolları için optimize eder
- UFM, portların çoğunda teorik kapasitenin %97'sinden fazla veri aktarımı bildirimi gönderdi ve bazı anahtarlar geçici olarak crash oldu
- Gün sonunda ayakta kalan portlar yeterince sağlam kabul edildi; geri kalanlar devre dışı bırakıldı veya daha sonra onarım için ayrıldı
- GPU'ların CPU overhead'i olmadan iletişim kurabilmesi için GPUDirect RDMA etkinleştirildi
- nvidia-peermem çekirdek modülü etkinleştirildi
- Anında kilitlenmeleri önlemek için PCIe ACS devre dışı bırakıldı
-
Kararlı makine kümesi ve bakım
- Modern donanımlı GPU kümeleri için pratik kural, her hafta makinelerin yaklaşık %3'ünün arızalanacağını varsaymaktır
- Tüm makineler eşit biçimde %3 olasılıkla arızalanmaz; sorunlu bazı makineler farklı şekillerde tekrar tekrar arızalanır
- Aynı fabric üzerinde çok sayıda makine bulunduğunda, rastgele makine sorunlarını sürekli kovalamak yerine kararlı olduğu bilinen bir golden makine kümesini büyütmek mümkündür
- InfiniBand bakımı çoğunlukla UFM uyarılarına müdahale etme, kablo ve transceiver değiştirme, arızalı anahtarları teşhis etmeden oluşur
- Büyük gerilemeler genelde iki etkenden kaynaklanır
- Kümenin yalnızca yarısına uygulanan bir firmware yükseltmesi UFM durumunu bozarak tüm InfiniBand anahtarlarında UFM yeniden başlatmasını gerekli kıldı
- GPU kutuları aynı anda toplu biçimde yeniden başlatıldığında UFM durum güncellemeleri akın ederek UFM servisinin yeniden başlatılmasını gerektirdi
Host sağlık kontrol sistemi
- Imbue, eğitim çalıştırmalarını başarısızlığa uğratan veya yavaşlatan çeşitli tek makine arızaları buldu ve eğitime yetecek kadar sağlıklı host'ları belirlemek için sağlık kontrolleri yazdı
- Kod cluster-health içinde açıklandı
- Pek çok kontrol Imbue'nun çalışma ortamına özgü olsa da amaç, eğitim hazırlık durumuna dair tek bir giriş noktasından evet/hayır döndürmekti
-
Hızlı sağlık kontrolleri
- GPU Health Check: GPU sayısını, ECC etkinliğini, ECC hatalarını, NVLink topolojisini ve hatalarını kontrol eder
- Disk Space Health Check: Host disk kullanımının %95'i aşmadığını kontrol eder
- Docker Health Check: GPU'ya bağlı container'ların çalışıp çalışmadığını ve izleme/profiling container'larının izinlerini kontrol eder
- Dmesg Health Check: NVIDIA GPU veya NVIDIA switch üzerindeki Xid ve SXid hatalarını arar, ayrıca dmesg log satırlarının beklenen log listesine sınıflandırılabildiğini kontrol eder
- iDRAC Health Check: Dell makinelerde iDRAC hatalarını kontrol eder ve kritik olmayan hata mesajlarını yok sayar
- Bu kontrol açık kaynak olarak paylaşılmıyor
- Disk Health Check: zpool mount durumunu, Docker bağlantısını ve diske erişim sırasında CPU'nun kilitlenip kilitlenmediğini kontrol eder
- InfiniBand Health Check: Artan InfiniBand hata oranlarını ve eski driver firmware'lerini kontrol eder
- Nvlink Health Check: Makinedeki NVLink hatalarını kontrol eder
- Deneyime göre eğitim başarısızlığına yol açmasa da yavaşlamaya neden olabilir
- GDR Health Check: Makinede GDR'nin etkin olup olmadığını kontrol eder
- VBIOS Health Check: GPU VBIOS sürümünün ve H100 baseboard firmware'inin güncel olup olmadığını kontrol eder
- Flint Health Check:
flintvehca_self_testile Mellanox OFED driver'ını, kart firmware'ini, transceiver firmware sürümünü ve NVIDIA driver derleme durumunu kontrol eder - PSB Health Check: PCIe aygıtlarını sorgulayarak GPU, PSB ve ağ kartları arasındaki bağlantı hızı ile genişliğinin beklendiği gibi olup olmadığını kontrol eder
- Dell tarafından geliştirilen bir betik olduğu için şu anda paylaşılamıyor
-
Daha uzun sağlık kontrolleri
- PyTorch ile matris hesaplamaları başlatılarak NVLink bant genişliği, GPU hesaplama hızı ve bellek ölçülür
- GDR bayrağı ayarlanarak hem InfiniBand hem de NVLink test edilir
ib_write_bwve--use_cudaile IB kartına veri gönderilerek PCIe ve InfiniBand kartı bant genişliği ölçülür- Flapping InfiniBand link'lerini yakalamak için yaklaşık 15 dakika çalıştırılır
- Çok düğümlü tanılama çalıştırmasıyla NCCL başlatılabilirliği ve rastgele takılmalar olup olmadığı kontrol edilir
- Takılırsa fork edilmiş NCCL kodu ek log bırakır
- Sorun tespiti 12~24 saat sürebildiği için çoğunlukla yeni düğümlerde veya şüpheli durumlarda çalıştırılır
- DCGM exports içinden GPU clock throttle olayları kontrol edilir, ancak beklenen
gpu_idlevepower_caphariç tutulur - Tüm GPU'ları, InfiniBand kartlarını, CPU'ları ve diskleri aynı anda kullanan çok düğümlü eğitim, güç olaylarını en iyi şekilde ortaya çıkarır
Eğitim sırasında genel hata teşhisi
-
Başlangıçtan hemen sonra çökme
- Başlangıçtan hemen sonraki çökmeler görece kolay yeniden üretilebildiği ve tekrarlanabildiği için ele alınması en kolay hatalardı
- Önce kod sürümünün, yapılandırmanın ve ortam değişkenlerinin doğru olduğu doğrulandı
- Docker image önbelleklemesi veya şeffaf olmayan secrets yapılandırmaları gibi ara soyutlamalar, kök nedenin tespitini zorlaştırabiliyordu
- Tüm makinelerin çevrimiçi olup olmadığı ve stack trace ile logların kolayca toplanıp incelenebildiği de kontrol edildi
- Imbue, Loki, Prometheus, Grafana yığınını kullanıyor
- Eşzamanlı dağıtık çalıştırmalarda ilk hata çoğu zaman ilgisiz zincirleme hataları tetikliyordu
- Otomatik yeniden çalıştırma sistemi kuruldukça, farklı yeniden çalıştırmalardaki loglar ve hataların birbirine karışmaması için log/hata toplama daha da önemli hale geldi
- Sık görülen hatalar şunlardı
Forward order differs across ranks...: PyTorch FSDP uygulamasının bir özelliği nedeniyle yeniden çalıştırmayla çözülebiliyorduCUDA out of memory...: yapılandırma ve kod kontrol edilip son kod değişiklikleri geri alınarak çözüldü- CPU/RAM OOM: bunu, konteyner dışındaki host
dmesgloglarında OOM Killer çağrısını tespit ederek anlamak daha iyiydi
-
Eğitimin ortasında çökme
- Donanım çalışmaya başladıktan sonra öncelik, tüm teşhis health check'lerini yeniden çalıştıran ve sağlıksız hostları hariç tutarak otomatik yeniden başlatan bir sisteme verilmeliydi
- Xid ve SXid gibi rastgele donanım hataları, anlamlı bir Python stack trace olmadan çalışmayı çökertebiliyordu
- Row remapping gibi bazı durumlar yeniden başlatmayla toparlanabiliyordu, ancak uncorrectable ECC hataları genelde donanım bakımı veya parça değişimi gerektiriyordu
- Özellikle kötü biçimlendirilmiş eğitim verileri de çökmelere yol açıyordu
- Korpus içindeki aşırı büyük tekil belgeler GPU veya CPU OOM'a neden olabiliyordu
- Tamamen deterministik bir data loader kullanılarak epoch ya da step numarası ile çökme kolayca ilişkilendirildi
- Sorunun veriden kaynaklanıp kaynaklanmadığını doğrulamak için veri yükleme kapatıldı veya yalnızca 0'lardan oluşan sahte veriyle değiştirildi
- Ethernet'te kısa süreli kopmalar ya da disk alanı yetersizliği faydalı hata mesajları üretmeyebildiğinden, korelasyon doğrulamak için ağ ve düğüm durumu metrikleri kaydedildi
-
Stack trace olmadan takılma
- Stack trace olmadan takılan veya timeout'a düşen hatalar, bilgi azlığı ve güvenilir biçimde yeniden üretmenin zorluğu nedeniyle debug edilmesi özellikle güç sorunlardı
- Tipik mesaj
Watchdog caught collective operation timeout...biçimindeydi - Bir veya daha fazla host NCCL işini tamamlayamazsa ya da NCCL/InfiniBand bağlantısından düşerse, diğer tüm hostlar ilgili tensör işleminde
NCCL_TIMEOUTsüresine kadar eşzamanlı olarak bloklanıyordu - NCCL kütüphanesinin doğası gereği soruna hangi hostun neden olduğunu bulmak zordu
- Imbue, NCCL fork içine loglama değişiklikleri ekleyerek çökme anındaki in-flight mesajları veya işleri daha görünür hale getirdi ve sorunlu host ya da GPU'yu belirledi
- Hatalı çalışan hostu bulmak için çoğu zaman belirli log mesajlarını üretmemiş olan hostlara bakmak gerekiyordu
- Py-Spy ve GDB ile durmuş süreçler canlı olarak debug edilerek NCCL takılmaları, sürücü takılmaları ve Python kodundaki race condition/deadlock durumları birbirinden ayrıldı
MFU açısından eğitim yavaşlaması
- Genel yavaşlamalar veya daha önce gözlenen seviyelerin altındaki MFU(Model FLOPs Utilization) birçok farklı nedenden kaynaklanabiliyordu
- Önce yapılandırmayı, kodu ve ortam değişkenlerini yeniden kontrol etmek faydalıydı
- yanlış model
- yanlış batch size
- yanlış UFM veya NCCL yapılandırması
- yanlış
CUDA_DEVICE_MAX_CONNECTIONS
- Yumuşatılmış ortalama yerine batch bazında anlık MFU ölçmek, sorun türünü teşhis etmekte daha faydalıydı
-
MFU desenlerine göre nedenler
- Eğitim başlar başlamaz beklenenin 1/10'undan düşük MFU'da kararlı şekilde kalıyorsa, bu genelde T2 veya T3 katmanında ölü switch gibi bir InfiniBand donanım sorunuydu
- GPU ile NIC arasındaki donanım sorunu da neden olabilir ve
dmesgiçindePCIe x16 lanes limited by ...olarak görünür
- GPU ile NIC arasındaki donanım sorunu da neden olabilir ve
- Başlangıçtan hemen sonra beklenenin %30'u MFU'da kararlı şekilde kalıyorsa, bir hosttaki GDR yapılandırması veya GDR ortam değişkenleri yanlış olabilir
- Başlangıçtan hemen sonra beklenenin %60~80'i MFU'da kararlı şekilde kalıyorsa, neden genelde zayıflamış ya da arızalı bir InfiniBand bağlantısıydı
- Belirli bir GPU'nun bağlı olduğu InfiniBand NIC arızalıysa, NCCL aynı hosttaki başka bir GPU NIC'ini yerel NVLink üzerinden kullanmaya çalışıyordu
- CPU throttling de neden olabildiğinden, belirli hostlarda BIOS ayarlarının düzenlenmesi gerekebiliyordu
- Tek bir batch'te 10 kat düşüş düzenli biçimde oluyorsa, bu neredeyse her zaman checkpoint alma veya değerlendirmeyle ilişkiliydi ve epoch/step sayısıyla karşılaştırılarak doğrulanabiliyordu
- Yalnızca MFU anormalliğine göre otomatik uyarı kurmak çok sayıda false positive üretiyordu
- Tek bir batch'teki 10 kat düşüş seyrek, rastgele ortaya çıkıyor ve hemen toparlanıyorsa, sık nedenlerden biri çalışan hostlardan birinde CPU yoğun bir iş yükünün zamanlanmasıydı
- Aralıklı ağ sorunları veya data loader darboğazı da neden olabilir
- Çalışma ilerledikçe MFU grafiği kademeli olarak düşüyor ve yeniden başlatıldığında %100'e dönüyorsa, Python ve NVIDIA profiler ile otomatik garbage collection'ın neden olduğu doğrulandı
- Otomatik garbage collection kapatılıp tüm hostlarda belirli aralıklarla garbage collection yapıldığında throughput düşüşü ortadan kalktı
- İlk performans iyi olup sonrasında sık sık beklenenin %70'i düzeyine düşüyorsa, bunun NVIDIA GPU clock throttle reasons ile korelasyon gösterdiği görüldü
- Nedenler GPU sıcaklığı, host soğutma fanı arızası/zayıflaması ve güç kaynağı arızasıydı
- Performans iyi olsa da beklenen MFU'nun %90~100'ü arasında yüksek frekanslı gürültü büyükse, bu genelde üst ağ katmanlarında orta düzey bozulma veya flapping link gibi bir InfiniBand donanım sorunuydu
- Eğitim başlar başlamaz beklenenin 1/10'undan düşük MFU'da kararlı şekilde kalıyorsa, bu genelde T2 veya T3 katmanında ölü switch gibi bir InfiniBand donanım sorunuydu
-
Throughput gerilemesini kontrol etme soruları
- Daha önce normal çalıştığı bir durum olup olmadığı kontrol edildi
- Son dönemde kod birleştirmeleri veya sürücü güncellemesi gibi bir değişiklik yapılıp yapılmadığı kontrol edildi
- Sağlıklı hostlarda çalışıp çalışmadığı ve Docker Hub, GitHub gibi bağımlı servislerin düzgün çalışıp çalışmadığı kontrol edildi
- Son düzgün çalıştırmayla aynı kod, ortam, yapılandırma, sürüm, host listesi, rank sırası ve random seed ile çalıştırılıp çalıştırılmadığı kontrol edildi
- Yeniden üretilebilir olup olmadığı kontrol edildi
- Başka süreçler, günlük crontab, host/DCGM/UFM metrikleriyle korelasyon olup olmadığı kontrol edildi
- Metrik ölçüm aracının doğru çalışıp çalışmadığı kontrol edildi
- Daha küçük bir modelde, sahte veride veya checkpoint kaydetme/yüklemeyi çıkaran küçültülmüş kodda da sorunun ortaya çıkıp çıkmadığı kontrol edildi
Otomasyon araçları ve operasyonel iyileştirmeler
- Eğitim iyi bir performansla başlayabilse de eninde sonunda bir şeyler bozulduğu için, insan müdahalesini en aza indiren araçlara ve sistemlere ihtiyaç vardı
- Imbue küçük bir ekip olduğu için sürekli manuel onarım yapacak yeterli personele sahip değildi ve mümkün olduğunca çok süreci otomatikleştirdi
- Eğitim çalıştırmalarındaki sorunların çoğu arızalı makineler veya ağ bileşenlerine kadar daraltıldı
-
Arızalı makineleri otomatik dışlama
- Çöken çalıştırmaları en son checkpoint'ten otomatik olarak yeniden başlatan bir sistem geliştirdi
- Yeniden başlatma süreci, kullanılabilir tüm makinelerde health check çalıştırıyor ve geçen kontrollere göre makine sağlık durumunu sınıflandırıyor
- Ardından eğitimi en sağlıklı makineler üzerinde yeniden çalıştırıyor
-
Ağ bileşenlerine otomatik müdahale
- Gözlemlenen ağ bileşeni arızalarının tamamı UFM tarafından tespit edilip UFM olay günlüğüne kaydedildi
- Gerçekten sorun yaratan olaylar onlarca olay türünün yalnızca bir kısmıydı ve çoğu link down veya yüksek symbol error count ile ilgiliydi
- Betikler, UFM olay günlüğünü parse ederek yakın zamanda yaşanan olaylarla ilişkili link ve portları devre dışı bırakıyor, bakım bileti oluşturuyor ve onarım tamamlandıktan sonra yeniden etkinleştiriyor
-
Yerel dosya sistemi aynası
- Küme içi ve dışı Ethernet hızları, büyük ölçekli dağıtık eğitim için darboğaz olabiliyordu
- Yaklaşık 10Gbit/s paylaşımlı Ethernet bağlantısı, yüzlerce worker veri setlerini ve model checkpoint'lerini aynı anda indirdiğinde hızla doygunluğa ulaşıyordu
- Imbue, S3'ten çekilmesi gereken dosya sayısını azaltmak için küme içinde bulut depolamayı yansıtan bir yerel dosya sistemi kurdu
- Makinelerin sık sık devre dışı kalması veya değiştirilmesiyle oluşan churn'e uyum sağlamak için her dosyayı 3 kopya halinde tuttu
- consistent hashing ile yükü dengeli dağıttı ve churn sırasında dosya taşınmasını en aza indirdi
- Sınırlı disk alanı nedeniyle dosya yaşam döngüsünü izleyen ve gereksiz dosyaları silen araçlar da geliştirdi
-
Yerel dağıtık Docker registry
- Docker image dağıtımı için Kraken kullanıldı
- Kraken, Docker image'larının peer-to-peer dağıtımını sağlayan açık kaynak bir yazılım ve Imbue buna neredeyse hiç sorun yaşamadıklarını belirtiyor
-
Performans izleme ve arızalı host tespiti
- Torch profiler ve NVIDIA Nsight Systems kuruldu
- Nsight Systems, forward/backward pass ile NCCL iletişiminin ne kadar zaman aldığını anlamakta faydalıydı
- Model boyutu ve worker sayısına göre darboğazın iletişimden mi yoksa hesaplamadan mı kaynaklandığını değerlendirmeye yardımcı oldu
- Docker privileged mode gerektirmesi, performans izleme olaylarıyla ilgili güvenlik kontrollerinin devre dışı bırakılması ve profilleri kaydetmek için eğitimin kesilmesi gerekmesi nedeniyle kullanımı biraz zordu
- Yavaş eğitim batch'lerini tespit edip nedenini anlamaya yönelik araçlar da yazıldı
- En faydalı araç, her batch süresini izleyip anormal derecede yavaş batch'lerde tüm worker'ların stack trace'lerini dump ediyordu
- Bu sayede ince donanım veya yazılım sorunları olan belirli host'ları tespit etmek kolaylaştı
- Health check'ler yeterince olgunlaşmadan önce, belirli bir makine kümesinde eğitim başarısız olduğunda sorunun hangi makineden kaynaklandığı belirsizdi
- Örneğin 48 makinelik bir grup başarısız olursa, 8'er makineden 6 grup ve 6'şar makineden 8 grup şeklinde daha küçük çalıştırmalar başlatılıyordu
- Her iki aşamada da başarısız gruplarda yer alan makineler, yüksek güvenle sorunlu makineler olarak değerlendiriliyordu
Kurulum sürecinden çıkarılan operasyonel ilkeler
- Belirli bir eğitim çalıştırması için gerekenden %10-20 daha fazla makine bulundurmak, makine arızası durumunda yeniden çalıştırmayı kolaylaştırıyor
- Küme ağını tüm makineler birbirine yakın bağlanacak şekilde kurmak, çalışan herhangi bir alt kümeyi kullanabilmeyi sağlıyor
- Eğitim sırasında karşılaşılan donanım ve yazılım arızaları tekrar ortaya çıktığı için, her arıza türü için test ve otomasyon çözümü yazmaya değer
- Anlaşılması güç her hata mesajı için daha yorumlanabilir araçlar üretmek faydalı
- Tekrarlanabilirlik için en basit değişiklikte bile aynı anda yalnızca tek bir şeyi değiştirme kuralı benimsendi
- Dış araçlar devreye alındığında veya sürece yeni biri katıldığında, özellikle sonraki adımlar bu sonuca bağlıysa, varsayımları yeniden doğrulamak gerekiyor
- Tüm süreç çok sayıda gözetim ve yineleme gerektirse de, altyapının tamamen kontrol edilebilmesi ve her soyutlama katmanında sorunların debug edilebilmesi belirleyici oldu
1 yorum
Hacker News yorumları
Yüksek performanslı eğitim için kendi kümelerini kullanmak, InfiniBand, Ethernet, GPU’lar ve düğümler dahil tüm bileşenlerin kusursuz çalışmasını gerektiriyordu; 12.000’den fazla bağlantıdan yalnızca birinin bile kararsız olması tüm eğitimi yavaşlatabiliyordu.
Altyapı kurulumu için açık kaynak script’ler ve uçtan uca bir rehber yayımladılar; bu, 70 milyarlık model eğitim araç seti üçlemesinin bir parçası. Değerlendirme ve hiperparametre optimizasyon aracı CARBS burada görülebilir: https://imbue.com/research/70b-intro/
Merak ettiğim iki şey var. Birincisi, 400 milyar parametreli bir modeli eğitirken nelerin değişeceği. Kümenin tamamında video belleği yeterli görünüyor, ama gerçek değerlendirmeyi merak ediyorum.
İkincisi, bu mimarinin model eğitiminin nihai biçimi olarak görülüp görülmediği. Çok kırılgan görünüyor; daha iyi bir paylaşımlı eğitim mekanizması ya da mimarisi, daha iyi bir küme yapısı var mı bilmek isterim.
İkincisiyse GPT-4’ü nasıl yendiğini bilmek isterim.
Gerçekten de bu cümle ve yazının büyük kısmı Twitter, LinkedIn ve Reddit’te neredeyse kelimesi kelimesine paylaşılmış gibi görünüyor; bu sadece spam mi?
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...
Bunun ne kadarının ve ne zaman, oyun PC’si bütçesine sahip hobi geliştiricilerin alanına girebileceğini merak ediyorum.
Yaşadıkları sorunları duymak eğlenceli.
Burada GPU’nun InfiniBand’e erişebildiği bir yapı var gibi, çok güzel. Doğrudan faydalı yazılardan biri.
İyi bir bölümdü; bu kararların neden alındığına dair gerekçeleri duymak değerli.
Zuckerberg bir podcast’te sıradaki 1GW modelini planladığını söylemişti; bu fiilen orta ölçekli bir santralin bağlı olduğu bir veri merkezi anlamına geldiği için daha da merak ediyorum.
Merak ettiğim birkaç şey var. Neden kendi kümelerini kurduklarını, bulut ortağıyla arızalı ekipman ya da switch’lerle uğraşma deneyiminin nasıl olduğunu merak ediyorum.
Ayrıca all-to-all iletişimin dışında küme mimarisi seçerken en çok neye önem verdiklerini ve gerçekte en değerli olanın ne çıktığını; Loki tabanlı olması dışında günlükleme altyapısının nasıl olduğunu; yerel Docker registry’sine neden ihtiyaç duyduklarını; nvidia-container-runtime dışında başka image’lar da kullanıp kullanmadıklarını bilmek isterim.
GPU’ları PCI ve InfiniBand backend’ine bağlayıp, yalnızca çok küçük bir ARM koordinasyon denetleyicisi koyarak bunların birbirleriyle koordine olmasını sağlamak mümkün değil mi? Bunun önceki tasarımların ataleti mi, yoksa özel GPU denetleyicisi pazarının yetersizliği mi olduğunu bilmiyorum.
Eğitim kodunu gerçekten analiz edip verileri yoğun biçimde ön işlerseniz çok hafif CPU/RAM kaynaklarıyla da mümkün olabilir; ama GPU pahalı olduğu için toplam sistem maliyetinde CPU/RAM küçük bir pay tutar, bu yüzden geliştirme zamanını o düzeyde optimizasyona harcamak şart olmayabilir.
Devasa ölçekli bir bulut sağlayıcısıysa, bu tür %0.x maliyet verimliliğinin bile peşine düşme olasılığı yüksek. Örneğin .png dosyalarını .webp (çok iş parçacıklı kayıpsız) veya .jpeg (kayıplı) olarak önceden işlemek isteyebilirsiniz; ancak bunları GPU’nun açabileceği bir formata dönüştürmek, eğitim sırasında CPU maliyetini azaltsa da depolama ve aktarım maliyetini artırabileceğinden muhtemelen uygun olmayabilir
Daha kesin söylemek gerekirse, CPU işi eğitimin darboğazıysa veri ön işleme ve eğitim betiği ayarlamalarıyla mümkün olduğunca optimize etmek gerekir. Burada kastedilen, “yeterince hızlı” ile “daha hızlı” arasındaki boşluktur: CPU eğitim için yeterince hızlı değil < CPU eğitim için tam olarak yeterince hızlı < CPU eğitimin gerektirdiğinden daha hızlı
Bir diğer sorun da GPU ile ilgili donanımın, sürücülerin ve operasyon deneyiminin tamamının PC tarafında olması. ARM üzerinde çalıştırmak için neredeyse sıfırdan başlamak gerekir ve kararlı hâle getirmek için de çok fazla ek çalışma gerekir. Sonuçta işlemci maliyetinden biraz tasarruf etmek uğruna büyük bir bedel ödenmiş olur
LLM/NLP deneyimim yok ama görüntü ve ses iş yüklerinde, sıradan 4–8 çekirdekli CPU’larla RTX 2/3/4xxx GPU’ları bile tam kapasite kullanmanın zor olduğu zamanlar olabiliyor. CPU’nun veya G/Ç’nin darboğaz hâline gelmesi hiç de zor değil
“self-coding” yaptıklarını söylüyorlar; bunun no-code ya da minimum kod çözümlerine daha yakın bir şey olup olmadığını merak ediyorum
Web sitelerinde de ilgi çekebilecek epey yazı var: https://imbue.com/our-work/
Bu tür projelerin özelliği, işi oldukça bağımsız iş paketlerine bölebilmeleriydi; model eğitiminin de böyle bölünüp bölünemeyeceğinden pek emin değilim