· kaynak dev.to (home feed)
vLLM H100'lerde nasıl gerçek verimlilik elde ediyor: PagedAttention ve sürekli batching açıklaması
dev.to'da yayımlanan derinlemesine bir inceleme, LLM decoding'in neden bellek bant genişliğine bağlı olduğunu ve vLLM'in PagedAttention, sürekli batching ve Hopper ayarlamalarının H100 ile H200 GPU'ları nasıl dolu tuttuğunu anlatıyor.

Decode bir bellek sorunudur, matematik sorunu değil
Gönderiye göre çıkarımın iki aşaması çok farklı davranır. Prefill, tüm prompt'u paralel işler; bu, GPU'ların iyi başa çıktığı yoğun matris çarpımıdır. Token'ların tek tek üretildiği decode ise sıralı matris-vektör çalışmalarına dayanır ve her adımda model ağırlıkları ile birikmiş Key-Value cache yüksek bant genişlikli bellekten yeniden okunur. Tensor core'lar bu zamanın çoğunda boşta bekler.
KV cache, attention'ın her adımda geçmişi yeniden hesaplamak zorunda kalmaması için vardır ama dizi uzunluğuyla büyür. Yazar, GQA tabanlı bir açık ağırlıklı mimari örneği kullanarak (gönderi 16 tam attention katmanı, 4 KV head ve 256 head boyutuyla Qwen3.6-27B'den söz ediyor) 8.192 token'lık bir dizinin BF16'da yaklaşık 0,54 GiB tükettiğini hesaplıyor. Standart PyTorch veya Hugging Face generate() hatları bu tamponları anında ayırır ve çok kiracılı yük altında bu, dış parçalanmaya yol açar: gigabaytlarca VRAM nominal olarak boş olsa bile gerekli boyutta bitişik bir blok kalmamıştır ve sonraki istek CUDA out-of-memory hatasıyla başarısız olur.
PagedAttention işletim sistemlerinden ödünç alır
vLLM'in çözümü, OS tasarımında on yıllara dayanan sanal bellek sayfalama fikrini GPU belleğine uygular. Her dizi için en kötü durum boyutunda bitişik bir parça ayırmak yerine, KV cache genellikle 16 veya 32 token barındıran sabit boyutlu fiziksel bloklara bölünür. Bir block table, her dizinin mantıksal token konumlarını bu blokların fiziksel olarak bulunduğu yerlerle eşler.
Ayırma yalnızca token'lar gerçekten üretildikçe yapılır; gönderi bunun iç parçalanmayı yüzde 4'ün altına indirdiğini ve aynı donanımın yaklaşık iki ila dört kat daha fazla eşzamanlı akış taşıyabildiğini söylüyor. Bu tasarım copy-on-write paylaşımını da mümkün kılar: GRPO gibi, tek bir prompt'tan 8 veya 16 aday rollout'un üretildiği pekiştirmeli öğrenme iş akışlarında tüm adaylar prompt'un fiziksel KV sayfalarını paylaşır ve kopyalama yalnızca tamamlamalar ayrışmaya başladığı yerde gerçekleşir.
Sürekli batching geciken işlerin boşluklarını ortadan kaldırır
Makale bunu, bir grubun en uzun isteğinin bitmesini beklediği statik batching ile karşılaştırıyor. Dört istek 50, 120, 240 ve 1.024 token üretiyorsa, GPU gecilen işi beklerken dört yuvadan üçü yüzlerce iterasyon boyunca boşta kalır. Gönderi bu boşta geçen aralıklara GPU bubble adını veriyor.
vLLM bunun yerine Orca sisteminin öncülük ettiği iterasyon düzeyinde zamanlama yaklaşımını izler: zamanlayıcı istek sınırlarında değil, her forward pass'te çalışır. Bir dizi end-of-sequence token'ını ürettiğinde blokları hemen havuza geri döner ve sıradaki istek çok sonraki iterasyonda o yuvayı kaplar; böylece işlem çekirdekleri sürekli beslenir.
Hopper'a özel ayarlamalar
Bellek ve zamanlamanın ötesinde yazı, kernel dispatch yüküne saldırarak H100 ve H200 silikonundan verimlilik sıkmaya yöneliyor. PyTorch eager modunda Python runtime tek bir token üretmek için çok sayıda işlem başlatır; bu yüzden vLLM, enforce_eager modunu devre dışı bırakarak yürütmeyi CUDA graphs olarak yakalayabilir. Makalenin, dev.to akışında kısmen kesilmiş kalan bölümleri, ek kaldıraçler olarak chunked prefill ve FP8 hassasiyetini de ele alıyor. Alıntılanan tüm benchmark'lar ve telemetri verileri gft-studio'da barındırılan adanmış H100 ve H100 ve H200 kümelerinde toplandı.
Neden önemli
Modelleri üretimde sunan veya büyük ölçekli RL rollout'ları çalıştıran herkes için gönderi, verimliliği bir donanım satın alma sorunu değil, sistem mühendisliği sorunu olarak yeniden çerçeveliyor. Decode'un neden bant genişliğine bağlı olduğu, saf cache'lemenin VRAM'i neden parçaladığı ve sayfalı ayırma ile iterasyon düzeyinde zamanlamanın nasıl çalıştığını anlamak, vLLM'i varsayılan serving yığını haline getiren şeyin çoğunu açıklar. Dallanan rollout'lar için paylaşılan sayfa mekaniği, gruplu RL örnekleme yaygın bir üretim iş yükü haline geldikçe özellikle önemlidir; çünkü bellek maliyetlerini bir prompt'u paylaşan aday sayısıyla orantılı biçimde düşürür.
- #vllm
- #llm-inference
- #gpu
- #paged-attention
- #nvidia