DeepGEMM: İnce ölçeklendirmeyle temiz ve verimli FP8 GEMM çekirdekleri

 (github.com/deepseek-ai)
2 puan yazan GN⁺ 2025-02-27 | 1 yorum | WhatsApp'ta paylaş
  • DeepGEMM, modern LLM'lerin temel hesaplama primitifi olan GEMM, fused MoE, MQA scoring, HyperConnection gibi bileşenleri tek bir CUDA codebase içinde birleştiren yüksek performanslı bir tensor core kernel kütüphanesidir
  • Tüm kernel'ler hafif bir JIT modülü olarak çalışma zamanında derlenir; kurulum sırasında CUDA derlemesi gerektirmez ve C++20, CUDA Toolkit, PyTorch, CUTLASS 4.0 veya üzerini ister
  • CUTLASS ve CuTe'nin bazı kavramlarından yararlanır, ancak template'lere ve cebirsel yapılara ağır biçimde dayanmaz; sınırlı sayıda temel kernel fonksiyonuyla NVIDIA GPU kernel optimizasyonu öğrenimini erişilebilir kılacak şekilde tasarlanmıştır
  • Destek kapsamı FP8, FP4, BF16 GEMM, grouped GEMM, DeepSeek v3.2 için MQA logits kernel'leri ve iletişim ile hesaplamayı örtüştüren Mega MoE'ye kadar uzanır; SM90 ve SM100'de bellek yerleşimi kısıtları farklıdır
  • Hafif tasarımına rağmen çeşitli matris shape'lerinde uzman ayarlı kütüphanelerle aynı ya da daha yüksek performansı hedefler; H800'de 1550 TFLOPS'a kadar ulaşan güncellemeler içerir

DeepGEMM'in amacı ve tasarımı

  • DeepGEMM, en yeni büyük dil modellerinde kullanılan başlıca hesaplama primitiflerini tek bir CUDA codebase'de birleştiren bir tensor core kernel kütüphanesidir
    • GEMM: FP8, FP4, BF16
    • İletişimi örtüştüren fused MoE: Mega MoE
    • lightning indexer için MQA scoring
    • HyperConnection(HC)
  • Tüm kernel'ler hafif bir Just-In-Time(JIT) modülü olarak çalışma zamanında derlenir
    • Kurulum sürecinde CUDA derlemesi gerekmez
  • CUTLASS ve CuTe'nin bazı kavramlarından yararlanır
    • Ancak ağır template'lere veya cebirsel yapılara büyük ölçüde bağımlı değildir
    • Temel kernel fonksiyonlarının sayısını sınırlayarak codebase'i basit tutar
  • Hafif tasarımına rağmen çeşitli matris shape'lerinde uzman ayarlı kütüphanelerle denk veya daha yüksek performans sunduğunu belirtir

Başlıca güncellemeler

  • 16 Nisan 2026 güncellemesi Mega MoE, FP8xFP4 GEMM, FP4 Indexer, PDL, daha hızlı JIT derleme gibi özellikleri içerir
    • Ayrıntılar #304
    • Mega MoE benchmark'ı #316
  • 28 Eylül 2025 güncellemesi DeepSeek v3.2 lightning indexer için weighted ReLU MQA logits scoring kernel'ini ekler
  • 20 Temmuz 2025 güncellemesi hem SM90 hem SM100 desteği sağlar ve düşük CPU overhead'li JIT CPP modülüyle tamamen refactor edilmiştir
    • NVRTC ve derleme sonrası SASS optimizasyonu devre dışı bırakılmıştır
    • NVRTC daha sonra desteklenecek olarak işaretlenmiştir
    • NVCC 12.9 FFMA interleaving'i otomatik yaptığı için derleme sonrası optimizasyon artık desteklenmez
    • Ayrıntılar #112
  • 14 Mayıs 2025 güncellemesi dense ve MoE backward için weight gradient kernel'lerini ekler
    • Ayrıntılar #95
  • 7 Mayıs 2025 güncellemesi NVRTC desteğiyle derlemede 10 kata kadar hızlanma sağlar
    • DG_JIT_USE_NVRTC=1 ile etkinleştirilebilir
    • Bazı durumlarda performans kaybı olabilir
    • Ayrıntılar #94
  • 18 Nisan 2025 güncellemesi H800'de 1550 TFLOPS'a kadar ulaşır

