30 Saniyelik Yönetici Özeti (TL;DR) — Mimari Karar Noktaları [Aç / Kapat]
- Donanım Maliyet Kontrolü: Kurumsal verileri buluta çıkarmadan çalıştırmak için yapılan yerel llm vram optimizasyonu, tekil 24 GB veya 48 GB GPU kartlarında 32B-70B sınıfı modellerin yüksek eşzamanlılıkla hizmet vermesini sağlar.
- Asıl Darboğaz Ağırlıklar Değil Bağlamdır: Üretim ortamlarında Out-Of-Memory (OOM) hatalarının %70’i model parametrelerinden değil, kontrolsüz büyüyen KV Cache (Key-Value önbelleği) tüketiminden kaynaklanır.
- Motor Seçimi: Düşük eşzamanlılıklı iç otomasyonlarda Ollama +
OLLAMA_KV_CACHE_TYPE=q8_0yeterliyken, 15+ eşzamanlı kullanıcılı kurumsal RAG sistemlerinde vLLM PagedAttention tabanlı yerel llm vram optimizasyonu zorunludur.
Kurumsal veri gizliliği (KVKK ve ISO 27001) gereksinimleri nedeniyle yapay zeka iş yüklerini kendi veri merkezine taşıyan organizasyonlar için yerel llm vram optimizasyonu, donanım yatırım maliyetlerini (CAPEX) doğrudan belirleyen en kritik mimari disiplindir. Kağıt üzerinde yalnızca 18 GB yer kaplayan kuantize edilmiş bir dil modeli, üretim ortamında 32.000 token bağlam penceresi (context window) ve 10 eşzamanlı kullanıcı isteği altında anında 48 GB sınırını aşarak sistemin çökmesine yol açabilir.
Bu teknik rehberde; AlmaLinux/Rocky Linux tabanlı kurumsal GPU sunucularında bellek ayak izini matematiksel olarak nasıl hesaplayacağımızı, yerel llm vram optimizasyonu kapsamında KV Cache sıkıştırma tekniklerini ve kurumsal veri mimarisi standartlarına uygun yüksek erişilebilirlikli çıkarım (inference) yapılandırmalarını inceliyoruz.
İçindekiler
1. Üretim Ortamında VRAM Tüketim Matematiği: Ağırlıklar vs. KV Cache
Bir GPU sunucusunun kapasite planlaması yapılırken yalnızca model dosyasının disk boyutuna bakmak en sık yapılan mimari hatadır. Etkili bir yerel llm vram optimizasyonu kurgulayabilmek için çıkarım anında VRAM’in dört ana bileşen arasında nasıl paylaşıldığını bilmek gerekir: Model Ağırlıkları (Weights), KV Cache, Aktivasyon Tamponları ve CUDA Context yükü (~0.8 GB – 1.5 GB).
Özellikle kurumsal RAG (Retrieval-Augmented Generation) mimarilerinde her sorguya 10-15 sayfalık doküman bağlamı eklendiğinde, KV Cache tüketimi model ağırlıklarının önüne geçer. Aşağıdaki formül, tek bir oturumun ihtiyaç duyduğu KV Cache miktarını net olarak ortaya koyar:
KV_Cache_Byte = 2 * Katman_Sayisi * KV_Head_Sayisi * Head_Boyutu * Context_Uzunlugu * Byte_Hassasiyeti # Örnek: Qwen2.5-32B (GQA Mimari: 64 Katman, 8 KV Head, 128 Head Dim) # 32.768 Token Context + FP16 (2 Byte) Hassasiyet: # 2 * 64 * 8 * 128 * 32768 * 2 = 8.58 GB (Tek bir eşzamanlı kullanıcı için!) # 8-Bit (q8_0) KV Cache Aktif Edildiğinde: 4.29 GB (%50 Net Tasarruf)
2. Kurumsal Yerel LLM Bellek ve İstek Yönetim Mimarisi
Geleneksel çıkarım motorları her kullanıcı oturumu için bitişik (contiguous) bellek blokları ayırdığından VRAM üzerinde %30’a varan parçalanma (fragmentation) oluşur. Modern yerel llm vram optimizasyonu mimarilerinde ise istekler sanal bellek sayfalarına bölünerek dinamik olarak yönetilir.
3. İleri Düzey Yerel LLM VRAM Optimizasyonu Stratejileri
Kaliteden ödün vermeden donanım verimliliğini maksimize etmek için dört katmanlı bir yerel llm vram optimizasyonu stratejisi uygulanmalıdır:
- Aktivasyon Duyarlı Ağırlık Kuantizasyonu (AWQ / Q4_K_M): FP16 yerine 4-bit ağırlık sıkıştırması kullanmak VRAM ihtiyacını %70 azaltır. Özellikle resmi vLLM dokümantasyonunda da vurgulandığı üzere, Donanım Tensor Çekirdekleri ile doğrudan hızlandırılan AWQ veya Marlin çekirdekleri gecikmeyi (TTFT – Time To First Token) minimumda tutar.
- KV Cache Quantization (FP8 / Q8_0): Bağlam penceresi önbelleğini FP16 yerine 8-bit formatında saklamak, uzun doküman analizlerinde bellek tüketimini yarıya indirir ve aynı GPU üzerinde eşzamanlı kullanıcı kapasitesini iki katına çıkarır.
- FlashAttention-2 Entegrasyonu: Dikkat (Attention) matrislerini HBM (High Bandwidth Memory) yerine doğrudan GPU’nun çok daha hızlı SRAM önbelleğinde hesaplayarak bellek karmaşıklığını karesel ($O(N^2)$) seviyeden doğrusal ($O(N)$) seviyeye düşürür.
- Automatic Prefix Caching (APC): Kurumsal sistemlerde her isteğin başında gönderilen 2.000 token’lık sabit sistem talimatlarını (System Prompt) ve şirket politikalarını her seferinde yeniden hesaplamak yerine VRAM’de sabitler.
4. Çıkarım Motoru Karşılaştırma Matrisi: Ollama vs. vLLM
Kurumsal altyapı tasarımında doğru çıkarım motorunu seçmek, yerel llm vram optimizasyonu başarısını doğrudan belirler. Aşağıdaki matris, 24 GB ve 48 GB VRAM sınıflarındaki üretim senaryolarına göre iki lider motoru kıyaslamaktadır:
| Mimari Kriter | Ollama (llama.cpp Tabanlı) | vLLM (PagedAttention Tabanlı) |
|---|---|---|
| KV Cache Sıkıştırma | OLLAMA_KV_CACHE_TYPE=q8_0 / q4_0 | --kv-cache-dtype fp8 (Ada/Hopper GPU) |
| Eşzamanlılık (Concurrency) | Düşük – Orta (1 – 8 Eşzamanlı Oturum) | Yüksek (20 – 100+ Eşzamanlı Oturum) |
| Bellek Parçalanma Kontrolü | Statik Slot Tahsisi (OLLAMA_NUM_PARALLEL) | Sanal Bellek Sayfalama (%4’ün Altı Kayıp) |
| Multi-GPU Ölçekleme | Layer Splitting (Sıralı Katman Bölme) | Tensor Parallelism (NVLink / PCIe Paralel) |
| İdeal Kullanım Senaryosu | İç Otomasyon, Tekil Geliştirici, Hızlı PoC | Kurumsal RAG, Çağrı Merkezi, ERP AI Asistanı |
5. Yerel LLM VRAM Optimizasyonu İçin Üretim Sunucusu Yapılandırması
AlmaLinux 9.x üzerinde çalışan bir AI çıkarım sunucusunda, hem işletim sistemi çekirdeğinin hem de servis katmanının bellek sızıntılarına karşı kilitlenmesi gerekir. İlk olarak NVIDIA Persistence Mode’u aktif hale getirerek GPU sürücüsünün her istekte yeniden başlatılmasını önleyin ve yerel llm vram optimizasyonu değişkenlerini servis dosyasına tanımlayın:
# 1. GPU Persistence Mode ve Bellek Parçalanma Önlemi nvidia-smi -pm 1 # 2. Ollama Üretim Ortamı VRAM Optimizasyon Parametreleri [Service] Environment="OLLAMA_FLASH_ATTENTION=1" Environment="OLLAMA_KV_CACHE_TYPE=q8_0" Environment="OLLAMA_MAX_LOADED_MODELS=1" Environment="OLLAMA_NUM_PARALLEL=4" Environment="OLLAMA_KEEP_ALIVE=24h" Environment="PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True" # Servisi yeniden yükle ve doğrula systemctl daemon-reload && systemctl restart ollama nvidia-smi --query-gpu=memory.used,memory.free,utilization.gpu --format=csv
Eğer yüksek eşzamanlılıklı bir kurumsal portal için vLLM kullanıyorsanız, VRAM kullanım oranını 0.92 seviyesinde sabitleyerek işletim sistemi tamponlarına güvenli alan bırakın:
python3 -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-32B-Instruct-AWQ \ --quantization awq_marlin \ --kv-cache-dtype fp8 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768 \ --enable-prefix-caching \ --enforce-eager \ --port 8000
6. Sıkça Sorulan Sorular (Teknik SSS)
32B parametreli bir model üretim ortamında kaç GB VRAM tüketir?
FP16 hassasiyetinde 32B model yalnızca ağırlıklar için yaklaşık 64 GB VRAM gerektirir. Ancak doğru yerel llm vram optimizasyonu adımları (Q4_K_M veya AWQ 4-bit quantization ve 8-bit KV Cache) uygulandığında bu tüketim 20-22 GB bandına düşürülerek tek bir 24 GB RTX 4090 veya NVIDIA L4 kartında yüksek verimlilikle çalıştırılabilir.
KV Cache quantization modelin yanıt kalitesini düşürür mü?
q8_0 veya fp8 formatında uygulanan KV Cache sıkıştırması, yerel llm vram optimizasyonu süreçlerinde 32K ve üzeri bağlam pencerelerinde bellek tüketimini yarı yarıya azaltırken perpleksite (perplexity) değerinde %0.5’in altında ihmal edilebilir bir sapma yaratır. Ancak q4_0 seviyesi çok uzun kod üretimlerinde hassasiyet kaybına yol açabileceğinden üretimde 8-bit önerilir.
Kurumsal çok kullanıcılı senaryolarda Ollama mı yoksa vLLM mi tercih edilmelidir?
Tekil veya düşük eşzamanlılıklı (1-8 kullanıcı) iç otomasyonlarda Ollama hızlı kurulum ve düşük bakım maliyeti avantajı sunar. Ancak 15 ve üzeri eşzamanlı kullanıcının bulunduğu kurumsal RAG sistemlerinde PagedAttention ve Continuous Batching mimarisi nedeniyle vLLM 3 ila 5 kat daha yüksek throughput sağlar.
Linux sunucularda GPU bellek parçalanması (OOM) nasıl önlenir?
PyTorch ve CUDA tabanlı çıkarım motorlarında PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True ortam değişkenini tanımlamak, NVIDIA Persistence Mode’u aktif etmek ve maksimum bağlam uzunluğunu (max-model-len) donanım kapasitesine göre sınırlandırmak Out-Of-Memory (OOM) hatalarını kesin olarak önler.
