Kendi modelinizi mi çalıştırmalı, bir API mi kullanmalı: nasıl karar verilir?

Güvenlik incelemesinde biri, hiçbir müşteri verisinin şirketin sunucularından çıkamayacağını söyler. İş tarafında biri, mevcut en yetenekli modeli ister. Bir iki toplantı içinde soru şirket çapında bir evet ya da hayıra dönüşür ve iki taraf da yanlış birim üzerinden tartışır.

“Yerel LLM mi, API mi?” sorusu şirket düzeyinde değil, iş akışı düzeyinde yanıtlanır: modelin nerede çalışacağı her iş akışı için ayrı verilen bir karardır. Açık ağırlıklı model, ağırlıklarını indirip kendi donanımınızda çalıştırabileceğiniz bir modeldir. Böyle bir modeli kendi sunucularınızda (şirket içi kurulum) çalıştırmak üç durumda mantıklıdır: veri altyapınızdan çıkmamalıysa, hacim yüksek ve düzenliyse ya da modelin ne zaman değişeceğini kontrol etmeniz gerekiyorsa. Bedeli işletme yüküdür: donanım, model sunma, izleme, yamalar, yükseltmeler ve bunların hepsini yapacak insanlar. Geri kalan her şey genellikle bir API üzerinde çalışabilir; bunun kalitede bir bedeli olup olmadığını değerlendirme seti gösterir.

Herkese açık bir API ile kendi sunucularınız arasında hangi seçenekler var?

Dört seçenek var; unutulanlar genellikle ortadaki ikisi.

“Kendi sunucumuzda çalıştırmak zorundayız” diye başlayan bir gereksinim, veri koruma görevlisi (DPO) ve hukuk danışmanı koşulları okuduktan sonra bazen ikinci ya da üçüncü satırda son bulur. Her satırın verileriniz için ne anlama geldiği mimari şemanın değil, onların sorusudur; neler sorulacağını bir dil modeli kullandığınızda verilerinizin nereye gittiğini anlatan not sıralıyor.

Kendi sunucunuzda çalıştırmak ne zaman mantıklıdır?

Aşağıdakilerden en az biri açıkça geçerliyse ve değerlendirme seti açık ağırlıklı bir modelin görev için yeterince iyi olduğunu gösteriyorsa:

• Veri altyapınızdan çıkmamalı. Mevzuat, bir müşteri sözleşmesi ya da şirket içi politika, hukuk danışmanı da inceledikten sonra diğer satırları dışarıda bırakıyor.
• Hacim yüksek ve düzenli. Donanımın maliyeti meşgul de olsa boşta da olsa aynıdır. Düzenli ve yoğun bir yük onu meşgul tutar; dalgalı ya da küçük bir yük tutmaz.
• Değişimi kontrol etmeniz gerekiyor. Sağlayıcılar modelleri kendi takvimlerine göre günceller ve kullanımdan kaldırır. Her değişikliğin kullanımdan önce doğrulanması gereken bir süreç, yalnızca siz istediğinizde değişen bir modele ihtiyaç duyabilir.
• Tesis dış dünyadan yalıtılmış. Bağlantısı sınırlı bir fabrikanın modeli tesiste çalıştırması gerekir.

Hacim düşük ya da öngörülemezse, değerlendirme setiniz çıtayı yalnızca en büyük barındırılan modellerin aşabildiğini gösteriyorsa ya da şirket içinde GPU altyapısını işletebilecek kimse yoksa nadiren mantıklıdır. Yukarıdaki koşullardan biri yoksa varsayılan seçim bir API ya da yönetilen bir kurulumdur.

İşletmek gerçekte ne gerektirir?

GPU’lu bir sunucudan fazlasını:

• En yoğun yüke göre boyutlandırılmış GPU kapasitesi; yedeğe geçiş ve bir sonraki modeli test etmek için pay da bırakılmalı. Uzun belgeler daha fazla bellek ister; bu yüzden bağlam uzunluğu da bir boyutlandırma sorusudur.
• Model sunma (serving): istekleri gruplayan ve kuyruğa alan, sınırları ve kimlik doğrulamayı uygulayan ve uygulamalarınızın çağırdığı bir iç API sunan yazılım.
• İzleme: yanıt süresi, işlem hacmi, hatalar ve GPU kullanımı; bunlara ek olarak değerlendirme setine göre ölçülen çıktı kalitesi.
• Güvenlik yamaları: işletim sistemi, sürücüler, model sunma yazılımı ve konteynerler için; model dosyaları yalnızca doğruladığınız kaynaklardan alınır.
• Model yükseltmeleri. Yeni açık ağırlıklı modeller sık çıkar; her biri bir değerlendirme çalıştırması, bir kapasite testi ve bir geçiş planı ister. Yoksa kendiliğinden eski bir modelde kalırsınız.
• İnsanlar: hem altyapıyı hem modelleri anlayan ve ay sonunda bir şey bozulduğunda nöbette olan kişiler.

Bu listenin bir sahibi yoksa yanıt zaten hayırdır.

Modelin nerede çalışacağı bütün şirket için bir ilke değil, her iş akışı için ayrı bir karardır.

Kalite ve dil desteği nasıl karşılaştırılır?

