Fp8 çekirdek adına "cutlass" eklemek yaklaşık 100 TFLOPS hız kazandırıyor

 (github.com/triton-lang)
1 puan yazan GN⁺ 2025-10-04 | 1 yorum | WhatsApp'ta paylaş
  • Attention çekirdeği, düşük context uzunluklarında performansı iyileştirmek için persistent biçimde yeniden düzenlendi
  • fp16'da büyük context boyutlarında, softmax bölümündeki ptxas komut zamanlama sorunu nedeniyle performans düşüşü oluşuyor
  • fp8'de çekirdek adına "cutlass" eklendiğinde yaklaşık 100 TFLOPS performans artışı gözlemleniyor
  • Bu optimizasyonun, çekirdek adlandırması üzerinden çalışan hard-coded bir optimizasyon hilesi olduğu değerlendiriliyor
  • Performans etkisi ve çalışma nedeni, NVIDIA ptxas iç uygulamasından kaynaklanan sıra dışı bir davranış

Özet: Persistent Attention çekirdeğinin yeniden düzenlenmesi ve "cutlass" adlandırma etkisi

Genel bakış

  • Bu Pull Request, Triton'un attention çekirdeğini persistent attention yaklaşımıyla yeniden düzenliyor
  • Ana amaç, düşük context uzunluğu aralığında performans optimizasyonu sağlamak
  • Ancak fp16 türünde, context boyutu büyüdükçe softmax bölümündeki ptxas komut zamanlama sorunu nedeniyle performans düşüşü görülüyor

fp8'de "cutlass" adını kullanmanın etkisi

  • fp8 modeli kullanıldığında, çekirdek adına "cutlass" eklemek yaklaşık 100 TFLOPS'a kadar performans artışı sağlayabiliyor
  • Bunun nedeni, NVIDIA'nın ptxas (PTX assembler) aracının çekirdek adında "cutlass" geçtiğinde dahili olarak özel bir optimizasyon uygulaması
  • Gerçek kodda dtype float8e5 olduğunda çekirdek adı "cutlass_gluon_attention" gibi atanıyor
  • ptxas disassembly analizi sonucunda, dahili kodda gerçekten strstr(kernel_name, "cutlass") koşulunun bulunduğu görülüyor

Performans benchmark'ları

  • Yeniden düzenleme öncesi ve sonrası benchmark verilerinde, persistent attention uygulanmadan öncekine kıyasla D=64'te göreli performans düşüşü gözlemleniyor
    • Bunun nedeni softmax kısmındaki komut zamanlama problemi
  • Ancak fp8 türü ile "cutlass" adlandırması birlikte kullanıldığında, belirli context ve boyutlarda belirgin biçimde daha yüksek throughput elde ediliyor
  • Öne çıkan sonuçların özeti:
    • Attention Z=4, H=32, D=64, causal=False:
      • persistent uygulanmadan önce: triton-fp16 yaklaşık 383, triton-fp8 yaklaşık 413, cudnn-fp16 yaklaşık 565
      • persistent uygulandıktan sonra: triton-fp16 yaklaşık 360, triton-fp8 yaklaşık 370
    • Attention Z=4, H=32, D=128, causal=True:
      • persistent uygulanmadan önce: triton-fp16 yaklaşık 312, triton-fp8 yaklaşık 345, cudnn-fp16 yaklaşık 553
      • persistent uygulandıktan sonra: triton-fp16 yaklaşık 356, triton-fp8 yaklaşık 351

Adlandırma hilesinin keşfi ve analizi

  • Çekirdek adında "cutlass" dizgesi bulunduğunda, NVIDIA ptxas içinde deneysel bir optimizasyon rutinini etkinleştirdiği topluluk analizlerinde doğrulandı
  • ptxas içinde ad eşleştirmesi için hard-coded mantık (strstr(kernel_name, "cutlass")) bulunuyor
  • Bu hile agresif ve deneysel bir optimizasyon olduğundan, çekirdeğin doğruluğunu etkileyip etkilemeyeceği donanıma ve koşullara göre değişebilir

