AI Hosting Rehberi: GPT/Llama Modellerini Doğru Host Etme

Günümüzde AI hosting (LLM inference ve bazen fine-tuning), sadece “GPU kirala” fikrinden ibaret değildir. Doğru mimariyi kurmazsanız gecikme (latency) yükselir, maliyet kontrolü zorlaşır ve güvenlik açıkları büyür. Bu rehberde GPT/Llama modellerini self-host ederken donanım/kapasite planlamasını, konteynerle çalıştırmayı, ölçeklemeyi ve izleme-güvenlik adımlarını net bir şekilde öğreneceksiniz.

Aşağıdaki başlıklarda özellikle şu soruları yanıtlayacağız: Hangi GPU sınıfı gerekir? VRAM nasıl hesaplanır? vLLM/Triton gibi servislerle performans nasıl optimize edilir? Yedekleme, loglama, erişim ve veri güvenliği nasıl kurgulanır?

## 1) AI hosting mimarisi: inference mi, fine-tuning mi?

LLM host etmenin iki ana senaryosu var:

Inference (çıkarım): Modeli çalıştırıp kullanıcıdan gelen isteğe cevap üretmek.
Fine-tuning (ince ayar): Modeli eğitime benzer şekilde yeniden uyarlamak (daha yüksek maliyet, daha kompleks pipeline).

Yeni başlayanlar için en doğru başlangıç noktası inference’tır. Fine-tuning’e geçmeden önce şu temel kararlar netleşmelidir.

Hangi seçenek ne zaman?

Sadece sohbet/özetleme/otomasyon hedefliyorsanız inference yeterlidir.
Özel veriyle davranış biçimi değiştirmek (ör. sınıflandırma formatı) istiyorsanız fine-tuning gündeme gelir.
Fine-tuning planlıyorsanız hem depolama (dataset), hem eğitim akışı (training framework), hem de sürümleme (model ve tokenizer versiyonları) ayrıca tasarlanmalıdır.

## 2) GPU seçimi ve VRAM hesaplama: “model sığar mı?” sorusunu netleştirin

LLM inference’ta belirleyici unsur VRAM (GPU belleği). CPU/RAM tek başına performansı kurtarmaz; GPU VRAM yetersiz olursa servis başlatılamaz veya sürekli swap davranışı yüzünden yavaşlar.

Aşağıdaki hesap yaklaşımı “yaklaşık planlama” içindir. Kesin değerler; quantization yöntemi, batch size ve context uzunluğuna göre değişir.

Model boyutu → VRAM çerçevesi

Model parametre boyutunu (ör. 7B, 13B, 34B) baz alarak yaklaşın: - FP16/BF16 (yüksek kalite): VRAM ihtiyacı en yüksektir. - FP8: FP16’dan daha düşük ama destek ve yazılımlara bağlı. - 4-bit/8-bit quantization (daha yaygın): VRAM ihtiyacını ciddi düşürür.

Net planlama için şu pratik yol kullanın:

Modelin hedef quantization’ını belirleyin (ör. 4-bit).
Beklenen max context length (ör. 4K, 8K, 16K token) seçin.
vLLM/TGI gibi motorlarda ihtiyaç duyulan ek bellek (KV cache) payını ekleyin.

KV cache (context) neden kritik?

LLM’in her yeni token eklemesiyle KV cache büyür. Context uzunluğu büyüdükçe aynı GPU’da daha az eşzamanlı istek (concurrency) çalışır.

Net karar kuralı: - Context 8K ve üstüyse, concurrency hedefinizi düşük başlatın ve ölçümle artırın. - 4K context ile başlamak, maliyeti kontrol etmek için daha kolaydır.

GPU sınıfı için pratik eşleşme

Aşağıdaki eşleşmeler “çoğu üretim senaryosunda işe yarayan” başlangıç noktalarıdır:

7B / 8B sınıfı (4-bit): 16–24 GB VRAM ile genelde daha rahat.
13B (4-bit): 24–48 GB VRAM tercih edilir.
30B+ (4-bit): 48 GB ve üstü VRAM daha güvenli; aksi halde concurrency çok düşer.

