vLLM Nedir? LLM Serving Rehberi

vLLM, büyük dil modellerini (LLM) çalıştırmak ve uygulamalara API üzerinden sunmak için kullanılan açık kaynaklı bir inference ve model serving yazılımıdır. Bir modeli GPU üzerinde çalıştırmak ile aynı modeli gerçek bir uygulamanın arkasında birden fazla kullanıcıya sunmak ise birbirinden farklı iki problemdir.

Tek kullanıcıyla yapılan basit bir model testinde performans ve kaynak yönetimi çok fazla önemsenmeyebilir. Ancak iş production ortamına geldiğinde GPU belleği, KV cache, context uzunluğu, eşzamanlı istekler, ilk token gecikmesi, throughput, model yükleme süresi, API güvenliği ve ölçekleme gibi konular doğrudan altyapının parçası haline gelir.

vLLM bu noktada devreye girer. Bu rehberde vLLM’nin ne olduğunu açıklamanın yanında Linux üzerinde kurulumdan başlayarak model çalıştırma, OpenAI uyumlu API kullanımı, Docker, GPU belleği, Kubernetes, monitoring, benchmark ve production ortamında karşılaşılan sorunları ele alacağız.

Önemli: vLLM bir yapay zekâ modeli değildir. Qwen, Llama veya benzeri modelleri çalıştıran ve bunları uygulamaların kullanabileceği bir servis haline getiren serving katmanıdır.

vLLM Nedir?

vLLM, büyük dil modellerinin inference ve serving süreçlerini yönetmek için geliştirilmiş açık kaynaklı bir yazılımdır.

Örneğin bir Qwen veya Llama modeli model ağırlıklarını ve model mimarisini sağlar. vLLM ise bu modeli çalıştırarak uygulamaların HTTP üzerinden istek gönderebileceği bir servis oluşturur.

Uygulama
   |
   | HTTP / API
   v
vLLM Server
   |
   v
LLM Model
   |
   v
GPU

Bu ayrım özellikle kurumsal yapılarda önemlidir. Bir modelin geliştirici bilgisayarında çalışması ile aynı modelin bir şirket uygulamasına sürekli olarak hizmet vermesi aynı altyapı gereksinimlerine sahip değildir.

vLLM’nin temel odağı, modeli eğitmekten ziyade eğitilmiş modelleri verimli şekilde servis etmektir. LLM mimarileri, Transformer yapısı, attention mekanizması ve model çalışma prensipleri hakkında daha kapsamlı bilgi için Kurumsal Large Language Models (LLM) Eğitimleri sayfamızı da inceleyebilirsiniz.

Daha ayrıntılı teknik bilgi için vLLM resmi dokümantasyonuna bakabilirsiniz.

LLM Inference Nedir?

Inference, eğitilmiş bir modelin kendisine verilen girdiyi işleyerek çıktı üretmesidir.

vLLM’nin ana kullanım alanı training değil, inference ve model serving tarafıdır.

Bir Modeli Çalıştırmak ile Servis Etmek Arasındaki Fark

Tek kullanıcılı bir testte modelin çalışması genellikle yeterlidir:

Kullanıcı
   |
   v
Model
   |
   v
Cevap

Bir production sisteminde ise aynı modele aynı anda çok sayıda istek gelebilir:

                    Kullanıcılar
                         |
                         v
                    Uygulamalar
                         |
                         v
                    API Gateway
                         |
              +----------+----------+
              |                     |
          vLLM Server           vLLM Server
              |                     |
             GPU                   GPU
              \                     /
               \___________________/
                         |
                       Model

Bu noktada modelin cevap verebilmesi tek başına yeterli değildir.

Kaç isteğin aynı anda işlenebildiği, request’lerin ne kadar beklediği, GPU belleğinin ne kadar dolduğu, ilk token’ın ne kadar sürede geldiği ve yük arttığında sistemin nasıl davrandığı da önemlidir.

vLLM Nasıl Çalışır?

KV Cache Nedir?

Transformer tabanlı LLM’lerde inference sırasında önceki tokenlara ait attention bilgileri KV cache içerisinde tutulabilir. Böylece yeni token üretilirken geçmişte yapılan hesaplamaların tamamının tekrar yapılması gerekmez.

Ancak KV cache GPU belleği kullanır. Bu nedenle modelin disk üzerindeki boyutu ile model çalışırken ihtiyaç duyduğu toplam VRAM miktarı aynı değildir.

Özellikle context uzunluğu ve eşzamanlı request sayısı arttıkça KV cache ihtiyacı da büyüyebilir.

