vLLM ile Üretim Ortamında LLM Çıkarımı: Mimari, GPU Optimizasyonu ve Token Maliyetlerini Düşürme

Bir büyük dil modelini demo ortamında çalıştırmak kolaydır. Aynı modeli üretim ortamında — güvenilir biçimde, ölçeklenebilir şekilde ve her bin istekte altyapı maliyetlerinin tırmanmasını izlemeden — çalıştırmak bambaşka bir meydan okumadır.

Bu rehber; vLLM'nin bulut ortamında nasıl dağıtılacağını, üretime hazır bir mimarinin nasıl göründüğünü ve üretilen token başına maliyeti kontrol altında tutarken GPU kullanımını maksimize etmenin temel tekniklerini ele almaktadır.

vLLM Nedir ve Üretim YZ için Neden Önemlidir?

vLLM, büyük dil modellerinin yüksek verimli çıkarımı için tasarlanmış açık kaynaklı bir çıkarım motorudur. UC Berkeley araştırmacıları tarafından geliştirilmiş olup Llama, Mistral, Qwen, Gemma ve DeepSeek dahil olmak üzere açık kaynaklı LLM'leri üretim ortamında çalıştıran kuruluşlar arasında en yaygın benimsenen çözümlerden biri haline gelmiştir.

vLLM'nin çözdüğü temel sorun GPU verimliliğidir. Geleneksel çıkarım çerçeveleri istekleri sabit toplu işlemlerle işler: GPU, çalışmaya başlamadan önce bir toplu işlemin dolmasını bekler, ardından bir sonraki toplu işlem oluşturulurken boşta kalır. Değişken trafik altında bu durum, pahalı donanımın kullanıcılar beklerken hiçbir şey yapmadığı anlamına gelen ciddi bir israfı beraberinde getirir.

vLLM bu sorunu iki mekanizmayla çözer:

• Sürekli toplu işleme — yeni istekler, sabit bir toplu işlemin dolmasını beklemek yerine GPU kapasitesi uygun hale geldikçe işlem ardışık düzenine dinamik olarak eklenir.
• PagedAttention — işletim sistemi sanal belleğinden ilham alan bir bellek yönetimi tekniğidir. Her isteğin KV önbelleği için büyük, bitişik bellek blokları ayırmak yerine PagedAttention, belleği küçük, bitişik olmayan sayfalara tahsis eder. Bu yaklaşım, naif tahsise kıyasla bellek israfını 4 kata kadar azaltır ve aynı donanım üzerinde çok daha fazla eş zamanlı isteğin çalışmasına olanak tanır.

Bu iki özellik, daha iyi verim, daha düşük gecikme ve üretilen token başına daha düşük altyapı maliyeti olarak doğrudan yansır; üretim ortamında gerçekten önemli olan metrik de budur.

vLLM için Üretime Hazır Mimari

vLLM'yi çalıştırmak kolaydır. Trafik zirvelerini, node arızalarını ve süregelen güncellemeleri kapsayan gerçek trafiği güvenilir biçimde yönetmesi için yapılandırılmış bir mimari gerekir.

Tipik bir üretim dağıtımı şu katmanları içerir.

Trafik giriş noktası: API Gateway; kimlik doğrulama, hız sınırlama ve istek yönlendirmeyi yönetir. Bu yapı, uygulama trafiğini çıkarım iş yüklerinden ayrı tutar ve güvenlik yönetimini basitleştirir.

Yük dağıtımı: Yük dengeleyici, gelen istekleri çıkarım örnekleri arasında dağıtır. Oturum tabanlı veya akış iş yükleri için bağlantı kalıcılığının yapılandırılması gerekebilir.

Orkestrasyon katmanı: Kubernetes; vLLM pod'larının dağıtımını, zamanlamasını, sağlık denetimini ve otomatik ölçeklendirmesini yönetir. GPU özellikli node'lar, zamanlama ve maliyet takibini kolaylaştırmak için CPU iş yüklerinden ayrı bir node havuzu olarak sağlanır. Kubernetes ortamını henüz değerlendiriyorsanız, Cloud4U'nun Hizmet Olarak Kubernetes (KaaS) çözümü, küme sağlama ve GPU node zamanlamasını yönetir; böylece ekibiniz altyapı yönetimi yerine çıkarım yapılandırmasına odaklanabilir.

