30 petabaytlık sabit disklerle ön eğitim için bir depolama kümesi kurmak

• Bilgisayar kullanımı sorun çözümü için model ön eğitimi amacıyla 90 milyon saatlik video verisini depolamayı hedefleyerek San Francisco şehir merkezinde doğrudan bir depolama kümesi kuruldu
• On-premise yaklaşım seçilerek yıllık $354k (5 milyar won) ile 30PB depolama altyapısı işletilebildi. AWS’de bu maliyet $12m (17 milyar won) olduğundan yaklaşık 34 kat tasarruf sağlandı
• Çoğu public cloud’un aksine yüksek erişilebilirlik ve bütünlük önceliklendirilmedi; eğitim verisinin doğası gereği veri kaybını tolere etme stratejisi uygulandı
• Basit Rust ve Nginx tabanlı yazılımla işletiliyor; Ceph veya MinIO gibi karmaşık sistemler yerine doğrudan yazılmış 200 satırlık bir program kullanılıyor
• Proje sürecinde fiziksel yerleşim, ağ yapılandırması ve kablo yönetimi gibi birçok gerçek dünya deneme-yanılma süreci ve pratik bilgi edinildi

---

Giriş ve arka plan

• Bilgisayar kullanımı için model ön eğitimi, çok büyük hacimde video verisi gerektiriyor
• Genel amaçlı metin LLM’leri (ör. LLaMa-405B) için yaklaşık 60TB veri yeterli olabilirken, video tabanlı eğitim için 500 kat daha fazla depolama alanı gerekiyor
• AWS gibi public cloud kullanıldığında yıllık 12 milyon dolar maliyet çıkarken, kolokasyon merkezi kiralama ve sistemi doğrudan kurma yöntemiyle bu tutar yaklaşık 354 bin dolara düşürülebildi
• Büyük hacimli veriyi kendi bünyelerinde tutarak, en büyük kısıt olan veri maliyeti problemi çözüldü

Neden doğrudan kuruldu

• Bulut, yüksek güvenilirlik, yedeklilik ve veri bütünlüğüne odaklanırken; ön eğitim verisi %5 kaybı bile tolere edebilecek kadar kritik değil
• Bu özellik sayesinde tipik kurumsal ortamlara kıyasla çok daha gevşek güvenilirlik gereksinimleri seçilebildi (13 nine güvenilirlik yerine 2 nine)
• Depolama fiyatları, gerçek maliyetin çok üzerinde fiyatlandırılıyor
• Verinin en büyük maliyet kalemi olduğu ve yerel veri merkezi kurulumunun yeterince öngörülebilir olduğu değerlendirilerek bu yol tercih edildi

Maliyet karşılaştırması: bulut vs kendi kurulum

• Aylık recurring maliyet: internet $7,500 + elektrik $10,000 = toplam $17,500
• Tek seferlik maliyetler: sabit diskler $300,000, şasi $35,000, CPU düğümleri $6,000, kurulum ücreti $38,500, işçilik $27,000, ağ ve diğer kurulum giderleri $20,000 → toplam $426,500
• 3 yıllık amortisman dahil aylık sabit maliyet $29,500 olarak hesaplandı
• AWS aylık $1,130,000, Cloudflare R2 aylık $270,000, doğrudan kurulum aylık $29,500
  • AWS: TB başına yaklaşık 38 dolar/ay
  • Cloudflare: TB başına yaklaşık 10 dolar/ay
  • Kendi kurulum: TB başına 1 dolar/ay
• Büyük ölçekli model eğitiminde Cloudflare’da bile iç sistem yükü nedeniyle rate-limit sorunları yaşanırken, kendi kurdukları ortamda 100Gbps özel hatla bu sorun aşıldı

Kurulum ve süreç

• Hızlı kurulum için Storage Stacking Saturday(S3) planlandı; çevreden destek alındı ve profesyonel yükleniciler dahil edildi
• 36 saat içinde 2.400 sabit disk rafa yerleştirilerek 30PB donanım tamamlandı
• Yazılım tarafı Rust (yazma işlemleri, 200 satır) + nginx (okuma tarafı) + SQLite (metadata takibi)
  • Ceph, MinIO, Weka, Vast vb. karmaşıklık/maliyet nedenleriyle kullanılmadı (fazla karmaşıklık, gereksiz oluşu, bakım yükü vb.)
  • Tüm sürücüler XFS ile biçimlendirildi

