AI Hosting: GPT/Llama Modellerini Sunmak için Kurulum Rehberi

AI hosting; GPT veya Llama gibi büyük dil modellerini (LLM) kendi altyapınızda veya kiralık sunucularda hizmete dönüştürme sürecidir. Buradaki kritik konu, yalnızca “GPU alıp çalıştırmak” değil; uçtan uca gecikme (latency), bant genişliği, konteyner/orkestrasyon, veri güvenliği ve ölçekleme hedeflerini aynı anda tutturmaktır. Bu rehberde, doğru mimariyi kurmak için gereken kararları somut ölçütlerle açıklayıp, pratik bir kontrol listesi veriyorum.

1) Önce modeli değil, kullanım hedefini belirleyin

AI hosting projelerinde en sık yapılan hata, modele odaklanıp servis hedeflerini (istek türü, bekleme süresi, eşzamanlılık, maliyet limiti) sona bırakmaktır. GPT/Llama host ederken mimariyi belirleyen şey “kaç kullanıcı ne zaman ne yapacak?” sorusudur.

Hedef bazlı teknik gereksinimler

Aşağıdaki tablo, tipik hedeflere göre hangi kaynak profilinin öne çıktığını netleştirir:

Senaryo	Baskın gereksinim	Neden	Sonuçta ne seçilir
Tek kullanıcı / düşük istek (örn. dahili asistan)	Ortalama gecikme + küçük ölçek	Uzun kuyruklar oluşmaz	1-2 GPU ile tek-instance, basit yük dengeleme
Yoğun istek (örn. müşteri destek botu)	Eşzamanlılık + throughput	Aynı anda birden fazla token akışı gerekir	GPU sayısı + otomatik ölçek (autoscaling)
Düşük gecikme (örn. sohbet)	En düşük başlangıç gecikmesi (TTFT)	İlk token geç gelirse kullanıcı deneyimi bozulur	Modeli hazır tutma (warm), uygun batch ayarı
Uzun bağlam (long context)	VRAM (GPU belleği)	Token sayısı arttıkça bellek tüketimi büyür	Daha yüksek VRAM veya daha agresif kuantalama
Dosya/arama ile RAG (Retrieval-Augmented Generation)	Ağ + vektör veritabanı	Model kadar retrieval da gecikme yaratır	Ayrık katman: vektör DB + servis

Net kural: Hizmet hedefiniz “ilk token ne kadar sürede gelsin?” ise TTFT’yi (Time To First Token) etkileyen parametreleri (warm state, paralellik, batch, model boyutu) önceliklendirin. “Gecikme tolere edilebilir, maliyet önemli” ise daha düşük GPU ile daha iyi maliyet/throughput optimizasyonu yapın.

2) GPU seçimi: VRAM/çekirdek sayısından daha fazlası

Llama/GPT ailesi modelleri host ederken asıl belirleyici unsur VRAM kapasitesidir. Ancak yalnız VRAM sayısı yetmez; model boyutu, bağlam uzunluğu ve eşzamanlılık birlikte ele alınmalıdır.

Pratik hesap: VRAM neden darboğaz olur?\n- İstenen bağlam (prompt + geçmiş sohbet) arttıkça ara tensörler büyür.

Eşzamanlı kullanıcı arttıkça aynı anda birden fazla istek için bellek kullanımı artar.
Kuantalama (quantization) bellek düşürür; fakat bazı senaryolarda hız/maliyet dengesi değişir.

Model boyutu için net yaklaşım

Aşağıdaki gibi düşünün: - Daha küçük modeller (düşük milyarlar parametre): Daha az VRAM ile çalışır; başlangıç için daha uygundur. - Orta ölçek modeller: Uzun sohbet/uzun bağlam hedefiniz varsa VRAM hızla yetmeyebilir. - Büyük modeller: Çoğu senaryoda tek GPU yetmez; ya daha yüksek VRAM gerekir ya da servis mimarisi katmanlara ayrılır.

Donanım/altyapı kontrol listesi

GPU almadan önce şu sorulara net cevap verin: - Hedef bağlam uzunluğu kaç? (örn. 8K/16K/32K) - Beklenen eşzamanlı istek sayısı nedir? (örn. 10/50/200) - Maksimum üretim (max output tokens) kaç? - Öncelik sıralaması: TTFT mi throughput mu? - Günlük kaç saat çalışacak? (boşta maliyet)

