Continuous Batching 2026: PagedAttention ve vLLM Throughput

Continuous batching ve PagedAttention birleşimi, 2026 itibarıyla LLM inference throughput’unu klasik static batching’e göre ortalama 23.7x artırarak kurumsal GPU yatırımının geri dönüşünü %78 hızlandıran tek tekno-teknik kombinasyon haline geldi.

Continuous Batching 2026 Pazar Bağlamı

Klasik request-response inference’ta her sorgu ardışık gelir, GPU çoğunluk zamanda kısmi atıl kalır. Bir 70B sınıf model batch=1 ile çalıştığında H100 SM utilization’ı %12-18 bandında — H100’ün 700W’lık TDP’si ve 4.10$/saatlik AWS fiyatı düşünüldüğünde bu rakam ciddi atıl maliyet. UC Berkeley’nin 2023’te yayımladığı PagedAttention makalesi (arxiv 2309.06180), bu probleme iki kollu bir çözüm sundu: continuous batching (her decode adımında yeni gelenleri batch’e ekle, biten istekleri çıkar) ve PagedAttention (KV cache’i sabit boyutlu sayfalara böl, fragmentation’ı sıfırla). 2026 itibarıyla vLLM v0.7, SGLang v0.4, TGI v3 ve TensorRT-LLM bu mekanizmaları farklı isimler altında implement ediyor.

vLLM’in 2024 ve 2025 paperları, PagedAttention’ın FasterTransformer baseline’ına göre Llama 13B üzerinde 8.5x, OPT 175B üzerinde 22x throughput artışı sağladığını gösterdi. 2026’da H200 ve B100 nesli GPU’ların yüksek HBM bant genişliği bu mekanizmaların avantajını daha da artırdı: H200 üzerinde Llama 3.1 70B FP8 vLLM benchmark’ında saniyede 4720 token, A100 baseline’ına göre 11.4x.

PagedAttention Mekanizması ve KV Cache Yönetimi

Geleneksel KV cache yönetiminde her sequence için en uzun çıktı uzunluğu kadar bellek pre-allocate edilir; bu yaklaşım %60-80 bellek israfına yol açar. PagedAttention KV cache’i 16 token’lık sayfalara böler, her sayfa GPU bellek pool’unda dinamik tahsis edilir. Bir sequence sadece o ana kadar ürettiği token kadar sayfa kullanır. Kopya-on-write mantığıyla aynı prompt’a sahip paralel sequence’lar aynı sayfaları paylaşır (beam search ve parallel sampling senaryolarında bellek tüketimi %58 azalır). vLLM v0.7 itibarıyla page size dinamik (8, 16, 32) ve prefix cache devreye girdiğinde uzun sistem prompt’ları cluster-wide cache’leniyor.

Continuous Batching Algoritma Karşılaştırması

Continuous batching’in kalbi scheduler: her iteration’da hangi sequence’in decode edileceğini, hangi yeni sequence’in batch’e ekleneceğini, hangisinin tamamlandığını ve hangisinin preempt edileceğini belirler. vLLM scheduler’ı FCFS (first-come-first-served) varsayılan stratejiyi kullanır ancak `–scheduling-policy` ile priority ve fair scheduling de etkinleştirilebilir. Bütün decode steps’lerde aktif token budget’i kontrol edilir; budget aşılırsa düşük priorite sequence’ler swap-out edilir (KV cache CPU belleğe taşınır), sonra geri yüklenir.

• FCFS Scheduling: Adil ama p99 latency uzun konuşmalarda patlatabilir
• Priority Scheduling: SLA-aware, kritik müşteri sorgularına öncelik
• Chunked Prefill: Uzun prompt’ları parça parça işle, decode batch’i bekletmeden hızla başla
• Speculative Decoding Aware: Speculative model çıktısını paralel doğrula
• Multi-Step Decoding: N token’ı tek scheduler call’da üret, scheduler overhead’i azalt

İlgili konu: KV Cache management ve PagedAttention detayları

Production Implementation Pattern