Açık ağırlıklı modeller arasında büyük farklar vardır; İngilizce dışında bu farklar daha da büyür. İngilizce sözleşmeleri iyi okuyan bir model yapay bir Türkçeyle yazabilir, resmi ve samimi hitabı karıştırabilir ya da alan terimlerini kaçırabilir. Genel kıyaslama testleri (benchmark) bunu size söylemez; değerlendirme setiniz söyler. Her adayı kendi Türkçe ve İngilizce örneklerinizde test edin, yanıtları işi bilen ve dili ana dili olarak konuşan kişilere puanlatın; kaliteyi, vaka başına maliyeti ve hızı aynı vakalar üzerinde karşılaştırın.

İki noktayı kontrol etmeye değer. Daha küçük açık ağırlıklı modeller, çıktının yapılandırılmış ve doğrulanmasının kolay olduğu bilgi çıkarma, sınıflandırma ve yönlendirme gibi dar görevlerde çoğu zaman yeterince iyidir. Ayrıca gücünüzün yettiği donanım, pratikte bağlam uzunluğunu ve hızı sınırlar: uzun bir belgeyi kırpmak zorunda kalan bir model, yanıtın bulunduğu kısmı kaybedebilir.

Her seçenekte maliyetler nasıl davranır?

Maliyet eğrilerinin biçimi, fiyatlardan daha çok farklılaşır:

• Herkese açık API’ler kullanım başına ücretlendirir. Maliyet sıfıra yakın başlar; hacimle ve gönderdiklerinizin uzunluğuyla büyür.
• Kurumsal ve bölgesel hizmetler de kullanım başına ücretlendirir, bazen taahhütlerle.
• Yönetilen kurulumlar çoğunlukla zamana yayılan ayrılmış kapasite üzerinden faturalanır; bu yüzden maliyet, iş olsa da olmasa da basamak basamak artar.
• Kendi sunucunuzda çalıştırmanın maliyeti büyük ölçüde sabittir: satın alınan ya da kiralanan donanım, enerji, alan ve insanlar. Kapasite dolana kadar her ek isteğin maliyeti düşüktür; sonra maliyet sıçrar.

Önemli karşılaştırma, insanlar dahil kendi sunucunuzun sabit aylık maliyeti ile zirveler dahil gerçek hacminizdeki API maliyeti arasındadır. Kesişme noktası fiyatlar ya da hacimler her değiştiğinde kayar; bu yüzden bir kez karar verip bırakmak yerine yeniden hesaplayın.

Seçim nasıl geri alınabilir tutulur?

Hiçbir iş akışının bir modeli doğrudan çağırmasına izin vermeyerek:

• Modelden bağımsız bir katman. Uygulamalar tek bir iç arayüzü çağırır; arkasında her iş akışı, nerede çalışırsa çalışsın, kendisi için seçilen modele yönlendirilir.
• Taşınabilir varlıklar. Promptlar, çıktı şemaları ve değerlendirme setleri sağlayıcıdan bağımsız kalır ve sizindir.
• Geçiş testi olarak değerlendirme seti. Bir iş akışı taşınmadan önce seti yeni seçenekte yeniden çalıştırılır; kararı sonuçlar verir.
• Çıkış koşulları. Sözleşmeler, ayrıldığınızda verinin nasıl dışa aktarılacağını ve silineceğini belirtir.

Üç iş akışı olan temsili bir sigorta şirketine bakalım. Hasar belgelerinden bilgi çıkarma iş akışı, sağlık raporlarını ve kimlik belgelerini yüksek ve düzenli bir hacimde okuyor. Veri koruma görevlisi ve hukuk danışmanıyla yapılan incelemeden sonra bu belgeler şirketin kendi veri merkezinde kalıyor; açık ağırlıklı bir model de değerlendirme setinde kabul eşiğini karşılıyor. Bu yüzden iş akışı şirketin kendi sunucularında çalışıyor. Sigorta brokerlerinden gelen e-postalara yanıt taslağı hazırlama iş akışının hacmi daha düşük, verisi daha az hassas ve daha büyük bir modelin yazım becerisinden yararlanıyor; bu yüzden hukuk danışmanının onayladığı bir bölgede, kurumsal koşullarla bir bulut API’si kullanıyor. Şirket içi bir politika asistanı ise şirketin bulut hesabındaki yönetilen bir kurulumda çalışıyor. Üçü de aynı iç arayüzü çağırıyor; böylece değerlendirme seti başka bir seçeneğin daha iyi olduğunu gösterdiğinde her biri taşınabiliyor.

Verinin nerede işlenebileceği ve bir sağlayıcının koşullarının KVKK ya da GDPR (AB Genel Veri Koruma Tüzüğü) kapsamındaki yükümlülüklerinizi karşılayıp karşılamadığı, veri koruma görevliniz ve hukuk danışmanınız için sorulardır. Onlara sorulacak soruların ayrı bir notu var.

Hangi iş akışı nerede çalışmalı?

Aday iş akışlarınızı listeleyin ve her birine üç soru sorun: veri içeride kalmak zorunda mı, hacim yüksek ve düzenli mi, modelin ne zaman değişeceğini siz mi kontrol etmelisiniz? Üç yanıtın da hayır olduğu yerde bir API ya da yönetilen bir kurulum kullanın ve emeğinizi başka yere harcayın.

Veri ve yapay zeka altyapısı çalışmamızda aday modelleri sizin örneklerinizde karşılaştırır ve sistemi, nasıl çalıştığımızı anlattığımız sayfada tarif edildiği gibi, verinizin bulunması gereken yere kurarız. Belirli bir iş akışını konuşmak için bize kısa bir proje özeti gönderin.

Bu not genel bilgi amaçlıdır; hukuki tavsiye değildir.