Menambahkan "cutlass" pada nama kernel FP8 membuatnya lebih cepat sekitar 100 TFLOPS

• Kernel attention direfaktorisasi ke bentuk persistent untuk meningkatkan performa pada panjang context yang pendek
• Pada fp16, untuk context besar, terjadi penurunan performa akibat masalah penjadwalan instruksi ptxas pada partisi softmax
• Pada fp8, jika nama kernel menyertakan "cutlass", teramati peningkatan performa sekitar 100 TFLOPS
• Optimasi ini dianalisis sebagai trik optimasi hardcoded melalui penamaan kernel
• Dampak performa dan penyebab perilakunya merupakan fenomena khusus akibat implementasi internal NVIDIA ptxas

---

Ringkasan: Refaktorisasi kernel Persistent Attention dan efek penamaan "cutlass"

Ikhtisar

• Pull Request ini berisi refaktorisasi kernel attention Triton ke pendekatan persistent attention
• Tujuan utamanya adalah memperoleh optimasi performa pada rentang context yang pendek
• Namun, pada tipe fp16, seiring membesarnya ukuran context, muncul penurunan performa akibat masalah penjadwalan instruksi ptxas di bagian softmax

Efek penggunaan nama "cutlass" pada fp8

• Saat memakai model fp8, menyertakan "cutlass" di nama kernel menghasilkan peningkatan performa hingga sekitar 100 TFLOPS
• Hal ini terjadi karena ptxas (assembler PTX) milik NVIDIA secara internal menerapkan optimasi khusus ketika nama kernel mengandung "cutlass"
• Dalam kode sebenarnya, ketika dtype adalah float8e5, nama kernel diatur menjadi "cutlass_gluon_attention" dan sejenisnya
• Hasil analisis disassembly ptxas menunjukkan bahwa memang ada kondisi strstr(kernel_name, "cutlass") di kode internal

Benchmark performa

• Pada data benchmark sebelum dan sesudah refaktorisasi, teramati penurunan performa relatif pada D=64 dibandingkan sebelum penerapan persistent attention
  • Ini disebabkan oleh masalah penjadwalan instruksi pada bagian softmax
• Namun, ketika tipe fp8 dikombinasikan dengan penamaan "cutlass", pada context dan ukuran tertentu tercatat throughput yang jauh lebih tinggi
• Ringkasan hasil representatif:
  • Attention Z=4, H=32, D=64, causal=False:
    • sebelum persistent: triton-fp16 sekitar 383, triton-fp8 sekitar 413, cudnn-fp16 sekitar 565
    • sesudah persistent: triton-fp16 sekitar 360, triton-fp8 sekitar 370
  • Attention Z=4, H=32, D=128, causal=True:
    • sebelum persistent: triton-fp16 sekitar 312, triton-fp8 sekitar 345, cudnn-fp16 sekitar 553
    • sesudah persistent: triton-fp16 sekitar 356, triton-fp8 sekitar 351

Penemuan dan analisis trik penamaan

• Jika string "cutlass" disertakan dalam nama kernel, analisis komunitas mengonfirmasi bahwa rutin optimasi eksperimental di NVIDIA ptxas diaktifkan
• Di ptxas terdapat logika hardcoded untuk pencocokan nama (strstr(kernel_name, "cutlass"))
• Trik ini merupakan optimasi agresif dan eksperimental, sehingga perubahan akurasi kernel dapat bervariasi tergantung perangkat keras dan situasi

Diskusi komunitas

• Beberapa reviewer mengajukan pertanyaan dan analisis terkait perbandingan performa, akurasi, dan metode optimasi
• Isi laporan teknis Deepseek, perbedaan pada arsitektur tertentu seperti GPU Hopper, dan sebagainya juga ikut dibahas
• Sejauh mana optimasi melalui perubahan nama ini diterapkan secara luas, serta isu stabilitasnya, juga turut diangkat

Kesimpulan dan implikasi

• Fakta bahwa hanya dari nama kernel saja dapat muncul perubahan performa nyata pada level perangkat keras adalah fenomena yang sangat tidak biasa
• Adanya trigger optimasi tersembunyi di stack software NVIDIA (ptxas) menyiratkan bahwa aturan penamaan juga bisa memengaruhi performa saat mengembangkan framework AI
• Dalam praktiknya, saat memakai trik ini, reproducibility dan stabilitas wajib diuji, dan kebijakan optimasi dari vendor hardware perlu terus dicermati

[GN⁺]

Komentar Hacker News

