Lokal LLM mi, Bulut API mi? Kurumsal Karar Rehberi

Son güncelleme: 17 Ağustos 2026 · Yazar: Dr. Gökhan Tahıl, Kurucu — AI Yapay Zeka Mühendislik A.Ş.

Bir yapay zekâ projesinde ilk teknik toplantı çoğu zaman aynı yerde düğümlenir: model kendi sunucumuzda mı çalışacak, yoksa bir sağlayıcının bulut servisine mi bağlanacağız? Soru masada teknik görünür, faturası ticaridir. Yanlış kurgu projeyi ya hukuk biriminde durdurur ya da ikinci yılın bütçesinde. Bu rehber, kararı sezgiyle değil ölçütle vermeniz için yazıldı.

Kısa cevap: lokal LLM mi, bulut API mi?

Kısa cevap: Veri kurum dışına çıkamıyorsa, hacim yüksek ve öngörülebilirse, çevrimdışı çalışma ya da model sürümünü dondurma zorunluluğu varsa lokal LLM doğrudur. Henüz fikir doğruluyorsanız, hacim düşük ve dalgalıysa, kurum verisine dokunmuyorsanız veya donanımı işletecek bir yapınız yoksa bulut API doğrudur. Kurumsal projelerin çoğu tek bir tarafta değil, yönlendirme kuralları yazılı olan bir hibrit mimaride kararlı hale gelir.

Lokal LLM, bulut API ve hibrit mimari ne demek?

Üçü de tek bir sorunun farklı cevabıdır: model nerede çalışacak ve veri nereye kadar gidecek?

• LLM (large language model, büyük dil modeli): Çok büyük metin kümeleriyle eğitilmiş, metni anlayıp metin üreten yapay zekâ modeli.
• Lokal LLM (on-premise LLM): Model dosyasının kurumun kendi sunucusunda ya da kendi kontrolündeki veri merkezinde çalıştırılması. Hem model hem veri kurum ağının içinde kalır.
• Bulut API: Modelin başka bir şirketin veri merkezinde çalışması, kurumun sonuca internet üzerinden erişmesi. API (application programming interface, uygulama programlama arayüzü), iki yazılımın birbiriyle konuşma biçimidir.
• Hibrit mimari: Aynı projede hem lokal modelin hem bulut API'nin, hangi isteğin nereye gideceğini belirleyen yazılı kurallarla birlikte kullanılması.
• Token: Metnin model tarafından işlenen en küçük parçası ve bulut faturalarının birimi. Türkçe eklemeli bir dil olduğu için bir kelime çoğu zaman birden fazla token'a bölünür; aynı içerik İngilizceye kıyasla daha çok token harcar.
• Gecikme (latency): İsteğin gönderilmesiyle cevabın dönmesi arasında geçen süre.
• RAG (retrieval augmented generation, erişim destekli üretim): Kurumun kendi belgelerinden ilgili parçaları arayıp bulan ve bunları modele bağlam olarak veren yöntem.
• Kuantizasyon: Model ağırlıklarının daha düşük sayısal hassasiyetle saklanması. Gereken GPU belleğini düşürür, karşılığında doğrulukta bir miktar kayıp olabilir.

Lokal LLM ile bulut API arasındaki gerçek fark nedir?

Fark "hangi model daha zeki" sorusunda değil, kontrol sınırının nerede çizildiğinde ortaya çıkar. Bulut API'de veri kurumun ağından çıkar, sağlayıcının altyapısında işlenir, size sonuç döner. Lokal kurulumda model dosyası sizin donanımınızda durur, veri de aynı yerde kalır. Bu tek fark, aşağıdaki sekiz başlıkta ayrı ayrı sonuç üretir.

Tablodaki tek satır bile tek başına kararı belirleyebilir. Sağlık verisiyle çalışan bir kurumda "verinin konumu" satırı, düşük hacimli bir iç araçta ise "başlangıç maliyeti" satırı tartışmayı bitirir.

Hangi durumda lokal LLM daha doğru seçimdir?

Lokal LLM; verinin kurum dışına çıkmasının hukuken ya da sözleşmeyle sınırlandığı, hacmin yüksek ve öngörülebilir olduğu, gecikmenin kritik olduğu veya model sürümünün sabitlenmesi gereken işlerde doğru seçimdir. Aşağıdaki maddelerden ikisi aynı anda sizde varsa, karar pratikte lokal tarafa kilitlenir.