Proje geri bildirimi ve çıkarımlar

İyi yapılanlar

• Yedeklilik / performans dengesi doğru kurulup 100G ağ neredeyse tamamen doldurularak kullanıldı
• Fiziksel olarak yakın bir yerde kurulum yapılarak debugging ve bakım kolaylığı sağlandı
• Tedarikçiler eBay üzerinden bulundu ancak gerçek satın alma bireysel satıcılarla doğrudan yapıldı; garanti ihtiyacının önemi vurgulandı
• 100G internet hattı birçok avantaj sağladı ve ağ sorunlarının kendi başlarına debug edilmesini kolaylaştırdı
• Kaliteli kablo yönetimi, sonraki sorun çözme süreçlerinde büyük fayda sağladı
• Karmaşık open source depolama sistemleri yerine sadelik ilkesi benimsendi ve bakım yükü azaltıldı
• Zaman ve işçilik maliyet tahminleri de isabetli çıktı; tasarruf etkisi net biçimde doğrulandı

Zorlayıcı noktalar ve deneme-yanılmalar

• Front-loader kullanımı nedeniyle 2.400 HDD’nin tek tek elle takılması yorucu oldu
• Depolama yoğunluğu yetersizdi; ilk tasarımda daha yüksek yoğunluk seçilse işçilik daha da azaltılabilirdi
• Daisy chain bağlantı hızı darboğaz yaratıyor; ideal olan her şasi için ayrı HBA bağlantısı
• Ağ bileşenlerinde marka uyumluluğu önemli, özellikle optik transceiver tarafında
• Ağ yapılandırmasını denemek ve ayarlamak zaman aldı; DHCP/NAT yerine performans ve kullanım kolaylığı odaklı kurulum yapıldı (yalnızca minimum firewall / secure link gereksinimleri uygulandı)
• Fiziksel erişilebilirlik ile kurulum sırasında monitör/klavye kablolamasının önemi net şekilde hissedildi

Denenebilecek fikirler

• KVM ve IPMI kullanımı ile uzaktan yönetim verimliliği artırılabilir
• Ayrı bir yönetim Ethernet ağı kurulması öneriliyor
• Ağ overprovisioning’i (ör. 400G iç ağ) düşünmeye değer
• Daha yüksek yoğunluklu sunucularla (90 sürücülü Supermicro / 20TB HDD vb.)
  rack sayısını azaltma, güç tüketimini düşürme, CPU yoğunlaşması gibi avantajlar elde edilebilir

Nasıl doğrudan kurulabilir

Depolama yapılandırması

• 10 adet CPU head node (Intel RR2000 vb., her sunucu için çift Intel Gold 6148 / 128GB ECC DDR4 RAM öneriliyor)
  • CPU’ya yük bindiren işlevler (ZFS vb.) için daha güçlü donanım seçilebilir
• 100 adet DS4246 şasi (her birinde 24 HDD)
• 2.400 adet 3.5" HDD (mümkünse SAS sürücü öneriliyor; hız avantajı var)
  • Farklı kapasiteler (12TB, 14TB vb.) karıştırılabilir; kapasite büyüdükçe yerleşim ve ikinci el değeri avantajlı hale geliyor
• Fiziksel montaj için raylar/braketler, ekipman kablolaması ve kablolar
• Ağ sorunlarını debug etmek için birden fazla crash cart (monitör + klavye)

Ağ altyapısı

• 100GbE switch (ikinci el Arista vb., QSFP28 portlu)
• Her sunucu için HBA (öneri: Broadcom 9305-16E vb.), HBA portları ile şasi bağlantı yöntemi
• Ağ kartı (Mellanox ConnectX-4 vb., mutlaka Ethernet modunda)
• DAC/AOC kablolar — rack’ler arası mesafe dikkate alındığında DAC uyumluluk açısından avantaj sağlayabilir
• CPU head node satın alırken HBA/NIC önceden takılmış tedarikçiler tercih edilebilir
• Seri kablo, ayrı yönetim Ethernet ağı (yedek amaçlı kablosuz adaptör + mini switch alternatifi)