GPU Belleği
├── Model ağırlıkları
├── KV Cache
├── Runtime / çalışma alanı
└── Diğer GPU kullanımları

PagedAttention Nedir?

vLLM’nin en çok bilinen tekniklerinden biri PagedAttention’dır. Temel fikir, KV cache’in daha küçük bloklar halinde yönetilmesi ve GPU belleğinin daha esnek kullanılabilmesidir.

Bu nedenle LLM serving performansını değerlendirirken yalnızca GPU’nun ham hesaplama kapasitesine bakmak yeterli değildir. Belleğin nasıl kullanıldığı ve aynı anda gelen request’lerin nasıl planlandığı da önemlidir.

Continuous Batching Nedir?

LLM request’lerinin giriş ve çıkış uzunlukları birbirinden farklı olabilir. Klasik sabit batch yaklaşımı bu nedenle her workload için ideal değildir.

Continuous batching yaklaşımında çalışan request’lerin sisteme giriş ve çıkışları daha dinamik şekilde planlanabilir. Aynı modelin çok sayıda kullanıcı tarafından aynı anda kullanıldığı serving senaryolarında bu yaklaşım önem kazanır.

Prefix Caching Nedir?

Kurumsal yapay zekâ uygulamalarında aynı sistem prompt’u veya ortak context çok sayıda request’te tekrar edebilir.

Örneğin bütün isteklerin benzer bir sistem prompt’u ile başladığını düşünelim:

Sen şirket içi dokümantasyon asistanısın.
Yalnızca yetkili kurumsal verileri kullan.

Prefix caching, daha önce işlenmiş prefix’e ait cache bilgilerinin yeniden kullanılabildiği senaryolarda gereksiz hesaplamayı azaltabilir.

Bu nedenle uzun ve tekrarlayan prompt’ların kullanıldığı RAG veya agent tabanlı workload’larda ayrıca değerlendirilebilir.

Daha fazla bilgi için vLLM Prefix Caching dokümantasyonuna bakabilirsiniz.

vLLM İçin Donanım Nasıl Seçilir?

LLM serving için GPU seçerken yalnızca modelin parametre sayısına veya ağırlıklarının kapladığı alana bakmak yeterli değildir.

Modelin veri tipi, quantization yöntemi, context uzunluğu, eşzamanlı kullanıcı sayısı ve hedeflenen performans GPU ihtiyacını doğrudan etkiler.

Örneğin tek kullanıcıyla çalışan bir model için yeterli olan GPU, aynı modele 32 eşzamanlı request geldiğinde yeterli cache alanı sunmayabilir.

Bu nedenle kapasite planlamasında şu değerler birlikte değerlendirilmelidir:

• Model boyutu ve veri tipi
• Quantization
• Context uzunluğu
• KV cache ihtiyacı
• Concurrency
• Hedef throughput
• Hedef latency

Donanım satın almadan önce gerçek model ve gerçek workload ile benchmark yapmak, yalnızca teorik VRAM hesabından daha sağlıklı sonuç verir.

Gerçek GPU donanımı üzerinde LLM inference, GPU izleme ve performans analizi konularını incelemek için NVIDIA Blackwell Yapay Zekâ ve LLM Eğitimi sayfamızı da inceleyebilirsiniz.

Linux Üzerinde vLLM Kurulumu

vLLM kurulmadan önce GPU altyapısının çalıştığından emin olmak gerekir.

NVIDIA sistemlerde ilk kontrol:

nvidia-smi

Bu komut GPU’nun işletim sistemi tarafından görüldüğünü ve NVIDIA sürücüsünün çalıştığını kontrol etmek için kullanılabilir.

Ardından izole bir Python ortamı oluşturulabilir. Örneğin uv ile:

uv venv --python 3.12 --seed
source .venv/bin/activate

vLLM kurulumu:

uv pip install vllm --torch-backend=auto

Kurulum sonrasında:

vllm --help

ile komut satırı arayüzü kontrol edilebilir.

Burada önemli bir ayrıntı var: vLLM’nin kurulmuş olması GPU altyapısının doğru olduğu anlamına gelmez. NVIDIA driver, CUDA/backend, PyTorch, GPU erişimi ve vLLM sürümü birlikte değerlendirilmelidir.

Linux sistem yönetimi, komut satırı, süreç yönetimi, SSH, kaynak izleme ve sistem bakımı hakkında daha kapsamlı bilgi için Kurumsal Linux Eğitimleri sayfamızı inceleyebilirsiniz.

Güncel kurulum seçenekleri için vLLM Installation dokümantasyonuna bakılmalıdır.

İlk Modeli vLLM ile Çalıştırmak