Çıkarım pod'ları: Her vLLM pod'u, modeli GPU belleğine yüklenmiş şekilde çıkarım motorunu çalıştırır. Bellek sınırları, çoğaltma sayıları ve başlatma araştırmaları dahil pod yapılandırması, model boyutuna göre ayarlanmalıdır.

Model depolama: Model ağırlıkları S3 uyumlu nesne depolama alanında saklanır ve başlatma sırasında GPU node'larına çekilir. Node düzeyinde önbelleğe alma, sık kullanılan modeller için soğuk başlatma sürelerini azaltır.

Gözlemlenebilirlik yığını: Prometheus, vLLM'nin yerleşik uç noktasından metrikleri toplar; Grafana ise gösterge panelleri sağlar. Bu yapı isteğe bağlı değildir — GPU kullanımı, kuyruk derinliği ve token verimi hakkında görünürlük olmadan optimizasyon tahmine dayanır.

Tek bir model için minimal dağıtım şu komutla başlatılabilir:

docker run --gpus all \
  -v /model-cache:/root/.cache/huggingface \
  -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model mistralai/Mistral-7B-Instruct-v0.2 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90

Kubernetes için GPU node yakınlığı, yatay pod otomatik ölçekleyici yapılandırması ve Prometheus ServiceMonitor içeren Helm tabanlı dağıtım, üretim ortamları için standart kalıptır.

Doğru GPU Yapılandırmasını Seçmek

GPU seçimi çoğunlukla bir bellek sorunu olarak ele alınır — "model sığıyor mu?" — ancak bu yaklaşım daha önemli soruyu gözden kaçırır: Beklenen eş zamanlılıkta modeli sunmak ne kadara mal olur?

Doğru yapılandırmayı belirleyen birkaç etken vardır:

• Model boyutu, ağırlıklar için temel bellek gereksinimini belirler.
• Bağlam penceresi uzunluğu, eş zamanlı istek başına ne kadar KV önbellek belleği gerektiğini belirler. 32K bağlam penceresi, aynı model için 8K penceresinden çok daha fazla bellek gerektirir.
• Beklenen eş zamanlılık, kaç isteğin aynı anda çalışması gerektiğini belirler.
• Gecikme gereksinimleri — özellikle İlk Token Süresi (TTFT) — verimden bağımsız olarak belirli yapılandırmaları dışlayabilir.

Başlangıç noktası olarak:

Önemli: Bunlar üretim boyutlandırma kararları değil, kıyaslama için başlangıç noktalarıdır. Sağlama yapmadan önce her zaman temsili trafik ile kıyaslama yapın. Cloud4U'nun yapay zeka ve makine öğrenimi için GPU sunucuları saatlik faturalandırmayla sunulmaktadır; bu da üretim kurulumuna karar vermeden önce farklı yapılandırmaları kıyaslamayı kolaylaştırır.

Büyük Modeller için Tensör Paralelliği

Tek bir GPU'nun belleğini aşan modeller için vLLM, tensör paralelliğini destekler; model katmanlarını birden fazla GPU'ya böler ve her biri hesaplamanın bir bölümünü üstlenir. Bu işlem --tensor-parallel-size bayrağıyla yapılandırılır:

--tensor-parallel-size 2   # modeli 2 GPU'ya böler
--tensor-parallel-size 4   # modeli 4 GPU'ya böler

Tensör paralelliği, GPU'lar arasında hızlı ara bağlantılar (NVLink veya yüksek bant genişlikli PCIe) gerektirir. Bulut GPU örneklerinde doğrusal ölçekleme varsaymadan önce ara bağlantı topolojisini doğrulayın.

PagedAttention ve KV Önbellek Yönetimi

PagedAttention, vLLM'yi önceki çıkarım çerçevelerinden anlamlı biçimde farklı kılan bellek yeniliğidir ve yüzeysel bir ifadeyle geçiştirilmemesi gerekir.