• Özel nitelikli kişisel veri işliyorsunuz. 6698 sayılı KVKK, sağlık verisini özel nitelikli kişisel veri sayar ve işlenmesini ayrı bir rejime bağlar. Verinin kurum dışına çıkması tek başına bir onay konusudur; çoğu hukuk birimi tam bu maddede durur.
• Sözleşmede veya mevzuatta veri ikametgâhı şartı var. Kamu ihaleleri ve bazı finans sözleşmeleri, verinin fiziksel olarak nerede işlendiğini yazılı olarak sorar.
• Çevrimdışı çalışması gerekiyor. Bağlantının garanti olmadığı sahalarda bulut API bir özellik değil, bir bağımlılıktır.
• Hacminiz yüksek ve öngörülebilir. Günde yüz binlerce çağrı üreten bir süreçte bulut faturası hacimle birlikte büyürken donanım maliyeti sabit kalır; çağrı başına maliyet düşer.
• Gecikme kritik. Üretim hattı ya da gerçek zamanlı görüntü işleme gibi işlerde her isteğe ağ gidiş-dönüşü ve sağlayıcı tarafındaki kuyruk süresi eklenir. Bu iki kalem de sizin kontrolünüzde değildir.
• Model sürümünü dondurmanız gerekiyor. Doğrulanmış bir klinik veya finansal akışta modelin habersiz güncellenmesi, o doğrulamanın da geçersiz olması demektir.

Hangi durumda bulut API daha doğru seçimdir?

Bulut API; fikrin henüz doğrulanmadığı, hacmin düşük ve dalgalı olduğu, kurum verisine dokunulmayan ve donanımı işletecek bir ekibin bulunmadığı işlerde açık farkla kazanır. Lokal kurulum her zaman doğru cevap değildir.

• Fikri doğruluyorsunuz. Bir kullanım senaryosunun işe yarayıp yaramadığını iki haftada anlamak için sunucu satın almak gereksiz.
• Hacim düşük ve dalgalı. Ayda birkaç bin çağrılık bir iç araç için GPU almak, kullanılmayan donanımı finanse etmek olur.
• Kurum verisine dokunmuyorsunuz. Genel araştırma, taslak metin üretimi ve kamuya açık kaynakla çalışan işler bu gruba girer.
• En üst seviye yeteneğe ihtiyaç var. Karmaşık akıl yürütme isteyen bazı görevlerde en büyük ticari modeller bugün için önde duruyor. Aradaki fark daralıyor, ama bugün hâlâ ölçülebilir durumda.
• Donanımı işletecek yapınız yok. GPU'lu bir sunucuyu ayakta tutmak, yedeklemek ve güncellemek bir işletim sorumluluğudur. Bu sorumluluğu kimin taşıyacağı belli değilse lokal kurulum birkaç ay sonra sahipsiz kalır.

Hibrit mimari gerçekten çalışır mı?

Çalışır, tek şartı var: yönlendirmenin kural tabanlı, yazılı ve denetlenebilir olması. Hibrit mimaride her istek önce bir sınıflandırma katmanından geçer. Kişisel veri, hasta kaydı veya sözleşme metni gibi hassas içerik lokal modele gider; kamuya açık veriyle çalışan görevler bulut API'ye yönlenir. Yönlendirme kuralı yazılı değilse elinizdeki şey hibrit bir mimari değil, bir umuttur.

Kuralın yazılı olması yetmez, denetlenebilir de olmalıdır: hangi isteğin nereye gittiği loglanmalı, sınıflandırma hatası durumunda varsayılan davranış "lokale gönder" olmalı ve bu kural düzenli olarak örneklemle test edilmelidir.

RAG kullanınca veri gerçekten kurum içinde mi kalır?

Hayır — model buluttaysa, RAG ile getirilen belge parçaları da bulutta işlenir. En sık yapılan hata tam burada olur. RAG, kurumun kendi belgelerinden ilgili parçaları bulup modelin önüne koyma yöntemidir; o parçalar isteğe eklenerek modele gönderilir. Yani "arama bizde, model onlarda" cümlesi veriyi kurum içinde tutmaz, sadece aramayı kurum içinde tutar.

Vektör veritabanının kurum içinde olması bu tabloyu değiştirmez. Belirleyici olan, modele gönderilen istemin (prompt) içinde ne olduğudur. Hibrit kurgu yapacaksanız bu ayrımı mimari şemada açıkça göstermeniz, hangi belge sınıfının hangi modele gidebileceğini de veri sınıflandırma politikasına bağlamanız gerekir.

Maliyet karşılaştırmasını nasıl doğru kurarsınız?

Doğru karşılaştırma, iki seçeneği aynı iş yükü ve aynı kalite eşiği üzerinden 24 aylık toplam sahip olma maliyetine (TCO) çevirmekle kurulur. İki tarafın maliyeti farklı birimlerde ölçüldüğü için, ham fiyatları yan yana koymak yanıltıcıdır.