• Jika ptxas dibongkar, terlihat ada logika yang di-hardcode untuk mendeteksi nama kernel cutlass
  Saya menduga NVIDIA menerapkan optimisasi yang tidak stabil, eksperimental, dan agresif di sini; kalau optimisasi ini selalu dinyalakan tanpa syarat, bisa muncul bug yang rumit

  • Dalam praktiknya, yang lebih sering muncul bukan bug rumit melainkan perubahan performa yang halus
    Compiler GPU itu sangat sulit, dan begitu mencoba melangkah lebih jauh dari optimisasi dasar, hasilnya hampir selalu campuran antara manfaat dan masalah
    Ada kernel yang jadi lebih cepat dan ada yang justru lebih lambat, dan sangat sulit berharap performa keseluruhan naik secara konsisten
    Hampir tidak pernah ada satu optimisasi tunggal yang selalu meningkatkan kecepatan di seluruh rangkaian pengujian
    Pengalaman saya memang di sistem GPU non-Nvidia, tetapi situasi ini terasa sangat familier
    Mungkin Nvidia juga menemukan optimisasi yang memberi hasil luar biasa untuk sebagian kumpulan kernel, namun buruk untuk kumpulan lain, dan mereka tampaknya tidak menemukan kriteria andal untuk menerapkannya secara otomatis

• Terima kasih atas konteks tambahannya
  Saya bukan dari bidang ini (bahkan baru pertama kali mendengar proyek ini), jadi judul dan isi PR-nya sama sekali tidak masuk akal bagi saya

• Ini mengingatkan saya pada kejadian 25 tahun lalu saat ATI (AMD) ketahuan memanipulasi benchmark Quake III karena performanya berubah ketika nama executable diganti menjadi quack
  Ada juga tautan terkait: ulasan techreport.com, ulasan hardocp.com, artikel 3dcenter.de

  • Kalau ada yang salah paham seperti saya, saya rangkum:
    ATI mendeteksi nama executable quake lalu mengubah kualitas tekstur dan hal lain untuk menaikkan skor benchmark
    Ini terungkap ketika orang-orang mengganti nama executable menjadi quack, lalu kualitas gambar naik dan skornya turun; artinya driver ATI sengaja menurunkan kualitas demi menambah kecepatan
    Jadi bukan ATI yang mengganti nama file, melainkan para pengguna

  • Atau isu Intel C++ Compiler yang memeriksa string "GenuineIntel" di output
    Tautan wiki terkait ada di sini

  • Sampai hari ini semua vendor masih melakukan hal seperti ini
    Driver mencegat rendering loop game populer untuk memperbaiki bug, mengganti shader dengan versi yang lebih optimal, atau membuka jalur kode yang lebih cepat, dan sebagainya
    Perubahan seperti ini seharusnya hanya berdampak minimal pada hasil akhir, tetapi dalam beberapa kasus intervensinya terlalu agresif sampai kualitas turun drastis
    Jadi mereka mengutak-atik agar game berjalan lebih cepat di hardware mereka sendiri

  • Ada thread yang membahas topik ini lebih dalam, jadi saya sarankan lihat di sini
    Lucunya, itu juga tulisan lama tentang optimisasi cutlass yang sama

  • Kasus seperti ini sangat umum
    Pabrikan chipset ponsel pernah curang untuk benchmark (VW untuk emisi, Nvidia untuk benchmark 3DMark, Intel untuk benchmark SPEC pada Xeon, dan seterusnya)
    Dalam grafis komputer, sekarang nyaris sudah jadi kebiasaan bahwa driver menyisipkan tweak, pengaturan, workaround, dan sejenisnya untuk tiap game
    (Sayangnya sekarang terlalu sering tautan sumber yang layak hilang, jadi harus memakai archive.org. Menurut saya ingatan seperti ini memang perlu dipertahankan.)
    Tautan referensi: kecurangan benchmark Mediatek, skandal manipulasi emisi Volkswagen, kontroversi Nvidia 3DMark, dampak compiler Intel pada benchmark SPEC

• Dari sudut pandang orang yang bekerja dengan compiler, optimisasi seperti ini kadang memang bergantung pada nama (schema, substring, dan sebagainya)
  Meski tidak ideal, dalam praktik memang begitu cara kerjanya
  Tidak selalu berniat jahat; merancang agar optimisasi hanya diterapkan ke library sendiri bisa jadi pilihan yang lebih aman daripada berisiko merusak semuanya
  Atau bisa juga karena frontend tidak mampu menyediakan informasi yang lebih bisa dipercaya (misalnya informasi struktural)

  • Mungkin memang tidak berniat jahat, tetapi cara optimisasi seperti ini tetap pada akhirnya menciptakan hambatan baru
  • Kalau bergantung pada tipe fungsi atau skema saya masih agak paham, tetapi kalau hanya berdasarkan nama sederhana rasanya agak aneh
  • Sekalipun alasannya “untuk mencegah hal rusak”, kalau ada orang yang kebetulan memakai nama yang sama maka masalah tak terduga bisa muncul
    Saya rasa pendekatan seperti ini tidak membantu

