Herhangi bir veri merkezi için büyük ve karmaşık GPU kümelerini işletmek, cesaret gerektiren bir iş! Yönetilmesi gereken büyük bir karmaşıklık mevcut. Soğutma, enerji, ağ durumu ve kuşkusuz fan değiştirme döngüleri gibi basit görünen unsurlar bile etkili bir şekilde yönetilmeli ve hızlandırılmış hesaplama veri merkezlerinde iyi bir şekilde yönetilmelidir.
Artık veri merkezinize doğrudan sohbet ederek GPU kümesi güvenilirliğini kontrol edebildiğinizi hayal edin. “Veri merkezimizde en sık değiştirdiğimiz 5 parçadan hangisinde en fazla tedarik zinciri riski var?” gibi bir soruyu düşünün veya “Her GPU kümesini inceleyin ve arıza riski en yüksek olan %5’lik grubu çözmek için en uygun teknisyeni atayın.” gibi daha karmaşık bir görev.
Bu tür soruları cevaplamak için NVIDIA ekibi olarak, projemize LLo11yPop (LLM + Gözlemlenebilirlik) adını vererek, gözlemlenebilirlik için bir AI ajan çerçevesi geliştirmeye başladık. Bu çerçeve, OODA döngüsü (gözlem, yönlendirme, karar verme, eylem) üzerine inşa edilmiştir.
GPU Kümeleriyle Sohbet Etmenizi Sağlayan Bir Gözlemlenebilirlik Ajanı Çerçevesi
NVIDIA DGX Cloud ekibi, tüm büyük bulut hizmeti sağlayıcılarını ve kendi veri merkezlerimizi kapsayan global bir GPU filosunu yönetmektedir. Hızlandırılmış veri merkezlerinin global yapımının devam etmesiyle birlikte, filoyu gözlemlemek için tamamen yeni yollar bulmamız gerekti.
Hızlandırılmış Veri Merkezlerini İzleme
Her yeni GPU sürümüyle birlikte, gözlemlenebilirlik ihtiyacı da büyümektedir. Kullanım oranı, hatalar ve veri akışı gibi standart veri merkezi metrikleri temel düzeydir.
Yeni nesil veri merkezlerinde nelerin olup bittiğini gerçekten anlayabilmek için, çevredeki fiziksel ortama dair her şeyi göz önünde bulundurmalısınız:
- Isı
- Nem
- Güç istikrarı
- Gecikme
Hızlandırılmış AI iş yüklerini profil oluşturmak için kritik olan birçok metrik bulunmaktadır. GPU kümeleri için temel model eğitimi açısından tasarlanan bu karmaşıklıklar, teknolojinin sunduğu imkanları kullanmamızı zorunlu kılmaktadır.
Bu amaçla, ekibimizin ilk hedefi, GPU kümeleriyle etkili bir iletişim kurabilen bir sistem inşa etmekti. NVIDIA NIM mikroservisleri ilham kaynağımız oldu; veri tabanlarıyla sohbet edebilmenin yanı sıra gözlemlenebilirlik sistemlerinden gelen yüksek boyutlu verilerle bir bağlantı oluşturmak için bu yeteneği kullanmak istedik.
NVIDIA bünyesinde, filomuzda erişilebilen birçok gözlemlenebilirlik sistemimiz bulunmaktadır. Bu nedenle, insan dilinde Elasticsearch ile sohbet edebilmemizi sağlayan NIM mikroservislerini kullanmaya karar verdik. Böylece, sistem soruları “Filomuzda fan arızaları en çok kime sahiptir?” gibi doğal bir şekilde yanıtlayabiliyor.
Model Mimarisi
Şekil 1’de tipik ajan türleri gösterilmektedir:
- Yönetici
- Yönlendirme ajanları: Soruları doğru analiste yönlendirir ve sonuç olarak en uygun eylemi seçer.
- İşçi
- Analiz ajanları: Belirli bir işlevsel alanda eğitilmişlerdir. Kullanılabilir verileri anlamlandırır ve geniş soruları, geri alma ajanlarının yanıtlayacağı spesifik sorulara çevirir.
- Eylem ajanları: Gözlemlerden sonra bir eylem başlatmak için yönlendirici tarafından koordine edilir.
- Uzman
- Geri alma ajanları: Belirli bir konudaki soruları, veri kaynakları veya hizmet uç noktalarında çalışan kodlara dönüştürür.
- Görev yürütme ajanları: Genellikle bir iş akışı motoru aracılığıyla belirli bir görevi yerine getirir.
Tüm ajanlar, bilgi çalışmaları yapan insan organizasyonlarında görülmesi olası hiyerarşik bir yapıya sahiptir. Yönetici, görevleri yönlendirir; yöneticiler uzmanlık alanlarını kullanarak işleri tahsis eder; işçi ajanları ise belirli görevlere optimize edilmiştir.
Şekil 2, belirli bir tipin veri kaynaklarından gelen farklı telemetreleri analiz edebilmek için oluşturduğumuz spesifik ajanları göstermektedir.
Ayrıca, off-topic soruları tespit etmek için belirli bir tip ajana ihtiyaç duyduğumuzu keşfettik. Erken aşamada bu tür koruma olmadan, modelin sistemin kapsamından uzak konularda daha fazla “haliç başı” yaratma olasılığının arttığını gördük.
Çoklu LLM Bileşik Modeline Doğru Gelişim
Bunun çalışması için, kümeleri etkili bir şekilde yönetmek amacıyla tüm farklı telemetri türlerini ele almak için birden çok büyük dil modeli (LLM) kullanmamız gerektiğini fark ettik. GPU metrikleri gerekli olsa da, ilgili tüm katmanları anlamak için yeterli değildir: GPU katmanından, Kubernetes gibi orkestrasyon katmanlarına kadar her şey düşünülmelidir.
Daha fazla bilgi için Modelden Bileşik AI Sistemlerine Geçiş başlıklı yazıya göz atabilirsiniz.
Ajanların Karışım Tekniğini Kullanma
Bu çeşitli ihtiyaçları karşılamak amacıyla, başlangıçta bir ajan karışımı (MoA) yaklaşımını benimsedik. Öncelikle GPU küme işletim parametreleri, Slurm iş verileri ve sistem lojistik desenleri gibi alanlarında uzman analist ajanları geliştirdik. Sonrasında, plan oluşturma ve görev atama görevini üstlenecek bir denetleyici model geliştirdik.
Tüm bunu, ilk versiyonun kullanımına sunulmadan önce prompt mühendisliği kullanarak gerçekleştirdik. Şekil 3, Slurm iş verileri hakkında bir soru sorduğumuzda, bir yanıt ve destekleyici bir grafiği geri aldığımız süreçleri göstermektedir.
Şekil 3’te, kaynak yönetimi ekibimizin, belirli bir bulut sağlayıcısı içinde yönettiğimiz tüm kümelerde Slurm iş hatalarıyla ilgili eğilimleri anlamak için ihtiyaç duyduğu bilgileri gösteriyoruz.
Bu sorular, denetleyici ajana iletilir ve doğru cevabı verecek olan ajan atanır. Bu durumda, Elasticsearch Slurm analisti seçilmiştir. Ajan, sorunun ihtiyaçları doğrultusunda, bir ya da birden fazla sorgu ajanından veri toplar. Bu durumda, Elasticsearch sorgu aracı, soruyu Elasticsearch REST arayüzü tarafından anlaşılacak SQL biçimine dönüştürmektedir.
Genellikle, bu ilk sorguyu kullanarak bir eğilimi anlamaya çalışırız, ardından daha fazla soru sorup aynı modelle daha derinlemesine inebiliriz. Belki Mayıs ayındaki normalden fazla hatanın nedenini keşfetmek için detaya inmek isteyebiliriz ya da başka analistlerden derinlemesine bir inceleme talep edebiliriz.
Hızlı bir yanıt almanın, bir grafiği görmenin ve sonraki soruya geçiş yapmanın sağladığı avantajlarla, GPU tahsisatından, sorun yaşama ihtimali en yüksek GPU kümeleri üzerinde daha fazla tanı koyabilme yetkisine sahibiz.
Bir ajan sürüsü tekniği kullanarak, bir dizi küçük, hedefe yönelik model bir araya getirdik ve birkaç ilginç optimizasyon gerçekleştirdik. Örneğin, Elasticsearch’ün anlayacağı SQL’yi geçebilen modelleri önceden oluşturulan daha büyük LLM’lerden elde ettiğimiz temel modellerle iyi bir şekilde ayrıştırarak, planlama görevlerinden yürütme ajanlarını yönlendirmek üzere işlevsellik kazandık.
Cevap ve Eylemlerden OODA Döngüleri ile Otonom Ajanlara Geçiş
Analiz ajanlarımızdan güvenilir yanıtlar aldığımızı gösterdiğimizde, şüphesiz ki, döngüyü kapatma fikri doğal bir sonraki adımdı. Bu, bir otonom denetleyici ajan oluşturma fikrini ortaya çıkardı. Eğer denetleyici ajan bir AI mühendislik yöneticisi olsaydı, onun için bir hedef belirler ve bu hedef doğrultusunda görev atarız. Bununla birlikte, AI yöneticisinin bir OODA döngüsünde çalışmasını bekleriz.
GPU Küme Güvenilirliğini Sağlama
Denetleyici AI ajanının daha iyi bir güvenilirlik elde etmesi için şu adımları gerçekleştirmesi gerekmektedir:
- Gözlem yaparak gözlemlenebilirlik sisteminden verileri anlamalıdır.
- Yönlendirme yaparak analiz gerçekleştirecek doğru ajanları seçmelidir.
- Karar verme sürecinde alınacak eylemi belirlemelidir.
- Eylemi başlatma adımını gerçekleştirmelidir.
Elbette, AI yöneticisinin doğru kararlar almak için yeterli güvene sahip olması adına, çoğu ilk eylemi bir site güvenilirlik mühendisinin (SRE) incelemesi ve müdahale edip etmeyeceği hakkında bilgi vermesini içeriyor. Bu, insan davranışını taklit eden bir süreçtir.
Otonom veri merkezi operasyonları, insan destekli sürüşten tamamen otonom bir yapıya kadar uzanan bir spektrumda bulunmaktadır. İlk benimseme aşamasında, her zaman insanların sürecin içinde olması gerekir.
Bir küme optimizasyon önerisi aldığımızda, SRE ekibimiz öneriyi inceleyip doğrulamakta, geçerli ise gerekli adımları atmaktadir. Eğer geçerli değilse öneride neyin yanlış olduğunu açıkça iletmektedirler. Bu, zamanla sistemin iyileşmesi için gerekli olan insan geribildirimine (RLHF) dayalı bir döngü oluşturmaktadır ve bu geri bildirim, sistemden alınan telemetri ile birleştirilir.
LLM Hiyerarşilerine Dair Test Piramidi
Geleneksel mikro hizmet mimarisinde, genellikle belirli hizmetlerin testleri, kendi birim, fonksiyonel veya uçtan uca testleri olduğu görülmektedir. Geleneksel mikro hizmetler ile benzer şekilde, bireysel bileşenlerde daha fazla test yapılması en verimli yöntemdir; yükseltiğimizde ise kapsamlı testlerin sayısı azalır (Şekil 4). Bu durum, alt seviyelerde hızlı geri bildirim sağlama ve üst seviyelerde kapsamlı değerlendirme gibi iki hedefi dengelemenizi sağlar.
LLM testi, tek bir yazının ötesine geçen büyük bir konu olmasına rağmen, klasik yazılım birim testleri çerçevesinin önemli ölçüde değişeceğini belirtmek önemlidir.
Örneğin, LLM’ye “Kaç GPU normal sıcaklık aralığını aştı?” gibi bir soru sorduğunuzda, “Üç,” “Üç GPU aştı,” “3,” “3.00” gibi çeşitli yanıtlar alabilirsiniz. Bu nedenle, 200’ü aşkın testin bulunduğu bir test dizisinde cevabın kavramsal eşdeğerliğini doğrulamak üzere genellikle daha güçlü bir LLM kullanacağız. Bu testler, sistemin her bir sürümünde çalışılmaktadır.
Gözlemlenebilirlik AI Ajanı inşasından öğrenilen dersler
Öncelikle, bir model eğitmeye veya ayarlamaya hemen atlamamalısınız ve açıkça belirtmek gerekirse, başlangıçta bunu yapmamalısınız. İşlevsel bir prototip oluşturmak için, prompt mühendisliğini ve bir dizi NIM mikroservisinin bir araya getirilmesini sağladık.
Sistemde kullanılan önemli modeller arasında Mixtral 8x7b ve daha yakın zamanda Llama 3.1 405b NIM modeli bulunmaktadır. Başlangıç yapmanızı sağlar ve grafikteki her düğüm için hangi modeli kullanacağınızı seçme özgürlüğü verir. Bu aşamada herhangi bir model eğitiminde köklü bir maliyet yoktur. Bu şekilde, düzgün bir şekilde çalışan bir şey elde ettiğinizde, ardından belirli modelleri daha yüksek doğrulukla iyileştirme amacıyla ince ayar yapabilirsiniz.
İkinci olarak, doğru işe doğru modeli seçin. Kodlama modelleri, insan-dan-SQL veya çıktı formatlama gibi işlemlerde harikadır. Daha basit alanlarda daha küçük modeller kullanmak hem hızı artırabilir hem de maliyetleri azaltabilir. En zor görevler için ise genellikle daha büyük modeller kullanın; buna, daha fazla bağlama ihtiyaç duyulan yönetici düzeyindeki görevler dahildir.
Son olarak, eylemleri ve kararları tam otonomiye geçmeden önce, bu sistemin doğru, kullanışlı ve güvenli olduğuna dair güçlü bir kanıtınız olmayan sürece insanlar devrede olmalıdır. Tam otonom sistemler üretime geçmeden önce, daha fazlasını başarılı bir şekilde sağlamak için “yürümek” gerekir, dolayısıyla “koşmak” için öncelikle güven sağlamak önemlidir.
Aİ Ajan Uygulamaları İnşa Etmeye Başlayın
NVIDIA generatif AI teknolojilerini ve araçlarını nasıl kullanabileceğiniz hakkında daha fazla bilgi için ai.nvidia.com adresini ziyaret edebilirsiniz veya NVIDIA NIM API’lerini deneyebilirsiniz.
Eğer yeni başlıyorsanız, İlk LLM Ajan Uygulamanızı İnşa Etme konusundaki makalemize göz atın.