İlk denemede büyük bir production modeliyle başlamak yerine serving zincirini küçük bir modelle doğrulamak daha pratik olabilir.

vllm serve Qwen/Qwen3-0.6B

Sunucu hazır olduktan sonra:

curl http://localhost:8000/health

ile sağlık durumu kontrol edilebilir.

Servis edilen modelleri görmek için:

curl http://localhost:8000/v1/models

İlk testte amaç benchmark yapmak değildir. Önce şu zincirin çalıştığını doğrulamak gerekir:

GPU
 ↓
vLLM
 ↓
Model
 ↓
HTTP Server
 ↓
API Response

Bu aşama sorunun hangi katmanda olduğunu anlamayı da kolaylaştırır.

İlk kurulum ve model çalıştırma adımları için vLLM Quickstart da incelenebilir.

OpenAI Uyumlu API ile vLLM Kullanmak

vLLM’nin önemli özelliklerinden biri OpenAI uyumlu API sunabilmesidir.

Örneğin server bir API key ile başlatılabilir:

vllm serve Qwen/Qwen3-0.6B \
  --api-key token-abc123

Ardından OpenAI Python client kullanılarak:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="token-abc123",
)

response = client.chat.completions.create(
    model="Qwen/Qwen3-0.6B",
    messages=[
        {
            "role": "user",
            "content": "vLLM nedir?"
        }
    ],
)

print(response.choices[0].message.content)

şeklinde istek gönderilebilir.

Bu yapının önemli avantajı, uygulama ile model serving katmanının birbirinden ayrılmasıdır.

Uygulama
   |
OpenAI-compatible API
   |
 vLLM
   |
  LLM

Uygulama tarafı aynı API yaklaşımını korurken model serving katmanı bağımsız olarak değiştirilebilir.

Güvenlik notu: --api-key önemli bir erişim kontrolü sağlar ancak vLLM üzerindeki bütün endpoint’leri koruyan tek başına eksiksiz bir güvenlik katmanı değildir. Public erişim gereken sistemlerde reverse proxy, ingress, network policy ve uygun authentication/authorization mekanizmaları ayrıca değerlendirilmelidir.

Daha fazla bilgi için vLLM OpenAI-Compatible Server dokümantasyonuna bakabilirsiniz.

Docker ile vLLM Çalıştırmak

Container kullanımı, vLLM deployment’ını farklı sunucularda daha tekrarlanabilir hale getirebilir. vLLM resmi Docker image’ları sağlamaktadır.

NVIDIA GPU için temel örnek:

docker run --runtime nvidia --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  --ipc=host \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen3-0.6B

Buradaki birkaç parametre özellikle önemlidir:

Production ortamında latest tag’ini kontrolsüz şekilde takip etmek yerine belirli bir vLLM sürümünü sabitlemek ve yükseltmeleri kontrollü yapmak daha sağlıklıdır.

Container image, Docker network, storage, image optimizasyonu ve container güvenliği gibi konular için Kurumsal Docker Eğitimleri sayfamızı da inceleyebilirsiniz.

Daha ayrıntılı deployment seçenekleri için vLLM Docker Deployment dokümantasyonuna bakabilirsiniz.

NVIDIA Container Toolkit Neden Gereklidir?

Host üzerinde NVIDIA sürücülerinin kurulu olması, Docker container’ının GPU’yu otomatik olarak göreceği anlamına gelmez.

NVIDIA Container Toolkit, container runtime’ın NVIDIA GPU kaynaklarını container’a aktarabilmesi için kullanılan temel bileşenlerden biridir.

Docker runtime yapılandırması için NVIDIA’nın önerdiği komutlardan biri:

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Ardından host tarafında:

nvidia-smi

ve Docker’ın GPU erişimi ayrı ayrı kontrol edilmelidir.

Host’ta GPU görünürken container’da görünmüyorsa doğrudan vLLM’yi değiştirmek yerine önce bu katmanı kontrol etmek çoğu zaman daha doğru teşhistir.

NVIDIA Container Toolkit Kurulum Rehberi

GPU Belleği ve gpu-memory-utilization

LLM serving sırasında GPU belleğini yalnızca model ağırlıklarından ibaret düşünmek doğru değildir.

GPU Belleği
├── Model ağırlıkları
├── KV Cache
├── Runtime / çalışma alanı
└── Diğer GPU kullanımları

vLLM’deki önemli seçeneklerden biri:

--gpu-memory-utilization

Güncel vLLM dokümantasyonunda bu parametrenin varsayılan değeri 0.92‘dir. Değer, vLLM instance’ının GPU belleğinin ne kadarını kullanabileceğini sınırlar ve otomatik KV cache kapasitesi hesaplamasında rol oynar.