Bulut API'de birim token'dır. Girdi ve çıktı token'ları genellikle ayrı fiyatlanır ve fatura işlenen token sayısıyla büyür. Pilotta küçük görünen tutar, süreç kuruma yayıldığında hızla değişir. Bütçede en sık atlanan kalemler şunlardır:

• RAG bağlamının şişirdiği girdi token'ları — her isteğe eklenen belge parçaları faturanın büyük kısmını oluşturabilir.
• Başarısız isteklerin yeniden denenmesi (retry).
• Geliştirme, test ve değerlendirme (eval) koşularının ürettiği trafik.
• Fiyat listesinin sağlayıcı tarafından değiştirilmesi riski ve döviz kuru etkisi.

Lokal tarafta birim donanımdır. Belirleyici kalem GPU'dur ve GPU'yu belirleyen tek sayı bellek miktarıdır (VRAM): model boyutu ve kuantizasyon seviyesi, modelin belleğe sığıp sığmayacağını tayin eder. Eşzamanlı kullanıcı sayısı ikinci belirleyicidir. Lokal TCO'ya şu kalemler girer:

• Sunucu ve GPU yatırımı, kaç yıla amorti edileceği.
• Barındırma: elektrik, soğutma, kabinet veya veri merkezi maliyeti.
• İşletim: izleme, yedekleme, güvenlik yaması, sürüm yönetimi ve bunları yapacak zaman.
• Kullanım oranı: boşta duran bir GPU'nun maliyeti, tam kapasite çalışan bir GPU'nunkiyle aynıdır.

İki tarafı da 24 aya yaydığınızda ortaya tek bir sayı çıkar: başabaş noktası. Bu, lokal kurulumun bulut faturasına eşitlendiği aylık çağrı hacmidir. Gerçekçi hacim tahmininiz bu noktanın belirgin biçimde üzerindeyse lokal, altındaysa bulut ekonomik olarak doğru taraftır. Tahmin bu noktanın çok yakınındaysa karar maliyetle değil, veri ve uyum ölçütleriyle verilmelidir.

KVKK açısından hangi soruları sormalısınız?

Bulut API kullanmak KVKK'ya aykırı değildir; belgelenmemiş bulut kullanımı sorun çıkarır. Karar öncesinde hukuk biriminizle şu altı sorunun yazılı cevabını almanız yeterlidir:

1. Modele giden veride kişisel veri var mı, varsa özel nitelikli mi?
2. Veri yurt dışına aktarılıyor mu? KVKK, yurt dışına aktarımı yeterlilik kararı veya standart sözleşme gibi uygun güvencelere bağlar; hangisine dayandığınız yazılı mı?
3. Sağlayıcı sözleşmede veri işleyen olarak mı konumlanıyor? Veri sorumlusu sıfatı ve sorumluluğu kurumda kalmaya devam eder.
4. Gönderilen veri modelin eğitiminde kullanılıyor mu? Cevabı pazarlama sayfasından değil, sözleşme metninden doğrulayın.
5. Veri sağlayıcı tarafında ne kadar süre saklanıyor, silme talebi nasıl işletiliyor?
6. Aydınlatma metniniz ve varsa açık rıza süreciniz bu aktarımı kapsıyor mu?

Bu altı sorunun cevabı yazılı değilse, teknik mimari ne kadar iyi olursa olsun proje canlıya çıkarken duracaktır.

Kararı hangi sırayla vermelisiniz?

Sıralama önemlidir: maliyetten başlayan ekipler çoğunlukla hukukta, hukuktan başlayanlar ise bütçede tıkanır. Doğru sıra şudur:

1. Veriyi sınıflandırın. Hangi veri sınıfı kurum dışına çıkabilir, hangisi çıkamaz?
2. Zorunlulukları yazın. Çevrimdışı çalışma, gecikme eşiği, model sürümünü dondurma gibi pazarlık dışı şartlar.
3. Hacmi tahmin edin. Bugünkü değil, süreç kuruma yayıldıktan sonraki aylık çağrı hacmi.
4. Kalite eşiğini tanımlayın. "İyi cevap" ne demek, nasıl ölçülüyor? Bu eşik olmadan iki seçeneği karşılaştıramazsınız.
5. TCO'yu 24 aya çıkarın ve başabaş noktasını bulun.
6. Kalan alanda hibriti kurgulayın ve yönlendirme kuralını yazılı hale getirin.

Bu kararda en sık yapılan hatalar neler?

Dört hata, bu kararın sonradan yanlış çıkmasının en yaygın nedenidir:

