vLLM GPU boyutlandırma: yalnızca modeli değil, iş yükünü boyutlandırın

Parametre sayısı GPU belleği için yalnızca bir alt sınırdır. Bu makale vLLM dağıtımlarını trafik, gecikme hedefleri ve bağlam uzunluklarının dağılımından yola çıkarak boyutlandırır; model ayak izini, key-value önbelleğini, eşzamanlılığı, paralellik stratejisini, kuantizasyonu ve egemenlik kısıtları altında yedek kapasiteyi ele alır. vLLM'in arkasındaki, önbellek yönetiminin ve zamanlamanın verimi belirlediğini gösteren sistem araştırmalarına dayanır.

Anahtar kelimeler vLLM · GPU boyutlandırma · KV önbelleği · eşzamanlılık · kuantizasyon · egemen çıkarım

Egemen LLM altyapısına gereğinden fazla harcamanın en hızlı yolu, bir kümeyi yalnızca parametre sayısına göre boyutlandırmaktır.

Teknik olarak GPU belleğine sığan bir model, uzun bağlamlar, eşzamanlı kullanıcılar, KV önbelleği, retrieval yükleri ve araç çağrıları iş yüküne girdiğinde üretim gecikme hedeflerini yine de kaçırabilir. Tersine, trafik orta düzeydeyse ve kalite ödünleşimi kabul edilebilirse, daha az GPU üzerinde yoğun biçimde kuantize edilmiş bir model daha iyi bir ekonomi sunabilir.

Faydalı bir boyutlandırma çalışması iş yüküyle başlar ve geriye doğru donanıma ulaşır.

Boyutlandırma, sunum sistemlerinin belleği nasıl kullandığından çıkar. Sunucu her istek için büyük olan ve dinamik olarak büyüyüp küçülen bir key-value önbelleği tutar; kötü yönetildiğinde bellek israf edilir ve toplu işlem (batch) boyutu sınırlanır. vLLM'in PagedAttention'ı bu sorunu ele alır ve aynı gecikmede önceki sistemlere göre 2–4 kat daha yüksek verim bildirir; daha uzun diziler ve daha büyük modellerde kazanç daha fazladır^[1]. Zamanlama da bellek kadar önemlidir: istek düzeyinde toplu işlemede biten istekler geri dönemez ve yeni istekler beklemek zorunda kalır; yineleme düzeyinde zamanlama bu sorunu çözmek için önerilmiştir^[2]. Donanım faturasını parametre sayısının değil, eşzamanlılığın ve bağlam uzunluğu dağılımının belirlemesinin nedeni budur.

Kuantizasyon denklemin ayak izi tarafını değiştirir. Bir derleme, dört bit veya daha az tamsayılara geçmenin teorik olarak bellek ayak izini ve gecikmeyi 16 kata kadar azaltabileceğini, pratikte ise çoğu zaman 4 ila 8 katın elde edildiğini not eder^[3]; AWQ, dil modelleri için yaygın, yalnızca ağırlıkları 4 bite indiren bir yöntemdir^[4]. Bu rakamlar makalelerin kendi kurulumlarından gelir ve hedef model ile donanım üzerinde yeniden ölçülmelidir.

Ağırlık belleği için kaba bir alt sınır şudur:

model parametreleri × ağırlık başına bit ÷ 8

Bu yalnızca başlangıç noktasıdır. Gerçek dağıtımların KV önbelleği, çalışma zamanı tamponları, CUDA grafikleri veya derleme artefaktları ve operasyonel pay için de belleğe ihtiyacı vardır.

Kuantizasyon ağırlık ayak izini önemli ölçüde azaltabilir, ancak verim ve kalite üzerindeki etkisi modele, donanıma ve kuantizasyon formatına bağlıdır.

Uzun bağlam pahalıdır, çünkü KV önbelleği aktif dizilerle ve token uzunluğuyla büyür. Bir uygulama büyük dokümanlar veya uzun konuşma geçmişleri gönderiyorsa küme, hesaplama gücüyle sınırlanmadan önce KV önbelleğiyle sınırlanabilir.

Bu yüzden 200 bin token'lık bir model sınırı otomatik olarak 200 bin token'lık bir üretim varsayılanı olmamalıdır.

Girdi uzunluğu, çıktı uzunluğu ve eşzamanlı isteklerin gerçek dağılımını ölçün. Ardından korkuluklar tanımlayın: azami bağlam, kesme veya özetleme politikası ve retrieval sınırları.

Kurumsal sistemlerde önemli soru genellikle "Saniyedeki azami token sayısı nedir?" değil, "Servis gecikme SLO'muzu karşılarken kaç gerçek kullanıcıyı destekleyebilir?" sorusudur.

En azından şunları izleyin:

• ilk token'a kadar geçen süre (TTFT);
• token'lar arası gecikme / üretim hızı;
• istek kuyruğunda bekleme süresi;
• eşzamanlı diziler;
• prompt ve tamamlama token dağılımları;
• GPU kullanımı ve bellek baskısı;
• hata ve öncelik kesme (preemption) oranları.

vLLM üretim metriklerini /metrics uç noktası üzerinden sunar; bu da bu sinyalleri Prometheus uyumlu izleme sistemlerine açar.

Güncel vLLM rehberliği açıktır:

• model tek bir GPU'ya rahatça sığıyorsa dağıtık karmaşıklıktan kaçının;
• tek bir düğümde birden fazla GPU gerekiyorsa normal sonraki adım tensör paralelliğidir;
• tek bir düğümü aşıyorsa tensör ve pipeline paralelliğini birleştirin;
• birden fazla bağımsız kopya veya trafik ölçekleme için veri paralel dağıtım önem kazanır.

MoE modelleri için uzman (expert) paralelliği de önemli olabilir. Doğru topoloji, darboğazın attention'da mı, uzman katmanlarında mı, ara bağlantıda mı yoksa bellekte mi olduğuna bağlıdır.

INT4, INT8 ve FP8 bellek gereksinimlerini azaltabilir ve bazen verimi artırabilir, ancak tam hassasiyetli taban çizgisiyle aynı değerlendirme setini geçmesi gereken dağıtım varyantları olarak ele alınmalıdır.

Örneğin uygun bir düşük bit formatındaki 32B'lik bir model, BF16 sürümünden çok daha küçük bir dağıtım zarfına sığabilir. İş yükü daha büyük bir modele ihtiyaç duymuyorsa bu, tüm iş gerekçesini değiştirebilir.

Satın almadan önce üç trafik seviyesini modelleyin:

Taban — normal mesai saatleri kullanımı.

Ani artış — bir toplantı, kampanya veya iç iş akışı kısa bir eşzamanlılık sıçramasına neden olur.

Arıza modu — bir kopya kullanılamaz durumdadır ve kalan kapasite kritik istekleri karşılamak zorundadır.

Her seviye için girdi token'larını, çıktı token'larını, eşzamanlılığı ve hedef TTFT'yi tahmin edin. Genel bir sıralama tablosuna güvenmek yerine gerçek modeli bu biçimlerle benchmark edin.

Egemen bir dağıtım, kontrol için bilinçli olarak biraz esneklikten vazgeçebilir. Ortamda kamu bulutunda ani artış kapasitesi yoksa küme, bakım ve düğüm arızasını atlatacak kadar yedeğe ihtiyaç duyar.

Mimari ayrıca şunları hesaba katmalıdır:

• model depolama kapasitesi ve güncelleme pencereleri;
• yerel konteyner/imaj kayıt deposu;
• gözlemlenebilirlik verilerinin saklanması;
• varsayılan olarak her şeyi reddeden çıkış (egress) gereksinimleri;
• yük devretme stratejisi;
• değerlendirme veya canary modelleri için yedek kapasite.

Egemen çıkarımı trafik + gecikme SLO'su + bağlam dağılımı + model kalite hedefi üzerinden boyutlandırır, ardından kabul testlerini geçen en küçük mimariyi seçeriz.

Bu, iki yaygın hatadan da kaçınır: gerçek eşzamanlılık için çok küçük bir küme satın almak ya da çoğunlukla boşta duran pahalı GPU'lar satın almak.

• vLLM — Parallelism and Scaling
• vLLM — Production Metrics
• LMXAI — Egemen vLLM kurulumu

• Egemen vLLM kurulumu + tedarikçi kontrol listesi
• vLLM kuantizasyonu: AWQ, GPTQ, FP8 ve INT4
• Kubernetes üzerinde üretim vLLM
• Egemen AI SSS