Küçük bir SaaS için yerel LLM çalıştırmak mantıklı mı?

“Modeli kendi makinemizde çalıştıralım” cümlesi, bir ürün ekibinin toplantısında hızla ikna edici hâle gelir: veri dışarı çıkmaz, istek başına ücret yoktur, her şey bizim denetimimizdedir. Sorun, bu üç vaadin de koşullu olmasıdır. Bu yazı bir tavsiye listesi değil, bir karar çerçevesidir. Maliyet, gecikme ve gizlilik eksenlerinde hangi soruların sorulması gerektiğini ve hangi cevapların kararı değiştirdiğini ele alıyor.

Bir uyarı baştan yapılmalı: bu yazıda barındırılan bir model API’sinin fiyatı, bir GPU’nun kira bedeli ya da bir modelin saniyedeki token hızı gibi sayılar yok. Bu rakamlar hızla değişiyor ve bu yazı için bugün doğrulanmış, tarihli bir kaynağa bağlanamadı; kaynaksız bir sayı vermektense akıl yürütme yalnızca niteliksel tutuldu. Somut sayılar, karar verilirken kendi iş yükünüzle ve güncel fiyat sayfalarıyla yeniden hesaplanmalıdır. Aşağıdaki somut bilgiler yalnızca llama.cpp ve Ollama’nın kendi sayfalarından alınmıştır.

Yerel çalıştırmak ne demek?

Yerel çalıştırmanın günümüzdeki en yaygın iki aracı llama.cpp ve Ollama’dır. Projenin sayfasına göre llama.cpp, 1,5 bitten 8 bite kadar tam sayı kuantizasyonu (modeli daha az bellekte tutan sıkıştırma) sunuyor, GPU belleğine sığmayan modelleri kısmen GPU kısmen CPU ile çalıştıran melez bir çıkarım destekliyor ve OpenAI uyumlu bir API sunucusu başlatabiliyor. Donanım desteği geniş: Nvidia için CUDA, AMD için HIP, Apple silikonu için Metal, bunun yanında Vulkan ve SYCL. İki projenin lisansı da MIT. Ollama ise GitHub sayfasına göre macOS, Windows, Linux ve Docker üzerinde kurulabilen, bir REST API sunan bir çalıştırıcıdır.

Bu bilgilerin karar açısından anlamı şudur: yerel çalıştırmak teknik olarak ulaşılabilir ve açık lisanslı araçlarla yapılabilir. Ama araçların varlığı, işin sizin için ucuz ya da kolay olduğunu göstermez. Asıl soru, hangi modelin hangi donanımda ne kalitede ve ne hızda yanıt vereceğidir ve bu soruya cevap, kendi ölçümünüzden gelir.

Maliyet: değişken gider sabit gidere dönüşür

Barındırılan bir model hizmetinde maliyet kullanımla orantılıdır: ne kadar istek, o kadar fatura. Bu, kullanıcı sayısı küçükken bir avantajdır; kullanılmayan kapasite için ödeme yapılmaz. Yerel çalıştırmada ise bu eğri tersine döner. Donanım ya satın alınır ya da kiralanır ve istek gelsin gelmesin ücret işler. Maliyet, değişkenden sabite kayar.

Bunun iki sonucu var. Birincisi, kırılma noktası kullanıma bağlıdır: istek hacmi küçük ve dalgalıysa sabit gider boşa harcanır; hacim büyük ve düzenliyse sabit gider birim maliyeti düşürür. İkincisi, karşılaştırmanın yalnızca token başına fiyatla yapılması yanıltıcıdır. Yerel kurulumda donanımın yanı sıra güncelleme, izleme, model değişimi ve arıza anında müdahale gibi emek kalemleri de vardır. Küçük bir ekipte bu emek, ekibin kıt kaynağıdır.

Bir de kalite kalemi var. Yerelde çalıştırılabilen modeller, genellikle büyük barındırılan modellerden küçüktür ve kuantizasyon bellek tasarrufunu bir miktar kaliteyle ödetebilir. Kalite farkı kullanım senaryosuna göre önemsiz de olabilir belirleyici de; sınıflandırma ya da kısa özetleme gibi dar bir görev için küçük bir model yeterli olabilirken, açık uçlu akıl yürütme gerektiren bir özellik için olmayabilir. Bunu bir tahminle değil, kendi örnek verinizle yapılan bir denemeyle öğrenmek gerekir.

Gecikme: ağ kısalır, bekleme uzayabilir

Yerel çalıştırmanın gecikme açısından bir avantajı vardır: istek bir internet hattı boyunca başka bir şirkete gitmez. Ama bu avantaj, modelin kendi hızıyla yarışır. Ollama’nın SSS sayfasındaki varsayılan değerler bu konuda önemli ipuçları veriyor.

