Yüksek Hacimli Sorgular için Local LLM Kullanımı

Local LLM'ler yüksek hacim altında neden zorlanır?

Bir SaaS platformu ya da müşteri destek robotu günde binlerce LLM isteğini işlediğinde, kendi sunucunuzda çalıştırdığınız local LLM'ler de geleneksel servis altyapıları gibi hızla darboğaza girer. Sorunun kalbinde KV cache var: modelin önceki token'lara ait ara hesaplamalarını sakladığı GPU belleği. Cache büyüdükçe hafıza parçalanır, boşa ayrılan alan ortaya çıkar.

UC Berkeley araştırmacılarının vLLM çalışmasına göre, klasik "her sorguya tek parça bellek ayır" yaklaşımı yüzde 60-80 oranında KV cache israfına yol açar. Buna bir de statik batching (sorguları sabit gruplar halinde çalıştırma) eklendiğinde uzun bir sorgu kuyruğu kilitler, kısa sorgular GPU boş dururken sırada bekler.

Local LLM'i yüksek hacimde verimli sunmanın yolu: bellek yönetimini ve kuyruk mantığını yeniden tasarlamak. vLLM bu iki problemi birden çözen açık kaynak local LLM sunucusudur.

vLLM: Local LLM için yüksek verimli sunucu

vLLM, local LLM çalıştırmak için tasarlanmış açık kaynak bir inference sunucusudur. İki temel yeniliği var: PagedAttention ve Continuous Batching.

PagedAttention: bellek israfını bitirir

Klasik sunucular her sorgu için baştan sonra büyük bir bellek bloğu ayırır. Sorgu bitince bu bloğun yarısı boş kalır, başka sorgu için kullanılamaz. vLLM ise işletim sistemlerindeki sayfalama mantığını model belleğine uyarlar: KV cache'i sabit boyutlu küçük "sayfalara" böler. Sayfaların bellekte yan yana olma zorunluluğu yoktur; boşalan bir sayfa anında başka sorgu için kullanılabilir. Sonuç: israf yüzde 4'ün altına iner.

Bonus: aynı sistem prompt'undan türeyen farklı kullanıcı çıktıları, ayrışana kadar aynı sayfaları paylaşır. RAG veya few-shot prompt kullanan local LLM kurulumlarında bu, ciddi VRAM kazancı demek.

Continuous Batching: GPU'yu boş bırakmaz

Statik batching'de bir grup sorgu birlikte başlar, en uzunu bitene kadar GPU diğer slot'larda boşa çalışır. vLLM ise her token üretimi sonrası biten sorguyu çıkarır, yerine kuyruktaki bir başkasını hemen ekler. In-flight batching denen bu yaklaşım GPU'yu sürekli dolu tutar; özellikle uzunlukları çok değişken sorgularda (sohbet, OTP doğrulama, kısa öneri vb.) throughput'u belirgin şekilde artırır.

Diğer optimizasyonlar

• vLLM, PagedAttention'ı verimli okuyan özel CUDA ve HIP (AMD GPU) çekirdekleri kullanır.
• Quantization (FP8, INT8 gibi düşük hassasiyetli model ağırlıkları) ve tensor parallelism (modeli birden fazla GPU'ya parçalama) destekler.
• Speculative decoding ile küçük bir "taslak model" cevabı önceden tahmin eder, ana model yalnızca doğrulamaya odaklanır; tipik gecikme yarı yarıya azalabilir.
• Tüm bu optimizasyonlar birlikte vLLM'i, HuggingFace Transformers ya da FasterTransformer/Orca gibi sunuculara kıyasla aynı gecikme seviyesinde 2-4 kat daha yüksek throughput'a çıkarır.

Local LLM'inizi vLLM ile nasıl ölçeklersiniz?

• Model seçimi: PagedAttention uzun bağlamı verimli yönettiği için 32k+ context window'lu local LLM'lerle (Llama 4, Qwen3, DeepSeek-R1 vb.) rahat çalışır.
• Donanım: Çok GPU varsa tensor parallelism ile büyük modelleri paylaştırabilirsiniz. Tek GPU'lu kurumsal kurulumda quantize edilmiş 7-13B modellerle saniyede yüzlerce kullanıcıya cevap vermek mümkündür.
• Hibrit mimari: KVKK kapsamında kişisel veri içeren sorguları kendi data center'ınızdaki local LLM'e (vLLM) gönderin, jenerik ya da kamuya açık sorgular için bulut API'lerini kullanın. Böylece veri Türkiye'de kalır, maliyet de tek başına lokal kurulumun altına iner.

vLLM dışında alternatifler

Tek seçenek vLLM değil. İki alternatif local LLM sunucusu öne çıkıyor:

• Text-Generation Inference (TGI): HuggingFace'in açık kaynak sunucusu. WebSocket/REST API ve çoklu GPU otomatik ölçekleme avantajı var. Ama PagedAttention olmadığı için aynı donanımda vLLM kadar verim alamazsınız.
• TensorRT-LLM: NVIDIA'nın üretim odaklı sunucusu. FP8 dönüşümleri ve özel kernel'larla en yüksek tek-GPU performansını verir. Karşılığında yalnızca NVIDIA GPU'larında çalışır ve bazı parçaları kapalı kaynaktır.

Üretimde sıklıkla şu seçim yapılıyor: standart local LLM dağıtımı için vLLM, kapalı/regüle ortamda en yüksek tek-GPU performansı gerektiğinde TensorRT-LLM.

SMS API tarafında benzer mimari

Yüksek hacimli LLM sunumunda PagedAttention ve continuous batching ne kadar kritikse, yüksek hacimli SMS gönderiminde de queue yönetimi ve concurrent request handling o kadar belirleyici. iletiMerkezi SMS API'si toplu gönderimleri kuyruklayıp operatöre dağıtırken benzer ilkelerle çalışacak şekilde tasarlanmıştır: kısa OTP'lerin uzun toplu kampanyaların arkasında bekletilmemesi için öncelik kuyrukları, retry/backoff politikaları ve rate-limit mekanizmaları altyapının bir parçası (ayrıntılar için SMS API dokümantasyonu). Local LLM'inizin kullanıcıyla SMS üzerinden temas kuran kısmını iletiMerkezi MCP Server veya doğrudan REST API ile entegre edebilir, hibrit mimari kurarken iletişim kanalını dert etmeden yapay zeka tarafına odaklanabilirsiniz.

Sonuç

Yüksek hacimli sorgular için local LLM kullanımı, doğru sunucu seçildiğinde kendi veri merkezinizde bile rahatlıkla mümkün. vLLM'in PagedAttention ve Continuous Batching çözümleri, bellek yönetimini işletim sistemi düzeyindeki sayfalama mantığıyla optimize ederek GPU kullanımını maksimize eder. Geleneksel LLM sunucularındaki yüzde 60-80 bellek israfı yüzde 4'ün altına iner, throughput 2-4 kat artar. SaaS ekipleri için sonuç: binlerce eş zamanlı kullanıcıyı düşük gecikmeyle yanıtlayabilen, ölçeklenebilir bir local LLM altyapısı. KVKK ve GDPR uyumu ise yine süreç tarafına bağlı; erişim kontrolü, log yönetimi, veri saklama/silme politikaları ve sözleşmesel gerekliliklerle birlikte kurgulandığında bu altyapı uyum gerekliliklerini karşılamayı kolaylaştırır.