Veri merkezi gereksinimleri

• Kabin başına 3.5kW güç tüketimi, 42U bazında 4U×10 + 2U×1 yerleşim varsayılıyor
• Kabin başına 3PB, switch için ek 1 adet 42U kabin veya bunun yerine 1U şasi
• Özel 100G cross-connect (genellikle QSFP28 LR4 optik çifti), form factor ve marka uyumluluğu önceden mutlaka doğrulanmalı
• Ofise yakın konumda kolokasyon öneriliyor; sorun çıktığında hızlı fiziksel müdahale mümkün olduğundan debugging ve operasyon verimliliği artıyor

İlk kurulum ipuçları

• Önce switch’in yerel konsoldan ilk yapılandırması yapılmalı; ardından 100GbE uplink port ayarı ve optik transceiver uyumluluğu doğrulanmalı
  • Gerekirse ISP optiği doğrudan NIC’e bağlanarak önce link-up doğrulanıp sonra switch’e taşınabilir
• Ubuntu kurulumu sırasında Netplan ile node ağ ayarlarını tamamlamak daha kolay
• Node internete bağlandıktan sonra, her DS4246 için tek kablo bağlantısı → formatlama / mount → durum kontrolü sırasıyla ilerlenirse kablolama ve disk arızaları erken tespit edilebilir

Performans / kararlılık uyarıları ve güvenlik

• Güvenlik varsayımı olarak bunun yalnızca eğitim verisine özel bir sistem olduğu kabulüyle, public IP’ye doğrudan bağlantı + port firewall + nginx secure_link ile sade işletim yapıldı
  • Müşteri verisi işlenecekse aynı yapı uygun değildir; DHCP / NAT / ayrıntılı firewall segmentasyonu zorunludur
• Daisy chain, yönetim ve kablolama açısından kolay olsa da bant genişliği darboğazı yaratır; mümkünse şasi başına özel HBA önerilir
• Optik transceiver’larda marka kilidi çok yaygındır; FS.com ve Amazon birlikte tedarik kaynağı olarak kullanılabilir ama özellik ve marka eşleşmesi dikkatle kontrol edilmelidir

Sonuç ve anlamı

• $1/TB-ay seviyesindeki çok düşük maliyetli özel depolama ile 30PB video ön eğitimi pratik hale getirildi; buluta kıyasla 10–38 kat maliyet tasarrufu sağlandı
• Basit mimari ve sahaya yakın erişim, zaman ve riskleri azalttı; 100G özel hat ise I/O darboğazını çözdü
• Büyük ölçekli çok modlu ve video modelleri çağında temel rekabet avantajı düşük maliyetli büyük veri altyapısı; bu yaklaşım, küçük ekiplerle bile uygulanabilecek gerçek dünyada denenmiş bir referans sunuyor

Kapanış ve iş birliği çağrısı

• Bu yazıyı referans alarak benzer bir depolama kümesi kurduysanız, iyileştirmelerinizi ve deneyimlerinizi paylaşmanız isteniyor
• Büyük ölçekli bilgisayar kullanımı modeli ön eğitimi ile, genelleme ve insan değerleriyle bağlantılı yapay zeka araştırmaları için işe alım yapılıyor (iletişim: [e-mail])

[GN⁺]

Hacker News görüşleri

