LLM Sunucusu Kiralama

LLM sunucusu kiralama nedir, kimler için uygundur?

LLM sunucusu kiralama, açık ağırlıklı dil modellerini üçüncü taraf bir yapay zekâ API’si yerine kendi denetiminizdeki GPU’lu sunucuda çalıştırmak için donanım kiralamaktır. Model sunucunuzda çalıştığı için gönderdiğiniz metinler, belgeler ve müşteri verileri başka bir şirketin altyapısına gitmez; maliyet ise istek başına değil, sunucu kaynağına göre belirlenir.

Kendi LLM sunucunuz şu senaryolarda öne çıkar:

• Gizli veriyle çalışan asistanlar: Sözleşme, sağlık, finans ya da personel belgeleri üzerinde soru-cevap (RAG) sistemleri
• Kurum içi sohbet arayüzü: Çalışanlara Open WebUI gibi bir arayüzle özel bir sohbet asistanı sunmak
• Yüksek hacimli otomasyon: Binlerce ürün açıklaması, e-posta sınıflandırma, özetleme ve çeviri gibi tekrarlayan işler
• Yazılım ekipleri: Kod tamamlama ve kod inceleme için yerel kod modelleri
• Ar-Ge ve ince ayar: Kendi verinizle LoRA / QLoRA ince ayarı ve model karşılaştırma

Bu iş yüklerinde işlemci tek başına yetersiz kalır; çıkarım hızını ekran kartının belleği ve bellek bant genişliği belirler. GPU sunucuların genel kullanım alanları için GPU sunucu nedir yazısına, model ve VRAM seçiminin ayrıntılı mantığı için yapay zekâ sunucusu seçimi yazısına bakabilirsiniz. Bu sayfa, hangi modelin hangi sunucuya sığacağını ve üretim ortamında nasıl çalıştırılacağını ele alır.

Hangi model için ne kadar VRAM gerekir?

Bir modelin ihtiyaç duyduğu VRAM’i kabaca parametre sayısı × parametre başına bayt formülüyle hesaplar, üzerine bağlam (context) için KV önbelleği ve çalışma payı eklersiniz. 16 bit (FP16 veya BF16) hassasiyette her parametre 2 bayt tutar; 8 milyar parametreli bir model yalnız ağırlıklar için yaklaşık 16 GB ister. Aynı model 4 bit kuantize edildiğinde yaklaşık 5 GB’a iner.

Hesapta unutulan kalem çoğu zaman KV önbelleğidir. Model, konuşmadaki her token için katman başına anahtar ve değer vektörleri saklar; bu bellek bağlam uzunluğu ve eşzamanlı istek sayısıyla doğrusal büyür. Uzun belgelerle çalışan ya da aynı anda çok kullanıcıya hizmet veren bir sistemde KV önbelleği, model ağırlıkları kadar yer kaplayabilir.

Pratik kurallar:

• Tablodaki ağırlık değerine tek kullanıcı ve orta uzunlukta bağlam için en az %10–30 pay ekleyin.
• Model VRAM’e tam sığmıyorsa katmanların bir kısmı işlemciye ve sistem belleğine aktarılabilir (llama.cpp’de kısmi GPU yükleme), ancak hız belirgin biçimde düşer.
• Çok kullanıcılı bir API planlıyorsanız modeli değil, “model + hedef bağlam uzunluğu × eşzamanlı istek” toplamını VRAM’e sığdırmayı hedefleyin.

Model kartlarında (model card) belirtilen bağlam uzunluğunun tamamını kullanmak zorunda değilsiniz; üretimde bağlamı ihtiyaç kadar sınırlamak, aynı GPU’da daha fazla eşzamanlı isteğe yer açar.

Kuantizasyon nedir, model kalitesini nasıl etkiler?

Kuantizasyon, model ağırlıklarını 16 bit yerine 8, 5 veya 4 bit gibi daha düşük hassasiyette saklayarak bellek ihtiyacını ve çoğu durumda yanıt üretim süresini azaltan tekniktir. Karşılığında modelin doğruluğunda bir miktar kayıp olur; bu kayıp 8 bitte genellikle fark edilmeyecek kadar küçükken, 4 bitin altına indikçe belirginleşir.

