DFloat11: LLM’leri %70 boyuta indiren kayıpsız GPU çıkarım sıkıştırması

• Büyük LLM’leri GPU bellek sınırları nedeniyle dağıtmak zor; DFloat11 ise BFloat16 ağırlıklarını yaklaşık %70 boyuta indirirken özgün modelle bit düzeyinde aynı çıktıyı koruyor
• Temel fikir, BFloat16’nın 8 bitlik exponent alanının gerçekte yalnızca yaklaşık 2,6 bit bilgi taşıması; sign ve mantissa korunuyor, yalnızca exponent Huffman coding ile sıkıştırılıyor
• Dinamik uzunluklu kodlama GPU’da kolayca darboğaz oluşturabildiği için DFloat11, paralel çıkarıma uygun olacak şekilde hiyerarşik LUT, iki aşamalı kernel ve transformer block düzeyinde sıkıştırma açma kullanıyor
• Llama 3.3, Qwen 3, Mistral 3, DeepSeek R1 Distilled, FLUX.1, Stable Diffusion 3.5 gibi modellerde yaklaşık %30 model boyutu azalması ve özgün çıktının korunması doğrulandı
• CPU offload alternatiflerine göre token generation throughput’u 2,3–46,2 kat daha yüksek; 8×80GB GPU’lu tek bir node üzerinde 810GB ölçekli Llama 3.1 405B’nin kayıpsız çıkarımını mümkün kılıyor

---

DFloat11’in hedeflediği bellek darboğazı

• LLM ve Diffusion Model gibi foundation model’lar hızla büyüdüğü için, bellek kısıtlı donanımlarda verimli şekilde dağıtılmaları zorlaşıyor
• Llama 3.1 405B, 405 milyar parametreyi BFloat16 biçiminde saklıyor ve tam çıkarım için yaklaşık 810GB bellek gerektiriyor
  • Bu, 8×80GB GPU’ya sahip tipik üst seviye GPU sunucularının kapasitesini aşıyor
  • Birden fazla node gerektiğinde dağıtım maliyeti ve erişilebilirlik yükü artıyor
• DFloat11, BFloat16 modellerini özgün boyutlarının yaklaşık %70’ine sıkıştırırken, her görevde doğruluğu %100 korumayı hedefliyor

Kayıplı quantization’dan farklı bir yaklaşım

• Quantization, ağırlık hassasiyetini düşürerek belleği azaltan kayıplı bir sıkıştırma yöntemidir
  • Bellek kullanımını büyük ölçüde azaltıp çıkarım hızını artırabilir, ancak yaklaşıklandırma hatası oluşur
  • Doğruluk kaybı temel modele, quantization yöntemine, değerlendirme benchmark’ına ve hedef bit-width’e göre değiştiğinden öngörülmesi zordur
• Örneğin 8-bit SmoothQuant, DeepSeek-R1-Distill-Qwen-1.5B’ye uygulandığında reasoning task ortalama doğruluğu %9,09 düşer
• Genel doğruluk metrikleri benzer olsa bile quantization uygulanmış model, özgün modelden farklı yanıt davranışları gösterebilir
  • Dutta et al., doğru yanıtların yanlışa ya da yanlış yanıtların doğruya dönüştüğü flips olgusunu gözlemledi
  • W8A16 GPTQ ile quantize edilen Qwen2-1.5B’de GSM8K 8-shot doğruluk düşüşü yalnızca %0,3 olsa da yanıtların %6,37’sinde doğru/yanlış durumu değişiyor
• Finans ve sağlık gibi alanlarda quantization uygulanmış modelin çıktı değişiklikleri, regülasyon ve güvenilirlik gereksinimlerini karşılamayı zorlaştırabilir
• Mevcut kayıpsız model sıkıştırma yaklaşımları ağırlıklı olarak checkpoint depolama verimliliğine, model hub indirme süresini kısaltmaya ve FPGA gibi özel donanımlara odaklandığından genel GPU çıkarımında avantajları sınırlıdır

BFloat16 exponent alanında kalan sıkıştırma payı

