AIREITERvLLM Humming, Hopper sınıfı donanımlarda yüksek eşzamanlılıklı kuantize MoE sunumu için güçlü bir aday. Ancak herkese uygun, doğrudan bir backend yükseltmesi olarak görülmesini sağlayacak kadar genel bir kıyaslama kanıtı yok. H100 üzerinde group-32 ölçekleme ve Ampere’de batch-1 decode sonuçları, modelin, GPU’nun, formatın ve batch şeklinin mutlaka ayrı ayrı test edilmesi gerektiğini gösteriyor.
Kısa cevap: Humming koşula bağlı bir yükseltme
Humming, kuantize çıkarım için JIT derlenen GEMM kernel’larından oluşan bir kütüphane. vLLM topluluğu tarafından Ant Group ile birlikte geliştirilen proje, farklı kuantizasyon formatlarında ve NVIDIA GPU nesillerinde hem yoğun hem de mixture-of-experts (MoE) iş yüklerini hedefliyor. Resmi duyuruda kernel hızlanmasının 5 kata, seçili uçtan uca MoE kazanımlarının ise %14–%43’e kadar çıkabildiği belirtiliyor. Ancak bu sonuçlar belirli model, donanım, format ve eşzamanlılık kombinasyonlarından elde ediliyor (vLLM duyurusu).
Benim geçiş kuralım basit:
- Önce Humming’i test edin: Desteklenen Hopper veya daha yeni yapılandırmalarda, büyük batch ya da yüksek eşzamanlılıklı W4A8/W4A16 MoE sunumu için ilk adayınız Humming olsun.
- Otomatik olarak kazanım beklemeyin: Batch-1 decode, eski Ampere GPU’ları veya alışılmadık group-wise ölçekleme senaryolarında sonuç garanti değil.
- Bir geri dönüş yolu bırakın: Güncel issue kayıtlarında şekil yönlendirme hataları ve backend’e özgü yavaş yollar raporlanıyor.
Bağımsız bir DeepSeek-V4.1-Flash raporunda, tek bir dört-GH200 düğümünde ayarlanmış vLLM baseline’ı 5.856 çıktı token/s, data-parallel attention 12.802 ve değiştirilmiş Humming W4A8 kernel’ları 17.634 çıktı token/s seviyesine ulaştı (mühendislik raporu). Ancak bu sonuç için hem kernel hem de tuning düzeltmesi gerekti. Dolayısıyla bu veri, belirli bir iş yükü sınıfı için kanıt niteliğinde; kutudan çıkar çıkmaz elde edilecek bir sonuç vaadi değil.
Humming, vLLM dağıtımında neyi değiştiriyor?
Humming, kuantize matris çarpımını yoğun ve MoE GEMM yolları için esnek bir JIT kernel katmanına taşıyor. Proje, Turing’den itibaren NVIDIA mimarilerini ve çeşitli düşük bitli formatları hedefliyor (Humming deposu).
Alıntılanan Hopper testinde Marlin, FP4 ağırlıkları BF16’ya dönüştürürken Humming, FP4 ağırlıkları SM içinde FP8’e yükseltti ve FP8 tensor core çarpımı kullandı. Bu fark, ancak decode iş yükü hesaplama sınırlı hâle geldikten sonra fayda sağladı. Bunun dışındaki durumlarda bellek trafiği, şekil döşemesi, scale işlemleri, kernel başlatma maliyeti ve register baskısı sonucu belirleyebilir.
Hız artışı nerede gerçek, nerede ortadan kalkıyor?
Herkese uygulanabilecek tek bir yüzde vermek yerine, mevcut verileri performans sınırlarını gösteren bir harita olarak okumak daha doğru.
Yüksek eşzamanlılıklı MoE: En net kazanım
Resmi DeepSeek-V4.1-Flash örneği, sekiz H20 GPU üzerinde Marlin W4A16 ile Humming W4A8’i karşılaştırıyor ve uçtan uca MoE throughput’unda %14–%43 artış bildiriyor. Daha yüksek eşzamanlılıkta kazanım da büyüyor. Benchmark’ı yeniden paylaşan bir kullanıcı, eşzamanlılık 64’te sonucu 442’ye karşı 634 çıktı token/s olarak verdi; ancak kuantizasyon formatının da değiştiğini belirtti (kullanıcı tartışması).
Bu sonuç, Humming’in umut vadeden bir sunum yolu olduğunu gösteriyor; aynı formatta çalışan bir kernel’in her durumda aynı oranda hızlanacağı anlamına gelmiyor.
H100’de group-32 W4A8: Ciddi bir uyarı
Humming issue #38, H100 üzerinde MXFP4 ağırlıkları, MXFP8 aktivasyonları ve group-32 scale değerlerini test etti. Karşılaştırılan tüm yollar sayısal olarak doğru sonuç verdi; ancak raporlanan şekillerde fused yol belirgin biçimde daha yavaştı. (4096,3072,4096) şeklinde fused Humming 4.969 ms sürerken QDQ baseline’ı 0.580 ms’de kaldı. (4096,14336,4096) şeklinde ise sonuçlar sırasıyla 22.298 ms ve 1.256 ms oldu (issue #38).
Issue kaydında daha sonra yerel tuning ile 500 TFLOPS’un üzerine çıkıldığı, deneysel bir uygulamanın ise ek preprocessing ve ağırlık depolama kullanarak yaklaşık 580–665 TFLOPS seviyesine ulaştığı belirtildi. Yani scale ayrıntı seviyesi, tile seçimi, register baskısı ve preprocessing sonucu tamamen değiştirebilir.
SM80’de tek istekli decode: Ampere kazanımı varsaymayın
Issue #72, NVIDIA SM80 üzerinde M=1 decode sırasında INT3 kullanımının zayıf kaldığını bildiriyor. CMP 170HX üzerinde ölçülen Humming kernel’ı yaklaşık 691 GB/s değerine ulaştı; bu, yaklaşık 1.591 GB/s olan tepe HBM bant genişliğinin %43,4’üne denk geliyor. Karşılaştırılan RTX 5070 Ti SM120 çalışması ise yaklaşık 827 GB/s tepe değere karşı 753 GB/s seviyesine, yani yaklaşık %91 kullanıma ulaştı (issue #72).
Aynı rapor, A800 için depo sonuçlarını da paylaşıyor: M=1 değerinde 692,4 GB/s; bu, belirtilen 2.039,04 GB/s tepe bant genişliğinin yalnızca %34,0’ı. Aynı karşılaştırmada düz BF16 1.232,3 GB/s seviyesine ulaştı.
“Mevcut SM80 INT3 Humming yolu bu iş yükü için verimsiz olabilir mi?” —
yangfangyunyun, vLLM Humming issue #72
Kurulum ve en güvenli ilk test
Resmi materyaller, CUDA kurulumlarında Humming’in bağımlılık olarak yer aldığı sürüm noktası şeklinde vLLM 0.29.0’ı gösteriyor. MoE yolu için --moe-backend humming, desteklenen linear katmanlar için --linear-backend humming veya modelin ihtiyaçlarına göre belgelenen Humming kuantizasyon yapılandırmasını kullanabilirsiniz (vLLM kuantizasyon belgeleri). Bir mimarideki flag’i başka bir mimariye taşımadan önce sürüm ve model belgelerini kontrol edin.
İlk adımda kontrollü bir test yapın:
- vLLM, CUDA, PyTorch, GPU mimarisi, checkpoint kuantizasyonu ve model şeklini kaydedin.
- Prompt uzunluğunu, çıktı uzunluğunu, eşzamanlılık düzeyini ve tekrar sayısını sabit tutun.
- Mevcut backend’i, aynı sunum komutuna ilgili backend flag’ini ekleyerek Humming ile karşılaştırın.
- Çıktı token/s, TTFT, token’lar arası gecikme, GPU belleği ve başlangıç/JIT ısınma süresini ölçün.
- Kernel cache ısındıktan sonra testi tekrarlayın; ardından batch 1’i ve üretim eşzamanlılığını ayrıca ölçün.
- Desteklenmeyen şekiller ve başarısız seçim durumları için otomatik veya manuel bir geri dönüş yolu bırakın.
TTFT, kuyruk gecikmesi, ısınma maliyeti veya bellek kullanımı kötüleşiyorsa yalnızca throughput artışı yeterli değildir. vLLM’nin perf-eval projesi, karşılaştırılabilir testler için YAML tarifleri, tekrarlı çalıştırmalar, medyan değerlerin birleştirilmesi ve sabit giriş/çıkış uzunlukları öneriyor (perf-eval deposu).
Backend yönlendirmesi, geçerli bir Humming yapılandırmasını engelleyebilir
Ayrı bir vLLM issue kaydı, fallback testlerinin neden önemli olduğunu gösteriyor. Issue #60700’da compressed-tensors W4A8 MoE checkpoint’inin ara boyutu 640’tı. CUTLASS, boyutların 256 ile hizalanmasını gerektirirken Humming test edilen şekli işleyebiliyordu; ancak seçilen backend yüklenmeden önce koşulsuz bir assertion çalışıyordu. Bu nedenle açıkça --moe-backend humming kullanmak da başarısız oldu.
Raporlayan kişinin yaması assertion’ı yalnızca CUTLASS için çalışacak şekilde sınırlandırdı. Bu değişiklikle iki H100 NVL GPU üzerinde 62 shard’ın tamamı yüklendi. Test ayrıca referans CUTLASS yapılandırmasına kıyasla %12–%50 daha düşük TTFT ve %2–%13 daha yüksek sistem throughput’u bildirdi (issue #60700). Kontrol edildiği sırada issue hâlâ açıktı ve yönlendirme düzeltmesi olarak PR #60711 önerilmişti.
Dolayısıyla başarısız bir Humming başlatma denemesi kernel sorunundan değil, vLLM’nin yetenek kontrolünden kaynaklanabilir. Yapılandırmayı tamamen elemeden önce seçilen backend’i, şekil kısıtlamalarını ve düzeltmenin durumunu kontrol edin.
Operatörler için karar tablosu
| İş yükünüz | Humming kararı | Neden |
|---|---|---|
| Hopper/GH200 üzerinde yüksek eşzamanlılıklı MoE | Erken test edin | Bağımsız bir sunum çalışması, düzeltmeler ve tuning sonrasında 17.634 tok/s seviyesine ulaştı. |
| Büyük batch’lerle DeepSeek tarzı decode | Güçlü aday | FP8 tensor core çalıştırması, MoE GEMM’leri hesaplama sınırlı hâle geldiğinde fayda sağlayabilir. |
| SM80 üzerinde batch-1 veya düşük batch’li decode | Kazanım varsaymayın | Issue #72, test edilen INT3 yollarında %34–%43 efektif bant genişliği bildiriyor. |
| H100 üzerinde group-32 aktivasyon ölçekleme | Dar bir şekil matrisiyle benchmark yapın | Issue #38, tek bir fused yolda ciddi gerilemeler olduğunu gösteriyor. |
| 256 ile hizalanmayan W4A8 MoE şekilleri | vLLM sürümünü ve yönlendirme düzeltmelerini kontrol edin | Ortak assertion’lar, ağırlıklar yüklenmeden önce Humming’i engelleyebilir. |
| Kaynak kodu yaması için bütçe olmayan üretim ortamı | Yalnızca temsili bir karşılaştırmadan sonra kullanın | Bazı bağımsız kazanımlar için kernel veya heuristic değişiklikleri gerekti. |
Sık sorulan sorular
Humming hangi GPU’ları destekliyor?
Proje, Turing’den itibaren NVIDIA GPU’larını ve birden fazla kuantizasyon yolunu hedefliyor. Ancak desteklenmek, her formatın ve iş yükünün aynı ölçüde optimize edildiği anlamına gelmiyor. SM80 ve alışılmadık ölçekleme senaryoları için ayrıca benchmark yapmanız gerekir.
Humming, önceden kuantize edilmiş bir checkpoint gerektiriyor mu?
Humming genel amaçlı bir kuantizer değil, çıkarım kernel’larından oluşan bir kütüphane. Buradaki iş akışlarında uyumlu kuantize ağırlıklara ve aktivasyon şemalarına sahip checkpoint’ler kullanılıyor. Sunuma geçmeden önce modelin formatını vLLM belgelerinden ve depodan doğrulayın.
Humming, diğer tüm vLLM backend’lerinden daha mı hızlı?
Hayır. Humming, özellikle raporlanan yüksek eşzamanlılıklı MoE senaryoları gibi seçili kuantize iş yüklerinde daha hızlı. Sonuçlar mimariye, formata, boyutlara, scale gruplamasına ve batch boyutuna göre değişiyor.
Pratik denge net: Humming, doğru eşleşmiş kuantize bir vLLM servisini ciddi ölçüde hızlandırabilir. Ancak herkese açık sonuçlar yapılandırmaya özel olduğu için, kısa ve tekrarlanabilir bir karşılaştırma testi bu geçişin ayrılmaz parçası olmalı.