NVIDIA H100 80GB GPU üzerinde 4 hassasiyet seviyesinde (BF16, FP8, GPTQ-Int8, GPTQ-Int4) Qwen3-32B'yi kıyasladık. Her yapılandırma, bilgi ve kod üretimi konularını kapsayan 2 kıyaslama testi (~12.2K soru) ve verimliliği ölçmek için 2.000'den fazla çıkarım çalıştırması üzerinde değerlendirildi. Int4, MMLU-Pro'da 2 puandan daha az kayıp yaşarken BF16'dan 2,7 kat daha hızlıdır, ancak kod üretimi (HumanEval) 8 puan düşüş gösterir.
Nicelleştirme kıyaslama sonuçları
MMLU-Pro, 14 alanda geniş kapsamlı mantıksal düşünmeyi test eder (~12.000 soru, 5 aşamalı). Bu, 4 yerine 10 seçenekli sorular içeren MMLU'nun daha zor versiyonudur.
HumanEval, kod üretimini test eder (164 problem, 1 başarılı sonuç). Model, birim testlerine karşı çalışan Python fonksiyonları yazar. Bu, çıktının sadece puanlanmadığı, aynı zamanda yürütüldüğü tek kıyaslama testidir.
Verim, 1'lik parti boyutuyla saniyede üretilen belirteç sayısıdır.
Model boyutu, yalnızca ağırlıkların yüklenmesinden sonra ölçülen, GPU belleğinde tüketilen bellek miktarıdır.
MMLU-Pro'nun kategoriye göre dağılımı
Mühendislik ve hukuk alanlarında Int4'te en büyük düşüşler gözlemleniyor. Matematik ise tüm hassasiyet seviyelerinde istikrarlı kalıyor.
Bellek kapasitesi ve eşzamanlılık
Nvidia-smi gibi GPU izleme araçları, vLLM'nin mevcut tüm belleği önceden tahsis etmesi nedeniyle model boyutundan bağımsız olarak neredeyse tam kullanım bildirmektedir. Asıl soru, bu belleğin model ağırlıkları ve KV önbelleği arasında nasıl bölündüğüdür, çünkü KV önbelleği aynı anda kaç kullanıcıya hizmet verebileceğinizi belirler.
Maksimum kullanıcı sayısı, bellek yetersizliğinden (OOM) önce ulaşılabilecek maksimum değerdir: toplam belirteç kapasitesinin kullanıcı başına bağlam uzunluğuna bölünmesiyle elde edilir. Bu teorik maksimum değerdir. Pratikte, zamanlama yükü bu değeri biraz azaltır.
Bu durum, akıl yürütme modelleri için doğrudan sonuçlar doğurmaktadır. DeepSeek-R1 ve Qwen-QwQ, nihai bir yanıt üretmeden önce binlerce dahili "düşünce" belirteci (genellikle 2K-5K) üretir. BF16'da, tek bir akıl yürütme isteği, 17K belirteç kapasitesinin tamamını tüketerek ikinci bir kullanıcının engellenmesine neden olabiliyordu. Int4'te ise 193K kapasite, birden fazla eş zamanlı akıl yürütme oturumuna olanak tanır.
Temel bulgular
FP8 ölçülebilir bir doğruluk kaybına uğramaz.
FP8, MMLU-Pro'da %69,64, BF16 ise %70,24 puan alarak 12.000 soru üzerinden 0,6 puanlık bir fark yakalamıştır. HumanEval'da ise hem FP8 hem de BF16 aynı puanı alarak %39,02'lik bir başarı elde etmiştir. FP8, 0,6 puanlık bir maliyetle 1,5 kat daha yüksek verimlilik sağlarken model boyutunu yarıya indirir.
GPTQ-Int8, MMLU-Pro'da %70,32 puan alırken HumanEval'de 1,8 puan düşüş göstererek %37,20'ye ulaşıyor. Kod üretimi önemliyse, FP8 daha güvenli bir seçimdir.
Int4, bilgi üretiminden ziyade kod üretimini daha fazla bozuyor.
MMLU-Pro, Int4'te 1,6 puan düşüş gösterdi (%70,24'ten %68,66'ya). HumanEval ise 8 puan düşüş gösterdi (%39,02'den %31,10'a). Kod üretimi, küçük ağırlık hatalarının fonksiyon gövdeleri boyunca birikerek büyüdüğü hassas belirteç tahminleri gerektirir.
Asıl kazanım hız değil, eşzamanlılıktır.
Int4, BF16'dan 2,7 kat daha hızlı. Ancak asıl etki bellekte. BF16, KV önbelleği için yalnızca 4,4 GB alan bırakıyor; bu da 4K bağlamda yaklaşık 4 eş zamanlı kullanıcı için yeterli. Int4 ise 47,3 GB alan açarak 47 kullanıcı için yeterli alan sağlıyor; bu da aynı GPU'dan 12 kat daha fazla hizmet kapasitesi anlamına geliyor.
Matematik puanları tüm hassasiyet seviyelerinde geçerlidir.
Matematik puanlarında neredeyse hiç değişiklik yok: BF16'da %81,87, FP8'de %81,87, Int8'de %81,87, Int4'te %80,24. Mühendislik (%49,64'ten %43,45'e) ve hukuk (%43,05'ten %40,60'a) daha hassas.
Jeton başına maliyet
RunPod'da H100 SXM fiyatlandırmasını (saatlik 2,69 $) 1'lik parti boyutu için kullanarak:
Bu rakamlar tek kullanıcılı, gerçek zamanlı üretimi yansıtmaktadır. Toplu işlem, maliyeti daha da düşürmektedir.
LLM nicelleştirme kıyaslama metodolojisi
Çevre
- GPU: Tek NVIDIA H100 80GB HBM3 (SXM) RunPod üzerinden ($2,69/saat)
- Yazılım: vLLM 0.17.0, lm-evaluation-harness 0.4.11, PyTorch 2.8.0, CUDA 12.8, Python 3.11
- Model: Qwen3-32B (eğitim sonrası/talimatlara göre ayarlanmış) HuggingFace'den. İnce ayar uygulanmadı.
Doğruluk değerlendirmesi
- Tüm değerlendirmeler
lm-evaluation-harnessvebatch_size="auto"aracılığıyla yürütülmektedir. - Her görev ayrı bir alt işlemde çalışır. Model her seferinde yeniden yüklenir ve GPU görevler arasında tamamen temizlenir. Bu, bellek parçalanmasından kaynaklanan bellek yetersizliği hatasını (OOM) önler.
- HumanEval,
HF_ALLOW_CODE_EVAL=1ile çalışıyor (kod yürütme etkinleştirildi). - MMLU-Pro sonuçları, kategori bazında (biyoloji, matematik, fizik, hukuk vb.) ayrıntılı döküm içermektedir.
- Qwen3'ün düşünme modu değerlendirmeler sırasında aktif değildi. lm-evaluation-harness, modelin sohbet şablonunu (varsayılan olarak
apply_chat_template=False) uygulamadan ham biçimlendirilmiş istemler gönderir, bu nedenle<think>belirteci asla eklenmez.
Performans değerlendirmesi
- Farklı alanlarda (bilim, kodlama, genel kültür) dönüşümlü olarak sunulan 5 soru.
- 10 ısınma yinelemesi (ölçülmedi), ardından 500 ölçülü yineleme.
- Düzeltilmiş çıktı:
max_tokens=256, temperature=0.7, top_p=0.9, batch_size=1 - Ölçümler: işlem hızı (token/saniye), GPU bellek kullanımı (GB)
Hassasiyet başına vLLM yapılandırması
Tüm hassasiyetler gpu_memory_utilization=0.90, max_model_len=4096 kullanır.
Bölünmüş süreç mimarisi
Bellek yetersizliğini önlemek için her kıyaslama testi iki ayrı işlem olarak çalıştırılır:
- Adım 1: Modeli yükleyin, ısınma işlemini gerçekleştirin, verimliliği ölçün, geçici dosyaya kaydedin, çıkın.
- Temizleme: vLLM ve Ray işlemlerini zorla sonlandırın, 10 saniye bekleyin.
- Adım 2: Modeli yeniden yükleyin, her değerlendirme görevini ayrı bir alt işlemde çalıştırın, 1. adımdaki ölçümlerle birleştirin ve son JSON dosyasını kaydedin.
Kontrollü değişkenler
Dış etkenleri ortadan kaldırmak için, tüm çalıştırmalarda aşağıdaki parametreler sabit tutuldu:
Test istemleri
5 test sorusu:
- “Görelilik kuramını basit terimlerle açıklayın.” (Bilim/Özet)
- “En uzun palindromik alt diziyi bulan bir Python fonksiyonu yazın.” (Kodlama)
- “İklim değişikliğinin başlıca nedenleri ve etkileri nelerdir?” (Karmaşık Akıl Yürütme)
- “Fotosentez sürecini adım adım açıklayın.” (Süreç Açıklaması)
- “Sinir ağı verilerden nasıl öğrenir?” (Teknik Açıklama)
Veri doğrulama: vLLM çalışma zamanı telemetrisi
Bu makaledeki bellek ve eşzamanlılık rakamları, kıyaslama testi yürütülmesi sırasında vLLM motorunun başlatma günlüklerinden doğrudan elde edilmiştir.
BF16 başlatma:
GPTQ-Int4 başlatma:
Sınırlamalar
Tüm testlerde batch boyutu 1 kullanılmıştır. Yüksek işlem hacmi gerektiren senaryolarda , bellek bant genişliği doygunluğu baskın darboğaz haline geldiği için Int4 ve BF16 arasındaki performans farkı genişlemektedir.
Sonuçlar H100 SXM'ye özgüdür. Daha eski GPU'larda (A100, A10) yerel FP8 desteği bulunmamaktadır. Tüketici GPU'larının (RTX 4090) bellek bant genişliği özellikleri farklıdır.
GPTQ modelleri (JunHowie), topluluk tarafından sağlanan nicelleştirmelerdir. Resmi sürümler, doğruluğu etkileyebilecek farklı kalibrasyon veri kümeleri veya parametreler kullanabilir.
Biz sadece GPTQ'yu test ettik. Diğer niceleme yöntemleri (AWQ, BitsAndBytes NF4, GGUF, HQQ) farklı avantaj ve dezavantajlar sunabilir.
Çözüm
H100 üzerinde Qwen3-32B için varsayılan seçenek FP8'dir. Bu sayede 1,5 kat daha yüksek işlem hızı, yarı yarıya daha az bellek kullanımı ve 0,6 puanlık doğruluk kaybı elde edersiniz.
Maksimum verim veya eşzamanlılık gerektiğinde Int4 mantıklıdır: MMLU-Pro'da 1,6 puan ve HumanEval'de 8 puanlık bir kayıp karşılığında 2,7 kat daha hızlı, 12 kat daha fazla eşzamanlılık sağlar.
Int8 ortada yer alıyor ve bu kurulumda FP8'e göre belirgin bir avantaj sunmuyor. FP8'e göre verimlilik artışı küçük (43,3'e karşı 37,9 tok/s) ve doğruluk karşılaştırılabilir düzeyde. FP8 daha basittir çünkü model yazarları tarafından resmi olarak sağlanmaktadır ve üçüncü taraf bir nicelleştirilmiş kontrol noktası gerektirmez.
Nicelleştirmenin en büyük pratik etkisi hız değil, eşzamanlılıktır. BF16, tek bir H100 üzerinde 4K bağlamda 4 kullanıcıya hizmet verebilir. Int4 ise 47 kullanıcıya hizmet verebilir. Saatte 2,69$ maliyetle, 1 milyon token başına maliyet 28,73$'dan 10,69$'a düşüyor.
Yorum yapan ilk kişi olun
E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir.