Açık kaynak gpuwaste aracı, varsayılan Kubernetes ayarlarının israf edilen GPU harcamasını gizlediğini gösteriyor

Bir geliştirici, bir Kubernetes cluster'ının ödediği ama gerçekte kullanmadığı GPU saatlerini ölçen açık kaynak bir araç olan gpuwaste'ü yayınladı. dev.to'daki bir yazıya göre, aracın gerçek üretim cluster'larında çalıştırılması tutarlı bir sonuç ortaya koydu: Tek biri bile bu soruya kutudan çıktığı haliyle yanıt veremiyordu ve her başarısızlık, kimsenin değiştirmediği yapılandırma varsayılanlarına dayanıyordu.

Standart utilization metriği meşguliyeti ölçer, faydalı işi değil

Neredeyse her GPU panosu DCGM_FI_DEV_GPU_UTIL üzerine inşa edilidir. Yazarın açıkladığı gibi, bu sayaç, cihazda en az bir kernel'in yerleşik olduğu sürenin oranını bildirir — o kernel'in anlamlı bir iş yapıp yapmadığı konusunda hiçbir şey söylemez. GPU'yu önemsiz bir döngüyle meşgul tutan bir süreç, hiçbir şey hesaplamasa bile tam kullanımda görünür.

Yazıya göre gerçek hesaplamayı yansıtan metrikler, streaming multiprocessor doluluğunu izleyen DCGM_FI_PROF_SM_ACTIVE ve tensor core etkinliğini izleyen DCGM_FI_PROF_PIPE_TENSOR_ACTIVE. İkisi arasındaki geniş fark — yüksek engine etkinliği ile neredeyse sıfır tensor etkinliğinin bir arada olması — GPU'nun makine öğrenmesinden başka bir şeyle meşgul olduğunu düşündürür. Yazar bu desene "hayalet iş" (ghost work) adını veriyor ve incelenen her panoda görünmez kaldığını bildiriyor, çünkü o panolar yanlış sayıyı çiziyordu.

GPU metrikleri yanlış pod'a atfediliyor

Daha ince bir sorun da atıf (attribution) konusunu etkiliyor. dcgm-exporter, workload pod etiketlerini yalnızca DCGM_EXPORTER_KUBERNETES=true ile Kubernetes pod eşlemesi etkinleştirildiğinde ekler. Bu olmadan, Prometheus GPU serilerini scrape hedefinin kendi kimliğiyle etiketler; böylece kullanım, monitoring namespace'indeki nvidia-dcgm-exporter-xxxxx gibi bir isme yazılır.

Bu nedenle veriler eksiksiz görünür: Her serinin bir namespace'i ve bir pod'u vardır ve pod'a göre gruplamak düzgün bir grafik üretir. Ama yazının deyişiyle, her GPU saati, onu tüketen workload yerine onu ölçen exporter'a atfedilir. Ucuz ipucu, GPU metriklerindeki pod isimlerini kube_pod_container_resource_requests'tekilerle karşılaştırmaktır — iki küme kesişmiyorsa atıf uydurmadır.

En değerli sayaçlar varsayılan olarak kapalı

Gerçek işi hayalet işten ayıran DCGM_FI_PROF_* metrikleri, exporter'ın sayaç yapılandırmasında profillemesinin etkinleştirilmesini gerektirir. İncelenen cluster'larda etkin değildi. Yazı, bu başarısızlığın sessiz olduğunu vurguluyor: Metrik hata vermeden hiçbir şey döndürmüyor, bu yüzden üzerine inşa edilen her şey sessizce gerçektekinden azını bildiriyor.

Kendinden emin yanlış bir sayı neredeyse yayına girdi

