7 poin oleh GN⁺ 2025-05-31 | 2 komentar | Bagikan ke WhatsApp
  • Kernel CUDA-C yang dihasilkan AI menunjukkan kinerja yang setara atau lebih baik daripada kernel hasil optimasi pakar milik PyTorch
  • Satu LLM (large language model) mengulang pembuatan ide optimasi dalam bahasa alami dan berbagai percabangan kode, sehingga mencapai kinerja unggul dalam keragaman optimasi dan penjelajahan paralel dibanding metode sebelumnya
  • Hasil benchmark utama menunjukkan performa yang sangat unggul dibanding PyTorch, termasuk Matmul (101%), Conv2D (179.9%), Softmax (111.8%), LayerNorm (484.4%), Conv2D+ReLU+MaxPool (290.1%)
  • Untuk melampaui batas pendekatan lama berupa "peningkatan kernel secara berurutan", diterapkan penalaran bahasa alami + struktur branching untuk menghasilkan kernel berkinerja tinggi dengan cepat
  • Kemajuan juga terlihat pada workload ML modern seperti FP16 dan Flash Attention, serta menunjukkan kemungkinan bahwa di masa depan AI akan secara mandiri mencari dan menyempurnakan kernel yang lebih cepat

TL;DR pencapaian utama

  • Tim riset Stanford CRFM menemukan bahwa kernel CUDA-C berperforma tinggi yang dihasilkan AI dapat menyamai atau melampaui kecepatan kernel rancangan pakar yang ada di PyTorch
  • Awalnya mereka ingin melatih model pembuat kernel otomatis yang lebih baik menggunakan data sintetis, tetapi mereka justru mengamati bahwa proses pembuatan data sintetis itu sendiri secara otomatis menghasilkan kernel cepat pada tingkat yang mengejutkan
  • Karena itu, mereka merilis lebih awal metode, benchmark performa, strategi optimasi, dan arah ke depan
  • Benchmark: berdasarkan GPU Nvidia L40S. Kinerja (%): waktu eksekusi PyTorch ÷ waktu eksekusi kernel hasil generasi
    • Matmul (FP32): 101.3% dibanding PyTorch (matriks 4096x4096)
    • Conv2D: 179.9% (input: 100, 3, 224, 224; spesifikasi AlexNet Conv1)
    • Softmax: 111.8% (tensor 4096x65536)
    • LayerNorm: 484.4% (tensor 16, 64, 256, 256)
    • Conv2D + ReLU + MaxPool: 290.1% dibanding referensi PyTorch, 189.0% dibanding torch.compile()

Motivasi riset dan metode

  • Tujuan awalnya adalah membuat data sintetis untuk melatih model pembuat kernel, tetapi selama eksperimen kernel yang dihasilkan sendiri mencapai performa tinggi yang jauh melampaui perkiraan
  • Memanfaatkan KernelBench (benchmark publik Stanford, dirilis pada Desember 2024)
    • Untuk kode torch yang diberikan, LLM menulis ulang kernel baru dengan kecepatan optimal
    • Akurasi diverifikasi lewat kesetaraan numerik hasil input/output
  • Pendekatan lama: loop revisi berurutan yang sedikit demi sedikit memperbaiki kernel tahap demi tahap
    • Kekurangan: kurangnya keragaman ide, optimasi yang sama berulang, dan konvergensi ke optimum lokal
  • Ide perbaikan
    1. Setelah menggagas dan mencatat ide optimasi dalam bahasa alami, sistem membuat beberapa cabang implementasi kode dari ide-ide tersebut secara bersamaan
    2. Di setiap ronde, berbagai percobaan optimasi dijalankan secara paralel → kernel dengan performa terbaik dijadikan seed untuk ronde berikutnya
    • Dengan cara ini, dalam jumlah iterasi penjelajahan yang terbatas tetap dimungkinkan eksplorasi strategi optimasi yang beragam dan pencarian paralel

Contoh ide optimasi

  • Optimasi akses memori: meningkatkan efisiensi hierarki memori global/shared/register
  • Pemrosesan asinkron dan penyembunyian latensi: menumpangtindihkan komputasi dan perpindahan data
  • Optimasi tipe data/presisi: memanfaatkan FP16/BF16 dan operasi yang dioptimalkan untuk perangkat keras tertentu
  • Optimasi komputasi dan instruksi: meminimalkan jumlah operasi dan instruksi, serta memaksimalkan penggunaan instruksi khusus perangkat keras
  • Paralelisme dan occupancy: memaksimalkan pemanfaatan SM (Streaming Multiprocessors)
  • Optimasi loop/percabangan/indexing: meminimalkan loop dan menghapus operasi indeks yang tidak perlu