Belgelere göre bir model için paralel istek sayısı (OLLAMA_NUM_PARALLEL) varsayılan olarak 1’dir; yani aynı anda iki kullanıcı geldiğinde ikincisi sırada bekler. Bekleyen istekler için kuyruk sınırı (OLLAMA_MAX_QUEUE) 512’dir ve bunun ötesindeki istekler 503 hatası alır. Paralelliği artırmak mümkündür, ama belgeler gereken belleğin bu değerle bağlam uzunluğunun çarpımıyla büyüdüğünü söylüyor. Başka bir deyişle eşzamanlılık bedavaya gelmez, belleğe dönüşür. Varsayılan bağlam uzunluğu 4096 token’dır; uzun belgeler işleyen bir özellik bu değeri artırmak zorunda kalır, bu da bellek ihtiyacını büyütür.

Bir diğer ayrıntı model yükleme süresidir. Ollama, varsayılan olarak bir modeli son kullanımdan 5 dakika sonra bellekten boşaltır (OLLAMA_KEEP_ALIVE). Bu, sakin bir saatten sonra gelen ilk isteğin modeli yeniden yüklemesi gerektiği anlamına gelir; yükleme süresi modele ve donanıma bağlıdır, ama gecikme profilinde “ilk istek yavaş” diye bir kuyruk oluşturur. Ayar değiştirilebilir, ancak bellek sürekli dolu tutulur.

Bu yüzden gecikme sorusu “yerel mi uzak mı” diye değil, “kaç eşzamanlı kullanıcı, hangi bağlam uzunluğu, hangi yanıt süresi hedefi” diye sorulmalıdır. Küçük bir SaaS’ta eşzamanlı kullanıcı sayısı azsa, tek paralel istekli bir kurulum yeterli olabilir. Trafik dalgalandığında kuyruk ve soğuk başlangıç kullanıcı deneyimini belirler.

Gizlilik: veri nerede, kim görüyor?

Gizlilik, yerel çalıştırmanın en güçlü gerekçesidir ve en çok yanlış anlaşılan yanıdır. Ollama’nın SSS sayfasına göre modeller yerelde çalıştırıldığında Ollama istemleri ve verileri görmez. Bulut barındırmalı modeller ayrı bir yoldur; bunlarda istemler ve yanıtlar hizmeti sunmak için işlenir ve Ollama bunların saklanmadığını, günlüğe alınmadığını ve eğitimde kullanılmadığını belirtir. Bulut özellikleri tümüyle kapatılabilir (OLLAMA_NO_CLOUD=1). Yani yerel çalıştırma, yalnızca yerel yolu kullandığınızdan emin olduğunuz sürece, istemlerin üçüncü bir tarafa gitmemesini sağlar.

Ama bu, bütün gizlilik sorununu çözmez. Veri, kendi sunucunuzda kalsa bile günlük dosyalarında, yedeklerde ve erişim yetkilerinde bir sorumluluk olarak durur. Bir barındırılan hizmet sözleşme ve sertifikalarla güvence verebilirken, kendi sunucunuzda bu güvenceyi sizin kurmanız gerekir. Müşteri verisi kişisel veri sayılıyorsa, yasal yükümlülükler yerelde de geçerlidir. Gizlilik kaygısı gerçekse, kararın ölçütü “veri dışarı çıkıyor mu” olmalı; ama “içeride güvende mi” sorusu da ayrıca cevaplanmalıdır.

Karar çerçevesi

Üç ekseni tek bir soruya indirmek mümkün: yerel çalıştırmak, bu SaaS için neyi ucuzlatıyor, neyi hızlandırıyor, neyi koruyor, ve bunun bedeli ne?

İstek hacmi küçük ve dalgalıysa, maliyet açısından barındırılan hizmet çoğunlukla daha rahattır; yerel kurulum sabit gider ve işletme emeği getirir.
Hacim büyük ve düzenliyse, sabit giderin birim maliyeti düşürme ihtimali artar, ama bu hesabın kendi iş yükünüzün ölçümleriyle yapılması gerekir.
Gecikme hedefi sıkıysa ve eşzamanlı kullanıcı çoksa, paralellik ve bellek hesabını önceden yapmak gerekir; varsayılan paralellik değeri 1 olduğu için bu ayar kendiliğinden yetmez.
Verinin üçüncü taraflara hiç gitmemesi bir zorunluluksa (sözleşmeyle ya da mevzuatla), yerel çalıştırma bu zorunluluğu karşılamanın doğal yoludur ve diğer iki eksenin bedelini taşımaya değer olabilir.
Hiçbir eksende net bir baskı yoksa, en makul başlangıç çoğunlukla barındırılan bir hizmettir; model arkasına bir soyutlama katmanı konulursa, ileride yerel bir modele geçiş ucuz kalır. llama.cpp’nin OpenAI uyumlu bir API sunucusu başlatabilmesi, bu geçişi kolaylaştıran bir ayrıntıdır.

Sonuç olarak, “yerel LLM mantıklı mı” sorusunun evrensel bir cevabı yok. Mantıklı olduğu durumlar, gizlilik zorunluluğu ya da yüksek ve düzenli hacim gibi belirli koşullara bağlı. Küçük bir SaaS için varsayılan, ölçmeden karar vermemek: kendi veriyle küçük bir deneme, güncel fiyat sayfalarıyla bir hesap ve ancak ondan sonra bir seçim.