Genel bir yol haritası şöyledir: önce hedeflediğiniz modelin 4 bit sürümüyle başlayın, kendi örnek sorularınızla kaliteyi ölçün. Sonuç yetersizse aynı modelin 5 veya 8 bit sürümünü ya da daha büyük bir modelin 4 bit sürümünü deneyin. Çoğu iş senaryosunda, büyük bir modelin 4 bit sürümü küçük bir modelin 16 bit sürümünden daha iyi sonuç verir. Matematik, kod ve yapılandırılmış çıktı (JSON) gibi hassas görevlerde ise düşük bit kuantizasyonun etkisini mutlaka kendi testlerinizle doğrulayın.

Ollama, llama.cpp mi yoksa vLLM mi kullanmalısınız?

Tek kullanıcılı deneme, geliştirme ve küçük ekip içi kullanım için Ollama; donanımı en ince ayrıntısına kadar denetlemek ve GGUF modellerini esnek biçimde çalıştırmak için llama.cpp; çok sayıda eşzamanlı isteğe yüksek verimle yanıt veren üretim API’si için vLLM doğru seçimdir. Üçü de OpenAI uyumlu bir API sunduğu için uygulamanızı bir yazılımdan diğerine geçirmek kolaydır.

vLLM, GPU belleğinin varsayılan olarak büyük bölümünü (--gpu-memory-utilization) baştan ayırır ve KV önbelleğini bu alanda yönetir; aynı GPU’da başka bir model çalıştıracaksanız bu oranı düşürmeniz gerekir. Adım adım kurulum örnekleri için LLM çalıştırma: açık kaynak modeli kendi sunucunuzda kullanın rehberine bakın.

Bir LLM sunucusu kaç kullanıcıya hizmet verir?

Bir LLM sunucusunun kaç kullanıcıya hizmet vereceğini modelin boyutu, kuantizasyon düzeyi, bağlam uzunluğu ve çıkarım yazılımının toplu işleme yeteneği birlikte belirler; tek bir sayı vermek yanıltıcı olur. Doğru yöntem, kendi istem (prompt) ve yanıt uzunluklarınızla yük testi yapmaktır.

Planlamada iki ölçüyü ayırın:

• İlk token süresi (time to first token): Kullanıcının yanıtın başlamasını beklediği süre. Uzun istemler ve uzun belgeler bu süreyi artırır.
• Saniyedeki token (tokens/s): Yanıtın akış hızı. Tek kullanıcı için GPU bellek bant genişliği belirleyicidir; çok kullanıcıda toplam verim önemlidir.

vLLM gibi sürekli toplu işleme yapan sunucular, aynı GPU’da birden fazla isteği birlikte işleyerek toplam verimi tek kullanıcıya göre katlarca artırabilir; buna karşılık her bir kullanıcının akış hızı bir miktar düşer. Ollama ise varsayılan ayarlarla sınırlı paralellik sunar ve kurum içi küçük ekipler için yeterlidir.

Kapasiteyi artırmanın yolları şunlardır: daha küçük ya da kuantize bir model seçmek, bağlam uzunluğunu sınırlamak, daha fazla VRAM’li bir GPU’ya geçmek ya da isteği birden fazla GPU sunucusuna dağıtmak. Gecikmeye duyarlı uygulamalarda sunucunun kullanıcılarınıza yakın olması da önemlidir; Türkiye’deki kullanıcılar için Türkiye’de barındırılan bir sunucu ağ gecikmesini azaltır.

GPU dışında işlemci, RAM ve disk ne kadar önemli?

LLM çıkarımında asıl işi GPU yapar, ancak sistem belleği, disk ve işlemci yanlış seçilirse GPU’nun gücünden tam yararlanılamaz. Özellikle model yükleme süresi ve CPU’ya taşan katmanlar bu bileşenlere bağlıdır.

• Sistem belleği (RAM): Model dosyası GPU’ya aktarılırken önce sistem belleğinden geçer; kullandığınız en büyük modelin dosya boyutundan daha fazla sistem belleği olması yükleme sırasında sorun çıkmasını önler. Katmanların bir kısmını CPU’da çalıştıracaksanız bu bellek ayrıca gerekir.
• Disk: 70 milyar parametreli bir modelin 4 bit sürümü bile onlarca gigabayttır; birkaç model ve sürümü denemek yüzlerce gigabayt yer ister. NVMe disk, modelin diskten okunup belleğe yüklenme süresini belirgin biçimde kısaltır.
• İşlemci: Tokenizasyon, istek yönetimi, RAG için belge işleme ve gömme (embedding) üretimi işlemci kullanır; çok kullanıcılı API’de yeterli çekirdek sayısı darboğazı önler.
• Ağ: Model indirme ve yoğun API trafiği için yüksek bant genişliği gerekir; LIONFIN altyapısının 600 Gbit/s toplam upstream kapasitesi büyük model dosyalarının indirilmesinde ağ tarafında pay bırakır.

