Self-Hosted LLM: Veri Egemenliği
Yapay zekadan yararlanmak için verinizin işlenmesini ve kullanım maliyetlerinizi bütünüyle dış hizmetlere bırakmak zorunda değilsiniz. Asıl mesele, kurumunuzun ihtiyaçlarına uygun modeli doğru altyapıda çalıştırmak.
Bir satış teklifini hazırlarken, şirket içi bir raporu özetlerken veya yazılım geliştirme sürecinde yapay zekadan destek alırken yalnızca bir model kullanmazsınız. Aynı zamanda verinizin nerede işleneceğine, hangi sistemlerden geçeceğine ve bu kullanımın nasıl maliyetleneceğine ilişkin bir mimari tercih yaparsınız.
Bu nedenle kurumsal yapay zeka stratejisinin başlangıç sorusu yalnızca “Hangi model daha iyi?” olmamalıdır. En az onun kadar önemli başka bir soru vardır:
“Bu model, bizim verimizle, bizim iş yükümüzde ve bizim kontrolümüzde nasıl çalışacak?”
Mad Cat Labs olarak Qwen3.8-27B modelini NVIDIA H200 tabanlı sunucularda ve NVIDIA DGX Spark sistemlerinde çalıştırarak yerel yapay zeka çıkarımı, yani inference, üzerine çalışmalar yürütüyoruz. Odağımız yalnızca modelden yanıt almak değil; model seçimini, donanımı ve uygulama entegrasyonunu kurumsal ihtiyaçlarla birlikte değerlendirmek.
Kurumsal yapay zeka için sıfırdan model eğitmek gerekmiyor
Kendi altyapınızda yapay zeka kullanmak, mutlaka yeni bir temel model geliştirmek veya büyük ölçekli bir eğitim projesi başlatmak anlamına gelmez. Önceden eğitilmiş bir modelin gelen soruları işlemesi, metin üretmesi veya bir görevi yerine getirmesi, inference aşamasıdır. Bu aşama, modelin eğitiminden ayrı olarak kurumun tercih ettiği altyapıda yürütülebilir.
Self-hosted LLM yaklaşımında modelin çalıştırılması ve servis olarak sunulması, kurumun yönettiği ortamda gerçekleştirilir. Bu ortam şirket içindeki bir sistem, veri merkezindeki bir sunucu veya yönetim kontrolü kuruma ait özel bir bulut altyapısı olabilir. Dolayısıyla self-hosted olmak ile fiziksel olarak şirket binasında bulunmak aynı şey değildir; veri konumu ve operasyonel kontrol ayrıca değerlendirilmelidir.
Bizim yaklaşımımızda başlangıç noktası “En büyük modeli nasıl çalıştırırız?” sorusu değil; “Hangi iş akışında, hangi kalite ve hız düzeyine ihtiyacımız var?” sorusudur.
Veri egemenliği: Verinin bulunduğu yerden daha fazlası
Veri egemenliği yalnızca dosyaların hangi sunucuda saklandığıyla ilgili değildir. Verinin nasıl işlendiği, kimlerin erişebildiği, sistemler arasında nasıl taşındığı ve yaşam döngüsü boyunca nasıl korunduğu da bu değerlendirmenin parçasıdır. Yapay zeka söz konusu olduğunda kullanıcı girdileri ve model çıktıları da bu kapsamda ele alınmalıdır.
Bu nedenle yerel bir yapay zeka mimarisi tasarlarken yalnızca ana modele bakmak yeterli değildir. Belge işleme, arama, kayıt tutma ve uygulama entegrasyonlarında oluşan veri akışı da incelenmelidir. Model içeride çalışırken belgeler başka bir serviste işleniyorsa uçtan uca yerel bir yapı kurulmuş olmaz.
Aynı şekilde, modelin kurum içinde çalışması bütün çalışanların bütün verilere erişebilmesi anlamına gelmemelidir. Kullanıcının erişim yetkileri, modelin yararlandığı veri kaynaklarına da uygulanmalıdır. Hassas bilgi sızıntısını önlemek için en az ayrıcalık ilkesi, veri kaynağı sınırlandırmaları ve güvenli sistem yapılandırması önemini korur. Yerel kurulum, güvenliğin yerine geçmez; güvenliği kurumun kendi politikalarıyla uygulayabileceği bir zemin oluşturur.
Qwen3.8-27B, H200 ve DGX Spark: Farklı ihtiyaçlara uygun altyapılar
Mad Cat Labs’te Qwen3.8-27B ile yürüttüğümüz inference çalışmalarını iki farklı donanım sınıfında ele alıyoruz: NVIDIA H200 tabanlı sunucu altyapısı ve NVIDIA DGX Spark.
Bu iki platformu değerlendirmemizin nedeni, her kurumun aynı ölçekte bir yapay zeka altyapısına ihtiyaç duymaması. Bir yazılım ekibinin kurum içi asistanı ile birden fazla uygulamaya hizmet veren merkezi model servisinin gereksinimlerini aynı kabul etmiyoruz.
H200 tarafında odak, sunucu ölçeğinde model servisidir. NVIDIA H200, 141 GB HBM3e bellek ve 4,8 TB/s bellek bant genişliği sunar. Bu özellikler, büyük dil modellerinin çalıştırılmasında ve bellek yoğun inference iş yüklerinde önemli bir altyapı kapasitesi sağlar.
H200 çalışmalarımızda odağımız, bu kapasiteyi uygulama ihtiyaçlarıyla birlikte değerlendirmek. Modelin belleğe sığmasını başlangıç noktası kabul ediyor; kullanılacak bağlam uzunluğunu, yanıt beklentisini ve servis katmanını da tasarımın parçası olarak ele alıyoruz.
DGX Spark tarafında ise yerel yapay zekayı kompakt bir sistem üzerinde çalıştırıyoruz. NVIDIA Grace Blackwell mimarisine dayanan DGX Spark, CPU ve GPU tarafından paylaşılan 128 GB birleşik sistem belleğine sahip. Masaüstü formunda model geliştirme, test ve yerel çalıştırma olanağı sunuyor.
DGX Spark’ı, belirli bir ekibin veya iş akışının ihtiyaçlarını yerinde değerlendirebileceğimiz bir platform olarak konumlandırıyoruz. Böylece başlangıç kararını doğrudan büyük bir sunucu yatırımına bağlamak yerine, kullanım senaryosundan hareket edebiliyoruz.
Buradaki önemli ayrım şu: H200 ve DGX Spark, aynı işi aynı hızda yapan iki farklı boyuttaki cihaz değildir. Bellek mimarileri ve bant genişlikleri farklıdır. Tercihi yalnızca bellek kapasitesine bakarak değil, hedeflenen iş yükünü ölçerek yapmak gerekir.
Maliyet kontrolü: Token fiyatından toplam işletme maliyetine
Yapay zeka maliyetini yalnızca ekranda görünen yanıt üzerinden değerlendirmek eksik kalır. Uzun belgeler, geçmiş konuşmalar, belge aramaları, çok adımlı ajan süreçleri ve tekrar denemeleri, tek bir işin arkasında birden fazla model çağrısı oluşturabilir. Bu nedenle token fiyatı, toplam maliyetin yalnızca bir bileşenidir.
Self-hosted yaklaşımında değerlendirme, model çağrısı başına ödenen bedelden altyapının toplam işletme maliyetine doğru genişler. Donanım veya sunucu kiralama, enerji, bakım, güvenlik, izleme ve teknik operasyon birlikte hesaba katılmalıdır. Yerel inference, işlem maliyetini ortadan kaldırmaz; maliyetin nasıl oluştuğunu ve hangi kapasiteyle karşılandığını yönetme imkanı verir.
Düzenli ve öngörülebilir iş yüklerinde ayrılmış kapasiteyi değerlendirmek anlamlı olabilir. Buna karşılık düşük kullanım oranı, gereğinden büyük donanımın birim işlem maliyetini yükseltebilir. Kapasitenin yetersiz kalması ise yanıt sürelerini ve hizmet kalitesini olumsuz etkileyebilir. Bu nedenle doğru boyutlandırma; modelin bellek ihtiyacı, eş zamanlı istek sayısı ve gecikme hedefleriyle birlikte yapılmalıdır.
Kurumun bilgisini kullanan yapay zeka
Yerel model çalıştırmayı değerlendirirken üzerinde durduğumuz kullanım alanlarından biri, kurumun mevcut bilgi kaynaklarıyla çalışan asistanlardır.
Bunun için her belgenin model eğitimine dahil edilmesi gerekmez. RAG olarak adlandırılan yaklaşımda, soruyla ilgili bilgiler dokümanlardan veya diğer veri kaynaklarından bulunarak modelin yanıt üretiminde kullanılır. Böylece modelin parametrelerini her güncellemede yeniden eğitmek yerine, yanıt üretimi güncel bilgi kaynaklarıyla desteklenebilir.
Örneğin teknik destek için tasarlanacak bir uygulamada, çalışanın sorusuyla ilgili ürün kılavuzlarının ve onaylı çözüm kayıtlarının bulunmasını hedefleyebiliriz. Satış tarafında ürün dokümanlarından teklif taslakları hazırlanmasını, yazılım ekiplerinde ise kurum içi teknik belgeler üzerinden açıklama ve geliştirme desteği verilmesini değerlendirebiliriz.
Bu senaryolarda hedefimiz yalnızca metin üreten bir sohbet ekranı değildir. Kullanıcının yetkili olduğu kaynaklara dayanan, ilgili belgeleri görünür kılan ve çıktısı denetlenebilen bir iş akışıdır. RAG mimarileri kurumsal arama, bilgi asistanları ve yardımcı uygulamalar için bu tür bir temel sunar.
Bununla birlikte, kaynak kullanılması hatasız yanıt garantisi değildir. Değerlendirmemizde kaynak doğruluğunu, yanıt kalitesini ve gerekli insan onaylarını ayrı başarı kriterleri olarak ele alıyoruz.
Bir modeli çalıştırmaktan, kullanılabilir bir servise
Kurum içi yapay zekayı yalnızca ayrı bir sohbet arayüzü olarak düşünmüyoruz. Mevcut uygulamaların ve otomasyonların yararlanabileceği bir servis olarak ele alıyoruz.
vLLM gibi model sunum araçlarının sağladığı OpenAI uyumlu API arayüzleri, yerel modellerin uygulamalara bağlanmasını kolaylaştırabilir. Ancak desteklenen özellikler ve model davranışları farklılaşabildiği için entegrasyonların gerçek kullanım senaryolarıyla test edilmesi gerekir.
Bizim için kurumsal devreye alma planı; kimlik doğrulama, erişim yetkileri, kullanım sınırları, izleme, sürüm yönetimi ve kesinti senaryolarını da kapsamalıdır. Başarı ölçütünü yalnızca “Model yanıt verdi” olarak tanımlamıyoruz. Doğru kullanıcının, doğru veriye, beklenen kalitede ve sürdürülebilir bir maliyetle ulaşmasını hedefliyoruz.
Yapay zekayı yalnızca kullanmak değil, yönetebilmek
Mad Cat Labs olarak yerel yapay zekaya yaklaşımımız, mümkün olan en büyük modeli çalıştırmak üzerine kurulu değil. Kurumun ihtiyacına uygun modeli, uygun donanımda ve ölçülebilir hedeflerle değerlendirmek üzerine kurulu.
Qwen3.8-27B ile H200 ve DGX Spark üzerinde yürüttüğümüz inference çalışmaları da bu yaklaşımın parçası. Modeli çalıştırmayı, bellek kullanımını, servis katmanını ve uygulama entegrasyonunu birbirinden bağımsız konular olarak ele almıyoruz.
Başlangıç için önerimiz, bütün kurumu kapsayan büyük bir proje yerine sınırları belirli bir iş akışı seçmek. Bu iş akışında yanıt kalitesini, işlem süresini, erişim kontrollerini ve tamamlanan iş başına maliyeti değerlendirmek; ardından kapasiteyi ölçülen ihtiyaca göre genişletmek.
Kurumunuz için doğru yapay zeka, yalnızca güçlü yanıtlar üreten değil; verisi, erişimi, performansı ve maliyeti yönetilebilen yapay zekadır.
Kurumunuzun iş yüklerine uygun yerel yapay zeka yaklaşımını değerlendirmek için Mad Cat Labs ile iletişime geçin.