Otoregresif çıkarım sırasında — bir LLM'nin metni bir token oluşturarak üretme süreci — her ileri geçiş, bağlamdaki önceki tüm token'lardan anahtar-değer tensörlerine erişime ihtiyaç duyar. Toplu olarak KV önbelleği adı verilen bu tensörler, üretilen her token'la büyür ve isteğin süresi boyunca GPU belleğinde tutulması gerekir.

Geleneksel çerçeveler, maksimum olası çıktı uzunluğuna göre boyutlandırılmış büyük, bitişik bellek bloklarını başlangıçta ayırır. Bu yaklaşımın iki sorunu vardır: çoğu istek maksimum uzunluğa ulaşmadığından ayrılan bellek boşta kalır; büyük bitişik ayırmalar ise GPU belleğini parçalayarak paralel çalışabilecek istek sayısını azaltır.

PagedAttention, KV önbellek belleğini bir işletim sisteminin fiziksel RAM'i ele aldığı gibi yönetir: belleği sabit boyutlu sayfalara böler ve her isteğin önbelleğini bellekte nerede bulunursa bulunsun kullanılabilir sayfalara eşler. Bir istek tamamlanır tamamlanmaz sayfalar serbest bırakılır.

Pratik sonuç şudur: vLLM aynı GPU üzerinde daha fazla eş zamanlı istek çalıştırabilir; bu da doğrudan daha yüksek verim ve token başına daha düşük maliyet anlamına gelir.

Kuantizasyon: GPU Maliyetlerini Düşürmenin En Hızlı Yolu

Çıkarım maliyetlerini azaltmanın en etkili — ve en az kullanılan — tekniklerinden biri model kuantizasyonudur. Model ağırlıklarının sayısal hassasiyetini azaltarak kuantizasyon, bellek gereksinimlerini küçültür ve çoğunlukla çıktı kalitesi üzerinde minimal etki ile verimi artırır.

vLLM birkaç kuantizasyon formatını yerel olarak destekler:

7B model için FP16'dan AWQ'ya geçiş, belleği yaklaşık 14GB'tan 7GB'a düşürür — modelin daha küçük bir GPU üzerinde çalışmasına ya da aynı GPU üzerinde daha fazla eş zamanlı istek için bellek boşaltılmasına olanak tanır.

vLLM'de kuantize edilmiş bir model yüklemek için:

--model TheBloke/Mistral-7B-Instruct-v0.2-AWQ \
--quantization awq

Üretim dağıtımları için FP8, özellikle NVIDIA H100 donanımında giderek tercih edilen seçenek haline gelmektedir; H100'ün özel FP8 tensör çekirdekleri, bellek azaltımının yanı sıra verim iyileştirmeleri de sağlar.

Gecikmeye Duyarlı İş Yükleri için Spekülatif Kod Çözme

Ham verimden çok İlk Token Süresi (TTFT) ve token başına gecikmenin önem taşıdığı uygulamalar için — etkileşimli asistanlar, gerçek zamanlı kod önerileri, müşteriye yönelik sohbet — spekülatif kod çözme değerlendirmeye değerdir.

Bu teknik, küçük ve hızlı bir "taslak" modelin aynı anda birkaç token spekülatif olarak üretmesini, ardından daha büyük bir "hedef" modelin bunları tek bir ileri geçişte doğrulamasını kullanır. Taslak token'lar doğru olduğunda — ki bu, tahmin edilebilir çıktı kalıpları için önemli bir oranda gerçekleşir — adım başına birden fazla token kabul edilir ve gerekli ileri geçiş sayısı azalır.

vLLM, --speculative-model bayrağı aracılığıyla spekülatif kod çözmeyi destekler. Verim kazanımları, alan ve çıktı özelliklerine göre büyük ölçüde değişir; ek altyapı karmaşıklığına karar vermeden önce iş yükünüze özgü kıyaslama yapın.

Uygulamada GPU Kullanımını Artırmak