Not: Aynı model bile farklı motor/ayarlarla farklı tüketim gösterebilir. Bu yüzden “sığacak mı?” sorusunu ölçümle doğrulamak zorunludur.

## 3) Doğru model motoru: vLLM, TGI veya kendi çözümünüz

Inference için yaygın motorlar:

vLLM: Yüksek throughput ve verimli KV cache yönetimiyle sık tercih edilir.
TGI (Text Generation Inference): Hugging Face ekosisteminde yaygın, servis odaklı.
Kendi inference pipeline’ınız: Çok esnektir ama operasyon yükü artar.

vLLM/TGI seçiminde ölçüm kriterleri

Motor seçerken sadece “hız” değil, şunları test edin: - Token başına gecikme (TTFT: Time To First Token) - Ortalama token üretim hızı (tokens/sec) - Eşzamanlı istek altında stabilite - Context uzunluğu artınca performans düşüşü

Test senaryosu (minimum)

1 istek, 4K prompt
5–10 eşzamanlı istek, 4K prompt
1 istek, 8K–16K prompt

Bu üç senaryodan sonra “aynı GPU ile kaç kullanıcı taşırım?” sorusu netleşir.

## 4) Konteynerle çalıştırma: Docker ile temiz dağıtım

AI hosting’de konteyner yaklaşımı, sürümleme ve yeniden dağıtım için kritiktir. Model ağırlıkları (weights) ve servis ayarları ayrıştırılmalıdır.

Minimum konteyner bileşenleri

GPU driver uyumu: Host OS ile NVIDIA sürücü uyumlu olmalı.
Model dosyaları: Boot sırasında indirmeyin; kalıcı depodan çekin.
Environment/secret yönetimi: API anahtarları ve erişim bilgileri image’a gömülmemeli.

Pratik dosya ayrımı

configs/ → motor ayarları (context, max tokens, batch)
models/ → indirilen ağırlıklar
logs/ → uygulama logları

LLM servisinde sık yapılan hata

Modeli konteyner her restart olduğunda yeniden yüklemek. Bu hem soğuk başlatmayı (cold start) artırır hem de dağıtım pencerelerini uzatır.

## 5) Ölçekleme ve maliyet: concurrency planı, rate limit ve gerekirse otomatik ölçek

AI hosting’de maliyetin büyük kısmı GPU çalıştığı sürece akar. Bu yüzden “kullanıcı var oldukça GPU’yu büyütme” hedeflenir.

Ölçekleme stratejileri

Dikey ölçek (vertical): Daha güçlü GPU.
Yatay ölçek (horizontal): Aynı GPU ile birden fazla instance.
Akıllı trafik yönetimi: Kuyruklama (queue) ve rate limit.

Net kapasite planı

Şu yaklaşım somut sonuç verir:

Motorunuzu test ortamında 1 instance ile ölçün.
“Ortalama cevap süresi” ve “token/sec” değerini çıkarın.
Hedef kullanıcı profilini tanımlayın (ortalama prompt uzunluğu, cevap uzunluğu).
Eşzamanlı kullanıcıyı kuyrukla yönetin.

Örnek karar mantığı: - Prompt ortalama 2K token ve hedef yanıt 300–800 token ise concurrency daha yüksek olur. - Prompt 8K token ve hedef yanıt 1.5K token ise concurrency düşürülmelidir.

Rate limit ve istek şekillendirme

Üretim sisteminde zorunlu kontroller: - Token limit (max input/output) - IP/abonelik başına istek limiti - Yüksek gecikme durumunda degradasyon (ör. max output kısaltma)

Bu ayarlar, GPU’nun “anlık çöken” maliyet dalgalarını engeller.

## 6) Güvenlik, erişim ve veri sorumluluğu: üretim checklist’i

LLM servisleri genelde kullanıcı metni alır. Bu veri hassas olabilir. Ayrıca servis uçları (API endpoints) kötüye kullanılabilir.

API erişimi