Örneğin:

vllm serve Qwen/Qwen3-0.6B \
  --gpu-memory-utilization 0.85

kullanılabilir.

Ancak OOM gördüğünüzde doğrudan “0.80 yap” yaklaşımı doğru değildir. Değerin düşürülmesi vLLM’nin kullanabileceği belleği ve bazı workload’larda KV cache kapasitesini de azaltabilir.

Önce:

• GPU’da başka process çalışıyor mu?
• Model GPU için fazla büyük mü?
• Context uzunluğu gereğinden yüksek mi?
• Concurrency çok mu yüksek?
• Quantization kullanılabilir mi?
• KV cache için yeterli alan var mı?

sorularına bakmak gerekir.

Daha hassas bellek kontrolünün gerektiği durumlarda güncel vLLM sürümlerindeki --kv-cache-memory-bytes seçeneği de değerlendirilebilir.

vLLM Serve Configuration

max-model-len Nedir?

--max-model-len, modelin servis edeceği context uzunluğunu sınırlar.

Örneğin uygulamanın gerçek ihtiyacı 8192 token civarındaysa:

vllm serve Qwen/Qwen3-0.6B \
  --max-model-len 8192

kullanılabilir.

Daha yüksek context kapasitesi her zaman daha iyi değildir. Uzun context, özellikle yüksek concurrency ile birlikte KV cache kullanımını artırabilir.

Burada amaç mümkün olan en büyük değeri seçmek değil, uygulamanın gerçekten ihtiyaç duyduğu değeri belirlemektir.

Generation Configuration Neden Önemli?

Bir modelin beklenmedik şekilde farklı sampling davranışı göstermesinin nedenlerinden biri model repository’sindeki generation_config.json dosyası olabilir.

Güncel vLLM’de default davranış auto olduğunda model yolundaki generation configuration kullanılabilir.

Gerekirse vLLM’nin kendi default değerlerinin kullanılmasını sağlamak için:

vllm serve Qwen/Qwen3-0.6B \
  --generation-config vllm

kullanılabilir.

Production ortamında model repository’sindeki generation ayarlarının uygulamanın beklediği davranışla uyumlu olup olmadığını kontrol etmek, “neden aynı prompt farklı sonuç veriyor?” türündeki sorunlarda faydalı olabilir.

vLLM Configuration

Kubernetes Üzerinde vLLM

Tek bir GPU sunucusundan daha büyük yapılarda Kubernetes, vLLM servislerinin dağıtılması ve yönetilmesi için kullanılabilir.

                     Kubernetes
                          |
                   Service / Ingress
                          |
              +-----------+-----------+
              |                       |
          vLLM Pod                vLLM Pod
            GPU                     GPU
              |                       |
              +-----------+-----------+
                          |
                     Model Cache
                          |
                      Monitoring

Kubernetes üzerinde vLLM çalıştırırken container’ın pod içerisine alınması yalnızca başlangıçtır. GPU kaynaklarının scheduler tarafından görünmesi, model cache’inin nerede tutulacağı, health check’leri ve servis erişimi ayrıca planlanmalıdır.

Kubernetes cluster, Pod, Deployment, Service, kaynak limitleri, volume, monitoring, scaling ve RBAC gibi konuları daha kapsamlı incelemek için Kurumsal Kubernetes Eğitimleri sayfamıza bakabilirsiniz.

Kubernetes’te GPU Kaynağı

NVIDIA GPU kullanan bir pod için örneğin:

resources:
  requests:
    nvidia.com/gpu: "1"
  limits:
    nvidia.com/gpu: "1"

tanımlanabilir.

Bu tanım pod’un GPU istediğini belirtir. Cluster tarafında GPU’nun scheduler’a sunulması için uygun NVIDIA GPU entegrasyonunun da kurulmuş olması gerekir.

GPU kaynaklarının node’larda nasıl göründüğünü:

kubectl describe nodes

ile inceleyebilirsiniz.

Model Cache için Persistent Volume

Model dosyalarının pod restart’larında tekrar indirilmesi hem zaman hem de ağ kullanımı açısından gereksiz olabilir.

Bu nedenle Hugging Face cache için PersistentVolumeClaim kullanılabilir:

volumeMounts:
  - name: model-cache
    mountPath: /root/.cache/huggingface

Volume tanımı:

volumes:
  - name: model-cache
    persistentVolumeClaim:
      claimName: vllm-models

şeklinde yapılabilir.