Paketlerin GPU belleği, işlemci, sistem belleği ve disk değerlerini bu sayfadaki paket tablosunda birlikte karşılaştırın; yalnız GPU modeline bakarak karar vermeyin.

LLM sunucusu nasıl hazırlanır?

LLM sunucusu hazırlamanın temel sırası; NVIDIA sürücüsü ve CUDA’yı doğrulamak, çıkarım yazılımını kurmak, modeli indirmek ve API’yi güvenli bir şekilde dışarıya açmaktır. LIONFIN AI sunucularında paket tablosunda CUDA hazır imaj belirtilen paketler sürücüyle birlikte gelir; kendi imajınızı kuracaksanız CUDA kurulumu rehberini izleyin.

1. GPU’yu doğrulayın: nvidia-smi komutu GPU’yu, sürücü sürümünü ve boş belleği göstermelidir.
2. Kapsayıcı katmanı (isteğe bağlı): Docker ve NVIDIA Container Toolkit kurarsanız modelleri --gpus all parametresiyle kapsayıcı içinde çalıştırabilirsiniz.
3. Çıkarım yazılımını kurun: Hızlı başlangıç için Ollama, üretim API’si için vLLM.
4. Modeli seçin ve indirin: Ollama’da ollama pull, vLLM’de Hugging Face model adıyla vllm serve. Bazı modeller indirme öncesi lisans onayı ister.
5. API’yi koruyun: Yazılımı yalnız 127.0.0.1 üzerinde dinletin, önüne kimlik doğrulama yapan bir Nginx reverse proxy koyun ve HTTPS’i açın.
6. Arayüz ekleyin: Ekip kullanımı için Open WebUI gibi bir sohbet arayüzünü aynı sunucuya kurabilirsiniz.

Sistemi bir systemd servisi ya da Docker Compose ile tanımlamak, sunucu yeniden başladığında modelin otomatik olarak ayağa kalkmasını sağlar.

Kendi belgelerinizle RAG sistemi nasıl kurulur?

RAG (Retrieval-Augmented Generation, getirme destekli üretim), modele soru sormadan önce kendi belgelerinizden ilgili parçaları bulup isteme ekleyen ve böylece modeli yeniden eğitmeden şirket bilginizle yanıt vermesini sağlayan yöntemdir. Çoğu kurumsal LLM projesinde ince ayardan önce denenmesi gereken yaklaşım RAG’dir.

Bir RAG sistemi dört parçadan oluşur:

1. Belge işleme: PDF, Word ve web sayfaları metne çevrilir ve anlamlı parçalara (chunk) bölünür.
2. Gömme (embedding): Her parça, küçük bir gömme modeliyle sayısal vektöre dönüştürülür. Gömme modelleri dil modellerinden çok daha küçüktür ve aynı GPU’da birlikte çalışabilir.
3. Vektör veritabanı: Vektörler PostgreSQL’in pgvector eklentisi, Qdrant gibi bir vektör veritabanında saklanır.
4. Yanıt üretimi: Kullanıcının sorusuna en yakın parçalar bulunur ve dil modeline bağlam olarak verilir.

RAG kalitesini çoğu zaman model değil, parçalama ve arama kalitesi belirler: çok büyük parçalar bağlamı doldurur, çok küçük parçalar anlamı böler. Türkçe belgelerle çalışıyorsanız gömme modelinin çok dilli olduğundan emin olun. RAG, bağlam uzunluğunu ve dolayısıyla KV önbelleği ihtiyacını artırdığı için VRAM hesabını uzun istemlere göre yapın. Vektör veritabanının kalıcı verisini düzenli yedekleme planına dahil etmeyi unutmayın.

LLM sunucusunda güvenlik ve veri gizliliği nasıl sağlanır?

LLM sunucusunda en sık yapılan güvenlik hatası, çıkarım API’sini kimlik doğrulama olmadan internete açık bırakmaktır. Ollama’nın API’si varsayılan olarak kimlik doğrulama içermez ve yalnız yerel adreste dinler; OLLAMA_HOST ile tüm arayüzlere açıldığında sunucunuzu bulan herkes GPU’nuzu ücretsiz kullanabilir, modellerinizi silebilir ya da indirebilir.