En öğretici başarısızlık, aracın kendi geri dönüş (fallback) yolundan geldi. Profilleme sayaçları eksik olduğunda utilization, güç tüketiminden kaba bir şekilde çıkarılabilir — boştaki bir A100, 400W TDP'ye karşılık yaklaşık 55W'de dururken, meşgul olanı tavana yaklaşır. Yazar bu geri dönüşü bilinmeyen GPU modelleri için genel bir 50–350W aralığıyla kurdu, sonra gerçek aralığı 15–130W olan bir kartta çalıştırdı.

Araç, bir GPU'nun yüzde 5 utilization'da ve framebuffer'ının yüzde 88'i dolu olduğunu bildirdi — yüklenmiş ama hiçbir iş sunmayan bir model — ve aylık 3.327 dolarlık bir israftan kendinden emin bir şekilde söz etti. Yazar başlangıçta buna inandı ve bunu yaklaşımın işe yaradığına dair ilk gerçek kanıt olarak sundu. Kart sağlıklıydı; genel aralık, kartın tüm çalışma aralığını boşta görünecek şekilde sıkıştırmıştı. Geri dönüşü GR_ENGINE_ACTIVE'e — watt'tan çıkarsama değil doğrudan bir ölçüm — geçirmek bulguyu ortadan kaldırdı.

Belirtilen ders şu: Bozuk girdilerden kendinden emin sayılar üreten bir maliyet aracı, hiç araç olmamasından daha kötüdür — çıktı, ekran görüntüsü olarak bir bütçe toplantısına gidiyordu. gpuwaste'ün sonraki sürümleri eksik veri olduğunu varsayar ve bunu söyler: Bir günden kısa gözlem pencerelerinden aylık maliyet projeksiyonu yapmayı reddeder, bulamadıkları her metriği adlandırır ve utilization tahmini olduğunda bunu tahmini olarak etiketler.

Kendi cluster'ınızı kontrol etme

Yazı, Prometheus'a karşı beş dakikalık, salt okunur bir kontrol öneriyor:

count({name=~"DCGM_FI_PROF_.*"}) count by (pod) (DCGM_FI_DEV_FB_USED) count by (pod) (kube_pod_container_resource_requests{resource="nvidia_com_gpu"})

İlk sorgunun boş dönmesi, profilleme sayaçlarının devre dışı olduğu anlamına gelir. İkinci ve üçüncü sorgulardaki pod isimleri örtüşmüyorsa, GPU metrikleri onları tüketen workload'lara atfedilmiyordur. Her iki düzeltme de tek satırlık yapılandırma değişiklikleridir ve hiçbiri varsayılan olarak açık değildir.

Aracın kendisi

gpuwaste bilinçli olarak gösterişsizdir: Dışa aktarılan metrikleri alır, utilization'ı tahsisle birleştirir ve ödenen ama kullanılmayan GPU saatlerini bir dolar rakamıyla raporlar. Üretim metrik uç noktaları genellikle doğrudan erişimi engelleyen ağ politikalarının ve mTLS'in arkasında bulunduğundan, tamamen çevrimdışı olarak CSV dışa aktarımından çalışır. Ayrıca, canlı bir cluster'a dokunmadan çıktının otuz saniyede değerlendirilebilmesi için bir sentetik veri üreteciyle birlikte gelir.

Neden önemli

GPU kapasitesi, modern altyapının en pahalı kalemlerinden biridir ve onunla ilgili kararlar giderek panosu telemetrisinden alınmaktadır. Varsayılan boru hattı (pipeline) utilization'ı olduğundan fazla gösteriyorsa, harcamayı workload'lar yerine monitoring pod'larına atfediyorsa ve gerçek eğitim ile hayalet işi ayırt eden tek sayaçları sessizce düşürüyorsa, FinOps konuşmaları her iki yönde de kurgu üzerinde yürütülüyor demektir.

Yazının pratik değeri, her cluster operatörünün bugün çalıştırabileceği iki satırlık bir denetim ve GPU'ların ötesine genelleşen bir tasarım ilkesidir: Kendi kör noktalarını açıklayan araçlar, onları kendinden emin sayıların arkasına saklayan araçlardan daha savunulabilirdir.