- CommaAI, tüm model eğitimi ve veri işlemeyi kendi veri merkezinde yürütüyor ve yaklaşık 5 milyon dolarlık altyapıyı doğrudan işletiyor
- Buluta bağımlılık, maliyet artışı ve kontrol kaybına yol açabilir; kendi compute altyapısını işletmek ise mühendislik kalitesini artırmayı ve maliyetleri düşürmeyi mümkün kılar
- Veri merkezi yaklaşık 450kW güç, 600 GPU, 4PB SSD depolama ve basit bir soğutma ile ağ yapısından oluşuyor
- Yazılım yığını, Ubuntu + Salt, minikeyvalue (mkv) depolama, Slurm zamanlayıcı, PyTorch dağıtık eğitim ve miniray dağıtık compute üzerine kurulu
- comma.ai bu yapı sayesinde otonom sürüş modeli eğitimini tamamen otomatikleştiriyor ve buluta kıyasla yaklaşık 5 kat maliyet avantajı elde ediyor
Kendi veri merkezini işletme nedeni
- Buluta bağımlılık artan maliyetler ve sağlayıcıya bağımlılık yaratır
- Bulut şirketleri sisteme girişi kolay, çıkışı ise zor olacak şekilde tasarlanmıştır
- Sürekli kullanımda yüksek maliyetli bir yapıya sıkışmak kolaydır
- Kendi compute altyapısını işletmek, teknolojik bağımsızlığı ve verimli bir mühendislik kültürünü teşvik eder
- Bulutta API ve ödeme sistemi odaklı yönetim gerekirken, veri merkezi güç, hesaplama ve bant genişliği etrafındaki gerçek teknik sorunların çözümünü gerektirir
- ML mühendisliği açısından da kaynak kısıtları, kod optimizasyonunu ve temel iyileştirmeleri teşvik eder
- Bulutta sorun çoğu zaman sadece bütçeyi artırarak çözülürken, kendi altyapınızda performans iyileştirmesi zorunludur
- Maliyet açısından comma.ai yaklaşık 5 milyon dolar yatırım yaptığını, aynı işi bulutta yapmanın ise 25 milyon doların üzerinde tutacağını hesaplıyor
Veri merkezinin bileşenleri
-
Güç
- En fazla 450kW kullanılıyor, 2025 elektrik maliyeti 540.112 dolar
- San Diego elektrik fiyatı 0,40 dolar/kWh ile dünya ortalamasının yaklaşık 3 katı
- İleriye dönük olarak kendi elektriğini üretme planından bahsediliyor
-
Soğutma
- Dış hava ile soğutma yöntemi kullanılıyor; bu, CRAC sistemlerine göre daha verimli
- Hava dolaşımı için iki adet 48 inç emiş ve iki adet 48 inç egzoz fanı bulunuyor
- PID kontrol döngüsü ile sıcaklık ve nem otomatik ayarlanıyor (%45'in altında tutuluyor)
- Güç tüketimi onlarca kW seviyesinde
-
Sunucular ve depolama
- Yapı, kendi üretimleri olan 75 adet TinyBox Pro'dan oluşuyor (toplam 600 GPU)
- Her sistemde 2 CPU + 8 GPU var ve eğitim ile genel hesaplama için kullanılıyor
- Kendi üretimleri olduğu için bakımı kolay
- Depolama, Dell R630/R730 tabanlı ve toplam 4PB SSD kapasitesine sahip
- Yedeksiz (non-redundant) yapıda, düğüm başına 20Gbps okuma hızı sunuyor
- Ağ yapısı, 3 adet 100Gbps Z9264F switch ve 2 adet Infiniband switch ile kurulmuş
Yazılım altyapısı
-
Temel yapılandırma
- Tüm sunucular Ubuntu + PXE boot ile çalışıyor ve Salt ile yönetiliyor
- Tek master yapısıyla %99 çalışma süresi korunuyor
-
Dağıtık depolama — minikeyvalue (mkv)
- Eğitim için sürüş verileri 3PB yedeksiz depolama üzerinde tutuluyor
- 1TB/s okuma hızı sayesinde önbellekleme olmadan doğrudan eğitim yapılabiliyor
- 300TB önbellek dizisi ve yedekli depolama dizisi üzerinde model ve metrikler saklanıyor
- Her dizi tek bir master sunucu tarafından yönetiliyor
-
İş yönetimi — Slurm
- PyTorch eğitim işleri ve miniray dağıtık işleri zamanlanıyor
-
Dağıtık eğitim — PyTorch + FSDP
- Infiniband ağı ile bağlanan iki eğitim bölümü işletiliyor
- Kendi eğitim framework'leri ile eğitim döngüsü otomatikleştiriliyor
- Model deney takibi servisi sağlanıyor
-
Dağıtık compute — miniray
- Hafif bir açık kaynak görev zamanlayıcı, boşta duran makinelerde Python kodu çalıştırıyor
- Dask'tan daha basit, görev yönetimi için merkezi Redis sunucusu kullanıyor
- GPU worker'ları, model çıkarımı için Triton Inference Server kullanıyor
- Yüzlerce makineye paralel ölçeklenebiliyor
- Örnek: Controls Challenge rekoru, veri merkezinin 1 saatlik kullanımıyla elde edildi
-
Kod yönetimi — NFS tabanlı monorepo
- Tüm kod tabanı 3GB'ın altında ve tüm workstation'lara kopyalanıyor
- İş başlatılırken yerel kod ve paketler senkronize ediliyor, bu işlem 2 saniye içinde tamamlanıyor
- Böylece tüm dağıtık işler aynı kod ve ortamda çalıştırılmış oluyor
Entegre eğitim hattı
- comma'daki en karmaşık iş, on-policy yöntemiyle bir sürüş modelini eğitmek
- Bunun için en güncel model ağırlıklarının uygulandığı simülasyon sürüşleri çalıştırılarak eğitim verisi üretilmesi gerekiyor
- Tüm hattı aşağıdaki gibi tek bir komutla çalıştırmak mümkün
./training/train.sh N=4 partition=tbox2 trainer=mlsimdriving dataset=/home/batman/xx/datasets/lists/train_500k_20250717.txt vision_model=8d4e28c7-7078-4caf-ac7d-d0e41255c3d4/500 data.shuffle_size=125k optim.scheduler=COSINE bs=4
- Bu eğitimi yürütmek için yukarıda açıklanan tüm altyapı kullanılıyor
- Komut tek satırdan ibaret görünse de, gerçekte birçok bileşeni birlikte orkestre ediyor
Sonuç
- comma.ai, kendi veri merkezini işleterek maliyet tasarrufu ve teknolojik bağımsızlık elde ediyor
- Aynı yaklaşımla şirketler ve bireyler de kendi altyapılarını kurabilir
3 yorum
Bellek pahalıdır!
hahahahahahahahahaha
Hacker News görüşleri
İçinde bulunduğumuz sektörde sahiplik vs bulut bir spektrumun iki ucu gibi
① Bulut, başlangıç yatırımı (capex) ve personel yükü açısından hafiftir ama işletme gideri (opex) yüksektir ve oynaktır
② Managed Private Cloud bizim yaptığımız iş; açık kaynak tabanlı olarak yönetiyoruz ve AWS'ye kıyasla yaklaşık %50 daha ucuz
③ Kiralık Bare Metal, donanım finansmanını üstlenen bir model ve AWS'den %90 daha ucuz
④ Doğrudan satın alıp colocation yapmak, teknik yetkinlik ve ölçek varsa en ucuz seçenek
Hetzner gibi şirketler 3 yıllık ROI'ye göre çalışıyor; 3 ve 4 numaralı seçenekler büyük ölçekli ya da altyapının çekirdek olduğu şirketler için uygun
Startup'lar için 1, KOBİ'ler için 2 daha gerçekçi (lithus.eu)
Sorun, bulutun maliyet yapısının sadece donanım fiyatından kaynaklanmaması; karmaşık mimarilere yönlendirdiği için verimsizlik artıyor
AWS'nin 'managed hizmetleri', kullanıcı sunucu verimliliğini artırdıkça AWS'nin gelirinin düştüğü bir yapıya sahip
Basitçe EC2 üstünde 4 Java sunucusu ve replike bir DB çalıştırmak çok daha verimli olabilir
Sonuçta saçma AWS faturaları, sayısız hizmet kötüye kullanıldığında ortaya çıkıyor
(Carolina Cloud'dan derek@) Biz de 4. modeli tercih ediyoruz ama teknik yetkinliği yetersiz kullanıcılar 1-3 aralığında kalıp kamusal bulutun yüksek maliyetli yapısına sıkışıyor
'Kullanım bazlı' deniyor ama pratikte temel ücretler ve asgari kullanım bedelleri ekleniyor, bu da işi çok daha pahalı hale getiriyor (carolinacloud.io)
Hetzner cazip bir seçenek
Postgres ya da VPN gibi hizmetleri kendin yönetmek yük gibi gelebilir ama aylık 10-15 bin dolar seviyesinden sonra AWS'ye göre avantajlı oluyor
Risk var ama alınmaya değer
Ben aylık 500 dolarlık bir bare metal sunucu kiralıyorum ve yönetim için yılda sadece birkaç saat harcıyorum
Gereksinimlerim basit olduğu için olabilir ama aşırı karmaşık bulut çözümlerinden çok daha iyi hissettiriyor
2 yıl önce colocation'a geçtik, şimdi %30 maliyetle daha büyük kapasiteye sahibiz
RAM/depolama tarafında sonradan gelen fiyat düşüşlerinden de faydalanıyoruz
Ama compliance yönetimine biraz daha fazla dikkat etmek gerekiyor
Eskiden buna sadece veri merkezi denirdi
Buluttan önce de vardı; sonuçta bu, sahip olmak vs kiralamak ve merkezileşme vs dağıtıklık döngüsünün tekrarından ibaret
Şirketler aşırı biçimde tek bir uca giderse aynı sorunlarla yeniden karşılaşıyor
İlginç olan, bulutun finans ekipleri için cazip olmasının nedenlerinden birinin vergi avantajı olmasıydı
Ama son düzenleme(OBB) ile CapEx gider yazılabilir hale gelince on-prem'e dönüş havası esmeye başladı
O halde neden fiyat açısından rekabetçi bulut alternatifleri çıkmıyor?
AWS ve Azure pazara hakim, bu yüzden fiyat indirme teşvikleri yok; Google tarafında ise hizmet kapatma riski büyük
Buluttan önce kurum içi altyapı ekipleri darboğazdı
Bulut bunu standartlaştırdı ve tekil faturalama yapısıyla basitleştirdi
Ayrıca ABD dışındaki bölgelerde sunucu tedariki yavaş olduğu için bulutun hız avantajı çok büyüktü
On-prem veri merkezlerinin operasyon yükü ağır ve ciddi mühendislik kaynağı tüketiyor
Bu yüzden bu tartışma sürekli geri dönüyor
Bulutun asıl yeniliği, "hizmet bazında maliyeti netleştirmesi" oldu
Eskiden "bunun için kime rica etmem gerekiyor?" denirken artık API üzerinden erişilebiliyor
İlgili bağlam şu yazıda iyi özetlenmiş: bu yazı
San Diego gibi sıcaklık kontrolünün kolay olduğu bir bölgede bile dış hava soğutması riskli
Nem ve kirleticiler sunucuları hızla bozuyor
Bunun yerine entalpi tekerlekli soğutucular (kyotocooling) gibi yöntemler verimli; soğutma etkinliğine kıyasla enerji tüketimi düşük
Dış hava soğutmasında ekipman ömrünü kısaltma riski yüksek, dikkat etmek gerek
Filtreleme ve nemi %45'in altında tutarak oldukça iyi sonuç alan örnekler de var
Böyle şeylere dikkat etmek gerektiğini bilmiyordum
O yüzden ben sadece bulut kullanıyorum — bu tür 'bilinmeyen risklerden' kaçınabiliyorum
On-prem ile bulutu birlikte kullanmak daha gerçekçi
Çekirdek altyapıyı güvenilir bir buluta bırakıp Slurm işleri gibi yükleri kendi sunucularında çalıştırmak mantıklı
Colocation hâlâ geçerli bir seçenek ve araştırma amaçlı HPC de düşünmeye değer
Norveç'te özel şirketler de ücret karşılığında araştırma HPC'si kullanabiliyor
Ben İtalya'da iki bölgede server farm işlettim; 5 çalışanla neredeyse %100 çalışma süresi sağladık
Yıllık 800 bin avroyla 7-8 milyon avroluk bulut maliyetinden kaçındık
Birçok geliştirici aslında hosting yapamayacağını sanıyor
Oysa pratikte düşünüldüğünden daha kolay ve teknik sorunları çözmek de keyifli olabiliyor
Equinix ya da Global Switch gibi yerlerde alan kiralarsanız güç, soğutma, kablolama gibi şeylerin hepsini onlar yönetir
Hatta iki bölgede kendi sunucu odalarınızı kurmak da gayet mümkün
Biz hâlâ kullanıcı hizmetleri için Azure kullanıyoruz
GPU gerektirmeyen web hizmetlerinde bulut daha verimli
GitHub'ı da hâlâ güvenilir bir hizmet olarak kullanıyoruz
(Şaka yollu) Slurm havuzunda Postgres daemon birbirine dolanıp Rust kontrolden çıkmıştı
Sonunda stabilize ettik ama donanım mühendisi açısından yazılım dünyası oldukça kaotik
Projenin başında AWS'de aylık 250 dolarla başlanır, aylık 30 bin dolar seviyesine gelince colocation'a geçilir
Buradaki kilit nokta maliyet hesabı yapabilme becerisi — iyi mühendisler bununla yönetime öneri sunabilmeli
Ama mesele sadece basit hesap değil; hangi yetenekleri çekmek ve nasıl bir iş kurmak istediğinizi de düşünmek gerekir
ML modeli eğiten bir şirketseniz kendi altyapınız daha uygun olabilir
Ama çoğu şirkette mühendisler platform seçimine dahil olamaz
Kararı yönetim önceden verir ve bildirir; durumların %99.999999'unda böyledir
Kariyerimin başlarında bulut varsayılan tercihti, şimdi ise on-prem yeniden moda
10 yıl sonra akım yine tersine dönebilir
Benim deneyimimde on-prem'i iten ekipler her zaman bakım yorgunluğunu küçümsedi
Startup gibi hızlı geliştirme gereken yerlerde bu, ayak bağına dönüşüyor
Buna karşılık bakım moduna geçmiş şirketlerde on-prem verimliydi
Yaş aldıkça "hızlı ve bütçe içinde bitirmek" daha önemli hale geliyor, altyapıyı kendi işletmenin cazibesi azalıyor
Bu akımı sadece teknik bir döngü değil, 'sahip olunamayan bir topluma' karşı tepki olarak görüyorum
Müzikten eve, arabaya kadar her şey abonelik modeline dönerken şirketler de hesaplama egemenliğini geri kazanmak istiyor
Bu tür döngüler hep vardı
Mainframe → PC → sunucu odası → bulut → edge computing şeklinde giden merkezileşme ↔ dağıtıklık salınımı bu
Sonuçta teknoloji ve öncelikler değişince ibre yeniden dönüyor
"Ağ bilgisayardır" sözü yeniden duyulmaya başlanırsa, bir tur daha tamamlanmış olur
(Şaka) Sıradaki aşama muhtemelen uzay (Skynet) olur
Çoğu şirketin on-prem'den kaçınmasının nedeni risk yönetimi
İyi şirketler riski temel rekabet alanlarına yoğunlaştırır
Kararı sadece maliyetle değil, riske göre ayarlanmış maliyetle vermek gerekir
Ama bugünlerde şirketlerin bu riski doğru değerlendirecek yetkinliğe sahip olup olmadığı da soru işareti
Sonuçta fiyat rekabetçiliği de farklılaştırıcı unsurlardan biri
Asıl mesele ana işe odaklanmak
Daha iyi satamayacağınız bir ürünü daha iyi satar hale getirmeyecekse veri merkeziyle vakit kaybetmemek gerekir
Yalnızca Google gibi altyapının bizzat ürün rekabetçiliği olduğu durumlar istisna
Sonuçta çoğu durumda Opex, Capex'e karşı kazanıyor
On-prem'in gerçek avantajı özgürlük, kontrol ve mahremiyet
Bu sadece para meselesi değil; ev sahibi olmakla kiracı olmak arasındaki fark gibi
2010'larda MBA tarzı öğreti "her şeyi buluta taşı" idi
Riski ve maliyeti üçüncü tarafa devretmek doğru cevap sayılıyordu
Ama gerçekte bizim veri merkezimiz çok daha ucuzdu ve yazılım abonelik ücretlerindeki artış oranı donanımdan çok daha yüksekti
Ama o ölçekte işçilik ve yönetim giderleri de hesaba katılınca basit maliyet karşılaştırmaları anlamsızlaşıyor
Tek bir hortum şirketi silebilir; bu yüzden son karar yine risk karşısında elde edilen değere göre verilmeli