Servisi sadece gerekli network’e açın (internet yerine VPN/özel ağ tercih edin).
Kimlik doğrulama zorunlu olsun (API key veya OAuth).
İstek doğrulama: boyut limiti (content length), token limit, format kontrol.

SSH ve sunucu erişimi

LLM servislerini barındıran VDS/VPS’te: - Şifreli giriş kapatın, SSH key ile giriş zorunlu kılın. - Kullanıcı bazında yetkiyi sınırlandırın. - Yönetim panelini (varsa) sadece belirli IP’lere açın.

Loglama ve gizlilik

Kullanıcı promptlarını loglarken maskeleme/anonimleştirme yapın.
Retention süresini belirleyin (ör. 7/30 gün).
Hata loglarında API anahtarlarını veya sistem promptlarını sakın yazmayın.

Yedekleme (backup) planı

AI hosting’de “yedeklenecek” şeyler: - Konfigürasyon dosyaları (motor ayarları) - Model sürümü metadata’sı (hangi quantization, hangi commit) - Uygulama kodu ve backend verisi (varsa)

Model ağırlıklarını her seferinde indirmek yerine, veri deposunda sürümleyin.

## 7) Test ve izleme: Sadece “çalışıyor” yetmez

Canlıya geçmeden önce şu ölçümleri alın. Bunlar, sonra “neden yavaşladı?” sorusunu hızlı çözer.

İzlenecek metrikler

TTFT (Time To First Token)
tokens/sec (üretim hızı)
GPU utilization (kullanım oranı)
VRAM kullanım piki (KV cache etkisi için)
Kuyruk uzunluğu / bekleme süresi
API 4xx/5xx oranları

SLO/SLA tarafı

AI servisleri için kullanıcı deneyimi gecikmeye bağlıdır. Uptime garantisi tek başına yetmez; p99 latency hedefi de tanımlanmalıdır. SLA (Service Level Agreement) metinlerinde uptime yüzdesini okurken şu yaklaşımı kullanın: - “Uptime” ölçümü hangi endpoint için? - “İşletim durumu” tanımı nedir? (ör. 200 dönen istek mi, process running mi) - Bakım pencereleri var mı ve bildirim süreleri nasıl?

Bu değerlendirme sayesinde “sunucu çalışıyordu ama kullanıcı yanıt alamıyordu” gibi uyuşmazlıklar azaltılır.

## 8) Kurulum için karar ağacı: pratik seçim adımları

Aşağıdaki listeyi takip edin; her adım sonunda bir sonraki karar netleşir.

Senaryo: Sadece sohbet mi? İçerik üretimi mi? Eylemli agent var mı?
Context uzunluğu: 4K mı 8K mı?
Kalite ihtiyacı: Quantization ile kalite kaybı kabul edilebilir mi?
GPU bütçesi: Hedef concurrency kaç kullanıcı?
Motor: vLLM mi TGI mi? (test sonuçlarına göre)
Erişim modeli: İnternet mi özel ağ mı? API key mi?
Güvenlik: SSH key, firewall, secret yönetimi.
İzleme: TTFT, tokens/sec, kuyruk, GPU/VRAM.
Maliyet kontrol: Rate limit + token limit + kuyruk.

Sonuç: En hızlı ilerleme için önce “kapasite testi” yapın

GPT/Llama modellerini host etmenin doğru yolu, önce mimariyi seçip sonra “VRAM + context + concurrency” üçlüsünü testle doğrulamaktır. İlk kurulumda en yaygın hedef, 4K context ile başlayıp motoru (tercihen vLLM/TGI) ölçerek gerçek tokens/sec ve gecikme değerlerini çıkarmaktır. Aksiyon önerim: Bir POC (Proof of Concept) kurun, 1 istek + eşzamanlı test + uzun context testiyle kapasiteyi bulun, ardından rate limit ve kuyruklama ile maliyeti sabitleyin. Sonra ölçeklemeyi dikey/yatay olarak planlayın; canlıya geçmeden önce erişim ve loglama checklist’ini tamamlayın.