• Kariyerime ilk başladığımda şirket içi altyapı varsayılan ortamdı; uzun ömürlü donanım sonunda emek verilen bir şeye dönüşüyor ve her sunucuda bir durum birikimi oluşuyordu. Zaman geçip donanım performansı yetersiz kaldığında, iç ekipler üzerinden mevcut listeden yeni donanım seçmek ve ek maliyet onayı almak gerekiyordu; bu da uğraştırıcıydı. Donanımı değiştirme sürecinde ya da evcil hayvan gibi özenle korunan ekipmanı tamamen ayırıp yeni ekipmana geçme aşamasında projeler gecikebiliyordu. Bulut ortaya çıkınca “artık kesinlikle buluta geçilmeli” diye düşünmeye başlamıştım. Ama zamanla insan ve kurum, donanımı doğrudan yönetmeyi unutuyor; sonunda bu beceriyi yeniden canlandırmadıkça bir zamanlar iyi bir tercih olan bulut giderek daha az cazip hale geliyor. O yüzden bu tür becerileri yeniden geliştirmeye yardımcı olduğu için teşekkürler.

  • Biz biraz sıra dışı bir durumdayız. En başından beri hyperscale bulutun işletme maliyetini karşılayamayacak durumdaydık, bu yüzden mecburen kendi yetkinliğimizi geliştirdik. Düşünüldüğü kadar zor değil ve bir süre daha bu şekilde devam etmeyi planlıyoruz. Yine de bahsedilen durum birikimi sorununu biraz görmeye başladık.

  • Benim hatırladığım kadarıyla şirket içi altyapı her zaman daha ucuzdu. Pek çok lojistik engel ortadan kalkıyor, tek bir faturayla iş daha pratik hale geliyordu. Bulutun parladığı dönemde tavsiye hep şuydu: temel yük için şirket içi altyapıyı kullanın, ani trafik artış ve düşüşlerinde ise bulutu kullanın. Ama geçici ölçekleme kullanımı giderek kalıcı kullanıma dönüştü ve geliştiriciler yeni makineleri anında ayağa kaldırmaya bağımlı hale geldi. Artık herkes bulutu varsayılan durum olarak görüyor. Bu süreçte gerçek maliyeti doğru hissetmeyi sağlayan zemini kaybettik ve bulutla şirket içi altyapı arasındaki maliyet farkı giderek daha da açıldı.

  • Docker, sunucuları evcil hayvan değil de değiştirilebilir bir varlık haline getiren müthiş bir araç. Rack’te duran bir sunucu sadece bir başka K3 ya da K8 düğümü gibi ele alınıyor; böylece ona evcil hayvan gibi davranılmıyor. Bu yönünü gerçekten seviyorum. Benzer şeyler VM’ler için de söylenebilir ama sonunda VM’in kendisi evcil hayvana dönüşüyor. Elbette imaj oluşturmak ya da snapshot almak mümkün, fakat Docker’daki dönüşüm hissi aynı değil.

  • Bir kez daha böyle bir işe girişmeyi düşünür müsünüz diye yarı şaka yollu soruyorum.

• İki harfli bir .inc alan adını hiç zorlanmadan alabilecek kadar parası olan bir startup, muhtemelen gereğinden fazla fon almıştır. Eskiden startup’larda ofiste kaç tane Aeron sandalye olduğunu saymaya benzer bir durum. İyi bir işaret değil.

  • Kullanılmamış iki harfli .inc alan adları yıllık 2300 dolara satılıyor; bu, tek bir geliştiricinin maliyetinin %5’i bile değil.

  • .inc alan adlarının gerçekten anlamlı bir değeri olup olmadığı tartışılır.

• Eğlenceli bir yazıydı; okurken dolaylı bir tatmin yaşadım. Deneyimi daha da keyifli kılmak için biraz daha fazla fotoğraf olsa güzel olurdu.

  • Yazarlar yorumlara gelirse Standard Intelligence PBC’nin tam olarak ne yaptığını merak ediyorum. Public Benefit Corporation mı, yoksa ne tür projeler yürütüyorlar, bunu sormak isterdim.

• Teknik ayrıntıların bu kadar detaylı yazılmış olmasını sevdim. Merak ettiğim bir şey var: colocation alanı bulma süreci nasıldı? Aracı kullandınız mı, fiyat pazarlığında ilk teklifle fiilen ödediğiniz tutar arasında ne kadar fark oldu?

  • San Francisco ve Fremont’taki colocation sağlayıcılarının çoğundan teklif aldık. Teklif edilen fiyatla fiilen ödediğimiz fiyat arasında fark yoktu, ama şartları ve tek seferlik ücretleri müzakere ettik.

• Bağlantısı verilen Discord blog yazısı da ilginçti. Çoğunlukla ciddi bir içerik olsa da şöyle eğlenceli bir kısım vardı: Dünya Kupası’nda gol olduğunda bu veri hemen izleme grafiklerine yansıyordu ve ekip üyeleri toplantı sırasında futbol maçı izlediklerini iş izleme ekranı bahanesiyle açıklayabiliyordu. Ayrıca sistemin gerçek kullanımına dair ya da Discord’un mesajları “petabayttan az” depolamayla tuttuğuna ilişkin dayanak olarak da anılmıştı. Tahminimce bu yazıdaki düğüm boyutu ve sayısına göre hesaplayınca eski küme yaklaşık 708TB, yeni kurulum ise yaklaşık 648TB çıkıyor, (büyüme payı dahil).

