Mimari ve Dağıtık Sistemler
Büyük Ölçekte Kendini Onaran GPU Filosu: Tespit, Drain, Remediation ve Otomasyonun Frenleri
Self-Healing a GPU Fleet at Scale
Binlerce GPU'da arıza istisna değil sabit bir orandır; kazanan ekip arızayı önleyen değil, tespit-boşalt-onar döngüsünü otomatikleştirip otomasyonu da frenleyen ekiptir.
Büyük GPU filosunda arıza önlenecek bir olay değil sabit bir orandır; güvenilirlik, otomatik tespit-boşalt-onar döngüsünün hızından ve otomasyonun frenlerinden gelir.
Hiperölçekleyiciler ve GPU bulutları bu modeli ürünleştirdi; tartışma otomasyonun ne kadar özerk olacağında ve frenlerin nerede duracağında.
Zihinsel model
GPU filosu bir hastane acil servisi gibidir: triyaj hızlı ve otomatik, ama aynı anda kırk hasta gelirse önce salgının kaynağı aranır.
Neden
- İş büyüdükçe kapsadığı donanım artar, ortalama arızasız süre saatlere iner; elle müdahale bu tempoya yetişemez.
- Arızalar en büyük ve en uzun işleri vurduğu için az sayıda arıza, çalışma süresinin orantısız bir kısmını tüketir.
- Ortak nedenli arızalarda tek tek node onarmak yedek havuzu tüketir; korelasyon freni olmayan otomasyon kesintiyi büyütür.
Kanıt
1.024 GPU'luk işlerin ortalama arızasız çalışma süresi yaklaşık 7,9 saat ölçüldü.
Meta, Revisiting Reliability in Large-Scale ML Research Clusters (2024)Llama 3 eğitiminde yüzlerce kesintiye rağmen ciddi elle müdahale yalnızca üç kez gerekti; gerisini otomasyon karşıladı.
DCD, Llama 3 eğitim raporu (2024)Kısa sürede çok sayıda node arızalanırsa otomasyonu durdurup insanı çağıran circuit breaker, yedek havuzun ortak nedenli arızada tükenmesini önlemek için canlıya alındı.
Crusoe AutoClusters (2026)Karşı görüş
Otomasyon yanlış sinyalle sağlam node'ları da devreden çıkarabilir ve Diskerase gibi vakalarda arızadan büyük hasar üretir. Küçük filolarda bu döngüyü kurmanın maliyeti, elle müdahalenin maliyetini aşabilir.
Kavramlar
Pratikte
- Aynı anda onarımda olabilecek node sayısına üst sınır koyun; aşılırsa otomasyonu durdurun.
- Node'u burn-in testinden geçmeden havuza döndürmeyin; tekrar arızalananı RMA'ya gönderin.
- Boş ya da beklenmedik büyüklükteki hedef listesini otomasyonda doğrudan reddedin.
Birkaç sunuculuk bir GPU kurulumunda arıza nadir bir olaydır; binlerce GPU'luk bir filoda ise her gün yaşanan bir istatistik. GPU'lar PCIe veriyolundan düşer, HBM bellek hataları birikir, NVLink ve ağ kartları kopar, bir node sessizce yavaşlayıp bütün eğitim işini aşağı çeker. Meta'nın 2024 verisinde 1.024 GPU'luk bir işin ortalama arızasız çalışma süresi yaklaşık 7,9 saat; donanım arızaları işlerin yalnızca binde 2'sini vurmuş ama toplam çalışma süresinin yüzde 18,7'sini yemiş. Bu yüzden soru 'arızayı nasıl önleriz' değil, 'arızayı ne kadar hızlı tespit edip node'u güvenle boşaltır, onarır ve geri alırız'. 2026'da NVIDIA NVSentinel'i açık kaynak yaptı, GPU bulutları self-healing'i ürün özelliği olarak sunmaya başladı; ama Kubernetes dışında kendi scheduler'ını işleten ekipler bu döngüyü hâlâ kendileri kuruyor. Döngünün en az konuşulan parçası da otomasyonun bir arızayı kesintiye çevirmesini engelleyen frenler.
Çıkarımlar
- Belli bir ölçeğin üzerinde arıza oranı kapasite planlamasının girdisidir; 1.024 GPU'luk bir iş için ortalama arızasız süre saatlerle ölçülür.
- Tespit pasif telemetri, aktif test ve korelasyon olmak üzere üç katmanlıdır; korelasyon en çok atlanan katmandır.
- Self-healing döngüsü cordon, drain, onar, doğrula ve geri al ya da emekliye ayır adımlarından oluşur.
- Otomasyon tek node'da cesur, çok node'da korkak olmalı: eşzamanlı onarım sınırı ve circuit breaker şart.
- Tekrar eden arıza node'larını ayıklamak en ucuz goodput kazancıdır.
- Telekomda GPU'lar sahaya dağıldıkça uzaktan tespit ve uzaktan onarım birinci savunma hattı oluyor.
Alt başlıklar
Arıza olay değil, oran
Meta'nın Llama 3 405B eğitiminde 16.384 H100 GPU'luk küme 54 günde 419 beklenmedik kesinti yaşadı; bunların yüzde 30,1'i arızalı GPU, yüzde 17,2'si HBM3 bellek kaynaklıydı. Kabaca her üç saatte bir kesinti. Buna rağmen etkin eğitim süresi yüzde 90'ın üzerinde kaldı ve ciddi elle müdahale yalnızca üç kez gerekti; yani asıl iş otomasyondaydı.
Meta'nın 2024 tarihli araştırma kümeleri çalışması aynı tabloyu ölçek fonksiyonu olarak veriyor: 8 GPU'luk bir işin ortalama arızasız süresi yaklaşık 47,7 gün, 1.024 GPU'luk işinki yaklaşık 7,9 saat, 16.384 GPU için projeksiyon 1,8 saat. Arızalar işlerin yalnızca binde 2'sini vurmuş ama çalışma süresinin yüzde 18,7'sini tüketmiş, çünkü en büyük ve en uzun işleri vuruyorlar. Sonuç: belli bir ölçeğin üzerinde 'arıza olursa' diye plan yapılmaz; arıza oranı kapasite planlamasının bir girdisi olur.
Ekim 2026 itibarıyla durum
Son on iki ayda GPU filosu sağlığı, her ekibin kendi betikleriyle çözdüğü bir sorundan paketlenmiş bir kategoriye dönüştü. NVIDIA Aralık 2025'te Kubernetes üzerinde GPU arızalarını tespit edip cordon, drain ve dış onarım kancalarını yöneten NVSentinel'i açık kaynak olarak tanıttı; Mart 2026 güncellemesine göre NVIDIA içinde 40.000'den fazla GPU bu sistemin gözetiminde. Crusoe Şubat 2026'da sıcak yedek havuzundan otomatik node değişimi yapan AutoClusters'ı, Together AI Mart 2026'da aktif sağlık testleri ve üç tıkla node onarımı sunan küme özelliklerini duyurdu. Kubernetes 1.34 (Eylül 2025), Pod durumunda DRA cihaz sağlığını raporlamayı alpha olarak ekledi.
Telekom tarafında Nokia Temmuz 2026'da ilk ticari GPU tabanlı AI-RAN platformunu açıkladı; T-Mobile US 2027'de ticari başlangıç planlıyor. SoftBank Mayıs 2026'da GB200 NVL72 tabanlı egemen GPU bulutunun betasını açtı. Türkiye'de Turkcell, Kasım 2025'te Google Cloud ile kurulacak bulut bölgesi için 1 milyar dolarlık yatırım açıkladı. Ortak nokta: GPU artık operatörlerin ve altyapı şirketlerinin işlettiği bir filo, filo da kendini onarmak zorunda.
Arızanın anatomisi: GPU, bellek, bağlantı, node
Filodaki arızalar dört ailede toplanıyor. GPU'nun kendisi: sürücünün GPU'yu PCIe veriyolunda görememesi (NVIDIA'nın Xid 79 kodu, 'fallen off the bus'), firmware ya da GSP hataları. Bellek: HBM'deki düzeltilemeyen hatalar; Xid 94 hatanın tek uygulamada kaldığını, Xid 95 kontrol altına alınamadığını ve GPU'daki tüm işlerin etkilenmiş olabileceğini söyler. Bağlantı: NVLink, InfiniBand ya da Ethernet kartı. Node: güç kaynağı, DIMM, BIOS, soğutma.
NCSA'nın Delta sisteminde 2,5 yıllık veri ilginç bir kayma gösteriyor: H100'de GSP ve NVLink hataları neredeyse yok olmuş ama GPU başına düzeltilemeyen bellek hataları A100'e göre yaklaşık 3,2 kat daha sık, çünkü bellek kapasitesi büyüdükçe yedek satır havuzu aynı oranda büyümüyor. Meta'nın 'lemon node' analizinde tekrar tekrar arızalanan node'ların kök nedenleri GPU, DIMM ve PCIe başta olmak üzere dağınık. Pratik ders: tek bir metrik yetmez, arıza ailesine göre ayrı sinyal ve ayrı aksiyon gerekir.
Tespit: pasif telemetri, aktif test, korelasyon
Tespit üç katmanda kuruluyor. Pasif katman sürekli akan veriye bakar: DCGM üzerinden sıcaklık, ECC sayaçları, güç, PCIe durumu; çekirdek log'undaki Xid satırları; ağ kartı ve fabric sayaçları. Ucuzdur, ani arızaları yakalar ama yavaş bozulmayı kaçırır. Meta kendi kümelerinde sağlık kontrollerini beş dakikada bir koşturuyor.
Aktif katman donanımı yük altında sınar: DCGM diagnostic seviyeleri, çok node'lu NCCL bant genişliği testleri, bellek stres testleri. İşler arasında ya da node yeniden havuza girmeden önce çalıştırılır; burn-in testinden geçmeyen node işe alınmaz.
Üçüncü katman korelasyon ve en çok atlanan katman. Aynı anda 40 node 'arızalı' görünüyorsa sorun büyük ihtimalle 40 GPU değil, bir switch, bir güç hattı ya da hatalı bir izleme sürümüdür. Tek tek node'ları boşaltmak yerine otomasyonu durdurup insanı çağırmak gerekir. Meta verisinde PCIe hataları ile Xid 79'un yüzde 43-63 oranında birlikte görülmesi, sinyallerin birbirine bağlı olduğunu hatırlatıyor.
Döngü: cordon, drain, onar, doğrula, geri al
Self-healing'in iskeleti beş adım. Cordon: arızalı node'a yeni iş verilmez. Drain: üzerindeki işlere checkpoint alıp çıkmaları için süre tanınır; Crusoe'nun varsayılanı 30 saniye. Onar: aksiyon arıza ailesine göre seçilir; GPU reset, node reboot, sürücü veya firmware yenileme, yeniden provisioning. Doğrula: node burn-in testlerinden geçmeden havuza dönmez. Geri al ya da emekliye ayır: aynı node belli bir pencerede tekrar arızalanıyorsa RMA kuyruğuna gider.
Kubernetes kullanan ekipler için cordon ve drain hazır ilkelerdir ve NVSentinel gibi araçlar bunları GPU sinyallerine bağlar. Kendi scheduler'ını işleten bir filoda ise bu kavramların her birini yeniden tanımlamak gerekir: 'node'a yeni iş verme' bayrağı, işin checkpoint alması için sinyal, onarım için idempotent bir Ansible playbook'u, doğrulama için test seti. Meta'nın verisine göre tekrar eden arıza node'larını ayıklamak büyük işlerin başarısızlık oranını yüzde 14'ten yüzde 4'e indirmiş; döngünün son adımı en ucuz kazanç.
Otomasyonun frenleri: arızayı kesintiye çevirmemek
Self-healing sisteminin en tehlikeli hali, yanlış sinyal üzerine bütün filoyu 'onarmaya' kalkmasıdır. Google'ın SRE kitabındaki Diskerase vakası klasik: bir rafı devreden çıkaran otomasyon yeniden başlatıldığında silinecek makine listesini boş buldu, boş kümeyi 'hepsi' diye yorumladı ve dakikalar içinde bütün CDN makinelerinin diskini sildi. Ekip sonrasında otomasyona hız sınırı dahil ek akıl sağlığı kontrolleri ekledi ve iş akışını idempotent yaptı.
GPU filosu için fren listesi: aynı anda onarımda olabilecek node sayısına üst sınır (ör. filonun yüzde 2'si); kısa pencerede çok sayıda arıza gelirse otomasyonu durduran circuit breaker (Crusoe'nun canlı özelliği tam olarak bu); boş ya da beklenmedik büyüklükte hedef listesini reddetmek; her aksiyonun önce dry-run çıktısı; yedek havuzu biterse yeni drain'i durdurmak; ve her otomatik aksiyonun bir insanın görebileceği bir kayda yazılması. İyi kural: otomasyon tek node'da cesur, çok node'da korkak olmalı.
Telekom ve enerji altyapısında nasıl görünüyor
Telekom 'self-healing' kavramını zaten tanıyor: 3GPP'nin Self-Organizing Networks çerçevesi self-configuration, self-optimization ve self-healing fonksiyonlarını LTE döneminden beri tanımlıyor. Yeni olan, aynı mantığın GPU'ya taşınması. Nokia'nın Temmuz 2026'da duyurduğu GPU tabanlı AI-RAN ile GPU'lar baz istasyonu bant işlemesine giriyor; filo artık bir veri merkezinde değil, binlerce sahaya dağılmış durumda. Sahaya teknisyen göndermek saatler sürdüğü için uzaktan tespit, trafiği komşu hücreye kaydırma ve uzaktan reset birinci savunma hattı oluyor. SoftBank ve Turkcell örneklerinde görüldüğü gibi operatörler aynı zamanda GPU bulutu işletmeye başlıyor.
Enerji ve altyapı tarafında GPU filosu doğrudan bir güç ve soğutma problemi. IEA'ya göre veri merkezlerinin elektrik tüketimi 2024'te yaklaşık 415 TWh idi ve 2030'da yaklaşık 945 TWh'ye çıkması bekleniyor. Güç kaynağı ve termal olaylar arıza kök nedenleri arasında; bir soğutma hattındaki sorun aynı anda onlarca node'u etkiler. Burada korelasyon katmanı hayati: tek tek GPU arızası gibi görünen dalga aslında bir altyapı olayıdır.
Ekonomi: goodput, yedek havuz ve overprovisioning
Self-healing'in iş karşılığı goodput, yani satın alınan GPU saatinin gerçekten faydalı işe dönen kısmı. Crusoe'nun açıkladığı örnek hesap öğretici: 1.000 GPU'luk, günde üç arıza gören bir kümede arıza başına 60 dakikalık elle müdahale goodput'u yaklaşık yüzde 81'de tutarken, 15 dakikalık otomatik değişim yaklaşık yüzde 92'ye çıkarıyor. Rakamlar varsayıma dayalı ama farkın yönü net.
Delta çalışması maliyet tarafını gösteriyor: ölçekte yüzde 99,9 iş düzeyi erişilebilirlik için yaklaşık yüzde 5 fazladan kapasite gerekiyor, bu da araştırmacıların hesabıyla ayda 1 milyon doları aşan bir bedel; node erişilebilirliğini yüzde 99,9'a çıkarmak gereken fazlalığı yaklaşık 2,5 kat azaltıyor. Karar çerçevesi: yedek havuzun büyüklüğü, ortalama onarım süresi ve checkpoint sıklığı birlikte ayarlanır. Checkpoint yazmak pahalıysa daha hızlı onarım, onarım yavaşsa daha sık checkpoint ya da daha büyük yedek havuz gerekir.
Son gelişmeler
Ekim 2026 itibarıyla
Önce kendi cevabını düşün, sonra aç.
Kubernetes kullanıyoruz; bu iş hazır gelmiyor mu?
Cordon ve drain ilkeleri hazır gelir, ama GPU'ya özgü arızaları tespit eden, sınıflayan ve onarım aksiyonunu seçen katman gelmez. NVSentinel gibi açık kaynak araçlar bu boşluğu dolduruyor; Kubernetes 1.34'teki DRA cihaz sağlığı raporlaması ise hâlâ alpha. Eşzamanlı onarım sınırı ve korelasyon frenini yine siz tanımlamalısınız.
Neden her arızada node'u hemen yenilemiyoruz?
Çünkü sinyallerin bir kısmı yanlış alarm ya da ortak bir nedenin belirtisi. Aynı anda çok sayıda node arızalı görünüyorsa büyük ihtimalle bir switch, bir güç hattı ya da izleme hatası vardır; hepsini yenilemek yedek havuzu tüketir ve kesintiyi büyütür. Bu durumda otomasyonu durdurup insana devretmek doğru aksiyon.
Xid 94 ile Xid 95 arasındaki fark operasyonu nasıl değiştirir?
Xid 94'te bellek hatası tek uygulamada kalmıştır; o süreç checkpoint'ten yeniden başlatılır, GPU reset bakım penceresine bırakılabilir. Xid 95'te hata kontrol altına alınamamıştır; GPU'daki tüm işler boşaltılmalı, GPU reset edilmeli ve son sağlam checkpoint'ten beri üretilen çıktılar şüpheli sayılmalıdır. Tekrarlayan 94'ler de belleğin bozulduğunun işareti.
Self-healing'in başarısını hangi metrikle ölçeriz?
Üç gösterge yeterli: tespit ile node'un havuzdan çıkması arasındaki süre, node'un doğrulanıp geri dönmesine kadar geçen süre ve goodput. Bunlara otomasyonun yanlış aksiyon oranını da ekleyin; hiç yanlış aksiyon almayan otomasyon büyük ihtimalle yeterince şey yapmıyordur, çok yanlış aksiyon alan ise güven kaybettirir.
Telekom operatörü için GPU filosu neden ayrı bir problem?
Veri merkezinde bir teknisyen birkaç dakikada rafa ulaşır; AI-RAN'da GPU'lar binlerce sahaya dağılır ve saha ziyareti saatler sürer. Bu yüzden uzaktan tespit, trafiği komşu hücreye kaydırma ve uzaktan reset/yeniden provisioning birinci hat olur, fiziksel müdahale son çaredir.
Notun kaynakları
- Meta report details hundreds of GPU and HBM3 related interruptions to Llama 3 training run (DCD, 2024)
- Automate Kubernetes AI Cluster Health with NVSentinel (NVIDIA Developer Blog, Aralık 2025, Mart 2026 güncellemesi)
- AutoClusters: minimizing GPU cluster failures (Crusoe, Şubat 2026)
- New in Together GPU Clusters: Autoscaling, observability, and self-healing (Together AI, Mart 2026)
- Nokia and NVIDIA Launch First GPU-Based AI-RAN (TechTimes, Temmuz 2026)
- SoftBank launches sovereign AI GPU cloud (RCR Wireless, Mayıs 2026)
- Turkcell ve Google'dan dev stratejik anlaşma (Ekonomi Gazetesi, Kasım 2025)
- Energy and AI: Executive Summary (IEA, 2025)
Sunum stili
12 slayt. Tıklarsan sunum o slayttan başlar.
Slayt notları
Binlerce GPU'da arıza bir olay değil, bir oran. Bu deste o oranla sistem olarak nasıl yaşanacağını anlatıyor.
Llama 3 eğitiminde 16 bin GPU'luk küme 54 günde 419 kesinti yaşadı; kabaca üç saatte bir.
Meta'nın araştırma kümeleri verisi, 2024. Arızalar işlerin binde 2'sini vurmuş ama çalışma süresinin yüzde 18,7'sini yemiş.
Her aile ayrı sinyal ve ayrı aksiyon ister. Delta verisinde H100'de bellek hataları A100'e göre GPU başına yaklaşık 3,2 kat daha sık.
Pasif katman ucuz ama yavaş bozulmayı kaçırır. Korelasyon en çok atlanan katman.
Kubernetes'te cordon ve drain hazır ilke. Kendi scheduler'ınız varsa her birini yeniden tanımlar, onarımı idempotent bir Ansible playbook'una bağlarsınız.
Lemon node'ları ayıklamak Meta'da büyük işlerin başarısızlık oranını yüzde 14'ten yüzde 4'e indirdi.
Kendini onaran sistem yanlış bir sinyalle kendini yok edebilir. Frenler tasarımın parçası, sonradan eklenen bir özellik değil.
İyi kural: otomasyon tek node'da cesur, çok node'da korkak olmalı.
3GPP SON çerçevesi self-healing'i LTE'den beri tanımlıyor. Nokia'nın Temmuz 2026'daki GPU tabanlı AI-RAN'ı aynı mantığı GPU'ya taşıyor.
Kubernetes dışında kendi scheduler'ını işleten ekipler bu döngüyü hâlâ kendileri kuruyor.
GPU kiralayan ekipler için soru: sağlayıcınızın ortalama onarım süresi ve yedek havuzu ne?