***Bir önceki bölümde AirLLM'in ne yaptığını anlatmıştım: _koca bir modeli tek seferde belleğe almak yerine, katman katman yükleyip sınırlı bir GPU'da bile çalıştırmayı*_..
Saha tek bir şeyi umursar: vardiyada kaç rapor işleniyor. Mimarinin ne kadar havalı da olduğu, kimseyi ilgilendirmez orada.
Şuan paylaşacağım Bölüm 2 içinde ise mantık hafızayı ekip olarak nasıl düşünerek oluşturuyor ve karar sonuç ilişkisi kurduğumuzu gösteriyor olacağım. Burada ki temel amaç, hemen haydi tekniğe geçelim, süslü ve komplex code ve algoritmaları da paylaşıp, özellikle dikkat çekmek olmadığı için..
Doğrudan bu işi hakkıyla “İş Süreç Akış ve Tasarımı” da nasıl oluşturduşumuzu bir sonraki Bölüm 3’de ki Core Teknik ve Platform kısmına özellikle hemen girmeden bu yazıyı paylaşmak istiyorum.
Teknik ve platform bir şekilde halledilir fakat paylaştığımız kısımlar da hayali bir senaryo üzerinden olmadan; gerçek “Sahadan yansımalar” olduğu için roadmap’iniz için bir anlam ifade edeceğine eminim.
Fabrika ve Detayları
Türkiye’de büyük bir otomotiv yan sanayi tesisinden bir POC talebi geldi. İsim veremem, aramızda bu konuda kritik bir NDA var, ama teknik tarafı rahatlıkla anlatabilirim.
Üç vardiya, 7/24 dönen bir hat. Kalite kontrol raporlarını, bakım loglarını, operatör notlarını işleyecek yerel bir dil modeli istiyorlardı. Ortam tamamen izole. Veri dışarı çıkmayacak, bulut yok, bu konu masaya bile gelmedi.
“Şuan eldeki donanım ile başlayacağız, patron ve yönetim kurulu çok istekli fakat şuan henüz bütçe yok” dediler ama bu dönüşümde ciddi motivasyonları olduğunu belirttiler. Artık bu cümleyi ekipçe ezbere tabii biliyoruz.. (:
İlk hafta özellikle kod yazmadık. Ortamda assestment yaptık ve değerli analiz ederek veri topladık yani özetle; evdeki bıçakla, ne kadar ve ne türde uygun Et keseriz onu anlamaya çalıştık. Kod yazmadan önce ölçmek işin en can sıkıcı kısmıdır.. Fakat bu adımı atlarsanız, ezbere next-copy-paste yaparsanız, kesinlikle %100 bedelini ödüyorsunuz. Sahada bu niş alanlar da aktif proje ve danışmanlık yapan bir kişi ve şirket olarak, tekrar özellikle hatırlatmak ve altını önemle çizmek isterim.
Burada Ekran kartıyla sistem arasındaki veri yolu pratikte saniyede 11-12 GB taşıyor. Yerel ortamdaki SSD saniyede yaklaşık 500 MB okuyor. NAS’a ağ üzerinden erişim ise 180 MB/s ile zaten bayağı yavaştı. Bunlar laboratuvar rakamı filan da değil, sahada bizzat telemetrik ölçtüğümüz müşteri ortamı bench-sayıları..
Bu değerleri bilmeden bir zamanlama ve başarı kriteri de kuramazsınız.. Yanlış varsayımla başlarsanız da GPU’nun çoğu zaman boşta durduğunu görür, “neden bu kadar yavaş” diye eldeki GPU kartı da suçlarsınız, patronun ekranına ve satın almaya yeni GPU ihtiyacı yapmak için devamlı talep geçersiniz. Oysaki gördüğümüz birçok proje ve detaylı ihtiyaçta meselenin aslında “Evet, Kesinlikle..” GPU kartı olmadığını da çok açıkça görüyoruz. Burada gerçek sahadaki formül şu; Verinin nereden -> nereye ve -> hangi sırayla aktığıdır..
_Önce “Ölçmelisin”, sonra “Zamanlamalı”, en son “Optimize” etmelisin. _Bunu her projede ekibime ve müşterilerde proje içine involve olacak ekiplere söylüyorum ve imtina da etmiyorum, çünkü genelde sıra tam tersine çevriliyor yada özellikle çevriltmek isteniyor. Bu 2 tarafında ticari karakteri yada beklentileri ile çoğu zaman doğru yada ters orantılı oluyor..
MasterLabs Technologies ekibi olarak, Open-Source AirLLM’in katman katman yükleme mantığını aldık, bu donanıma özel bir zamanlayıcı yazdık. Bu bize peki ne sağladı ?
GPU bir katmanı hesaplarken bir sonraki katman aynı anda diskten okunup belleğe hazırlanıyor ve hesaplama ile aktarım üst üste biniyor.
Pratikte CUDA’nın paralel veri kanalları, belleğin özel ayrılması, aktarılan parçanın boyutu derken ilk denemede tutmadı. Üç kez baştan başladım, dördüncüde oturdu.
Kritik olan parça boyutuydu. Küçük parçalar taşırsanız her transferin kendi yükü sizi yorar; büyük parçalar taşırsanız GPU işini bitirip bekler. 512 KB ile 2 MB arasında denedik, bu sistemde 1 MB en iyi dengeyi verdi. Başka bir donanımda başka bir sayı çıkar, bunu ölçmeden asla kesinlik almayın.
Modelin çoğu katmanında 4-bit sıkıştırma kullandık. Neden ?
Bu soru kafada yer edebilir. Sebeb sayıları normalden çok daha az yer kaplayacak şekilde bilerek ve geleneksel kitapta yazdığı gibi değil de ezber bozan şekilde yuvarlamak istedik..
Evet şunda çok iyi biliyor ve farkındayız ki bu karar Bellekten büyük tasarruf ama Küçük bir doğruluk riski de getiriyor.
Sahadaki yazılı ve çizili raporlar “spindle”, “RMS”, “tolerans”, “kalibrasyon”, “runout” gibi örneklemeler ile malum yazılmış, tabi realitede uygulanabilir değil, hep teori sineması var.. Biz yinede bu teoriler üzerinden de test ettik ve saygımızı da eksik etmedik. (:
Sahada tabikii Teoriler dışında “4-bit gibi bir sıkıştırma” ölçülebilir bir bozulma da yaratır..
Küçük ama gerçek, nur topu gibi bir bozulma diyebiliriz. Ve sahada küçük bir bozulma, yanlış yazılmış bir Üretim Bakım Formuna, tehlikeli olabilecek şekilde dönüşebiliyor.
Biz ekip olarak ne yaptık ? Modelimizin girişe yakın ilk 8 katmanını 8-bit’te bıraktık, kalanını 4-bit’e düşürdük. Böylece İlk katmanlar önce bir kelimenin ne olduğuna karar veriyor; sonra da orada bozulma olursa çıktı en baştan yada anlık yanlış hemen çıkarıyor. Nasıl kulağa hoş geliyor değil mi ? Kesinlikle..
Son katmanlarda ise Teknik yaptığımız analiz ve değerlendirmelerde küçük bir hassasiyet kaybı oldu. Olması da beklenir. Fakat genel çalışmayı, data modeli ile machine learning algoritmasının çalışması, sonuç ve anlamını asla “bu dar ve kısıtlı seviyelerde” etkilemiyor.
Bir Saha notu: “İlk 8 katman” genel bir kural asla değil (Teoride takılmayın lütfen). Biz özellikle mevcut bu modele, o test verisine özel bulduğumuz bir sayı.. Başka bir modelde kendi ölçümünüzü yapın ve doğrulayarak devam edin.
4.Haftamız bitmeden bu rakamlar ve çıktılarımız ile POC’i teslim kanıt belgeleri ile tamamladık.
Telemetrik Sonuç Verileri;
Bir kalite kontrol raporu yaklaşık 120 kelime ile, 47 saniye sürdü.
Dört istasyon birlikte çalıştığında vardiyada ortalama 350 rapor tamamlanabiliyor.
Bu kuyruklamada giriş hazırlığı, health-check ile beraber sahada yaşanacak aksaklıkları da daima baz almasınız. Hiçbirşey kağıt üzerindeki hesap gibi olmuyor.. Bu yüzden planlama ve hesabınızı buna göre yapmanızda kesinlikle fayda var..
Tesisin temel ihtiyacı “şuan ilk Ready fazı için” vardiya başına özelikle 200-250 gibi bir ortalama rakam belirlemişlerdi. _MasterLabs Technologies olarak biz bunu karşıladık ve hali hazırda üzerine de çıktık. _
Artık Fabrika Operatörü arızayı kendi cümleleriyle doğal bir şekilde yazıyor, model bunu düzenli bir bakım formuna çevirerek sonuç üretiyor. Gayet başarılı ve bir çıktısı olan, şuan ready fazında bile bir yararı olan çalışma oldu.
Bu kısıtlı bütçe ile dar kapsamlı çalışma ile eskiden manuel çalışma yapan bir mühendis bu işi elle yapmak için günde 6-7 saat harcıyordu. Artık harcadan tamamlıyor oldu.
“Sahadan Yansımalar Serisinin” bu 2. bölümünde ki Çıkarılacak Ders nedir ?
Yeni bir ekran kartı aldırmadık, yeni sunucu da aldırmadık. Eldeki; Dört eski workstation, doğru assestment, doğru bellek yönetimi ve doğru veri akışı ve ML/Data Engineering algoritması geliştirmek yetti.
Bunun anlamı lütfen şu olmasın, özellikle ifade ediyorum. Buraki “eski donanım her zaman yeterlidir” yazısı yada kung-fu show’u değil.. Böyle bir show yaparak commit de etmek riski sebebiyle yeterince aptalca olurdu.
Yeni söylemek istediğim, yatırım kararınınızdan önce pain-point’leriniz üzerinden use-case’lerinizi çıkartın, mevcut darboğazınızı ölçün ve bazen bu ölçümünüz sandığınızda da geniş çaplı ihtiyaçlarınız olduğunu da görmenize sebeb olur, bazen de olmayacaktır.
Bu yüzden bu yola çıkmadan önce; taslak bir kurumsal gizlilik sözleşmesi ile detaylı analiz ve assestment sonucu çalışması raporu talep etmeniz çok mantıklı hareket olacaktır. Riski üzerinizde tutmayın, devamlı dağıtın ve çalıştırın. Siz sadece Süreci Yöneten olun..
Böylece masalarda şu dönem içinde yapılan güzellemeler sebebiyle, bir masada har vurulup, diğer masada da harman savrulurken; sizde bu “Kurumların Kaslarını” da hem güzelce bir test etmiş de olursunuz..🙂
Not: Bu yazıda Production kelimesini POC-Prod_Ready kapsamında kullanıyoruz. Yani sistem 7/24 çalışıyor ama henüz monitoring arayüzü yazmadık yada kurmadık. Disk arızasında otomatik yedekleme de devreye girmiyordu. Dolayısı ile henüz teknik borç (Technical Dept.) var. Bunları Bölüm 3'te High Level çalışması ve Teknik Kurulum da ele alacağız.
Top comments (0)