Gereksinimler ve kurulum akışı

  • Çalışma ortamı NVIDIA SM90 veya SM100 mimarili GPU gerektirir
  • Yazılım gereksinimleri şunlardır
    • Python 3.8 veya üzeri
    • C++20 destekli derleyici
    • CUDA Toolkit
      • SM90: CUDA 12.3 veya üzeri
      • En iyi performans için CUDA 12.9 veya üzeri güçlü biçimde önerilir
      • SM100: CUDA 12.9 veya üzeri
    • PyTorch 2.1 veya üzeri
    • CUTLASS 4.0 veya üzeri
    • {fmt} kütüphanesi
  • Geliştirme ortamında repository submodule'lerle birlikte clone edildikten sonra develop.sh ile gerekli include bağlantıları ve CPP JIT modülü build edilir
  • Kurulum, install.sh çalıştırıldıktan sonra Python projesinde deep_gemm import edilerek yapılır

GEMM arayüzü ve yerleşim kısıtları

  • DeepGEMM'in GEMM kernel adlandırma kuralı D = C + A @ B şeklindedir
  • Girdi shape yerleşimi NT temel alınarak yapılır
    • fp8_gemm_nt, D = C + A @ B.T işlemini gerçekleştirir
  • SM90 implementasyonu yalnızca NT bellek yerleşimini destekler
    • row-major, col-major kombinasyonuna karşılık gelir
  • SM100 implementasyonu NT, TN, NN, TT bellek yerleşimlerinin tamamını destekler
  • Her iki mimaride de LHS scaling factor, TMA hizalı ve transpose edilmiş yerleşimde olmalıdır
    • SM90 scaling factor'ı FP32 formatında ister
    • SM100 packed UE8M0 formatını ister ve 4 UE8M0 değerini tek bir torch.int içine pack eder
  • Girdi transpose'u veya FP8 casting gibi işlemler kullanıcı tarafından ayrıca ele alınmalıdır
    • Kütüphane basit PyTorch yardımcı fonksiyonları sağlar, ancak performansları yavaş olabilir
    • Ana odak GEMM kernel optimizasyonudur

Dense ve Grouped GEMM

  • Temel non-grouped FP8 GEMM, fp8_gemm_{nt, nn, tn, tt} fonksiyonlarını kullanır
  • contiguous layout'taki grouped GEMM, CUTLASS'in geleneksel grouped GEMM'inden farklı olarak yalnızca M ekseninde gruplama yapar
    • N ve K sabit olmalıdır
    • MoE modellerinde expert'lerin aynı shape'i paylaştığı durumlara uygun bir tasarımdır
  • Eğitim forward pass'i veya inference prefilling sırasında her expert'in işlediği token sayısı farklı olabilir
    • Bu token'ların tek bir tensor halinde ardışık eklenmiş biçimine contiguous layout denir
    • Her expert segment'i GEMM M block size'a hizalanmalıdır
    • Hizalama ölçütü get_mk_alignment_for_contiguous_layout() ile kontrol edilir
  • MoE weight backward için K ekseni grouped API de sunulur
    • M ve N sabit olmalıdır
    • İlgili fonksiyon k_grouped_fp8_gemm_tn_contiguous
  • Inference decoding aşamasında CUDA graph açıkken ve CPU expert başına token sayısını bilemediğinde masked grouped GEMM desteklenir
    • Mask tensor'ı sağlanırsa kernel yalnızca geçerli alanları hesaplar
    • Fonksiyon m_grouped_fp8_gemm_nt_masked
    • DeepEP'nin low-latency kernel çıktısını girdi olarak kullanan bir örnek vardır