Ancak PVC kullanmak tek başına yüksek erişilebilirlik sağlamaz. Storage’ın erişim modeli, pod’ların hangi node’larda çalışacağı ve model dosyalarının nasıl dağıtılacağı ayrıca düşünülmelidir.

Basit Kubernetes Deployment Örneği

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          command:
            - vllm
            - serve
          args:
            - --model
            - Qwen/Qwen3-0.6B
            - --max-model-len
            - "8192"
          ports:
            - containerPort: 8000
          resources:
            requests:
              cpu: "2"
              memory: "6Gi"
              nvidia.com/gpu: "1"
            limits:
              cpu: "10"
              memory: "20Gi"
              nvidia.com/gpu: "1"
          volumeMounts:
            - name: model-cache
              mountPath: /root/.cache/huggingface
            - name: shm
              mountPath: /dev/shm
          readinessProbe:
            httpGet:
              path: /health
              port: 8000
            initialDelaySeconds: 60
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health
              port: 8000
            initialDelaySeconds: 120
            periodSeconds: 10
      volumes:
        - name: model-cache
          persistentVolumeClaim:
            claimName: vllm-models
        - name: shm
          emptyDir:
            medium: Memory
            sizeLimit: 2Gi

Bu manifest bir production ortamına doğrudan kopyalanıp uygulanması gereken hazır mimari olarak düşünülmemelidir. Model boyutu, GPU kapasitesi, storage tipi, probe süreleri, authentication, Service, ingress, security context ve scheduling ayarları gerçek ortama göre değiştirilmelidir.

vLLM’nin güncel Kubernetes örneklerinde GPU kaynakları, model cache volume’u ve /health üzerinden liveness/readiness probe’ları kullanılmaktadır.

vLLM Kubernetes Deployment

Kubernetes’te Readiness Probe Neden Önemlidir?

LLM modellerinin startup süresi klasik web servislerinden daha uzun olabilir. Container başlamış olsa bile model henüz GPU’ya yüklenmemiş olabilir.

Pod başladı
    ↓
Container başladı
    ↓
Model yükleniyor
    ↓
vLLM hazır
    ↓
Traffic kabul ediliyor

Readiness probe’un amacı, model gerçekten hazır hale gelmeden pod’a traffic gönderilmesini önlemektir.

Probe değerleri gereğinden agresif ayarlanırsa Kubernetes model hazır olmadan container’ı yeniden başlatabilir.

Kontrol için:

kubectl describe pod <pod-adı>
kubectl logs <pod-adı>
kubectl get events

Modelin gerçek startup süresini ölçmeden probe değerlerini rastgele yükseltmek yerine, önce loglar ve pod event’leri üzerinden problemin kaynağı belirlenmelidir.

vLLM Monitoring ve Prometheus

Production ortamında model server’ın ayakta olması tek başına yeterli değildir. Request’lerin nasıl davrandığını ve kaynakların nasıl kullanıldığını görebilmek gerekir.

vLLM Prometheus uyumlu metric endpoint’i sunar:

curl http://localhost:8000/metrics

Örneğin aşağıdaki metrikler özellikle yararlı olabilir:

Bu metrikler Prometheus tarafından toplanarak Grafana gibi araçlarda görselleştirilebilir.

Daha fazla bilgi için vLLM Metrics dokümantasyonuna bakabilirsiniz.

TTFT Nedir?

TTFT (Time To First Token), request gönderildikten sonra ilk token’ın üretilmesine kadar geçen süredir.

Toplam response süresi tek başına kullanıcı deneyimini anlatmaz.

B sistemi toplam cevap süresinde daha hızlı olmasına rağmen kullanıcı tarafından daha yavaş hissedilebilir. Bunun nedeni ilk çıktıyı dört saniye boyunca görememesidir.

Bu nedenle production LLM sistemlerinde TTFT’nin yanında inter-token latency, toplam request latency, queue time ve throughput da birlikte değerlendirilmelidir.

vLLM Performansı Nasıl Benchmark Edilir?

“GPU saniyede 100 token üretiyor” tek başına anlamlı bir benchmark sonucu değildir.

Gerçek performans; model, GPU, input uzunluğu, output uzunluğu, concurrency, context uzunluğu ve workload dağılımına göre değişir.

Örneğin aynı model için aşağıdaki testler yapılabilir:

Güncel vLLM sürümlerinde serving benchmark’ları için vllm bench serve kullanılabilir.

Örneğin:

vllm bench serve \
  --model Qwen/Qwen3-0.6B \
  --dataset-name hf \
  --dataset-path philschmid/mt-bench \
  --num-prompts 80