Proses nyata optimasi kernel (contoh Conv2D)

  • Alur ide optimasi dan peningkatan performa per ronde
    • Awal (ronde 0): porting CUDA sederhana (kecepatan 20% dari PyTorch)
    • Ronde berikutnya: → pemanfaatan cache baca → komputasi FP16 Tensor Core (konversi GEMM) → double buffering/pipeline → pra-perhitungan indeks/shared memory → vektorisasi → buffering bersamaan pada K-loop, dll. dengan pemanfaatan arsitektur GPU tingkat lanjut
    • Akhir (ronde 13): mencapai 179.9% performa dibanding PyTorch
  • Kode aktual memanfaatkan banyak teknik pemrograman CUDA tingkat lanjut
    • Di setiap ronde, ide baru dihasilkan dalam bahasa alami, beberapa implementasi dicoba secara paralel, lalu kode terbaik dipilih

Takeaways dan implikasi

  • Pembuatan kernel berbasis AI dapat melampaui tingkat pakar manusia melalui loop penjelajahan yang kuat dan kombinasi berbagai ide optimasi berbasis bahasa alami
  • Beberapa operator modern (FP16 matmul, Flash Attention) saat ini masih memiliki performa lebih rendah dibanding PyTorch
  • Komputasi FP32 pada perangkat keras terbaru relatif kurang dioptimalkan dibanding FP16/BF16 → sehingga area ini mungkin memberi keunggulan performa
  • Peningkatan performa yang berkelanjutan tetap terkonfirmasi bahkan dalam kondisi token penjelajahan terbatas (total input/output 7 juta token)
  • Riset terbaru seperti AlphaEvolve dan Gemini 2.5 Pro juga mengindikasikan bahwa penjelajahan berbasis percabangan masif + verifikasi dapat menghasilkan peningkatan performa besar tanpa retraining
  • Ke depannya, pendekatan seperti ini akan menghasilkan data sintetis dan kernel berperforma tinggi dalam jumlah besar, lalu berkembang menjadi loop AI yang memperbaiki dirinya sendiri (self-improving AI)

Kesimpulan

  • Pembuatan dan optimasi kernel otomatis berbasis AI telah mencapai tingkat hand-coding pakar, dan dalam waktu dekat kombinasi model + penjelajahan branching + verifikasi berpotensi memungkinkan sistem AI yang mampu meningkatkan dirinya sendiri
  • Muncul kemungkinan bahwa AI akan secara mandiri melampaui batas performa framework seperti PyTorch dan TensorFlow

Lampiran: seluruh kode kernel Conv2D

  • Mencakup seluruh source code fungsi dan kernel aktual (kode detail dihilangkan)
  • Fitur utama di dalam kode:
    • vektorisasi shared memory, double-buffering hierarkis K-dim, CUDA WMMA, buffer output tingkat warp, dll.
    • perhitungan indeks dinamis secara real-time, penanganan bias, pemuatan data tertunda secara bersamaan di dalam K loop, dll.
  • Contoh kode lengkap dan kernel contoh dapat dilihat di repositori GitHub

2 komentar

 
aer0700 2025-06-02