• BFloat16, 16 biti 1 bit sign, 8 bit exponent, 7 bit mantissa olarak böler
• DFloat11’in çıkış noktası, LLM ağırlıklarının BFloat16 bileşenleri bazında Shannon entropy analizidir
  • sign ve mantissa entropy değerleri kendi bit-width’lerine yakın olduğundan sıkıştırma payı sınırlıdır
  • exponent için 8 bit ayrılmış olsa da entropy yalnızca yaklaşık 2,6 bittir
• Exponent değerlerinin dağılımı oldukça dengesizdir
  • Olası 256 adet 8 bitlik değerden yalnızca yaklaşık 40’ı kullanılır
  • Kalan değerler hiç görülmez
  • Frekans sıralaması da hızla düşer
• Düşük entropy sayesinde exponent kayıpsız sıkıştırma için uygun hâle gelir ve yaklaşık 5,4 bitlik exponent bilgisi sıkıştırılabilir

DFloat11 biçimi

• DFloat11 veya DF11, BFloat16 ağırlıklarının yalnızca exponent kısmını entropy coding ile sıkıştıran dinamik uzunluklu bir kayan nokta biçimidir
• Huffman tree, model ağırlıklarının exponent dağılımına göre oluşturulur
  • Sık görülen exponent değerlerine kısa kodlar atanır
  • Nadir değerlere uzun kodlar verilir
• sign ve mantissa özgün hâliyle korunur
  • exponent, EncodedExponent byte array içinde bit-packed biçimde saklanır
  • sign ve mantissa, PackedSignMantissa byte array içinde ayrı olarak saklanır
• Sonuçta BFloat16 ağırlıkları ortalama yaklaşık 11 bit seviyesine iner ve hassasiyet kaybı olmadan özgün BFloat16 değerlerine geri yüklenebilir

GPU çıkarımına uygun sıkıştırma açma

• Entropy-coded ağırlıklar dinamik uzunluklu kodlama kullandığından matrix multiplication’a doğrudan sokulamaz
  • Gerekli weight matrix anında özgün BFloat16 hâline açılmalıdır
  • Matrix multiplication tamamlanınca BFloat16 matrix, GPU belleğinden tasarruf etmek için hemen atılır
• Genel Huffman decoding bit düzeyinde tree üzerinde sıralı gezinme yaptığı için GPU’nun paralel yapısına uymaz
  • Sıkıştırma açmayı tek bir thread üstlenirse GPU kullanım oranı düşük kalır ve latency artar

Hiyerarşik LUT tabanlı decoding

• DFloat11, Huffman tree üzerinde gezinmek yerine lookup table tabanlı decoding kullanır
• Maksimum Huffman code uzunluğu L ise tek bir LUT için 2^L boyut gerekir
  • LLM’lerde L genellikle 24–32 aralığındadır
  • 2^32 girişlik bir LUT’u GPU SRAM’e koymak zordur
• Bunu önlemek için Huffman tree, yüksekliği 8 olan ve örtüşmeyen subtree’lere bölünür; her subtree 256-entry compact LUT hâline getirilir
• Hiyerarşik LUT’ta bazı girişlerin alt LUT’lara referans görevi görmesi gerekir
  • LLM exponent’larında kullanılmayan çok sayıda değer bulunmasından yararlanılır
  • 240–255 aralığındaki unused exponent değerleri internal pointer olarak yeniden kullanılır
  • Bu değerler ±2^113 ile ±2^128 düzeyinde çok büyük büyüklükleri temsil eder ve LLM ağırlıklarında görülmez
• Deneylerde BFloat16 exponent Huffman tree’nin compact LUT sayısı k, 4–8 aralığındadır
  • CodeLengths ile birlikte en fazla (8 + 1) × 256 bytes bellek kullanır
  • Bu boyut SRAM’e sığar ve tekrarlı lookup işlemlerinin hızlı yapılmasını sağlar

İki aşamalı GPU kernel ve yardımcı metadata