Bu komut örnek bir benchmark senaryosudur. Gerçek kapasite testi için kurumun gerçek prompt uzunluklarını, output uzunluklarını ve concurrency dağılımını temsil eden bir workload kullanmak daha değerlidir.

Daha fazla bilgi için vLLM Benchmark CLI dokümantasyonuna bakabilirsiniz.

p95 ve p99 Latency Neden Önemlidir?

Ortalama latency bütün kullanıcıların deneyimini göstermez.

Örneğin 100 request’in ortalama latency’si bir saniye olabilir. Ancak küçük bir kullanıcı grubunun çok daha uzun süre beklemesi mümkündür.

Bu nedenle production sistemlerinde:

Average latency
p95 latency
p99 latency

birlikte değerlendirilmelidir.

Özellikle concurrency yükseldikçe throughput artarken p95 ve p99 latency değerlerinin kötüleşmesi mümkündür. Bu nedenle en yüksek throughput değerini elde etmek her zaman en iyi production konfigürasyonu anlamına gelmez.

vLLM mi, Ollama mı?

İki teknoloji de LLM çalıştırmak için kullanılabilir ancak odak noktaları farklıdır.

Bir geliştiricinin laptop’ında model çalıştırması ile aynı modeli onlarca uygulamaya servis etmek farklı gereksinimler doğurur. vLLM özellikle ikinci probleme odaklanır.

vLLM mi, SGLang mi, TensorRT-LLM mi?

Production LLM serving tarafında vLLM dışında SGLang ve TensorRT-LLM gibi alternatifler de değerlendirilebilir.

Burada tek bir motorun bütün modellerde ve bütün workload’larda en hızlı olduğunu varsaymak doğru değildir. Gerçek seçim; model, GPU, concurrency, context uzunluğu ve hedeflenen latency/throughput değerleriyle yapılan benchmark sonucunda verilmelidir.

SGLang ve NVIDIA TensorRT-LLM projelerinin güncel dokümantasyonları alternatif serving yaklaşımlarını karşılaştırmak için incelenebilir.

Production Ortamında vLLM Güvenliği

Bir vLLM API’sini public IP üzerinde açıp API key eklemek tek başına production güvenliği için yeterli değildir.

Kurumsal bir deployment için temel mimari örneği:

Internet / Kurum Ağı
        |
     Firewall
        |
Reverse Proxy / Ingress
        |
Authentication / Authorization
        |
      vLLM
        |
       GPU

Burada:

• TLS
• Authentication
• Authorization
• Network erişim kontrolleri
• Secret yönetimi
• Container güvenliği
• Audit ve loglama

gibi katmanlar birlikte değerlendirilmelidir.

vLLM’nin güncel dokümantasyonunda --api-key kullanımının bütün endpoint’leri korumadığı özellikle belirtilmektedir.

Production altyapısında CI/CD, Kubernetes, GitOps, observability, DevSecOps ve operasyon süreçlerini birlikte değerlendirmek için Kurumsal DevOps Danışmanlığı sayfamızı da inceleyebilirsiniz.

Daha ayrıntılı güvenlik bilgileri için vLLM Security dokümantasyonuna bakabilirsiniz.

On-Premise LLM Altyapısında vLLM

On-premise yapay zekâ sistemlerinde vLLM, model serving katmanı olarak konumlandırılabilir.

Kurumsal Uygulamalar
        |
   API Gateway
        |
     RAG / AI
        |
     vLLM API
        |
       LLM
        |
       GPU
        |
Monitoring / Logging

Buradaki amaç yalnızca modeli şirket içindeki bir sunucuya kurmak değildir. Model, veri, API erişimi, storage, network, monitoring ve operasyon süreçlerinin kurumun mevcut altyapısıyla birlikte yönetilebilmesi önemlidir.

Bu nedenle:

“Modeli kendi sunucuma kurdum.”

ile:

“Kurumsal on-premise LLM altyapısı kurdum.”

aynı şey değildir.

On-premise yapay zekâ sistemlerinde veri kontrolü, GPU kapasitesi, RAG, erişim kontrolü, monitoring ve güvenlik gibi konuları daha geniş bir çerçevede incelemek için On-Premise Yapay Zekâ: Kurum İçi LLM Rehberi içeriğimize de bakabilirsiniz.

vLLM ile RAG Kullanılır mı?

Evet. Ancak vLLM ile RAG aynı şey değildir.

RAG, kullanıcı sorgusuyla ilişkili bilgi veya belgelerin bulunarak LLM’e context olarak verilmesini sağlayan uygulama mimarisidir. vLLM ise bu LLM’nin serving katmanı olabilir.

