AI/ML Datalake için Referans Mimarisi Oluşturmaya Yönelik Mimar Kılavuzu

Bu gönderinin kısaltılmış bir versiyonu 19 Mart 2024'te The New Stack'te yayınlandı. Kurumsal yapay zekada iki ana model türü vardır: ayırt edici ve üretken. Ayırıcı modeller verileri sınıflandırmak veya tahmin etmek için kullanılırken, üretken modeller yeni veriler oluşturmak için kullanılır. Her ne kadar Üretken Yapay Zeka son zamanlarda haberlere hakim olsa da kuruluşlar hâlâ her iki yapay zeka türünün de peşinde. Ayrımcı yapay zeka, daha verimli çalışmak ve ek gelir akışları elde etmek isteyen kuruluşlar için hâlâ önemli bir girişim olmaya devam ediyor. Bu farklı yapay zeka türlerinin pek çok ortak noktası vardır ancak aynı zamanda yapay zeka veri altyapınızı oluştururken dikkate alınması gereken önemli farklılıklar da vardır. Kuruluşlar, İş Zekası, Veri Analitiği ve Veri Bilimi gibi iş yüklerini kendi hallerine bırakarak yalnızca yapay zeka ve yapay zekaya ayrılmış bir altyapı oluşturmamalıdır. Kuruluşun tüm ihtiyaçlarını (İş Zekası, Veri Analitiği, Veri Bilimi, ayrımcı yapay zeka ve Üretken yapay zeka) destekleyen eksiksiz bir veri altyapısı oluşturmak mümkündür. Başka bir gönderide iş zekası, veri analitiği, veri bilimi ve AI/ML ihtiyaçlarını karşılayabilen modern bir datalake için referans mimarisini sunduk. Modern Datalake Referans Mimarisini inceleyelim ve AI/ML iş yüklerini desteklemeye yönelik yeteneklerini vurgulayalım. Modern Datalake Referans mimarimizin temelini oluşturacak bir Modern Datalake tanımlayarak başlayalım. Bu mimari "geri dönüştürülmüş" değildir; daha ziyade geniş çapta uygulanabilir ilk mühendislik ilkelerini yansıtır. Modern Datalake, yarı Veri Ambarı ve yarı Veri Gölü'nden oluşur ve her şey için nesne depolamayı kullanır. Nesne depolaması, Veri Gölü'nün depolaması gereken yapılandırılmamış veriler için olduğundan, bir Veri Gölü için nesne depolamanın kullanılması son derece mantıklıdır. Bununla birlikte, bir Veri Ambarı için nesne depolamanın kullanılması tuhaf gelebilir; ancak bu şekilde oluşturulan bir Veri Ambarı, yeni nesil Veri Ambarlarını temsil eder. Bu, Netflix, Uber ve Databricks tarafından yazılan ve bir veri ambarında nesne depolamayı sorunsuz hale getiren Açık Tablo Formatı Spesifikasyonları (OTF'ler) sayesinde mümkün olmaktadır. OTF'ler Apache Iceberg, Apache Hudi ve Delta Lake'dir. Bunlar sırasıyla Netflix, Uber ve Databricks tarafından yazıldı; çünkü piyasada onların veri ihtiyaçlarını karşılayabilecek hiçbir ürün yoktu. Temelde hepsinin yaptığı şey (farklı şekillerde), nesne depolamanın (MinIO) üzerine inşa edilebilecek bir Veri Ambarı tanımlamaktır. Nesne depolama, diğer depolama çözümlerinin sağlayamayacağı ölçeklenebilir kapasite ve yüksek performansın birleşimini sağlar. Bunlar modern özellikler olduğundan, bölüm gelişimi, şema gelişimi ve sıfır kopya dallanma gibi eski moda veri ambarlarının sahip olmadığı gelişmiş özelliklere sahiptirler. Son olarak, Veri Ambarı nesne depolamayla oluşturulduğundan, aynı nesne deposunu görüntüler, video dosyaları, ses dosyaları ve belgeler gibi yapılandırılmamış veriler için kullanabilirsiniz. Yapılandırılmamış veriler genellikle endüstrinin veri gölü olarak adlandırdığı yerde depolanır. Hem veri gölünüzün hem de veri ambarınızın temeli olarak bir nesne deposunun kullanılması, tüm verilerinizi tutabilecek bir çözümle sonuçlanır. Yapılandırılmış depolama, OTF tabanlı Veri Ambarında bulunur ve yapılandırılmamış depolama, Veri Gölü'nde bulunur. Her ikisi için de aynı MinIO örneği kullanılabilir. MinIO olarak, OTF tabanlı Veri Ambarı ve Veri Gölü kombinasyonuna Modern Datalake adını veriyoruz ve bunu tüm AI/ML iş yüklerinizin temeli olarak görüyoruz. Verilerin toplandığı, depolandığı, işlendiği ve dönüştürüldüğü yerdir. Ayırt edici yapay zeka (denetlenen, denetlenmeyen ve takviyeli öğrenme) kullanan eğitim modelleri genellikle Veri Ambarında yaşayabilecek yapılandırılmış verileri işleyebilen bir depolama çözümü gerektirir. Öte yandan, Büyük Dil Modelleri (LLM) eğitimi veriyorsanız, yapılandırılmamış verileri veya belgeleri Veri Gölü'nde ham ve işlenmiş haliyle yönetmelisiniz. : Kaynak Modern Datalake Referans Mimarisi Bu gönderi, AI/ML için Modern Datalake Referans Mimarisinin farklı AI/ML iş yüklerini destekleyen alanlarına odaklanmaktadır. Bu fonksiyonel alanlar aşağıda listelenmiştir. Modern Datalake'in görsel bir tasviri yukarıda gösterilmiştir. Bu işlevsel alanların bulunabileceği katmanlar vurgulanmıştır. Ayırt edici yapay zeka Yapılandırılmamış Verilerin Depolaması Yarı Yapılandırılmış Verilerin Saklanması Veri Ambarında Sıfır Kopya Dallanma Üretken Yapay Zeka Vektör Veritabanıyla Özel Bir Corpus Oluşturma Belge Ardışık Düzeni Oluşturma Erişim Artırılmış Nesil (RAG) Büyük Dil Modellerinde İnce Ayar Yapma Yüksek Lisans Doğruluğunu Ölçme Makine Öğrenimi İşlemleri Bu gönderi aynı zamanda GPU'ların mevcut durumuna ve bunların AI veri altyapınızı nasıl etkilediğine de bakıyor. Ayrıca altyapınızı nasıl inşa edeceğinizi ve altyapınızı nasıl inşa etmeyeceğinizi gösteren birkaç senaryoya da bakacağız. Son olarak bu yazı, kendinize ait bir Yapay Zeka Veri Altyapısı oluşturmaya yönelik birkaç öneri sunuyor. GPU'ların Mevcut Durumu Aç GPU Sorunu Nesne Depolamayı Güçlendiriyor İki Organizasyonun Hikayesi Yapay Zeka Veri Altyapınızı Oluşturmaya Yönelik Bir Plan Ayırt edici yapay zeka Ayırt edici yapay zeka modelleri, eğitim için her türden veriye ihtiyaç duyar. Görüntü sınıflandırma ve konuşma tanıma modelleri, görüntü ve ses dosyaları biçimindeki yapılandırılmamış verileri kullanacaktır. Öte yandan sahtekarlık tespiti ve tıbbi teşhise yönelik modeller, yapılandırılmış verilere dayalı tahminler yapmaktadır. Ayırt edici yapay zekanın ihtiyaç duyduğu verileri depolamak ve işlemek için Modern Datalake'te mevcut seçeneklere bakalım. Yapılandırılmamış Verilerin Depolaması Yapılandırılmamış veriler, modellerin eğitimi ve test edilmesi için kullanılabilecek Veri Gölü'nde bulunacaktır. Belleğe sığabilecek eğitim setleri, eğitimden önce (epoch döngünüz başlamadan önce) yüklenebilir. Bununla birlikte, eğitim setiniz büyükse ve belleğe sığmayacaksa, eğitimden önce nesnelerin bir listesini yüklemeniz ve epoch döngünüzdeki her bir toplu işlemi işlerken gerçek nesneleri almanız gerekecektir. Data Lake'inizi yüksek hızlı bir ağ ve yüksek hızlı disk sürücüleri kullanarak oluşturmazsanız, bu durum Data Lake'inizi zorlayabilir. Belleğe sığamayan verileri içeren modelleri eğitiyorsanız Data Lake'inizi 100 GB ağ ve NVMe sürücüleriyle oluşturmayı düşünün. Yarı Yapılandırılmış Verilerin Saklanması Modern Datalake'te Parke dosyaları, AVRO dosyaları, JSON dosyaları ve hatta CSV dosyaları gibi yarı yapılandırılmış dosyaları depolamak için birkaç seçenek mevcuttur. Yapılacak en kolay şey, bunları Veri Gölünüzde depolamak ve yapılandırılmamış nesneleri yüklediğiniz şekilde yüklemektir. Bu yarı yapılandırılmış dosyalardaki verilere Modern Datalake'in desteklediği diğer iş yükleri (İş Zekası, Veri Analitiği ve Veri Bilimi) ihtiyaç duymuyorsa bu en iyi seçenektir. Diğer bir seçenek de bu dosyaları diğer iş yüklerinin kullanabileceği Veri Ambarınıza yüklemektir. Veriler Veri Ambarınıza yüklendiğinde şunları kullanabilirsiniz: verilerinizle. Deneyleri gerçekleştirmek için Sıfır Kopya Dallanma Veri Ambarında Sıfır Kopya Dallanma Özellik mühendisliği, bir modeli eğitmek için kullanılan veri kümelerini iyileştirmeye yönelik bir tekniktir. OTF tabanlı Veri Ambarlarının sahip olduğu çok şık bir özellik Sıfır kopya dallanmadır. Bu, kodun Git deposunda dallara ayrılmasıyla aynı şekilde verilerin dallara ayrılmasına olanak tanır. Adından da anlaşılacağı gibi, bu özellik verilerin bir kopyasını oluşturmaz; bunun yerine, verilerin benzersiz bir kopyasının görünümünü oluşturmak için Veri Ambarı'nı uygulamak için kullanılan açık tablo formatının meta veri katmanını kullanır. Veri bilimcileri bir dalda deneyler yapabilir; eğer deneyleri başarılı olursa, diğer veri bilimcilerin kullanması için dallarını ana dalla tekrar birleştirebilir. Deneme başarılı olmazsa dal silinebilir. Üretken Yapay Zeka İster Scikit-Learn ile oluşturulmuş küçük modeller, ister PyTorch veya TensorFlow ile oluşturulmuş özel sinir ağları, ister Transformer mimarisini temel alan Büyük Dil Modelleri olsun, tüm modeller girdi olarak sayılara ihtiyaç duyar ve çıktı olarak sayılar üretir. Bu basit gerçek, kelimelerin sayılara (veya göreceğimiz gibi vektörlere) dönüştürülmesinin gerektiği Üretken Yapay Zeka ile ilgileniyorsanız, Yapay Zeka/Makine Öğrenimi altyapınıza birkaç ek gereksinim getirir. Yüksek Lisans'ların ürettiği yanıtları geliştirmek için şirketinizin özel bilgilerini içeren özel belgeleri kullanmak istiyorsanız, üretken bir yapay zeka çözümü daha da karmaşık hale gelir. Bu geliştirme, Alma Artırılmış Üretim veya Yüksek Lisans İnce Ayarı şeklinde olabilir. Bu bölümde tüm bu teknikler (kelimelerin sayılara dönüştürülmesi, RAG ve İnce ayar) ve bunların yapay zeka altyapısı üzerindeki etkileri tartışılacaktır. Özel Bir Corpus'un nasıl oluşturulacağını ve nerede bulunması gerektiğini tartışarak başlayalım. Vektör Veritabanıyla Özel Bir Corpus Oluşturma Üretken yapay zeka konusunda ciddiyseniz özel derleminiz kuruluşunuzu tanımlamalıdır. Başka hiç kimsenin sahip olmadığı bilgilere sahip belgeler içermeli ve yalnızca doğru ve doğru bilgileri içermelidir. Ayrıca, özel derleminiz bir Vektör Veritabanı ile oluşturulmalıdır. Bir vektör veritabanı, belgelerinizin sayısal temsilleri olan vektör yerleştirmelerinin yanı sıra belgelerinizi indeksler, saklar ve bunlara erişim sağlar. (Bu, yukarıda açıklanan sayı problemini çözer.) Vektör Veritabanları anlamsal aramayı kolaylaştırır. Bunun nasıl yapılacağı çok fazla matematiksel altyapı gerektirir ve karmaşıktır. Ancak anlamsal aramanın kavramsal olarak anlaşılması kolaydır. Diyelim ki “yapay zeka” ile ilgili her şeyi tartışan tüm belgeleri bulmak istiyorsunuz. Bunu geleneksel bir veritabanında yapmak için, "yapay zeka"nın olası tüm kısaltmalarını, eşanlamlılarını ve ilgili terimlerini aramanız gerekir. Sorgunuz şuna benzer: SELECT snippet FROM MyCorpusTable WHERE (text like '%artificial intelligence%' OR text like '%ai%' OR text like '%machine learning%' OR text like '%ml%' OR ... and on and on ... Manuel benzerlik araması sadece zorlu ve hataya açık olmakla kalmaz, aynı zamanda aramanın kendisi de çok yavaştır. Bir vektör veritabanı aşağıdaki gibi bir isteği alabilir ve sorguyu daha hızlı ve daha doğru bir şekilde çalıştırabilir. Alma Artırılmış Üretimi kullanmak istiyorsanız anlamsal sorguları hızlı ve doğru bir şekilde çalıştırma yeteneği önemlidir. { Get { MyCorpusTable(nearText: {concepts: ["artificial intelligence"]}) {snippet} } } Özel derleminiz için bir diğer önemli husus güvenliktir. Belgelere erişim, orijinal belgeler üzerindeki erişim kısıtlamalarına uymalıdır. (Bir stajyerin, CFO'nun henüz Wall Street'te açıklanmayan mali sonuçlarına erişebilmesi talihsiz bir durum olacaktır.) Vektör veritabanınız içinde, orijinal içeriğin erişim düzeyleriyle eşleşecek şekilde yetkilendirme yapmalısınız. Bu, Vector veritabanınızı kuruluşunuzun Kimlik ve Erişim Yönetimi çözümüyle entegre ederek yapılabilir. Vektör veritabanları özünde yapılandırılmamış verileri depolar. Bu nedenle Data Lake'inizi depolama çözümü olarak kullanmaları gerekir. Belge Ardışık Düzeni Oluşturma Ne yazık ki çoğu kuruluşun temiz ve doğru belgeleri içeren tek bir deposu yoktur. Bunun yerine belgeler, çeşitli ekip portallarında birçok formatta kuruluş geneline yayılır. Sonuç olarak, özel bir derleme oluşturmanın ilk adımı, yalnızca Generative AI ile kullanılması onaylanmış belgeleri alan bir işlem hattı oluşturmak ve bunları vektör veritabanınıza yerleştirmektir. Büyük küresel kuruluşlar için bu, bir Üretken Yapay Zeka çözümünün potansiyel olarak en zor görevi olabilir. Ekiplerin portallarında taslak formatta belgelere sahip olması yaygındır. Ne olabileceğine dair rastgele düşünceler içeren belgeler de olabilir. Bu belgeler, işletmeyi doğru şekilde temsil etmedikleri için özel bir külliyatın parçası haline gelmemelidir. Maalesef bu belgeleri filtrelemek manuel bir çaba olacaktır. Bir belge hattı aynı zamanda belgeleri metne dönüştürmelidir. Neyse ki, birkaç açık kaynak kütüphanesi bunu birçok yaygın belge formatı için yapabilir. Ek olarak, bir belge hattının belgeleri vektör veritabanına kaydetmeden önce küçük bölümlere ayırması gerekir. Bunun nedeni, bu belgelerin daha sonraki bir bölümde tartışılacak olan Erişim Artırılmış Oluşturma için kullanıldığında bilgi istemi boyutundaki sınırlamalardır. Büyük Dil Modellerinde İnce Ayar Yapma Büyük bir dil modeline ince ayar yaptığımızda, onu özel derlemdeki bilgilerle biraz daha eğitiriz. Bu, alana özgü bir Yüksek Lisans derecesi almanın iyi bir yolu olabilir. Bu seçenek, özel derlemenize göre ince ayar yapmak için bilgi işlem gerektirse de, bir modeli sıfırdan eğitmek kadar yoğun değildir ve mütevazı bir zaman diliminde tamamlanabilir. Alanınız günlük kullanımda bulunmayan terimler içeriyorsa, ince ayar yapmak LLM'nin yanıtlarının kalitesini artırabilir. Örneğin, tıbbi araştırmalardan, çevre araştırmalarından ve doğa bilimleriyle ilgili herhangi bir şeyden elde edilen belgeleri kullanan projeler ince ayardan yararlanabilir. İnce ayar, belgelerinizde bulunan son derece spesifik yerel dili alır ve bunları modelin parametrik parametrelerine dönüştürür. Bu yaklaşıma karar vermeden önce ince ayarın avantaj ve dezavantajları anlaşılmalıdır. Dezavantajları İnce ayar, bilgi işlem kaynakları gerektirecektir. Açıklanabilirlik mümkün değildir. Derleminiz geliştikçe yeni verilerle periyodik olarak yeniden ince ayar yapmanız gerekecektir. Halüsinasyonlar endişe vericidir. Belge düzeyinde güvenlik imkansızdır. Avantajları LLM, ince ayar yoluyla özel korpusunuzdan bilgi alır. Çıkarım akışı RAG'dan daha az karmaşıktır. İnce ayar, bir Yüksek Lisans'a işletmenizin dilini öğretmenin iyi bir yolu olsa da, çoğu Yüksek Lisans'ın milyarlarca parametre içermesi nedeniyle verileri seyreltir ve verileriniz tüm bu parametrelere yayılır. İnce ayarın en büyük dezavantajı belge düzeyinde yetkilendirmenin imkansız olmasıdır. Bir belge İnce ayar için kullanıldığında, bilgileri modelin bir parçası haline gelir. Bu bilgilerin kullanıcının yetki seviyelerine göre sınırlandırılması mümkün değildir. Özel verilerinizi ve parametrik verilerinizi çıkarım anında birleştiren bir tekniğe bakalım. Erişim Artırılmış Nesil (RAG) Erişim Artırılmış Üretim (RAG), sorulan soruyla başlayan bir tekniktir; soruları ek verilerle birleştirmek için bir vektör veritabanı kullanır ve ardından soruyu ve verileri içerik oluşturmak için bir Yüksek Lisans'a aktarır. RAG ile herhangi bir eğitime gerek yoktur çünkü LLM'yi kaliteli belgeler topluluğumuzdan ilgili metin parçacıklarını göndererek eğitiriz. Soru yanıtlama görevi kullanılarak şu şekilde çalışır: Bir kullanıcı, uygulamanızın kullanıcı arayüzünde bir soru sorar. Uygulamanız soruyu - özellikle de içindeki kelimeleri - alacak ve bir vektör veritabanı kullanarak, bağlamsal olarak alakalı metin parçacıkları için kaliteli belgeler topluluğunuzda arama yapacaktır. Bu parçalar ve orijinal soru Yüksek Lisans'a gönderilir. Bu paketin tamamı - soru artı parçacıklar (bağlam) bilgi istemi olarak bilinir. Yüksek Lisans bu bilgiyi cevabınızı oluşturmak için kullanacaktır. Bu aptalca bir şey gibi görünebilir - eğer cevabı (parçacıkları) zaten biliyorsanız, neden Yüksek Lisans ile uğraşasınız ki? Bunun gerçek zamanlı olarak gerçekleştiğini ve amacın, araştırmanıza kopyalayıp yapıştırabileceğiniz bir metin oluşturmak olduğunu unutmayın. Özel derleminizdeki bilgileri içeren metni oluşturmak için Yüksek Lisans'a ihtiyacınız var. Bu, ince ayardan daha karmaşıktır. Ancak, belgeler (veya belge parçacıkları) çıkarım anında vektör veri tabanından seçildiği için kullanıcı yetkilendirmesi uygulanabilir. Dokümanlardaki bilgiler hiçbir zaman modelin parametrik parametrelerinin bir parçası haline gelmez. RAG'ın avantajları ve dezavantajları aşağıda listelenmiştir. Dezavantajları Çıkarım akışı daha karmaşıktır. Avantajları LLM, özel külliyatınızdan doğrudan bilgiye sahiptir. Açıklanabilirlik mümkündür. İnce ayar yapılmasına gerek yoktur. Halüsinasyonlar önemli ölçüde azalır ve vektör veritabanı sorgularından elde edilen sonuçlar incelenerek kontrol edilebilir. Yetkilendirme uygulanabilir. Makine Öğrenimi İşlemleri (MLOps) MLOps'un önemini daha iyi anlamak için model oluşturmayı geleneksel uygulama geliştirmeyle karşılaştırmak faydalı olacaktır. Bir uygulamaya yeni bir özellik ekleyen yeni bir mikro hizmetin uygulanması gibi geleneksel uygulama geliştirme, bir spesifikasyonun gözden geçirilmesiyle başlar. Yeni veri yapıları veya mevcut veri yapılarında yapılacak değişiklikler ilk önce tasarlanır. Kodlama başladıktan sonra verinin tasarımı değişmemelidir. Daha sonra hizmet uygulanır ve kodlama bu süreçteki ana faaliyettir. Birim testleri ve uçtan uca testler de kodlanmıştır. Bu testler kodun hatalı olmadığını ve spesifikasyonu doğru şekilde uyguladığını kanıtlar. Uygulamanın tamamını dağıtmadan önce bir CI/CD işlem hattı tarafından otomatik olarak çalıştırılabilirler. Model oluşturmak ve onu eğitmek farklıdır. Ham verilerin anlaşılması ve gerekli tahmin ilk adımdır. ML mühendislerinin sinir ağlarını uygulamak veya bir algoritma oluşturmak için bazı kodlar yazması gerekir, ancak kodlama baskın etkinlik değildir. Tekrarlanan deneyler ana faaliyettir. Deney sırasında verilerin tasarımı, modelin tasarımı ve kullanılan parametrelerin tümü değişecektir. Her deneyden sonra modelin eğitilirken nasıl performans gösterdiğini gösteren ölçümler oluşturulur. Ayrıca bir doğrulama kümesine ve bir test kümesine göre model performansı için metrikler oluşturulur. Bu metrikler modelin kalitesini kanıtlamak için kullanılır. Bir model bir uygulamaya dahil edilmeye hazır olduğunda paketlenmesi ve konuşlandırılması gerekir. Makine Öğrenimi Operasyonlarının kısaltması olan MLOps, bu farklılıkları gidermeyi amaçlayan bir dizi uygulama ve araçtır. Deney takibi ve işbirliği, MLOP'larla en çok ilişkilendirilen özelliklerdir, ancak bugün sektördeki daha modern MLOP araçları çok daha fazlasını yapabilir. Örneğin, denemeleriniz için bir çalışma ortamı sağlayabilirler ve bir uygulamaya entegre edilmeye hazır olduklarında modelleri paketleyip dağıtabilirler. Aşağıda bugün MLOps araçlarında bulunan bir dizi özellik bulunmaktadır. Bu liste aynı zamanda destek ve veri entegrasyonu gibi dikkate alınması gereken diğer hususları da içerir. - MLOps teknikleri ve özellikleri sürekli olarak gelişmektedir. Önemli bir oyuncu tarafından desteklenen ve aracın sürekli olarak geliştirilip iyileştirildiğini garanti eden bir araç istiyorsunuz. Büyük bir oyuncunun desteği - Deneyler çok sayıda yapılandırılmış ve yapılandırılmamış veri üretir. İdeal olarak bu, Veri Ambarı ve Veri Gölü'nde saklanabilir. Bununla birlikte, birçok MLOps aracı, Modern Datalake'in ortaya çıkmasına neden olan Açık Tablo Formatlarından önce de mevcuttu, bu nedenle çoğu, yapılandırılmış verileri için ayrı bir çözüme sahip olacak. Modern Datalake Entegrasyonu - Her deneyin veri kümelerini, modellerini, hiperparametrelerini ve metriklerini takip edin. Deney izleme aynı zamanda tekrarlanabilirliği de kolaylaştırmalıdır. Deney Takibi - ekip üyelerinin, tüm makine öğrenimi mühendisleri tarafından yürütülen tüm deneylerin sonuçlarını görüntülemesine olanak tanıyın. İşbirliğini Kolaylaştırın - Modeli, diğer programlama ortamlarından erişilebilecek şekilde paketleyin. Model Paketleme - Modellerin bir kuruluşun resmi ortamlarına dağıtılması. Modellerinizi mevcut bir CI/CD hattına dahil etmenin bir yolunu bulduysanız buna ihtiyacınız olmayacak. Model Sunumu - Tüm modellerin tüm sürümlerini koruyun. Model Kaydı - Bazı araçlar, bir işlevin veya modelin bir kümede denemeler yürütmek için kapsayıcılı bir hizmet olarak dağıtılabileceği şekilde koda açıklama eklenmesine olanak tanıyan özellikler sağlar. Sunucusuz İşlevler - Bazı MLOps araçları, uçtan uca eksiksiz yetenekler sağlamayı amaçlar ve ham verilerinizi almak ve depolamak için işlem hatları oluşturmanıza olanak tanıyan özelliklere sahiptir. Zaten bir veri hattınız varsa buna ihtiyacınız olmayacak. Veri Hattı Yetenekleri - Sunucusuz işlevlerinizi Yönlendirilmiş Döngüsel Olmayan Grafik halinde düzenleme yeteneği. Ayrıca eğitim ardışık düzenlerinin planlanmasına ve çalıştırılmasına da olanak tanır. Eğitim Hattı Yetenekleri GPU'ların Yapay Zeka Veri Altyapınız Üzerindeki Etkisi Bir zincir, en zayıf halkası kadar güçlüdür ve AI/ML altyapınız yalnızca en yavaş bileşeniniz kadar hızlıdır. Makine öğrenimi modellerini GPU'larla eğitiyorsanız zayıf bağlantınız depolama çözümünüz olabilir. Sonuç, "Açlıktan Ölen GPU Sorunu" dediğimiz şeydir. Starving GPU sorunu, ağınız veya depolama çözümünüz, eğitim verilerini GPU'larınızı tam olarak kullanacak kadar hızlı bir şekilde eğitim mantığınıza sunamadığında ortaya çıkar. Belirtiler oldukça açıktır. GPU'larınızı izlerseniz, hiçbir zaman tam olarak kullanılmaya yaklaşamadıklarını fark edeceksiniz. Eğitim kodunuzu ayarladıysanız, toplam eğitim süresine IO'nun hakim olduğunu fark edeceksiniz. Ne yazık ki bu sorunla boğuşanlara kötü bir haber var. GPU'lar hızlanıyor. Bu sorunun önümüzdeki yıllarda nasıl daha da kötüleşeceğini anlamak için GPU'ların mevcut durumuna ve onlarla yapılan bazı ilerlemelere bakalım. GPU'ların Mevcut Durumu GPU'lar hızlanıyor. Yalnızca ham performans iyileşmekle kalmıyor, aynı zamanda bellek ve bant genişliği de artıyor. Nvidia'nın en yeni GPU'larının bu üç özelliğine bir göz atalım. , ve . A100 H100 H200 GPU VERİM HAFIZA BELLEK BANT GENİŞLİĞİ A100 624 TFLOP 40GB 1.555 GB/sn H100 1.979 TFLOP 80GB 3,35 TB/sn H200 1.979 TFLOP 141GB 4,8 TB/sn Not: Yukarıdaki tablo, A100 için PCIe (Çevresel Bileşen Ara Bağlantı Ekspres) soket çözümü ve H100 ve H200 için SXM (Sunucu PCI Ekspres Modülü) soket çözümüyle uyumlu istatistikleri kullanır. A100 için SXM istatistikleri mevcut değildir. Performans açısından karşılaştırma için Kayan Nokta 16 Tensör Çekirdeği istatistiği kullanılır. Yukarıdaki istatistiklere ilişkin birkaç karşılaştırmalı gözleme değinmeye değer. İlk olarak, H100 ve H200 aynı performansa sahiptir (1.979 TFLOPS), bu da A100'den 3,17 kat daha fazladır. H100, A100'den iki kat daha fazla belleğe sahip ve bellek bant genişliği de benzer miktarda arttı; aksi takdirde GPU kendini aç bırakacaktı. H200, 141 GB gibi devasa bir belleği işleyebilir ve bellek bant genişliği de diğer GPU'lara göre orantılı olarak artırılmıştır. Bu istatistiklerin her birine daha ayrıntılı olarak bakalım ve makine öğrenimi için ne anlama geldiğini tartışalım. - Bir teraflop (TFLOP), saniyede bir trilyon (10^12) kayan nokta işlemidir. Bu, arkasında 12 sıfır bulunan 1'dir (1.000.000.000.000). Model eğitimi sırasında meydana gelen kayan nokta işlemleri basit tensör matematiğinin yanı sıra kayıp fonksiyonuna (diğer adıyla gradyanlar) karşı ilk türevleri içerdiğinden, TFLOP'ları gigabayt cinsinden IO talebine eşitlemek zordur. Ancak göreceli karşılaştırmalar mümkündür. Yukarıdaki istatistiklere baktığımızda, her ikisi de 1.979 TFLOPS hızında çalışan H100 ve H200'ün üç kat daha hızlı olduğunu görüyoruz; diğer her şey buna ayak uydurabilirse potansiyel olarak verileri 3 kat daha hızlı tüketiyor. Performans - Video RAM veya Grafik RAM olarak da bilinir. GPU belleği, sistemin ana belleğinden (RAM) ayrıdır ve grafik kartı tarafından gerçekleştirilen yoğun grafik işlem görevlerini yerine getirmek üzere özel olarak tasarlanmıştır. GPU belleği, modelleri eğitirken parti boyutunu belirler. Geçmişte, eğitim mantığı CPU'dan GPU'ya taşındığında toplu iş boyutu azalıyordu. Ancak GPU belleği kapasite açısından CPU belleğini yakaladıkça GPU eğitimi için kullanılan parti boyutu artacaktır. Performans ve bellek kapasitesi aynı anda arttığında, her bir gigabaytlık eğitim verisinin daha hızlı işlendiği daha büyük talepler ortaya çıkar. GPU Belleği - GPU bellek bant genişliğini, bellek ile hesaplama çekirdeklerini birbirine bağlayan "otoyol" olarak düşünün. Birim zamanda ne kadar veri aktarılabileceğini belirler. Tıpkı daha geniş bir otoyolun belirli bir sürede daha fazla arabanın geçmesine izin vermesi gibi, daha yüksek bellek bant genişliği de bellek ile GPU arasında daha fazla verinin taşınmasına olanak tanır. Gördüğünüz gibi bu GPU'ların tasarımcıları her yeni sürüm için bellek bant genişliğini bellekle orantılı olarak artırdı; bu nedenle çipin dahili veri yolu darboğaz olmayacaktır. Bellek Bant Genişliği Model Eğitimi için Nesne Depolamayı Güçlendirin Starving GPU sorunu yaşıyorsanız 100 GB ağ ve NVMe sürücüleri kullanmayı düşünün. A Böyle bir konfigürasyonla MinIO kullanıldığında, yalnızca 32 kullanıma hazır NVMe SSD düğümüyle GET'lerde 325 GiB/s ve PUT'larda 165 GiB/s elde edildi. son kıyaslama Bilgisayar dünyası geliştikçe ve sunucu yapılandırmalarının genellikle 500 GB veya daha fazla DRAM ile geldiğini görüyoruz. Ultra yoğun NVMe sürücülere sahip olanlar bile dahil olmak üzere daha büyük dağıtımlarla uğraşırken, sunucu sayısı bu sunuculardaki DRAM ile çarpıldığında hızlı bir şekilde toplanabilir (çoğunlukla örnek başına birçok TB'ye ulaşır). Bu DRAM havuzu, dağıtılmış paylaşımlı bir bellek havuzu olarak yapılandırılabilir ve büyük IOPS ve işlem performansı gerektiren iş yükleri için idealdir. Sonuç olarak, Enterprise ve Enterprise Lite müşterilerimizin, GPU eğitimi gibi temel AI iş yüklerinin performansını daha da artırmak ve aynı zamanda tam kalıcılığı korumak amacıyla altyapılarını bu paylaşılan bellek havuzundan yararlanacak şekilde yapılandırmalarına olanak sağlamak için MinIO Cache'i oluşturduk. DRAM'in fiyatı düştü İki Organizasyonun Hikayesi Son bir düşünce deneyi olarak, AI/ML yolculuklarında çok farklı yaklaşımlar benimseyen iki kuruluşun hikayesini anlatalım. Organizasyon #1'in "Yinelemeli İyileştirmeler" kültürü vardır. Tüm büyük girişimlerin daha küçük, daha yönetilebilir projelere bölünebileceğine inanıyorlar. Bu küçük projeler daha sonra her biri bir önceki projenin sonuçları üzerine inşa edilerek giderek daha karmaşık hale gelen sorunları çözecek şekilde planlanır. Her biri işletmeye değer katacak şekilde düzenlenen bu küçük projeleri de seviyorlar. İş için herhangi bir yeni özellik içermeyen, yalnızca altyapıyı iyileştirmeye veya yazılımı modernleştirmeye yönelik projelerin, bütçeleri kontrol eden yöneticiler arasında pek popüler olmadığını buldular. Sonuç olarak, üretken bir yapay zeka kavram kanıtı için şık depolama aygıtları ve bilgi işlem kümeleri talep etmenin, altyapı iyileştirmelerini ve yeni yazılım yeteneklerini düzenlemenin en iyi yolu olmadığını öğrendiler. Bunun yerine, büyüdükçe ölçeklenebilecek altyapı ürünleriyle küçükten başlayacaklar ve basit yapay zeka modelleriyle başlayacaklar, böylece MLOP araçlarını devreye sokabilecekler ve mevcut DevOps ekipleriyle ve CI/CD işlem hatlarıyla nasıl çalışacaklarını çözebilecekler. Organizasyon #2'nin “Parlak Nesneler” kültürü vardır. En yeni fikir sektöre girdiğinde, ilk önce teknik gücünü göstermek için en yüksek profilli zorluğun üstesinden gelir. Bu projelerin hem içeride hem de dışarıda oldukça görünür olduğunu buldular. Bir şey bozulursa akıllı insanlar onu her zaman tamir edebilir. Kuruluş #1, ana e-ticaret sitesi için bir öneri modeli üzerinde çalışırken yapay zeka veri altyapısının bir kısmını oluşturarak ilk projesini yapılandırdı. Öneri modelinin eğitilmesi nispeten basitti. Bir dosya paylaşımında zaten mevcut olan veri kümelerini kullanan, ayırt edici bir modeldir. Bununla birlikte, bu projenin sonunda ekip aynı zamanda küçük (ama ölçeklenebilir) bir Modern Datalake oluşturmuş, MLOP araçlarını uygulamış ve modelleri eğitmek ve dağıtmak için bazı en iyi uygulamalara sahip olmuştur. Model karmaşık olmasa da yine de sitelerine birçok verimlilik kattı. Bu olumlu sonuçları, üretken bir yapay zeka çözümü olacak bir sonraki projeleri için finansman sağlamak amacıyla kullandılar. 2 numaralı kuruluş, e-ticaret siteleri için müşterilerin ürünlerle ilgili sorularını yanıtlayan bir sohbet robotu oluşturdu. Büyük Dil modelleri oldukça karmaşıktır; ekip, İnce Ayarlama veya Geri Alma Artırılmış Üretime aşina değildi; bu nedenle, bu projedeki tüm mühendis döngüleri, dik bir öğrenme eğrisi üzerinde hızlı bir şekilde ilerlemeye odaklandı. Model tamamlandığında, iyi sonuçlar verdi; olağanüstü hiçbir şey olmadı. Ne yazık ki, onu dağıtacak bir MLOps aracı bulunmadığından, üretim öncesi ve üretim ortamlarına manuel olarak yandan yüklenmesi gerekiyordu. Bu, DevOps ekibi arasında küçük bir sürtüşmeye neden oldu. Modelin kendisinde de üretimde birkaç stabilite sorunu vardı. İçinde çalıştığı küme, üretken bir yapay zeka iş yükü için yeterli bilişime sahip değildi. Birkaç ciddiyet derecesi bir çağrı vardı, bu da LLM'nin yoğun trafik koşullarında arıza yapmaması için kümede acil durum geliştirmesiyle sonuçlandı. Projenin ardından yapılan retrospektif bir değerlendirme, yapay zeka konusunda başarılı olmak istiyorlarsa altyapılarını güçlendirmeleri gerektiğini belirledi. AI/ML Veri Altyapınızı Oluşturmaya Yönelik Bir Plan Yukarıdaki kısa hikaye iki aşırı durumun basit bir anlatımıdır. Yapay zeka modelleri oluşturmak (hem ayırt edici hem de üretken), geleneksel yazılım geliştirmeden önemli ölçüde farklıdır. Bir AI/ML çalışmasını sıraya alırken bu dikkate alınmalıdır. Aşağıdaki grafik önceki bölümde anlatılan hikayenin görsel bir tasviridir. Bu, Önce Yapay Zeka Veri Altyapısı ile Önce Model yaklaşımının yan yana karşılaştırmasıdır. Yukarıdaki hikayenin gösterdiği gibi, altyapı ilk yaklaşımı için aşağıdaki tuğlaların her birinin bağımsız bir proje olması gerekmez. Kuruluşlar, altyapıları oluşturulurken yapay zekayı sunmanın yaratıcı yollarını aramalıdır; bu, yapay zeka ile ilgili tüm olasılıkları anlayarak, basit bir başlangıç yaparak ve ardından karmaşıklığı giderek artan yapay zeka projelerini seçerek yapılabilir. Çözüm Bu gönderi, AI/ML için Modern Datalake Referans Mimarisi oluşturmak üzere kuruluşlarla çalışma deneyimimizi özetlemektedir. Farklı yapay zeka yaklaşımlarının temel bileşenlerini, temel yapı taşlarını ve ödünleşimlerini tanımlar. Temel öğe, bir nesne deposunun üzerine inşa edilmiş modern bir veri gölüdür. Nesne deposunun, ölçeğin yüzlerce petabayt ve çoğunlukla eksabayt olduğu ölçekte performans sunabilmesi gerekir. Bu referans mimariyi takip ederek kullanıcının, AI ve ML'yi hedeflerken tüm OLAP iş yüklerinde eşit performans gösterecek esnek, genişletilebilir bir veri altyapısı oluşturabileceğini öngörüyoruz. Bileşen parçalarıyla ilgili özel tavsiyeler almak için lütfen şu adresten bana ulaşmaktan çekinmeyin: . keith@min.io