Mungkin ini bisa disebut semacam teknik ensemble. Luar biasa.

 
GN⁺ 2025-05-31
Opini Hacker News
  • Menurut saya, cara para penulis artikel ini memandang "agen AI" cukup menarik
    Kebanyakan orang cenderung memikirkan agen seperti karyawan manusia
    Mereka menyiapkan hanya sedikit agen secara paralel, sering kali bahkan cuma satu, lalu membiarkan masing-masing berputar dalam loop dan menangani satu pekerjaan pada satu waktu
    Mereka masih terjebak dalam dunia dengan jumlah tenaga kerja tetap, pekerja yang hanya bisa melakukan satu hal sekaligus, dan perpindahan tugas yang lambat
    Tetapi LLM tidak seperti itu
    Pada dasarnya kita bisa menciptakan agen dalam jumlah nyaris tak terbatas kapan saja sesuka hati
    Tidak ada perbedaan biaya antara memproses permintaan LLM secara berurutan atau paralel
    Begitu menyadari hal ini, pola di mana tiap agen bercabang menjadi banyak sub-agen sesuai kebutuhan terasa muncul secara alami
    Itulah tepatnya pendekatan yang dicoba oleh para penulis
    Rasanya lebih tepat memandang agen sebagai "task" atau "job", lalu menerapkan pelajaran dari Celery atau Sidekiq

  • "FP32 jauh lebih jarang digunakan pada workload ML modern, dan di hardware terbaru juga kurang dioptimalkan dibanding FP16 atau BF16. Jadi ini bisa menjadi salah satu alasan mengapa lebih mudah meningkatkan performa dibanding PyTorch pada kernel FP32"
    Para pengembang hampir tidak menginvestasikan waktu untuk mengoptimalkan versi kernel fp32 selama bertahun-tahun
    Menurut saya, yang benar-benar menarik adalah ketika performa bisa ditingkatkan pada kernel yang memang dikembangkan secara intensif dan benar-benar dipakai orang

    • Saya rasa hasil bagus seperti ini sebagian bisa dijelaskan oleh fakta bahwa NVIDIA tidak menyediakan dokumentasi yang cukup rinci untuk GPU mereka
      Pada prosesor dengan mikroarsitektur yang terdokumentasi dengan baik, programmer atau compiler bisa menulis program optimal secara deterministik, jadi sulit mendapatkan peningkatan besar lewat ML/AI yang melampaui sekadar menemukan solusi yang sudah diketahui
      Sebaliknya, pada kasus yang kurang terdokumentasi seperti GPU NVIDIA, menemukan program optimal sering kali memerlukan pencarian acak sambil merujuk contoh program yang sebelumnya sudah dioptimalkan, atau analisis reverse engineering tentang bagaimana hardware sebenarnya bekerja dalam situasi tertentu
      Dalam kondisi seperti ini, ML/AI bisa menunjukkan potensi, dan dengan belajar dari program-program bagus sebagai data, ia bisa menangkap undocumented behavior yang bahkan sulit ditemukan programmer manusia

    • Saya penasaran apakah mungkin peningkatan yang sudah diketahui pada kernel fp16/bf16 hanya dipindahkan begitu saja ke fp32

    • "Apakah maksudnya orang-orang sama sekali tidak menyentuh kernel fp32 selama bertahun-tahun?"
      Wah, kalau benar begitu, menurut saya keren sekali bahwa AI berarti berhasil menciptakan algoritma baru di wilayah yang belum punya solusi sebelumnya

  • Kesimpulan saya, seperti terlihat dari artikel ini, AlphaEvolve dari Google(di sini), dan kabar terbaru bahwa o3 menemukan zero day di kernel Linux(di sini)
    Saya merasa khususnya Gemini Pro 2.5 dan o3 telah mencapai level kemampuan baru, di mana ide-ide yang tidak bisa dilakukan model sebelumnya tiba-tiba bisa mereka lakukan

    • Menurut saya ini bukan soal tiba-tiba sesuatu yang sebelumnya tidak bisa lalu mendadak jadi bisa
      Yang terjadi adalah iterasi dan pengujian kini bisa dilakukan dengan kecepatan jauh melampaui manusia
      Dan karena sejumlah besar informasi bisa dimanfaatkan seketika
      Kita sekarang sampai pada titik di mana kombinasi informasi yang sangat besar, kemajuan, dan brute force yang diterapkan secara cerdas mulai berhasil di beberapa bidang aplikasi

    • Saya rasa contoh-contoh yang kamu sebut dan hasil kali ini memang punya banyak kemiripan
      Di teks utama juga ada pernyataan bahwa "loop iterasi saat pengujian bukan chatbot interaktif yang memeriksa hasil modifikasi kode satu per satu secara bergiliran, melainkan lebih mirip pencarian terstruktur yang secara aktif melakukan evaluasi paralel berdasarkan hipotesis optimasi yang jelas"
      Kesimpulan saya adalah bahwa sekarang, dengan kemampuan LLM sebagai dasar
      Kita telah belajar memanfaatkan fungsi evaluasi yang jelas, atau cara yang secara signifikan memperkecil ruang solusi dengan pola-pola serupa
      Bukan soal model mana melampaui model lain, atau hanya model tertentu yang bisa menyelesaikannya...
      Yang lebih bermakna menurut saya adalah kenyataan bahwa penerapan seperti ini kini terlihat jelas

    • Gemini Pro 2.5 terasa seperti AI pertama yang benar-benar bisa dipakai manusia, tetapi secara ketat sebenarnya baru saja melewati ambang itu
      Ada juga cukup banyak kasus di mana tingkat keberhasilannya turun di bawah 20%
      Kalau 3.0 keluar... rasanya itu bisa mulai sedikit menakutkan

    • Tunggu, maksudnya apa? Ini tidak ada hubungannya dengan kernel Linux, ini "kernel" dalam konteks pemrograman GPU
      Jangan-jangan kamu salah memahami seluruh isi artikelnya?

    • Menarik sih, tapi adakah bukti yang lebih kuat? Hasil sekali saja belum cukup meyakinkan

  • "Kode baseline memakai FP32 default, dan toleransi error-nya 1e-02"
    Dengan tingkat error seperti ini, operasi fp16 bisa dengan mudah menggantikan kernel "fp32"

    • Kalau dipikir satu langkah lagi, saya jadi curiga inti pekerjaan kali ini sebenarnya hanyalah mengganti sebanyak mungkin operasi fp32 di kernel itu menjadi fp16
      Perlu dicek seberapa sulit pekerjaan porting seperti ini dalam praktik
      Tetapi secara intuitif, rasanya tidak terlalu mengesankan
      Kalau pemikiran saya salah, saya harap para penulis menjelaskan bagian ini dengan jelas

    • Kalau begitu hasilnya jadi tidak berarti
      Entah mereka memeriksa error relatif atau tidak
      Mengganti float32 dengan float16 tidak ada artinya
      Presisi justru bisa dibilang satu-satunya alasan memilih float32
      Kalau karakteristik itu hilang, tidak ada lagi pembeda antarversi

  • Apa cuma saya yang membaca judul artikel ini lalu sempat mengira AI telah membuat kernel OS?

    • Saya juga begitu
  • Peningkatan kecepatan 400% memang luar biasa
    Tetapi yang paling menarik adalah metodologinya: bukan sekadar optimasi operasi sederhana di tiap iterasi, melainkan memaksa adanya tahap penalaran bahasa untuk mendorong keragaman pencarian
    Sangat menarik karena pendekatan ini benar-benar bekerja dengan baik

    • Saya kira ada teknik seperti map-elites atau island method yang dipakai, tapi sepertinya saya melewatkan bagian itu
      Menurut saya ini hanya evolusi memetik biasa
  • Hasil yang benar-benar menarik
    Orang-orang ini tampaknya terlalu bersemangat sampai langsung mempublikasikannya di blog
    Mungkin sebenarnya mereka juga ingin mendapat umpan balik sebelum publikasi resmi
    Saya tidak tahu apakah ini benar-benar jalan legendaris menuju "self improvement"
    Tetapi rasanya hasil seperti inilah yang memang akan terlihat di jalur tersebut

    • "Saya tidak tahu apakah ini benar-benar jalan menuju self improvement yang sesungguhnya"
      Metode seperti ini hanya efektif ketika ada fungsi evaluasi yang sangat jelas
  • Berbagi pengalaman saya: dalam upaya replikasi, kernel LayerNorm menurut saya tidak stabil secara numerik sehingga tidak bisa divalidasi
    Karena pengujian hanya dilakukan pada rata-rata 0 dan simpangan baku 1, gejala numerical cancellation tidak langsung terlihat
    Sebagai tambahan, belakangan saya mengetahui bahwa mereka kemudian membuat versi baru yang stabil secara numerik
    Menurut saya itu hal yang sangat baik

  • Hasil yang sangat keren
    Mereka memakai o3 dan Gemini 2.5 Pro
    Tapi sayangnya tidak disebutkan pihak mana yang menghasilkan kernel yang lebih baik

  • Menarik untuk mengamati bagaimana kode yang dihasilkan AI menangani area yang luas seperti fused kernel
    Misalnya ada gemm + relu + gemm + normalization dan sebagainya
    Kalau harus menyapunya dengan tuner atau ditulis satu per satu oleh manusia, itu pekerjaan yang cukup melelahkan

    • Tapi saya masih kurang paham apa tepatnya yang dimaksud "kernel" di sini dalam konteks AI
      Yang pasti ini bukan kernel OS