· kaynak dev.to (home feed)
FP8 mi AWQ mi: vLLM için uygulamalı quantization karşılaştırma rehberi
Bir dev.to eğitimi, llm-compressor ile FP8 ve AWQ checkpoint'lerini oluşturmayı ve bunları vLLM ile doğal olarak sunmayı gösteriyor; her formatın VRAM, throughput ve doğruluk açısından ne zaman öne geçtiğini haritalıyor.

Rehber neyi kapsıyor
dev.to'da yayınlanan bir eğitim, büyük bir dil modelinin llm-compressor ile sıkıştırılıp ortaya çıkan checkpoint'in doğrudan vLLM tarafından sunulabileceği şekilde hazırlanmasını anlatıyor; FP8 ile AWQ (activation-aware weight quantization) arasındaki seçimi, yazılımsal bir sorundan önce donanımsal bir soru olarak çerçeveliyor. Yazar, güçlü sunum throughput'unu vLLM'ın PagedAttention'ına bağlıyor; ancak düşük hassasiyetli formatların yalnızca kalibrasyonun model kalitesini, perplexity ile ölçüldüğü haliyle, kabul edilebilir sınırlar içinde tutması durumunda karşılığını verdiğini savunuyor.
Üç aşamalı bir pipeline
Rehbere göre quantization üç aşamada yürüyor. Örnek uygulamada temel model olan Llama-3-8B önce özgün hassasiyetinde, genellikle BF16 veya FP16 olarak yükleniyor. Sıra kalibrasyonda: ağ üzerinden temsili bir veri seti geçirilerek activation istatistikleri toplanıyor. FP8 için bu, scaling factor'leri türetmek amacıyla activation'larda görülen en büyük mutlak değerlerin kaydedilmesi anlamına geliyor; AWQ'da ise quantization parametreleri yeniden yapılandırma hatasını en aza indirecek şekilde ayarlanıyor. Son aşamada, quantize edilmiş ağırlıklar vLLM yükleyicisinin beklediği metadata ile birlikte yazılıyor; böylece sunum sırasında ek bir dönüştürme adımı gerekmiyor.
Uygulamalı FP8 örneği
Yazıdaki Python tarifi bir kalibrasyon derlemi hazırlıyor — beş kısa cümlenin yüz kez tekrarlanması; üretim çalışmasında bunun yerine gerçek eğitim verisinin çeşitli bir dilimini kullanılması gerektiğine dair açık bir uyarı da var — ve ardından tek atımlık (one-shot) bir quantization geçişi uygulanıyor. Bir QuantizationModifier, FP8 şeması ve hem girdi hem çıktıda float8_e4m3fn dtype'ları ile modelin Linear katmanlarını hedefliyor ve sonuç yerel bir dizine kaydediliyor. Yazarın belirttiğine göre FP8 için en kritik adım kalibrasyon; çünkü scaling factor'ler yanlışsa activation tensor'leri taşabilir.
Bitmiş checkpoint'i sunmak için yalnızca olağan vLLM bayrakları gerekiyor: model yolunu çıktı dizinine gösterin, dtype'ı float8 olarak ayarlayın ve bir tensor-parallel boyutu ile maksimum bağlam uzunluğu seçin.
Bellek aritmetiği
Rehberin boyutlandırma tablosu 8B'lik bir modeli BF16'da yaklaşık 16 GB, FP8'de 8 GB ve AWQ'nun INT4'ünde 4 GB olarak veriyor; 70B'lik bir model ise sırasıyla yaklaşık 140 GB, 70 GB ve 35 GB'ye denk geliyor. Bu rakamlar KV cache'i kapsamıyor; yazar, uzun bağlamlı iş yüklerinde KV cache'in toplam VRAM'in yüzde 20 ile 40'ını tüketebileceğini tahmin ediyor.
Formatlar arasında nasıl seçim yapılır
Yazının merkezindeki iddia, LLM çıkarımının ham işlem gücünden çok bellek bant genişliği tarafından darboğaza sokulması. FP8, ağırlık ayak izini BF16'ya göre yarıya indiriyor; yazar bunu, ağırlıkları akıtma için kullanılabilir bant genişliğini kabaca ikiye katlamak olarak tarif ediyor; ancak format H100 ve H200 gibi NVIDIA Hopper GPU'larda tam hıza ulaşıyor. A100 gibi Ampere sınıfı donanımda FP8 çok az hızlanma sağlayabilir, hiç sağlamayabilir hatta datatype dönüşüm yükü ekleyebilir.
AWQ'nun INT4'ü ağırlık ayak izini yüzde 75 azaltıyor, daha büyük batch'ler veya daha uzun bağlamlar için VRAM serbest bırakıyor ve donanım üreticileri arasında daha kolay taşınıyor. Ödünleşim ise şu: INT4 matris çarpımı çoğu GPU'da yerleşik değil ve gecikme yaratabilen, vLLM içinde gelenler dahil, özelleştirilmiş kernel'lere bağlı. FP8 perplexity bozulmasını daha düşük tutarken, AWQ maksimum sıkıştırma karşılığında bir miktar doğruluktan vazgeçiyor.
Rehberden çıkan pratik kural şu: Hopper sınıfı GPU'lar mevcutsa ve öncelik doğruluksa FP8 seçin; Ampere veya daha eski donanımda, batch boyutu veya bağlam uzunluğu için VRAM payı en çok önemliyse ve küçük bir kalite kaybı kabul edilebilirse AWQ seçin. Yazar, CPU offloading'in her iki formatla da daha küçük PCIe aktarımları sayesinde kazanç sağladığını, ancak hassasiyetten bağımsız olarak gerçek zamanlı sunum için nadiren yeterince hızlı olduğunu ekliyor.
Neden önemli
Quantization formatı, donanım maliyetini, batch kapasitesini, gecikmeyi ve yanıt kalitesini aynı anda etkileyen az sayıdaki dağıtım kararından biri; bu rehber o soyut ödünleşimi somut ve tekrarlanabilir bir iş akışına dönüştürüyor. vLLM uyumlu FP8 veya AWQ checkpoint'lerini tek bir kalibrasyon betiğine indirgemek, BF16 sunumunu karşılayamayan ekipler için engeli düşürüyor. Uyarılar da dikkati hak ediyor: VRAM ve bant genişliği rakamları tek bir blog yazısından geliyor, yazarın kendisi de kalibrasyon verisi kalitesini belirleyici olarak işaretliyor; ve akıllıca bir sonraki adım, taahhütte bulunmadan önce her iki formatı kendi GPU'larınızda ve trafiğinizde ölçmek.
- #vllm
- #quantization
- #llm
- #gpu
- #inference