• Her GPU thread’i encoded exponent’ın ardışık n byte’lık bir aralığını üstlenir
  • Deneylerde n = 8 kullanılmıştır
  • Thread, kendi aralığı içinde başlayan Huffman code’ları decode eder
• Dinamik uzunluklu kodlar nedeniyle iki sorun ortaya çıkar
  • Her thread’in tam başlangıç bit konumu net değildir
  • İlk thread dışında decoded element’in çıktı index’ini bilmek zordur
• İlk sorun Gaps dizisiyle çözülür
  • Gaps, thread başına bir girişe sahiptir
  • Her giriş, thread’in başlangıç byte’ına göre ilk valid Huffman code’un bit offset’ini gösterir
  • Maksimum code length 32 bit olduğundan offset [0, 31] aralığındadır ve 5 bit olarak saklanır
• Çıktı konumu sorunu, yalnızca thread block düzeyindeki konum saklanarak bellek overhead’i azaltacak şekilde çözülür
  • Her thread için 32 bit çıktı konumu saklanırsa weight matrix başına on binlerce thread nedeniyle overhead büyür
  • DFloat11, her thread block’un ilk element çıktı konumunu saklar
• Kernel iki aşamada çalışır
  • 1. aşamada her thread kendi aralığını decode eder, yalnızca element sayısını sayar ve HBM’e yazmaz
  • Block içindeki thread’ler Blelloch algorithm ile prefix sum yaparak thread başına çıktı konumunu hesaplar
  • 2. aşamada aynı aralık yeniden decode edilir ve hesaplanan konuma göre decoded değerler SRAM write buffer’a yazılır
  • Encoded exponent, ilk pass öncesinde SRAM’e yüklenerek tekrarlı global memory access önlenir
  • Tüm decoded exponent’lar SRAM’e yazıldıktan sonra HBM’e tek seferlik coalesced write yapılır

Transformer block düzeyinde sıkıştırma açma

• Tek bir weight matrix’in sıkıştırmasını açmak, boyutu küçük olduğundan GPU kaynaklarını yeterince kullanamayabilir
• Matrix boyutu büyüdükçe DFloat11’in sıkıştırma açma throughput’u iyileşir
• Birden fazla matrix birlikte açılarak throughput artırılır ve latency gizlenir
  • Bir transformer block içindeki tüm DFloat11 weight matrix’ler tek bir batch olarak açılır
  • Bu batched decompression, ilgili transformer block’un forward pass’inden hemen önce yapılır
• LLM’in token embedding ve language modeling head’i de sıkıştırma kapsamındadır
  • Bu matrix’ler GPU kaynaklarını doyuracak kadar büyük olduğundan ayrıca batching gerekmez

Değerlendirme sonuçları ve pratik etkisi

• DFloat11, Llama 3, Qwen 3, Mistral 3, DeepSeek R1 Distilled, FLUX.1, Stable Diffusion 3.5 dahil LLM’ler ve diffusion transformer’lar üzerinde değerlendirildi
• Sonuçlar yaklaşık %30 model boyutu azalması ve özgün çıktının tamamen korunduğunu gösteriyor
  • Çıktı, özgün modelle bit-for-bit aynıdır
  • Kayıplı sıkıştırma olmadığı için özgün BFloat16 ağırlık hassasiyeti korunur
• Bellek kısıtlarını karşılamak için sıkıştırılmamış modelin bir kısmını CPU’ya offload eden alternatiflerle karşılaştırıldığında DFloat11, token generation’da 2,3–46,2 kat daha yüksek throughput’a ulaşıyor
• Sabit GPU bellek bütçesinde, sıkıştırılmamış modele göre 5,7–14,9 kat daha uzun generation length’i mümkün kılıyor
• Llama 3.1 405B, 810GB ölçekli bir model olsa da DFloat11, 8×80GB A100 GPU’lu tek bir node üzerinde kayıpsız çıkarımı mümkün kılıyor
• Bu sonuç, Llama-3.1-405B çalıştırmak için gereken donanım gereksinimini yarıya indirirken accuracy loss olmadan çıkarım yapılabileceğini gösteriyor