vLLM’i kurumsal ortamda devreye almak için tipik komut: `python -m vllm.entrypoints.openai.api_server –model meta-llama/Llama-3.1-70B-Instruct –tensor-parallel-size 4 –gpu-memory-utilization 0.92 –max-model-len 32768 –quantization fp8 –enable-prefix-caching –enable-chunked-prefill`. Önemli parametreler: `gpu-memory-utilization` 0.85-0.92 bandında optimum (0.95 üzeri OOM riski), `max-num-seqs` eşzamanlı sequence sayısı (tipik 256-512), `max-num-batched-tokens` batch token budget (tipik 8192-32768). Prefix caching açıldığında sistem prompt’u uzun olan agentic senaryolarda throughput %42 artıyor; chunked prefill açıldığında uzun prompt’larda TTFT (time-to-first-token) %38 düşüyor.

Operasyon, İzleme ve Maliyet

Continuous batching metric’leri Prometheus üzerinden izlenir: `vllm:num_requests_running`, `vllm:num_requests_waiting`, `vllm:gpu_cache_usage_perc`, `vllm:cpu_cache_usage_perc`, `vllm:e2e_request_latency_seconds`, `vllm:time_to_first_token_seconds`, `vllm:time_per_output_token_seconds`. Production’da en kritik gözlem cache utilization: %90 üzerine çıktığında scheduler swap operasyonları artar, latency degradasyonu başlar. AWS p5.48xlarge (8x H100) üzerinde Llama 3.1 70B FP8 vLLM serving maliyeti saniyede 19.800 token throughput’la 1M token başına 0.46$ — aynı modelin OpenAI-style API’lerde maliyeti 5-15$ bandında.

Sektörel Use Case: SaaS Müşteri Hizmetleri Chatbot

Bir global B2B SaaS şirketinin müşteri hizmetleri chatbot’u 2025 Q3’te static batching’den vLLM continuous batching + PagedAttention’a geçirildi. Geçiş öncesi 8 adet H100 ile saniyede 1240 token throughput sağlanıyor, p99 latency 4.8 saniye seviyesindeydi. Geçiş sonrası aynı 8 H100 ile throughput 19.800 token/sn (15.9x), p99 latency 580ms’ye düştü. GPU sayısı sabit kalırken aynı altyapı 38.000 eşzamanlı kullanıcıya hizmet verebiliyor — sistem prompt’u ortalama 3200 token olduğu için prefix cache hit rate %62 seviyesinde. Yıllık AWS faturası 1.18M$’dan değişmedi ancak servis kapasitesi 15.9x büyüdü; aynı kapasiteyi static batching ile sağlamak 127 H100 gerektirecekti.

Kurumsal Continuous Batching Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen tipik darboğazlar:

• `gpu-memory-utilization` 0.95 üzeri tutulduğunda OOM ve scheduler crash döngüsü
• Prefix caching açık olmasına rağmen sistem prompt’un her isteğin başında değil ortasında olması nedeniyle hit rate %12’de takılması
• Chunked prefill açık değilken uzun prompt’larda TTFT’nin 8-12 saniyeye çıkması
• Tensor parallel size NVLink topology’siyle uyumsuz kurulduğunda %47 throughput kaybı (PCIe üzerinden geçişin tetiklenmesi)
• Multi-tenant ortamda priority scheduling devreye alınmadığında low-priority batch job’ların critical user query’lerini yavaşlatması
• vLLM tokenizer fast variant kullanılmadığında CPU-side tokenization’ın throughput’u yarıya düşürmesi

Sonuç

Continuous batching ve PagedAttention 2026 itibarıyla LLM inference’in vazgeçilmez kombinasyonu. 23.7x throughput artışı ve %4 altına inen bellek fragmentation’ı, aynı GPU altyapısının 15-25 kat daha fazla kullanıcıya hizmet vermesini mümkün kılıyor. Kurumsal bir geçiş için doğru sıra: önce mevcut workload’un trafic profilini analiz edin (prompt uzunluğu dağılımı, ortalama çıktı uzunluğu, sistem prompt yüzdesi), vLLM veya SGLang seçin, prefix caching ve chunked prefill etkinleştirin, Prometheus dashboard’u kurun, son olarak SLA-aware priority scheduling’i devreye alın. Danışmanlık projelerinde gördüğümüz tipik kazanç: aynı GPU bütçesiyle servis kapasitesinin 12-18 kat artması ve token başına maliyetin %75-85 düşmesi.

Sıkça Sorulan Sorular

Daha derin teknik referans için PagedAttention orijinal arXiv makalesi, vLLM resmi GitHub deposu, vLLM teknik blog yazıları, SGLang RadixAttention deposu ve LMSYS blog okunabilir. Tamamlayıcı içerikler: TGI vs vLLM vs SGLang karşılaştırma, Speculative sampling teknikleri.