Kullanıcı Sorusu
       |
       v
Retriever / Search
       |
       v
Kurumsal Belgeler
       |
       v
Prompt + Context
       |
       v
vLLM
       |
       v
LLM Cevabı

Embedding, vector database, document chunking, metadata filtering ve retrieval kalitesi RAG’in ayrı bileşenleridir.

Bu nedenle RAG sisteminde yaşanan retrieval sorunları yalnızca inference engine’i değiştirerek çözülmez.

vLLM Sorun Giderme

CUDA Out of Memory

Önce:

nvidia-smi

ile GPU belleğinde başka process’ler olup olmadığını kontrol edin.

Ardından model boyutu, context uzunluğu, concurrency ve KV cache ihtiyacını değerlendirin.

gpu-memory-utilization azaltılabilir fakat bu ayarın mevcut cache kapasitesini de etkileyebileceği unutulmamalıdır.

Docker GPU’yu Göremiyor

Host üzerinde:

nvidia-smi

çalışıyor fakat container GPU’yu göremiyorsa öncelikle NVIDIA Container Toolkit ve Docker runtime yapılandırmasını kontrol edin.

vLLM’den önce aşağıdaki zincirin çalışması gerekir:

GPU
 ↓
NVIDIA Driver
 ↓
NVIDIA Container Toolkit
 ↓
Docker GPU Access
 ↓
CUDA / PyTorch
 ↓
vLLM

Kubernetes Pod Sürekli Restart Oluyor

Özellikle büyük modellerde model startup süresi uzun olabilir.

Şunları kontrol edin:

kubectl describe pod <pod-adı>
kubectl logs <pod-adı>
kubectl get events

Readiness veya startup probe çok erken failure veriyorsa Kubernetes model hazır olmadan container’ı öldürüyor olabilir.

İlk Token Çok Geç Geliyor

Toplam response süresine bakmak yerine TTFT’yi ayrıca ölçün.

Model startup süresi ile normal request latency’yi birbirinden ayırın.

Uzun prompt’lar, yüksek concurrency ve yetersiz cache kapasitesi ilk token gecikmesini etkileyebilir.

Concurrency Arttıkça Sistem Yavaşlıyor

GPU utilization yüzdesi tek başına yeterli değildir.

KV cache, request queue, context uzunluğu, TTFT ve p95/p99 latency birlikte incelenmelidir.

Model Beklenmedik Davranıyor

Model architecture, tokenizer, quantization, generation configuration ve kullanılan backend’in destek durumunu kontrol edin.

Hugging Face üzerinde bulunan her modelin bütün özelliklerinin her vLLM ve GPU kombinasyonunda aynı şekilde çalışacağı varsayılmamalıdır.

vLLM Supported Models

Production Öncesi Kontrol Listesi

vLLM Öğrenmeye Nereden Başlanmalı?

vLLM öğrenirken komutları ezberlemekten ziyade model serving zincirini anlamak daha faydalıdır.

1. LLM inference temellerini öğrenin.
2. GPU ve VRAM kapasitesini anlayın.
3. KV cache ve context uzunluğunu öğrenin.
4. Linux üzerinde vLLM çalıştırın.
5. OpenAI uyumlu API’yi test edin.
6. Docker ile deployment yapın.
7. Kubernetes üzerinde GPU workload’u çalıştırın.
8. Prometheus ile metric toplayın.
9. Gerçek workload ile benchmark yapın.
10. Production security ve operasyon süreçlerini planlayın.

Böylece yalnızca “vLLM nasıl çalıştırılır?” sorusunun değil, “LLM servisi production ortamında nasıl işletilir?” sorusunun da cevabını öğrenmiş olursunuz.

vLLM ile İlgili Sık Sorulan Sorular

vLLM nedir?

vLLM, büyük dil modellerinin inference ve serving işlemleri için kullanılan açık kaynaklı bir model serving yazılımıdır.

vLLM bir LLM midir?

Hayır. vLLM bir model değildir. Qwen, Llama ve benzeri modelleri çalıştıran ve bunları API üzerinden servis eden altyapı katmanıdır.

vLLM Docker ile çalışır mı?

Evet. vLLM’nin resmi Docker image’ları bulunmaktadır ve GPU destekli container ortamlarında çalıştırılabilir.

vLLM Kubernetes üzerinde çalışır mı?

Evet. Kubernetes üzerinde GPU resource tanımları, model cache’i, Service ve health probe’ları ile deployment yapılabilir.

vLLM ile OpenAI API kullanılabilir mi?

Evet. vLLM OpenAI uyumlu API endpoint’leri sunabilir. Bu da mevcut uygulamaların vLLM tabanlı model servislerine bağlanmasını kolaylaştırır.