DeepSeek v3.2 Indexer için MQA kernel'leri

  • V3.2 MQA kernel ailesi non-paged ve paged sürümler sunar
    • non-paged prefilling içindir
    • paged decoding içindir
  • fp8_mqa_logits 6 girdi alır
    • q: E4M3 tensor, shape [seq_len, num_heads, head_dim]
    • kv: E4M3 tensor ve float scaling factor
      • tensor shape'i [seq_len_kv, head_dim]
      • scaling factor shape'i [seq_len_kv]
    • weights: float tensor, shape [seq_len, num_heads]
    • cu_seq_len_k_start, cu_seq_len_k_end: int tensor, shape [seq_len]
    • clean_logits: doldurulmamış logits'lerin -inf ile temizlenip temizlenmeyeceği
  • Çıktı tensor shape'i [seq_len, seq_len_kv] olup token-to-token logits'i temsil eder
  • Her q token'ı i, cu_seq_len_k_start[i]'den cu_seq_len_k_end[i] öncesine kadar kv token'ı j üzerinde dolaşır
    • kv_j ile scaling factor çarpılır
    • q[i, :, :] @ kv_j ile head başına değerler hesaplanır
    • ReLU uygulandıktan sonra weights[i, :] ile çarpılıp toplanarak scalar logit oluşturulur
  • Paged sürüm fonksiyonu fp8_paged_mqa_logits'tir

Mega MoE

  • Mega MoE, birden çok MoE adımını tek bir mega-kernel içinde fuse eder
    • EP dispatch
    • linear 1, FP8xFP4
    • SwiGLU
    • linear 2, FP8xFP4
    • EP combine
  • Mega MoE, NVLink iletişimi ile tensor core hesaplamasını overlap eder
  • Çalıştırmak için symmetric memory kullanan multi-process launch gerekir
  • Kullanım akışı şöyledir
    • deep_gemm.get_symm_buffer_for_mega_moe ile symmetric memory buffer allocate edilir
      • PyTorch 2.9 veya üzeri gerekir
    • deep_gemm.transform_weights_for_mega_moe ile FP4 ve UE8M0 SF içeren weight'ler gerekli yerleşime dönüştürülür
    • Çağrıdan önce girdi, scaling factor, top-k index ve top-k weight buffer'a kopyalanır
    • deep_gemm.fp8_fp4_mega_moe ile fused mega MoE kernel'i çalıştırılır
  • Tam multi-process kurulum ve benchmark örnekleri tests/test_mega_moe.py içindedir

Yardımcı fonksiyonlar ve ortam değişkenleri

  • Başlıca yardımcı fonksiyonlar yürütme kaynaklarını, hizalamayı, JIT derlemeyi ve scaling factor dönüşümünü kontrol eder
    • deep_gemm.set_num_sms / get_num_sms: kullanılacak maksimum SM sayısını ayarlama ve sorgulama
    • deep_gemm.set_tc_util / get_tc_util: yaklaşık tensor core utilization ratio değerini ayarlama ve sorgulama
    • deep_gemm.set_pdl / get_pdl: Programmatic Dependent Launch(PDL) etkinleştirme ve devre dışı bırakma
    • deep_gemm.set_mk_alignment_for_contiguous_layout / get_mk_alignment_for_contiguous_layout: contiguous layout'un group-level M/K alignment değerini ayarlama ve sorgulama
    • deep_gemm.transform_sf_into_required_layout: scaling factor'ı gerekli yerleşime dönüştürme
    • deep_gemm.get_tma_aligned_size: gerekli TMA alignment size değerini sorgulama
  • JIT ile ilgili ortam değişkenleri debug çıktısını, cache konumunu, derleyici seçimini ve profiling seçeneklerini kontrol eder
    • DG_JIT_DEBUG: JIT debug bilgilerini yazdırır
    • DG_PRINT_CONFIGS: shape başına seçilen config'i yazdırır
    • DG_JIT_CACHE_DIR: derlenmiş kernel cache dizini, varsayılan değer $HOME/.deep_gemm
    • DG_JIT_USE_NVRTC: NVCC yerine NVRTC kullanır; hızlı derleme sağlar ancak bazı durumlarda performans daha düşük olabilir
    • DG_JIT_NVCC_COMPILER: NVCC derleyici yolu
    • DG_JIT_CPP_STANDARD: C++ standart sürümü, varsayılan değer 20
  • Debug ve profiling ortam değişkenleri de sunulur
    • DG_JIT_DUMP_ASM, DG_JIT_DUMP_PTX, DG_JIT_DUMP_SASS: PTX ve SASS output dump'ı
    • DG_JIT_WITH_LINEINFO: profiling araçları için source line bilgisi ekler
    • DG_COMM_KERNEL_DEBUG: Mega MoE çağrısından önce symmetric buffer'ı 0 ile başlatır
    • DG_USE_NVIDIA_TOOLS: harici NVIDIA araçları çalıştırılırken dahili profiling'i atlar
  • Build seçenekleri kurulum ve kernel yükleme biçimini kontrol eder
    • DG_SKIP_CUDA_BUILD: kurulum sırasında CUDA extension build'ini atlar
    • DG_FORCE_BUILD: pre-built wheel indirmek yerine yerel build'i zorunlu kılar
    • DG_JIT_USE_RUNTIME_API: kernel yüklemede CUDA Runtime API kullanır, CUDA runtime 12.8 veya üzeri gerekir