Bu soruların çıktısına göre “kaç GPU / hangi VRAM” kararını verirsiniz. Sadece “CPU/RAM yeter mi?” yaklaşımı AI hosting için yanıltıcı olur; asıl darboğaz çoğunlukla GPU VRAM’dir.

3) Mimaride 3 katman: Model, API, veri (RAG varsa)

GPT/Llama host etmeyi tek bir makineye “her şey dahil” kurmak yerine, katmanlara ayırmak hem ölçeklemeyi hem de arıza izolasyonunu kolaylaştırır.

Önerilen katmanlar

Model servisi: GPU üzerinde çalışan inference engine.
API katmanı: İstek doğrulama, oran sınırlama (rate limiting), kimlik doğrulama, istek kuyruklama.
Veri katmanı (opsiyonel): RAG kullanıyorsanız vektör arama ve doküman depolama.

Neden katman ayırmalısınız?

Model katmanı CPU/IO sorunlarından daha az etkilenir.
API katmanı hızlı ölçeklenebilir; model katmanı daha yavaş ölçeklenir.
Güvenlik kontrolleri tek noktada uygulanır.

RAG kullanıyorsanız veri akışı

Kullanıcı sorgusu → embedleme → vektör DB araması → ilgili parçalar → model’e context olarak iletim.
Bu akışta gecikme “tek başına model” değil, arama + ağ + context derleme toplamıdır.

4) Konteyner ve servis ayarları: gecikmeyi düşürmenin somut yolları

LLM servislerinde gecikmeyi iki ana kalem belirler: - TTFT: İlk token gelene kadar geçen süre - Token throughput: Token üretim hızı (örn. tokens/s)

TTFT’yi düşürmek için net uygulamalar

Warm state: Modelin her istekte yeniden yüklenmesini engelleyin. Autoscaling kullanıyorsanız scale-in/scale-out sırasında “soğuma” süresini planlayın.
Model yükleme stratejisi: Konteyner başlatma sürelerini ölçün. “Konteyner ayağa kalktı ama model henüz hazır değil” penceresi TTFT’yi artırır.
Batching ayarı: Çok agresif batching eşzamanlılıkta gecikmeyi artırabilir. Ama kontrollü batching throughput’u iyileştirir.

Token throughput’u iyileştirmek için net uygulamalar

Kuantalama (quantization) kullanıyorsanız hedef senaryoya uygun seviyeyi seçin.
GPU kaynaklarını paylaşırken (multiple workers) VRAM çarpanlarını hesaba katın.
Uzun output’larda (max tokens) kullanıcı başına maliyet artar; output sınırı net olmalı.

Basit mimari örnek (konsept)

Aşağıdaki akış, çoğu AI hosting kurulumu için temel iskeleti verir: - API Gateway / uygulama katmanı - Rate limiting + auth - İstek kuyruğu (ani trafik burst’lerinde) - Model inference servisi - (Varsa) Vektör DB / doküman servisleri

5) Ölçekleme: autoscaling, kuyruk ve kapasite planlama

AI hosting’te ölçekleme sadece “GPU sayısını artırmak” değildir; burst trafiği yönetmek için kuyruk ve önceliklendirme (priority) gerekir.

Kapasiteyi ölçün: kabul edilebilir hedefler

Şu ölçümleri koymadan ölçekleme sağlıklı olmaz: - Ortalama TTFT (p50/p95) - Token throughput (örn. tokens/s) - Eşzamanlı kullanıcı başına ortalama GPU kullanımı - Kuyruk uzunluğu ve bekleme süresi

Autoscaling nasıl yapılmalı?

Ölçüm temelli autoscaling: GPU utilization, queue length veya request latency gibi metriklere göre.
Ölçüm gecikmesi dikkate alınmalı: Hemen ölçeklenmeyen veya geç geri ölçeklenen sistemlerde p95 gecikme büyür.
Scale-down’da warm state kaybını ölçün: “Gecikmeyi artıran soğuma” birim maliyeti düşürürken kullanıcı deneyimini bozabilir.

Net kapasite kuralı

Eşzamanlılık artışını kuyruksuz yönetmek pahalıdır.
Kuyruk eklemek daha ucuzdur ama p95 gecikmeyi yönetmek gerekir.
Bu nedenle “hedef p95 TTFT” için servis kapasitesi belirleyin.