vLLM ile RAG yapılabilir mi?

vLLM doğrudan bir RAG platformu değildir. Ancak RAG uygulamasının arkasındaki LLM serving katmanı olarak kullanılabilir.

vLLM için kaç GB VRAM gerekir?

Tek bir sabit değer yoktur. Model boyutu, veri tipi, quantization, context uzunluğu, KV cache ve concurrency gibi faktörlere göre değişir.

vLLM production ortamında kullanılabilir mi?

Evet. Ancak production deployment’ta GPU kapasitesi, KV cache, concurrency, API güvenliği, monitoring, storage, Kubernetes ve benchmark süreçleri birlikte değerlendirilmelidir.

vLLM ile Ollama arasındaki fark nedir?

Ollama daha çok kolay yerel model çalıştırma deneyimine odaklanırken vLLM özellikle yüksek performanslı inference ve model serving senaryolarına odaklanır.

vLLM, SGLang ve TensorRT-LLM arasındaki fark nedir?

Üçü de LLM serving için kullanılabilir ancak farklı optimizasyonlara ve ekosistemlere sahiptir. En doğru seçim model, GPU, workload ve hedeflenen latency/throughput değerleriyle yapılan benchmark sonucunda belirlenmelidir.

Kurumsal LLM ve Yapay Zekâ Altyapıları

vLLM, kurumsal yapay zekâ altyapısının yalnızca bir parçasıdır. Gerçek bir production AI sistemi; model serving’in yanında Linux, GPU, container, Kubernetes, storage, network, monitoring ve güvenlik katmanlarının birlikte değerlendirilmesini gerektirir.

Bu nedenle LLM projelerinde yalnızca model seçimine değil, modelin üzerinde çalışacağı altyapıya ve bu altyapının nasıl işletileceğine de bakmak gerekir.

Absonet Technology olarak Linux, Docker, Kubernetes ve yapay zekâ altyapıları konusunda kurumsal eğitim ve danışmanlık hizmetleri sunuyoruz. Kurumunuzun kendi altyapısında LLM serving, GPU altyapısı, Kubernetes tabanlı AI sistemleri veya on-premise yapay zekâ çözümleri planlanıyorsa teknik ekibimizle iletişime geçebilirsiniz.

Yapay zekâ alanındaki diğer kurumsal eğitim seçenekleri için Kurumsal Yapay Zekâ Eğitimleri sayfamızı, altyapı ve production süreçleri için ise Kurumsal DevOps Danışmanlığı sayfamızı inceleyebilirsiniz.

Sonuç

vLLM’yi yalnızca “LLM çalıştıran bir araç” olarak değerlendirmek eksik kalır. Asıl kullanım alanı, büyük dil modellerini uygulamaların kullanabileceği bir servise dönüştürmek ve bu servisi gerçek bir altyapı üzerinde işletmektir.

Linux üzerinde çalışan bir vLLM kurulumu Docker ile paketlenebilir, Kubernetes üzerinde GPU kaynaklarıyla dağıtılabilir ve Prometheus ile izlenebilir. OpenAI uyumlu API sayesinde uygulamalarla entegrasyon da kolaylaşır.

Ancak production seviyesinde başarılı bir LLM serving altyapısının ölçüsü yalnızca modelin cevap vermesi değildir. GPU belleğinin yeterli olması, KV cache’in doğru planlanması, concurrency altında kabul edilebilir latency alınması, servisin izlenebilmesi ve güvenli şekilde erişilebilir olması gerekir.

Asıl soru, LLM’nin çalışıp çalışmadığı değil; gerçek kullanıcı yükü altında hangi latency ile, hangi GPU maliyetiyle ve hangi operasyonel modelle çalıştırılabildiğidir.

vLLM bu problemin serving katmanını çözer. Geri kalan altyapı ise Linux, GPU, Docker, Kubernetes, storage, network, monitoring ve güvenlik bileşenleriyle birlikte tasarlanmalıdır.

Teknik Kaynaklar

• vLLM Resmi Dokümantasyonu
• vLLM Installation
• vLLM Quickstart
• vLLM OpenAI-Compatible Server
• vLLM Docker Deployment
• vLLM Kubernetes Deployment
• vLLM Metrics
• vLLM Prefix Caching
• vLLM Benchmark CLI
• vLLM Security
• vLLM Supported Models
• NVIDIA Container Toolkit
• NVIDIA TensorRT-LLM
• SGLang

Hazırlayan: Absonet Teknik Ekibi

Son güncelleme: Ekim 2026