• Yerel dinleme: Ollama, vLLM ve llama-server yalnız 127.0.0.1 üzerinde dinlesin; dışarıya yalnız HTTPS üzerinden, kimlik doğrulamalı reverse proxy açılsın.
• API anahtarı: vLLM’in --api-key parametresiyle ya da proxy katmanında anahtar doğrulaması yapın.
• Güvenlik duvarı: 11434, 8000 ve 8080 portları dışarıya kapalı olsun; yalnız SSH ve 443 açık kalsın.
• Kayıtlar: İstem ve yanıt kayıtları kişisel veri içerebilir; ne kadar süre saklandığını ve kimin erişebildiğini belirleyin.
• İstem enjeksiyonu (prompt injection): RAG ve araç kullanan sistemlerde belge içeriğinden gelen talimatlara karşı modelin yetkilerini sınırlayın; modelin doğrudan veritabanı yazma ya da e-posta gönderme yetkisi olmasın.

Kendi sunucunuzda çalışan bir modelde gönderilen veri üçüncü taraf bir yapay zekâ hizmetine aktarılmaz; bu, kişisel verilerin yurt dışına aktarımı gibi konularda değerlendirmeyi kolaylaştırır. Veri konumu ve teknik önlemler için KVKK uyumlu hosting yazısına bakabilirsiniz.

Kendi LLM sunucusu mu, yapay zekâ API’si mi, bulut GPU mu?

Kendi LLM sunucunuz; sürekli ve öngörülebilir kullanım, veri gizliliği ve açık modelleri özelleştirme ihtiyacı olduğunda, ticari yapay zekâ API’leri ise düşük ve düzensiz hacimde ya da en güçlü kapalı modellere ihtiyaç duyduğunuzda daha mantıklıdır. Saatlik bulut GPU ise kısa süreli eğitim ve deneyler için uygundur.

Karar için aylık token hacminizi tahmin edin ve aynı işi açık bir modelle yapıp yapamayacağınızı küçük bir pilotla test edin. Pilotta kalite yeterliyse ve hacim süreklilik gösteriyorsa sabit maliyetli bir sunucu çoğu zaman avantajlı hâle gelir. Ayrılmış GPU sunucu ile saatlik bulut GPU arasındaki farkları GPU sunucu mu bulut GPU mu sayfası ayrıntılı karşılaştırır. Görsel ve video işleme gibi farklı GPU iş yükleri için render sunucusu kiralama sayfasına da göz atabilirsiniz.

LLM sunucusunda en sık görülen sorunlar nelerdir?

LLM sunucularında en sık görülen sorunlar VRAM yetersizliği, modelin GPU yerine işlemcide çalışması, sürücü ve CUDA sürüm uyumsuzluğu ve ilk isteğin uzun sürmesidir. Teşhisin ilk adımı her zaman nvidia-smi çıktısına bakmaktır: GPU belleğinin dolup dolmadığı ve hangi sürecin GPU kullandığı burada görünür.

• “CUDA out of memory”: Model, bağlam uzunluğu ve eşzamanlı istekler VRAM’e sığmıyordur. Daha düşük bitli bir sürüm seçin, vLLM’de --max-model-len değerini düşürün ya da GPU’da çalışan başka süreçleri kapatın.
• Yanıtlar çok yavaş, GPU boşta: Model işlemcide çalışıyordur; sürücü yüklenmemiş, kapsayıcı GPU erişimi olmadan başlatılmış ya da model VRAM’e sığmadığı için katmanlar CPU’ya taşınmıştır. Ollama’da ollama ps çıktısı modelin GPU’da mı CPU’da mı çalıştığını gösterir.
• Sürücü / CUDA uyumsuzluğu: Çıkarım yazılımının derlendiği CUDA sürümü sürücünün desteklediğinden yeniyse yazılım GPU’yu görmez.
• İlk istek uzun sürüyor: Model diskten belleğe yükleniyordur. Ollama’da OLLAMA_KEEP_ALIVE ile modelin bellekte kalma süresini uzatabilirsiniz.
• Türkçe yanıt kalitesi düşük: Seçtiğiniz model Türkçe veride zayıf olabilir; çok dilli eğitimi güçlü modelleri ve daha yüksek bitli sürümleri karşılaştırın.

Donanım kaynaklı bir şüpheniz varsa müşteri panelinden destek talebi açarken nvidia-smi çıktısını eklemeniz teşhisi hızlandırır.