• Depolamanın kendisi çok ucuz. Ama eğitim ve ağ kurulum kısmını anlamıyorum. Başka yorumlarda GPU’ların tek bir yerde olmadığı söylenmişti; öyleyse eğitim verisi siteler arasında sadece 100Gbps ile gidip gelmek zorunda kalıyor. Bu durumda pretraining sürecinde darboğaz oluşmasından endişe ederim.

  • Şu anda yalnızca tek bir 100G bağlantımız var ve GPU kümeleri de şimdilik veri alıp vermede ancak bu kadarını işleyebiliyor. İleride büyüdükçe bant genişliğini ve depolamayı da artıracağız. Bu arada colo içinde birkaç 4090 var; veri parçalama ya da embedding işleri için inanılmaz faydalı oldular.

• Bu ölçekte bir iş yükü için AWS ya da başka bulutlardan özel teklif almak gayet mümkün. S3 tarafında 0.5PB bile ayrı fiyat teklifi almak için yeterli olabilir. Bunun toplam maliyetin kendi başınıza yönetmekten mutlaka daha ucuz olduğu anlamına geldiğini söylemiyorum; ama CSP’nin liste fiyatlarını, eBay’den alınmış ekipman + ücretsiz emekle (pizza masrafı hariç) karşılaştırmak tam anlamıyla adil bir kıyas değil.

  • AWS ya da bulutta asıl kritik konu egress ücretleri. O tarafta pazarlık etmeye çalışsanız da hiç taviz vermiyorlar. Yapay zeka eğitimi için fiilen kullanılamayacak seviyede. Cloudflare teklifi, yönetilen object bucket storage seçenekleri arasında daha ucuz olanlardan biri. Kendi kümenizi kurunca yönetilen hizmetlerle aradaki fark biraz kapanıyor; ayrıca kendi kurulumunuzu yapmanız pazarlık gücü de sağlıyor. Ama yönetilen bucket hizmetleri, salt pretraining depolaması için gereğinden fazla kapsamlı. Glacier arşiv için fiyat/performans açısından iyi, fakat ML için tam uyan bir ürün hâlâ yok.

  • Somut olarak ne düzeyde bir anlaşma yapılabiliyor, merak ediyorum. %50’den fazla indirim bile mümkün mü?

• Disk takma işine birlikte katılmak keyifliydi; bu kadar büyük veriyi gerçekten elleçlemek en heyecan verici deneyimlerden biri :P

• Disk arıza oranına dair bir şey söylenmemiş. Birkaç ay sonra durumun nasıl olduğunu merak ediyorum.

  • Daha önce yaşadığım bir deneyim var: birden fazla disk dizisini devreye alırken toplu sürücü arızaları görmüştük. Cuma öğleden sonra rack kurulumunu yapıp hafta sonu dokunmadan, basit bir shell script ile veri okuma/yazma testi çalıştırdık. Pazartesi geldiğimizde disklerin neredeyse yarısı bozulmuştu ve ortada hiçbir log yoktu. Sorunun striping sürecinden mi kaynaklandığını, yoksa stres testinde mi patladığını anlamak mümkün değildi. Meğer üretimden hatalı bir partiymiş; aynı şirketin başka müşterileri de şikayetçiydi. Üretici hepsini değiştirdi ve sadece canlıya alma süreci gecikti. Ondan sonra bir yıl boyunca hiç arıza yaşanmadı.

  • Son 10 yılda disk arıza oranları çok düştü. Eskiden haftada 10’dan fazla disk değiştirdiğim olurdu, şimdi ise nadir görülen bir şey. Bence Backblaze’in sabit disk istatistiklerine bakmak yeterli.

  • Söz konusu kümenin enterprise disk kullandığı söylenmişti; maliyetten kısmaya çalışmak sonradan çok daha büyük zarara yol açabilir. Ben ev sunucusunda ikinci el disk kullanmayı denedim, performans farkları çok büyüktü ve pek iyi bir deneyim değildi.

  • İyi nokta.