FP8 quantization, Qwen2.5 çıktısını sessizce bozarak vLLM'i %47 daha ucuz gösterdi

Fazla temiz gelen bir tasarruf

Tek bir AMD MI300X üzerinde çıkarım maliyetlerini ölçen bir geliştirici kesin bir zafer gibi görünen bir sonuç aldı: vLLM'de FP8 quantization'ın etkinleştirilmesi, Qwen2.5-72B-Instruct sunumunun ölçülen maliyetini %47 düşürdü. Ölçüm gerçekti, ama arkasındaki model bozuktu. dev.to'daki firsthand bir anlatıma göre FP8 sunucusu cevaplar yerine ardı ardına ünlem işaretleri üretiyor ve her istekte output-token sınırına takılıyordu; yani görünen tasarruf, tam hızla anlamsız token'lar üretmekten geliyordu.

Kurulum

Yazarın GPU'da bir saati vardı ve basit bir cevap istiyordu: tek bir output token'ın maliyeti ne kadar. Test, vLLM'in ROCm derlemesini 7B, 32B ve 72B boyutlarındaki Qwen2.5 ile çalıştırdı; 32 eşzamanlı istek, 256 token'lık output sınırı ve sağlayıcının GPU başına saatte 2,99 dolarlık liste fiyatı kullanıldı; her rakam, duvar saatine o fiyat çarpılıp üretilen token sayısına bölünerek hesaplandı. BF16'daki baseline'lar, her biri dört tekrarla, 7B modelde milyonda output token başına 0,227 dolar, 32B'de 0,77 dolar ve 72B'de 1,67 dolar çıktı; 72B tekrarları %0,4 içinde örtüşüyordu — yani stabil bir makine.

Tuzak

FP8 ağırlıkları yarı boyutta sakladığı için sıradaki adım vLLM'in anında --quantization fp8 bayrağını açmaktı. Her birinde üç çalışmayla, 32B milyonda token başına 0,77 dolardan 0,449 dolara düştü (%41'lik kesinti), 72B ise 1,67 dolardan 0,872 dolara (%47).

İpucu, manşette değil blok bazındaki ayrıntıdaydı. Temperature 0'da aynı 32 prompt'la BF16 32B blok başına yaklaşık 6.900 output token yazarken, FP8 her seferinde tam olarak 8.192 yazdı — 32 istek çarpı 256 token sınırı, yani her istek sınıra kadar çalıştı. Birinci Dünya Savaşı'nın nedenlerini yaklaşık 80 kelimede özetlemesi istendiğinde BF16 89 token'lık bir cevap verdi; FP8 sunucusu 256 token'ın tamamında ünlem işaretleri bastı. Maliyet rakamı yanlış davranışı fiyatlıyordu.

Ayakta kalan rakamlar

Karşılaştırmayı önceden quantize edilmiş checkpoint'lerle — RedHatAI'nin Qwen2.5 FP8-dynamic sürümleriyle — tekrarlayıp önce cevapları doğrulamak daha küçük ama kullanılabilir bir sonuç verdi. 72B'de output uzunluğu BF16 ile yaklaşık %1 içinde örtüştü (blok başına 6.361'e karşı 6.328 token), örnekleme yapılan cevaplar doğruydu ve maliyetler 7B'de %18 (milyonda token başına 0,227'den 0,185'e), 72B'de %32 düştü (1,67'den 1,13'e); gürültü sınırları sırasıyla %3'ün ve %1'in altındaydı.

Yazarın belirttiği uyarılar

Gönderi sınırları konusunda açık sözlü. Tek bir oturumu ve tek bir workload'u kapsıyor — kısa prompt'lar, 256 output token, eşzamanlılık 32 — yani uzun bağlam veya uzun çıktılı trafik farklı davranabilir. 72B FP8 sunucusu VM'nin ikinci GPU'sunda çalışırken baseline ilkini kullandı; aynı kart modeli, birebir aynı kart değil. Bozuk anında FP8 72B yalnızca output uzunluğuyla teşhis edildi, cevapları okunmadı. 7B'de anında FP8 aslında sorunsuzdu; altı cevabın altısı doğruydu ve %18 tasarruf sağlıyordu. Ve altı prompt bir doğruluk benchmark'ı değil, bir akıl sağlığı kontrolü — yazar, FP8 bir ürün için önemliyse gerçek eval'ler çalıştırın diyor. Başarısızlığın bu ROCm imajına mı yoksa daha büyük Qwen2.5 modellerine mi özgü olduğu hâlâ belirsiz.

Neden önemli

Token başına maliyet, sunum yapılandırmalarını karşılaştırmanın varsayılan metriği ve burada daha ucuz bir modelle bozuk bir modeli ayırt edemediği somut bir örnek var; %47'lik rakam basit bir benchmark'tan sorunsuzca geçebilirdi. Yazarın karşı önlemleri ucuz. Ortalama output uzunluğunu ve sınıra takılan istekleri izleyin, çünkü bu veri zaten benchmark çıktısında duruyor. Temperature 0'da birkaç sabit prompt'u okuyun. Küçük bir farkı zafer ilan etmeden önce kendi gürültü tabanızı bilin diye baseline'ı tekrarlayın. Quantization bayraklarıyla, özellikle ROCm donanımında vLLM çalıştıran ekipler için pratik çıkarım şudur: bir maliyet farkına güvenmeden önce output kalitesini doğrulayın ve bu başarısızlık modu anlaşılayana kadar anında dönüştürme yerine önceden quantize edilmiş checkpoint'leri tercih edin. Ölçümler açık kaynaklı bir CLI olan Throttle ile yapıldı; yazar, bir sonraki sürümün çalışma arasında output uzunluğu değiştiğinde CHEAPER yerine OUTPUT CHANGED raporlayacağını söylüyor.