Pek çok üretim YZ ortamı, anlamlı bir yük altında bile %30–50 GPU kullanımıyla çalışır. Yaygın nedenler şunlardır:

• Çok küçük istek toplu işlemleri
• GPU'yu yavaşlatan ön/son işlemedeki CPU darboğazları
• Soğuk depolama alanından yavaş model yükleme
• Çoğaltmaları çok yavaş ekleyen otomatik ölçeklendirme politikaları
• Birden fazla küçük örnek yerine tek büyük örnekler

Daha yüksek kullanıma giden en güvenilir yol:

1. Sürekli toplu işlemeyi etkinleştirin — vLLM'de bu varsayılan olarak aktiftir, ancak yapılandırma tarafından geçersiz kılınmadığını doğrulayın.
2. --gpu-memory-utilization değerini 0,90 veya üzerine ayarlayın — vLLM bu oranı KV önbelleği için kullanır; gereksiz biçimde düşürmek eş zamanlılığı azaltır.
3. Yük dengeleyicinin arkasında birden fazla çoğaltma dağıtın — kuyruklu tek bir örnek, baş satır engelleme sorunu yaratır; çoğaltmalar yükü dağıtır ve P95/P99 gecikmesini azaltır.
4. Kuyruk derinliğine göre otomatik ölçeklendirmeyi yapılandırın — vllm:num_requests_waiting Prometheus metriği üzerinde ölçeklendirme, CPU veya bellek metriklerine göre gerçek çıkarım yüküne daha hızlı yanıt verir. KEDA bu amaçla özel Prometheus metriklerini destekler.
5. Modelleri node yerel depolama alanına önceden yükleyin — 15GB'lık bir modeli pod başlangıcında nesne depolamadan çekmek, ölçek genişletme süresine 1–3 dakika ekler. DaemonSet tabanlı model önbelleğe alma bu sorunu ortadan kaldırır.

Token Ekonomisi: Gerçekten Önemli Olanı Ölçmek

Altyapı ekipleri GPU maliyetlerini çoğunlukla saatlik olarak değerlendirir. Finans ekipleri ise YZ iş yüklerini aylık olarak değerlendirme eğilimindedir. Her iki metrik de çıkarım yığınınızın verimli olup olmadığını göstermez.

İkisini birbirine bağlayan rakam, üretilen milyon token başına maliyet'tir — toplam altyapı harcaması bölü toplam üretilen token sayısı. Bu rakamı azaltmak, bu rehberdeki her optimizasyonun hedefidir. Tam YZ yığınında kaynak etiketleme, Spot örnekler ve FinOps uygulamalarını kapsayan daha geniş bir çerçeve için yapay zeka/ML iş yükleri için GPU maliyet optimizasyonu stratejileri rehberimize bakabilirsiniz.

Kaba bir referans olarak: orta düzey eş zamanlılıkta kuantize edilmiş 7B model sunan NVIDIA L40S üzerindeki iyi yapılandırılmış bir vLLM dağıtımı (bulut GPU altyapısında saatte yaklaşık 2–3 €), bağlam uzunluğu ve toplu işleme özelliklerine bağlı olarak saniyede 1.000–3.000 token sunabilir. Bu verimde, milyon token başına maliyet 1–2 €'nun altına düşer — yüksek hacimli iş yükleri için yönetilen API sağlayıcılarıyla rekabet edebilir ve üstelik veri gizliliği ile token başına fiyatlandırma sürprizlerinin olmaması gibi ek avantajlar sunar.

Bu rakamı en çok etkileyen unsurlar:

• Kuantizasyon — aynı donanım, saniyede daha fazla token, token başına daha düşük maliyet
• Sürekli toplu işleme — değişken yük altında daha iyi GPU kullanımı
• Otomatik ölçeklendirme — yoğun olmayan saatlerde boşta kapasite için ödeme yapmaktan kaçınma
• Modeli doğru boyutlandırma — iyi ayarlanmış bir 8B model, altyapı maliyetinin çok küçük bir bölümüyle alana özgü görevlerde çoğunlukla 70B modelle eşleşir

Üretim vLLM Dağıtımını İzleme