6) Güvenlik ve veri: prompt sızıntısı, anahtar yönetimi, log politikası

GPT/Llama host ederken güvenlik sadece dışarıya saldırı değil; içe doğru veri sızıntısı (prompt/response logging) ve yetkisiz erişimi de kapsar.

Uygulanması gereken net kontroller

Kimlik doğrulama (auth): Kullanıcı bazlı erişim ve kullanım kotası.
Oran sınırlama (rate limiting): “Tek kullanıcı fiyatı bitiriyor” riskini kapatır.
API anahtarı yönetimi: Model sağlayıcı veya inference katmanı için kullanılan anahtarlar uygulama kodunda bulunmamalıdır.
Log politikası: Prompt ve response içeriğini otomatik log’a yazmayın; yazmanız gerekiyorsa maskeleme (masking) veya şifreli saklama uygulayın.
Şifreleme: Trafik için TLS (HTTPS) zorunlu; saklama için disk encryption ve erişim yetkileri belirgin olmalı.

Veri kalıcılığı (persistency)

RAG dokümanları ve vektör indeksleri için yedek (backup) ve sürümleme stratejisi belirleyin.
Model servisinde cache varsa (prompt cache vb.), cache’in silinmesi kullanıcı için nasıl davranış doğurur netleştirin.

7) Maliyet kontrolü: token başına maliyet + altyapı maliyeti toplamı

AI hosting’in bütçesi “sadece GPU fiyatı” değildir. Token başına maliyet; eşzamanlılık, output uzunluğu ve kuyruk yönetimiyle değişir.

Maliyet kalemleri

GPU kira/işletim maliyeti
Depolama (RAG dokümanları, vektör DB, loglar)
Ağ çıkışı (outbound) ve veri aktarımı
Operasyon: izleme (monitoring), yedek (backup), güncelleme

Net maliyet azaltma yöntemleri

Output sınırı: max output tokens ile maliyeti tavanlayın.
Sorgu optimizasyonu: Gereksiz uzun history’i kesmek (history window yönetimi).
Cache: Tekrarlayan sorgularda prompt/response cache maliyeti düşürebilir; ama veri sızıntısı riskine göre tasarlanmalıdır.
Çalışma saatleri: Günün tamamında sıcak tutmak yerine kullanım paternine göre warm plan yapın.

8) Kurulum kontrol listesi (kopyala-uygula)

Aşağıdaki listeyi proje başlangıcında kullanın:

Teknik gereksinimler

[ ] Hedef kullanıcı sayısı ve eşzamanlılık net mi?
[ ] Bağlam uzunluğu hedefi kaç token?
[ ] max output tokens limiti belirlendi mi?
[ ] TTFT hedefi (p95) tanımlandı mı?

Altyapı ve servis

[ ] GPU VRAM kapasitesi hedef bağlam/eşzamanlılık için yeterli mi?
[ ] Model warm state planı var mı?
[ ] Autoscaling metrikleri tanımlandı mı? (queue length / latency / utilization)
[ ] Rate limiting ve kullanım kotası var mı?

Veri ve güvenlik

[ ] Prompt/response loglama politikası net mi?
[ ] TLS (HTTPS) ve saklama şifreleme var mı?
[ ] Yedek (backup) planı ve geri dönüş testi yapıldı mı?

İzleme (monitoring)

[ ] p50/p95 TTFT ölçülüyor mu?
[ ] tokens/s ve hata oranı izleniyor mu?
[ ] GPU kullanım eğrileri izleniyor mu?

Sonuç: İlk sprinti “ölçülebilir hedeflerle” kapatın

AI hosting’de doğru kararı, model boyutunu büyütmek yerine gecikme ve maliyet hedeflerini ölçülebilir biçimde tanımlamak belirler. Bu nedenle ilk sprintte hedef p95 TTFT, max output tokens limiti, beklenen eşzamanlılık ve VRAM planını netleştirip; ardından warm state, rate limiting ve ölçekleme metriklerini kurun. En hızlı ilerleme için NetKıyas’ta ihtiyacınıza uygun GPU/VPS seçeneklerini, yalnızca fiyatına değil VRAM kapasitesi, ağ performansı ve ölçek kabiliyetine göre listeleyin; seçim kriterinizi bu rehberdeki kontrol listesiyle sabitleyin.