• Pilot maliyetini üretim maliyeti sanmak. Pilotta çağrı sayısı düşüktür; asıl fatura yaygınlaşmayla gelir.
• RAG'i veri sınırı sanmak. Arama kurum içinde olsa da bağlam bulutta işlenir.
• Model sürümünü sabitlemeden doğrulama yapmak. Sürüm değişince doğrulama da düşer.
• Lokal kurulumun sahibini belirlememek. İşletim sorumluluğu atanmamış her lokal kurulum birkaç ay içinde bakımsız kalır.

Biz nasıl çalışıyoruz?

AI Yapay Zeka Mühendislik olarak biz de hibrit çalışıyoruz: lokal açık kaynak LLM modelleriyle ticari API entegrasyonlarını aynı projede kullanabiliyoruz. Kurulumlarda on-premise'i esas alıp bulutu opsiyon olarak bırakıyoruz. Dağıtımı Docker konteynerleriyle yapıyoruz; Docker konteyneri, uygulamayı bağımlılıklarıyla birlikte paketleyip her sunucuda aynı biçimde çalıştıran bir dağıtım yöntemidir, taşınabilirliği bu sağlar. Yönetişim tarafında ISO 42001 belgemiz var ve aynı standart için danışmanlık da veriyoruz.

Sıkça sorulan sorular

Lokal LLM mi bulut API mi daha ucuz?

Hacme bağlıdır. Bulut API düşük ve dalgalı hacimde daha ucuzdur, çünkü başlangıç yatırımı yoktur ve yalnızca kullandığınız token kadar ödersiniz. Lokal LLM yüksek ve öngörülebilir hacimde daha ucuzdur, çünkü donanım maliyeti sabit kalırken çağrı başına maliyet düşer. Doğru karşılaştırma, iki seçeneği 24 aylık toplam sahip olma maliyetine çevirip başabaş noktasını bulmaktır.

Lokal LLM çalıştırmak için hangi donanım gerekir?

Belirleyici bileşen GPU'dur ve GPU seçimini yapan tek sayı bellek miktarıdır (VRAM). Modelin parametre sayısı ve kullanılan kuantizasyon seviyesi, modelin belleğe sığıp sığmayacağını belirler. İkinci belirleyici eşzamanlı kullanıcı sayısıdır: aynı anda kaç isteğin karşılanacağı, gereken bellek ve GPU adedini doğrudan etkiler.

Bulut API'ye gönderdiğim veri model eğitiminde kullanılır mı?

Sağlayıcıya ve seçtiğiniz hizmet katmanına göre değişir. Kurumsal katmanlarda bu genellikle varsayılan olarak kapalıdır, ancak bunu pazarlama sayfasından değil sözleşme metninden doğrulamak gerekir. Aynı sözleşmede verinin sağlayıcı tarafında ne kadar süre saklandığını ve silme talebinin nasıl işletildiğini de aramalısınız.

Hibrit mimari KVKK uyumu için tek başına yeterli mi?

Hayır. Hibrit mimari, hassas verinin kurum içinde kalmasını teknik olarak mümkün kılar; uyumu ise yönlendirme kuralının yazılı olması, loglanması ve düzenli denetlenmesi sağlar. Kural belgelenmemişse hangi verinin nereye gittiğini kanıtlayamazsınız ve denetimde bu kanıt istenir.

RAG kullanırsam veri kurum içinde mi kalır?

Model buluttaysa kalmaz. RAG'de kurum belgelerinden bulunan parçalar isteme eklenerek modele gönderilir; model nerede çalışıyorsa o parçalar da orada işlenir. Vektör veritabanını kurum içinde tutmak yalnızca arama adımını kurum içinde tutar, modele giden bağlamı değil.

Açık kaynak lokal modeller ticari modeller kadar iyi mi?

Dar ve tanımlı görevlerde çoğu zaman yeterlidir: sınıflandırma, özetleme, kurum belgeleri üzerinde soru-cevap gibi işlerde açık kaynak modeller pratikte iş görür. En karmaşık akıl yürütme gerektiren görevlerde en büyük ticari modeller bugün için önde duruyor. Aradaki fark daralıyor, bu yüzden kararı model markasına değil, kendi görevinizde ölçtüğünüz kalite eşiğine bağlamak gerekir.

Bu kararı birlikte verelim

Kendi veri sınıflarınız, hacminiz ve uyum şartlarınız üzerinden lokal, bulut veya hibrit kurgunun hangisinin doğru olduğunu değerlendirmek isterseniz bize yazabilirsiniz.

AI Yapay Zeka Mühendislik A.Ş. · Her gün 09.00-19.00
Telefon: 0540 509 19 05 · E-posta: gokhan@aiyapayzeka.io
Şehit Muhtar Mah., Mis Sk. No:24, 34435 Beyoğlu/İstanbul

Ücretsiz danışmanlık için bize ulaşın

← Tüm yazılar