Lisans ve atıf

  • DeepGEMM repository'si MIT License ile yayımlanmıştır
  • Proje CUTLASS'tan ilham aldığını belirtir
  • Atıf öğesinin başlığı DeepGEMM: clean and efficient BLAS kernel library on GPU şeklindedir

İlgili okumalar

1 yorum

 
GN⁺ 2025-02-27
Hacker News yorumları

  • FFMA SASS interleaving gerçekten şaşırtıcı düzeyde görünüyor
    NVCC 12.2 ile 12.3 arasında CUTLASS FP8 çekirdeklerinin performansının iyileştiğini görüp derlenmiş SASS'ı karşılaştırınca, birkaç FADD komutunda bir bitin interleaving deseninde ters çevrildiğini fark etmişler; açık kaynak bir CUDA assembler uygulamasına bakarak da bu bitin mevcut warp'ı bırakıp başka bir warp'ın çalışmasını sağlayan yield biti olduğunu anlamışlar gibi görünüyor
    Bunu kullanarak derlenmiş ikili dosyadaki FFMA komutlarını değiştiren bir betik hazırlamışlar; yalnızca yield bitini değil, warp yield edince register reuse mümkün olmadığından reuse bitini de birlikte ters çevirip ince ölçeklemeli FP8 GEMM'de MMA komutlarıyla yükseltme FFMA komutlarını daha iyi üst üste bindirerek bazı durumlarda performansı %10'dan fazla artırmaları etkileyici

    • Başka bir yerde okuduğuma göre, performansın kritik olduğu matris işlemi optimizasyonlarında bu tür yöntemler tipik olarak kullanılıyor
      Ancak bu belirli problemde diğer yapay zeka şirketleri henüz buna ihtiyaç duymamış ve uygulamamış gibi; sonunda herkesin benzer bir noktaya varması muhtemel
    • Scott Gray 2015'te Maxwell üzerinde tam olarak bunu ve daha fazlasını zaten keşfetmişti; sonrasında da birçok kişi bu konuyu epey ele aldı

  • Bu tür örnekler, yalnızca yüksek seviyeli kodla donanım performansını ortaya çıkarmada mevcut derleyicilerin ne kadar uzakta olduğunu iyi gösteriyor
    Geleneksel derleyici tekniklerinin ya da yapay zeka tabanlı optimizasyon ajanlarının böyle sonuçlar üretebilmesi için ne gerektiğini merak ediyorum

    • Pekiştirmeli öğrenme geri bildirim döngüsü içinde muazzam bir deneme-yanılma gerekecek gibi

  • Bildirilen hızlanma rakamları kendi CUTLASS tabanlı baseline'larıyla karşılaştırılmış
    cuBLAS ile doğrudan performans karşılaştırması yapan biri var mı merak ediyorum
    Şimdiye kadar gördüğüm CUTLASS GEMM sonuçları cuBLAS'a kıyasla kabaca %10 içinde kalıyordu; makalede söylenen 2x–2,5x iyileşme korunuyorsa gerçekten etkileyici olur

    • Normalde FP8'den kaçınıp I8'i tercih ederim, ama bu soruyu görünce cuBLAS'ın ne kadar iyi sonuç verdiğini merak ettim
      Öncelikle cuBLAS, FP8 gibi karma hassasiyetli işleri işlemek için cuBLASLt genişletme API'sine ihtiyaç duyuyor
      Ayrıca A x B'de E5M2 x E5M2 gibi uygun görünen tür kombinasyonlarını desteklemiyor, ama E5M2 x E4M3'ü destekliyor; Ampere, Hopper, Blackwell'de A matrisinin her zaman transpoze edilmiş düzende olması gibi kısıtlar da devam ediyor
      FP8 cuBLASLt benchmark'ını "Less Slow C++" depom <https://github.com/ashvardanian/less_slow.cpp> içine entegre ettim ve mevcut cuBLAS ile kendi yazdığım CUDA/PTX benchmark listesine ekledim
      H100 ile aynı performansa sahip olması gereken bir H200 GPU üzerinde çalıştırıyorum; kare girdilerde throughput yaklaşık 1,35 Peta-ops seviyesinde tepe yapıyor
      256 yaklaşık 2,68T/s, 512 20,49T/s, 1024 144,23T/s, 2048 665,68T/s, 4096 1,26P/s, 8192 1,34P/s, 16384 ise 1,23P/s idi; bu da yoğun GEMM için NVIDIA'nın tanıttığı değerin <https://resources.nvidia.com/en-us-data-center-overview-mc/e...> yaklaşık %67'si
    • CUTLASS ile cuBLAS'tan daha iyi performans alınabildiğini duymuştum
      Baseline'ın cuBLAS ile CUTLASS arasında daha iyi olan taraf seçilerek belirlendiğini düşünmüştüm

  • Bu tür açık kaynak, sektörün verimliliğe ulaşma hedefini gerçekten iyi gösteriyor
    Ancak bu yazılımın faydası, öğrenip deney yapmak ya da tüketici donanımında model sunmak isteyen genel açık kaynak topluluğundan çok, modelleri büyük ölçekte sunan büyük şirketlere, yani DeepSeek'in potansiyel rakiplerine daha fazla dönecek gibi görünüyor

    • Verimlilik artarsa sonunda herkes için, DeepSeek'in kendisi için de daha ucuz donanım anlamına gelebilir

  • Giderek daha düşük hassasiyete doğru optimize etmenin uzun vadede iyi olup olmadığından pek emin değilim
    Bu, modelin aslında epey seyrek olduğu anlamına geliyor; şu an böyle olabilir ama bunun doğası gereği bu kadar seyrek olması gerektiğinden ziyade, eğitim yöntemlerinde kötü fikirlerin karışmış olmasından kaynaklanma ihtimalinin yüksek olduğunu düşünüyorum

    • Bedavaya gelen seyreklik işe yaradığı sürece tadını çıkarmak gerek
      Yalnızca daha yüksek hassasiyette çok iyi modeller eğitmeyi mümkün kılmak bir araştırma problemi; düşük hassasiyetli eğitim ve çıkarım ise bir mühendislik problemi
      CNN döneminden beri, en azından 9 yıl öncesinden beri bu tür işleri yapıyoruz ve bence önümüzde birkaç yıl daha var
    • Aktivasyon fonksiyonları kayan noktalı sayıların dinamik aralığının önemli bir bölümünü attığı için, zaten doymuş aktivasyon bölgelerine geniş bir aralık ayırmanın muhtemelen pek faydalı olmadığı oldukça açık

  • Bu, Blackwell'in yerel mikro ölçekleme desteği olan MXFP nedeniyle anlamsız hale gelebilir
    Hopper'da bunu daha kaba bir birimde, fakat FP32 ölçekleme katsayıları kullanarak elle uygulamışlar sayılır

    • Evet
      Bu tür yüksek kaliteli herkese açık demolar, $NVDA'nın hendeğinin nerede olduğunu iyi gösteriyor
      Genel amaçlı GPU'lar çok esnek; donanım tedarikçisinin başta aklına gelmemiş ama yeterince mantıklı olan birçok işi programlama yoluyla yapabiliyorsunuz
      Ancak geleceğin giderek daha fazla özel donanım desteğine yakınsayacağını ve bu tür yazılım optimizasyon alanlarının ortadan kalkacağını öngörürseniz, sözde CUDA hendeği çöker
      NVIDIA bu oyunda kalmak için kendi hendeğini kendi eliyle yıkıyor sayılır :p

  • Vay, MIT lisansı
    Büyük şirketlerin bu tür açık kaynak iş birliği yaklaşımını benimsemesini isterim

  • Neden belgelenmemiş komutların var olduğunu merak edip duruyorum
    Tamamen kararlı olmasa bile kullanıcıya sunmanın daha doğru olduğunu düşünüyorum
    Böyle şeyler içeride muhtemelen belgelenmiştir; neden kamuya açılmadığını anlamıyorum
    Belirsizliğe dayanan güvenlik işe yaramaz, rakipler de zaten hepsini tersine mühendislikle çıkarır

    • Muhtemelen bizim yaptığımız şeylerde de belgelenmemiş kısımların ortaya çıkmasının nedenine benziyordur
      Zaman yetersizliği olabilir ya da kararsız veya deneysel bir özellik için destek ima etmek istemediklerinden olabilir
      Zarar en fazla yan masadaki ekiple sınırlı kalıyorsa değiştirmek de çok daha kolay olur
    • “Böyle şeyler içeride belgelenmiştir” varsayımı en baştan doğru olmayabilir
      Muhtemelen yalnızca mimari tasarım dokümanı ya da spesifikasyon gibi yerlerde bulunuyordur; böyle dokümanları da doğal olarak paylaşmak istemezler

  • Açıkçası benim kullanım alanımın ve anlayışımın ötesinde bir konu
    Yine de bu tür keşifleri ve iyileştirmeleri paylaşarak herkesin faydalanmasını sağlamaları gerçekten takdire değer ve ferahlatıcı

    • FFMA, Fused Floating-point Multiply-Add’in kısaltmasıdır; D = A*B + C işlemini tek seferde yapan temel bir GPU komutudur
      Matris çarpımı ve derin öğrenme iş yüklerinde çok önemlidir
      NVIDIA’nın SASS’inde FFMA komutu 64 bit veya 128 bit komut olarak kodlanır ve kesin davranışı belirleyen çeşitli kontrol bitlerine sahiptir
      yield biti ayarlandığında, warp zamanlayıcıya bu komuttan sonra mevcut warp’ın yürütmeyi devredebileceğini bildirir; donanım da gecikmeyi gizlemek için başka bir warp’ı çalıştırabilir
      GPU, yüksek verimi büyük ölçekli paralellik sayesinde elde eder; bir warp bellek bekleme gibi nedenlerle durursa başka bir warp ilerleyebilir
      reuse biti, kaynak register’ın hemen sonraki işlemde yeniden kullanılıp kullanılamayacağını gösterir; yield biti ayarlandığında mutlaka kapatılmalıdır
      Çünkü warp yürütmeyi devrettiğinde, sıradaki çalıştırılan warp aynı warp olmayabilir ve başka bir warp register file durumunu değiştirebilir; bu yüzden donanım yield’in ötesinde register değerinin korunacağını garanti edemez
      FFMA komutlarında yield bitini çapraz bir desenle ayarlamak, derleyicinin diğer warp’ların ilerleyebileceği açık zamanlama noktaları oluşturmasını sağlar; doğruluğu korumak için ilgili komutun reuse bitini de birlikte temizlemek gerekir
      Bu değişiklik, matris çarpımının çekirdeği olan MMA komutları ile FP8’i daha yüksek hassasiyetle biriktirmek için dönüştüren yükseltme FFMA komutlarını örtüştürmede özellikle yardımcı olur
      FP8 GEMM genellikle biriktirme için daha yüksek hassasiyete dönüştürüp sonra geri döndürme süreci gerektirdiğinden ek FFMA’lar doğurur; bellek bant genişliği gereksinimini azaltır ama yükseltme/düşürme işlemlerinin karıştığı karmaşık bir hesaplama deseni oluşturur
      “İnce taneli ölçekleme”, hesaplamanın çeşitli noktalarında hassasiyeti dikkatle yönetme işi anlamına geliyor gibi görünüyor
      yield bitiyle oynamak, hesaplama işlemleriyle biçim dönüşümlerinin daha iyi iç içe geçirilmesini sağlayarak GPU yürütme birimlerinin daha verimli kullanılmasına yol açar; bu optimizasyon olmazsa warp zamanlayıcı doğal geçiş fırsatları bulamayabilir ve hesaplama kaynakları daha az kullanılabilir