Topluluk tartışması

  • Birden fazla reviewer, performans karşılaştırmaları, doğruluk ve optimizasyon yöntemi hakkında soru ve analizler yaptı
  • Deepseek technical report içeriği ve Hopper GPU gibi belirli mimarilerdeki farklar da tartışıldı
  • Ad değişikliğiyle yapılan optimizasyonun ne kadar geniş çapta uygulandığı ve olası kararlılık sorunları da gündeme geldi

Sonuç ve çıkarımlar

  • Yalnızca çekirdek adıyla bile donanım seviyesinde gerçek performans farkı oluşabilmesi oldukça sıra dışı bir durum
  • NVIDIA yazılım yığınında (ptxas) gizli optimizasyon tetikleyicileri bulunduğunu göstermesi açısından, yapay zeka framework geliştirmede adlandırma kurallarının da performansı etkileyebileceğine işaret ediyor
  • Pratikte bu tür hileler kullanılırken yeniden üretilebilirlik ve kararlılık mutlaka test edilmeli; donanım üreticisinin optimizasyon politikaları yakından izlenmeli

İlgili okumalar

1 yorum

 
GN⁺ 2025-10-04
Hacker News yorumu

  • ptxas tersine incelendiğinde, çekirdek adında cutlass geçmesini algılayan mantığın hardcoded olduğu görülüyor
    NVIDIA'nın burada kararsız, deneysel ve agresif optimizasyonlar uyguladığını düşünüyorum; bu optimizasyon her zaman koşulsuz açılırsa sinsi hatalara yol açabilir diye değerlendirmiş olmalılar

    • Aslında sinsi hatalardan çok ince performans değişimleri daha sık görülür
      GPU derleyicileri son derece zordur ve temel optimizasyonların ötesine geçmeye çalıştığınızda sonuçlar her zaman sorunlarla karışık olur
      Bazı çekirdekler hızlanır, bazıları yavaşlar ve genel performansın artmasını sağlamak çok zordur
      Tüm testlerde tek bir optimizasyonla performansın sürekli artması neredeyse hiç görülmez
      Benim deneyimim Nvidia dışı GPU sistemleriyle ilgili ama bu durum bana çok tanıdık geliyor
      Nvidia da muhtemelen bazı çekirdek kümelerinde harika, bazılarında ise berbat sonuçlar veren bir optimizasyon buldu ve bunu otomatik uygulamak için güvenilir bir ölçüt de bulamadı

  • Bu bağlamı açıkladığınız için teşekkürler
    Bu alanın insanı değilim (bu projeyi de ilk kez duyuyorum), o yüzden başlıkla PR içeriği bana hiç mantıklı gelmiyordu

  • Bu bana 25 yıl önce ATI'nin (AMD) Quake III benchmark'ında, çalıştırılabilir dosya adı quack olarak değiştirildiğinde performansın farklılaştığının ortaya çıkmasıyla hile yaparken yakalanmasını hatırlattı
    İlgili bağlantılar: techreport.com incelemesi, hardocp.com incelemesi, 3dcenter.de yazısı

    • Benim gibi yanlış anlamış olabilecekler için özet geçeyim
      ATI, quake adlı çalıştırılabilir dosyayı algılayıp doku kalitesi gibi ayarları değiştirerek benchmark puanını yükseltiyordu
      İnsanlar dosya adını quack yapınca görüntü kalitesinin arttığı ve puanın düştüğü görüldü; yani ATI sürücüsü performans için kaliteyi bilerek düşürüyordu
      Yani dosya adını ATI değiştirmedi, kullanıcılar değiştirdi

    • Ya da Intel C++ Compiler'ın çıktıdaki GenuineIntel dizgesini kontrol etmesi meselesi vardı
      İlgili wiki bağlantısı burada

    • Bugün bile tüm satıcılar bunu yapıyor
      Sürücü, popüler oyunların render döngüsüne müdahale edip hataları düzeltiyor, shader'ları daha optimize sürümlerle değiştiriyor ya da hızlı kod yollarını açıyor
      Bu değişikliklerin çıktıya etkisinin asgari düzeyde olması gerekir ama bazı durumlarda fazla agresif davranılıp kalite ciddi biçimde düşebiliyor
      Yani oyunlar kendi donanımlarında daha hızlı çalışsın diye kurcalıyorlar

    • Bu konunun daha derin tartışıldığı bir başlık var, buraya bakmanızı öneririm
      İlginç şekilde o da aynı cutlass optimizasyonuyla ilgili eski bir gönderi

    • Bu tür örnekler çok yaygındır
      Telefon yonga seti üreticileri benchmark'lar için hile yaptı (VW emisyonlarda, Nvidia 3DMark benchmark'ında, Intel de Xeon için SPEC benchmark'larında vb.)
      Bilgisayar grafiklerinde ise sürücülerin her oyun için tweak, ayar ve workaround eklemesi artık neredeyse bir gelenek haline geldi
      (Ne yazık ki bugünlerde düzgün kaynak bağlantıları çok sık kayboluyor, bu yüzden archive.org kullanmak gerekiyor. Bence bu tür anıları korumak önemli.)
      Referanslar: Mediatek benchmark hilesi, Volkswagen emisyon skandalı, Nvidia 3DMark tartışması, Intel compiler'ın SPEC benchmark'ına etkisi

  • Derleyicilerle çalışan biri olarak, bu tür optimizasyonların bazen ada (schema, substring vb.) bağlı olduğunu söyleyebilirim
    Hoşunuza gitmese bile pratikte bazen işler böyle yürüyor
    Bu her zaman kötü niyetli değil; optimizasyonun yalnızca kendi kütüphanelerinde uygulanmasını sağlamak, her şeyi bozma riskine kıyasla daha güvenli bir tercih olabilir
    Ya da frontend daha güvenilir bilgi (örneğin yapısal bilgi) veremediği için böyledir

    • Muhtemelen kötü niyetli değil ama bu tür optimizasyon biçimi sonuçta yeni bir bariyer yaratıyor
    • Fonksiyon tipine ya da şemaya dayanmasını bir yere kadar anlayabilirim ama sadece isme dayanıyorsa biraz tuhaf geliyor
    • Amaç “bozulmaları önlemek” olsa bile biri tesadüfen aynı adı kullanırsa beklenmedik sorunlar doğabilir
      Bence bu yaklaşım faydalı değil

  • Bana pek yeni gelmiyor

    • 2024 başında SPEC, Intel Xeon CPU'lara ait 2.600 benchmark sonucunu geçersiz saydı; gerekçe, Intel derleyicisinin puanı yükselten haksız optimizasyonlar kullanmasıydı (Tom's Hardware haberi)
    • Microsoft da Java/C derleyici benchmark metriklerinde benzer şeyler yaptı
    • Ve herkes AI benchmark'larını kandırma yarışına girmiş durumda (AI benchmark skandalı)

  • Yaklaşık 10 yıl önce belirli bir Webpack sürümünde add.svg adlı bir dosya kullanınca build'in bozulduğunu hatırladım
    Sonunda dosya adını plus.svg yaparak çözmüştük

    • numpy de benzer
      secret.py adlı bir dosya kullanıp farkında olmadan numpy'yi bozmuş olanlar var

  • Commit mesajının dürüstçe yazılmış olması etkileyici

    • Bunun üzerine commit diff'inin nasıl düzenlendiğine dair eleştiri gelmişti
      Birisi “bir şeyi yaklaşık 100 tflops hızlandırdım” yazıldığında bile çıkıp “commit mesajı kötü” diyorsa… o kişi muhtemelen John Carmack'in commit tarzından da hoşlanmaz

    • Ben şahsen bu kadar dürüst mesajları seviyorum
      AI tarafından otomatik üretilmiş, durmadan refactored X benzeri tekrarlar yapan commit mesajlarını görmekten çok daha iyi

    • Bence squash yapıp commit geçmişini birleştirmek daha iyi olurdu
      GitHub'a koyarken neden squash yapılmadığını pek anlamıyorum

  • NVIDIA Jetson kullanmayı öğrendiğim zamanı hatırlattı
    Tek bir komut çalıştırınca her şeyin hızlandığını öğrenmiştim (ilgili bağlantı)

    • Güç modundan mı bahsediyorsunuz diye merak ettim
      Yazıya göre iki mod var: 5W ve 10W; 10W varsayılan olduğundan, aslında yalnızca varsayılandan 5W'a geçince “daha hızlı” ifadesi anlamlı olur gibi geldi, ben mi yanlış anladım diye soruyorum

  • Yüksek seviyeli dillerle (C++ vb.) aşırı derecede ayarlanmış kod yazıp aynı zamanda GPU assembly düzeyinde çok belirli sonuçlar beklediğinizde, derleyici bazen istediğinizi üretmez
    Derleyici ekibine sorarsanız çeşitli çözümler önerebilirler ama açık kaynak kod söz konusuysa bunların çoğunu uygulamak zordur (örneğin özel #pragma, intrinsic'ler vb.)
    Yüksek performanslı kütüphane geliştiren biri için, performans çıkmazsa ürünü sevk etmek bile mümkün olmaz
    Böyle durumlarda fonksiyon adı gibi şeylerle belirli kod dönüşümlerini tetikleyen hileler kullanmak zorunda kalabilirsiniz
    Bu tür optimizasyonlar gerçek dünyada yaygındır ve benchmark'ı kandırmak için görüntü kalitesini düşürmekle aynı seviyede görülmemelidir

    • Böyle durumlarda neden inline assembly kullanılmadığı da soruldu

  • Bu PR ilk açıldığında zaten tartışılmıştı
    Yeni bir şey yokmuş gibi geliyor
    Önceki tartışma

    • Gözüme tanıdık geldi, sanki daha önce görmüştüm

  • Kod paylaşımının kolay olduğu bir ekonomik yapı olmasını isterdim
    Binary blob sürücüler, baseband'ler ve benzeri karmaşık yapılar yerine herkesin bilgiye kolayca erişebildiği, boşa harcanan zaman ve emeğin azaldığı bir dünya daha iyi olurdu
    Sayısız yetenekli mühendis ve araştırmacı, birilerinin zaten elinde bulunan belgeleri, şemaları ve binary kodu reverse engineer edip çözmek için aylarını, yıllarını harcıyor
    CUDA ve NVIDIA gibi şirketler bu açıdan gerçekten sinir bozucu

    • Sorunun özü; bir yazılım kod tabanını geliştirmenin başlangıçtaki sabit maliyeti, sonrasındaki bakım iş gücü ve küçük dağıtım maliyetleridir (ör. indirme sunucuları gibi)
      Masaüstü uygulamalar açısından bakıldığında kullanıcı başına ek maliyet neredeyse sıfıra iner
      Bu yüzden yazılımın sürdürülebilir bir düzenli gelir modeline ihtiyacı vardır ama gelir kullanıcı sayısıyla orantılı biçimde sonsuza kadar artmamalıdır
      Yeni kod geliştirmeye yatırım yapanların, ürün popüler olduğunda yatırımlarını geri alabilmesi gerekir ama mevcut crowdfunding modelleri bunu sağlayamaz
      Kullanıcı sayısı arttıkça kişi başına katkı miktarı dramatik biçimde düşer; herkes %100, %10 hatta %1 katkı yapsa bile toplam yatırım astronomik olabilir
      Sonuçta açık artırma benzeri bir pledge yapısı gerektiğini düşünüyorum
      Bunun da sorunları var; özellikle tekelci ve tekelci olmayan modlar arasında geçiş çok sıkıntılı
      Birkaç büyük şirket tüm geliştirme maliyetini üstlenip sonra kodu açık kaynak yaparsa, geri kalan bütün bireyler ve şirketler fiilen bedavacı olur