vLLM, /metrics adresinde Prometheus uyumlu bir metrik uç noktası sunar. Asgari olarak şunları izleyin:

• vllm:gpu_cache_usage_perc — KV önbellek kullanımı; %95'in üzerindeki sürekli değerler bellek baskısına işaret eder
• vllm:num_requests_waiting — kuyruk derinliği; yükselen değerler dağıtımın gelen yükü karşılayamadığını gösterir
• vllm:e2e_request_latency_seconds — uçtan uca istek gecikmesi (P50, P95, P99 takip edin)
• vllm:time_to_first_token_seconds — etkileşimli uygulamalar için kritik
• vllm:request_success_total ve vllm:request_failure_total — hata oranı
• nvidia-smi veya DCGM exporter aracılığıyla GPU kullanımı ve GPU bellek kullanımı

Zirve saatlerinde sürekli olarak %60'ın altında seyreden GPU kullanımı, kullanılmayan kapasiteye işaret eder. İş saatlerinde sıfırı aşan kuyruk derinliği ise dağıtımın daha fazla kapasiteye ihtiyaç duyduğunu gösterir.

Yaygın Dağıtım Hataları

Model sığdırma için boyutlandırma, eş zamanlılık için değil. Modelin GPU belleğine sığması gerekli ama yeterli değildir. Eş zamanlı istekler için yeterli KV önbelleği alanı olmadan, gerçek trafik altında verim çöker.

Yayına geçmeden önce yük testi yapmamak. 10 eş zamanlı kullanıcıyı yönetebilen bir dağıtım, 50'de kuyruk oluşturabilir. Herhangi bir üretim lansmanından önce zirveler dahil gerçekçi trafik desenleriyle yük testleri çalıştırın.

Otomatik ölçeklendirmesiz tek çıkarım örneği. Tek bir pod hem tek hata noktası hem de baş satır engelleme sorunu oluşturur. Yük dengeleyicinin arkasında birden fazla çoğaltma, minimum üretim gereksinimidir.

Model katmanını görmezden gelmek. Kuruluşlar altyapıyı optimize etmeye çaba gösterirken, kuantize edilmiş bir alternatifin GPU maliyetinin yarısıyla eşit performans sergileyeceği aşırı büyük bir FP16 modeli çalıştırır.

İzleme eksiklikleri. KV önbellek kullanımı ve kuyruk derinliği hakkında görünürlük olmadan, performans düşüşü kullanıcılar bildirene kadar fark edilmez.

Sonuç: Verimli Bir YZ Çıkarım Platformu İnşa Etmek

vLLM; sürekli toplu işleme, PagedAttention, kuantizasyon desteği ve OpenAI uyumlu API aracılığıyla açık kaynaklı LLM'leri üretim ortamında verimli biçimde sunmak için teknik temeli sağlar. Kubernetes orkestrasyonu, GPU özellikli bulut node'ları, otomatik ölçeklendirme ve gözlemlenebilirlikten oluşan altyapı katmanı ise bu potansiyelin güvenilir performansa ve öngörülebilir maliyetlere dönüşüp dönüşmediğini belirler.

vLLM aynı zamanda üretim ortamında Retrieval-Augmented Generation (RAG) sistemlerini pratik ölçekte hayata geçiren çıkarım katmanıdır — bir kurumsal bilgi asistanı veya belge arama platformu geliştiriyorsanız, o rehber tam ardışık düzen mimarisini kapsamaktadır.

LLM çıkarımına bir platform mühendisliği sorunu olarak yaklaşan — eş zamanlılık için tasarlayan, token ekonomisini ölçen ve iteratif olarak ayarlayan — kuruluşlar, altyapı maliyetlerinde orantılı artışlarla karşılaşmadan YZ hizmetlerini ölçeklendirecektir.

vLLM veya diğer YZ/ML iş yükleri için GPU bulut altyapısı değerlendiriyorsanız, Cloud4U makine öğrenimi için NVIDIA destekli GPU sunucuları saatlik faturalandırma ve ücretsiz deneme süresiyle sunmaktadır.