• Menurut saya ini tidak terlalu baru

  • Pada awal 2024, SPEC membatalkan 2.600 hasil benchmark CPU Xeon Intel karena compiler Intel memakai optimisasi yang tidak adil untuk menaikkan skor (artikel Tom's Hardware)
  • Microsoft juga pernah melakukan hal serupa pada metrik benchmark Java/C
  • Dan semua orang sekarang bersemangat memanipulasi benchmark AI (skandal benchmark AI)

• Ini mengingatkan saya pada sekitar 10 tahun lalu, di versi tertentu Webpack build akan rusak jika memakai nama file add.svg
  Pada akhirnya saya menyelesaikannya dengan mengganti nama file menjadi plus.svg

  • numpy juga mirip
    Ada juga yang pernah tanpa sengaja merusak numpy hanya karena menaruh file bernama secret.py

• Saya terkesan dengan kejujuran commit message-nya

  • Ada kritik terhadap cara diff commit itu disusun
    Ketika seseorang menulis “membuat sesuatu sekitar 100 tflops lebih cepat”, malah ada yang menilai “commit message-nya jelek”... kalau begitu saya rasa mereka juga akan tidak suka gaya commit John Carmack

  • Secara pribadi saya suka pesan yang sejujur ini
    Jauh lebih baik daripada linimasa penuh commit message buatan AI yang berulang-ulang seperti "refactored X"

  • Menurut saya riwayat commit sebaiknya di-squash
    Saya kurang paham kenapa tidak di-squash saat diunggah ke GitHub

• Ini mengingatkan saya saat belajar memakai NVIDIA Jetson
  Waktu itu saya sadar bahwa hanya dengan menjalankan satu perintah, semuanya bisa jadi lebih cepat (tautan terkait)

  • Apakah yang dimaksud mode daya?
    Kalau mengikuti artikelnya, ada dua mode yaitu 5W dan 10W, dan 10W adalah default, jadi justru bisa ditafsirkan bahwa “lebih cepat” hanya berlaku saat berpindah dari default ke 5W; atau mungkin saya salah paham?

• Ada kalanya Anda menulis kode yang sangat dituning dalam bahasa tingkat tinggi (C++ dan sejenisnya), lalu mengharapkan hasil tertentu sampai level assembly GPU, tetapi compiler tidak mengeluarkan hasil seperti yang Anda inginkan
  Jika bertanya ke tim komputer, mereka mungkin akan menawarkan berbagai solusi, tetapi untuk kode open source banyak di antaranya sulit diterapkan (misalnya #pragma proprietari, intrinsic, dan sebagainya)
  Dari sudut pandang pembuat library berkinerja tinggi, kalau performanya tidak keluar maka produk itu praktis tidak bisa dirilis
  Dalam situasi seperti ini, tidak ada pilihan selain memakai trik seperti memicu transformasi kode tertentu lewat nama fungsi dan sebagainya
  Optimisasi seperti ini umum dipakai di dunia nyata, dan menurut saya tidak setara dengan tindakan menurunkan kualitas gambar demi memanipulasi benchmark

  • Dalam kasus seperti ini, ada juga yang bertanya kenapa tidak memakai inline assembly

• Hal ini sudah dibahas saat PR ini pertama kali muncul
  Rasanya tidak ada hal baru
  Diskusi sebelumnya

  • Rasanya familier, jadi saya merasa seperti pernah melihatnya sebelumnya

• Saya berharap ada struktur ekonomi yang memudahkan berbagi kode
  Bukan driver binary blob, baseband, dan struktur rumit lain, melainkan situasi di mana semua orang bisa dengan mudah mendapat informasi sehingga waktu dan tenaga yang terbuang bisa dikurangi
  Begitu banyak engineer dan peneliti hebat menghabiskan berbulan-bulan atau bertahun-tahun untuk merekayasa balik dan menguraikan dokumen, skematik, dan kode biner yang sebenarnya sudah dimiliki seseorang
  CUDA dan perusahaan seperti NVIDIA terasa sangat membuat frustrasi

  • Inti masalahnya adalah biaya tetap awal untuk mengembangkan codebase perangkat lunak, lalu biaya tenaga kerja pemeliharaan setelahnya, dan biaya distribusi yang kecil (misalnya server unduhan)
    Untuk aplikasi desktop, biaya tambahan per pengguna nyaris mendekati nol
    Karena itu perangkat lunak memerlukan struktur pendapatan berkala yang berkelanjutan, tetapi pendapatannya tidak boleh terus meningkat sebanding dengan jumlah pengguna
    Orang-orang yang berinvestasi dalam pengembangan kode baru harus bisa mendapatkan kembali investasinya saat produk menjadi populer, tetapi crowdfunding yang ada sekarang tidak memenuhi struktur seperti ini
    Semakin banyak pengguna, kontribusi per orang justru turun tajam; bahkan jika semua orang hanya menyumbang 100%, atau 10%, bahkan 1%, total investasi bisa menjadi sangat besar
    Pada akhirnya menurut saya dibutuhkan model pledge berbasis lelang
    Model ini juga punya masalah, dan yang paling merepotkan terutama adalah peralihan antara mode eksklusif dan non-eksklusif
    Jika beberapa perusahaan besar menanggung seluruh biaya pengembangan lalu hasilnya dirilis sebagai open source, maka semua individu atau perusahaan lain pada dasarnya menjadi penumpang gratis