- Yapay zekanın ürettiği CUDA-C kernel’ları, PyTorch’un uzmanlarca optimize edilmiş kernel’larıyla benzer ya da daha iyi performans gösteriyor
- Tek bir LLM (büyük dil modeli), doğal dille optimizasyon fikirleri üretme ve çeşitli kod dallanmalarını yinelemeli olarak kullanarak, mevcut yöntemlere kıyasla optimizasyon çeşitliliği ve paralel arama açısından üstün performans elde ediyor
- Temsili benchmark sonuçlarında Matmul(101%), Conv2D(179.9%), Softmax(111.8%), LayerNorm(484.4%), Conv2D+ReLU+MaxPool(290.1%) gibi alanlarda PyTorch’a karşı ezici üstünlük görülüyor
- Mevcut “ardışık kernel iyileştirme” yaklaşımının sınırlarını aşmak için doğal dil akıl yürütmesi + dallanma yapısı uygulanarak, yüksek performanslı kernel’lar hızlı biçimde üretiliyor
- FP16, Flash Attention gibi güncel ML iş yüklerinde de ilerleme kaydediliyor ve gelecekte yapay zekanın kendi başına daha hızlı kernel’lar arayıp iyileştirdiği bir paradigmanın ana akım hâline gelebileceğini gösteriyor
TL;DR temel sonuçlar
- Stanford CRFM araştırma ekibi, yapay zekanın ürettiği yüksek performanslı CUDA-C kernel’larının mevcut PyTorch uzman tasarımı kernel’larla benzer ya da daha iyi hızlara ulaştığı örnekler buldu
- Başlangıçta amaç, sentetik veri üzerinden daha iyi kernel otomatik üretim modelleri eğitmekti; ancak yalnızca sentetik veri üretim sürecinin bile şaşırtıcı derecede hızlı kernel’ları otomatik olarak ortaya çıkardığı gözlemlendi
- Bu nedenle yöntem, performans benchmark’ları, optimizasyon stratejileri ve ileriye dönük yönelimler erkenden paylaşıldı
- Benchmark: Nvidia L40S GPU temel alınmıştır. Performans(%): PyTorch referans çalışma süresi ÷ üretilen kernel çalışma süresi
- Matmul (FP32): PyTorch’a göre %101.3 (4096x4096 matris)
- Conv2D: %179.9 (girdi: 100, 3, 224, 224; AlexNet Conv1 boyutu)
- Softmax: %111.8 (4096x65536 tensör)
- LayerNorm: %484.4 (16, 64, 256, 256 tensör)
- Conv2D + ReLU + MaxPool: PyTorch reference’a göre %290.1,
torch.compile()’a göre %189.0
Araştırma motivasyonu ve yöntem
- Başlangıç hedefi kernel üretim modeli eğitimi için sentetik veri üretmekti; ancak deney sürecinde, sistemin kendi ürettiği kernel’ların beklentilerin ötesinde yüksek performansa ulaştığı görüldü
- KernelBench (Stanford’un açık benchmark’ı, Aralık 2024’te yayımlandı) kullanıldı
- Verilen torch kodu için LLM, en yüksek hızlı kernel’ı yeniden yazıyor
- Doğruluk, girdi/çıktı sonuçlarının sayısal eşdeğerliğiyle doğrulanıyor
- Mevcut yaklaşım: kernel’ı adım adım küçük değişikliklerle geliştirilen ardışık düzeltme döngüsü
- Dezavantajları: fikir çeşitliliği eksikliği, aynı optimizasyonların tekrarı, yerel optimumlara yakınsama
- İyileştirme fikri
- Optimizasyon fikirlerini doğal dille üretip kaydettikten sonra, bu fikirlerin kod uygulama dallarını aynı anda birden fazla biçimde üretmek
- Her turda birden fazla optimizasyon denemesini paralel yürütmek → en yüksek performanslı kernel’ı bir sonraki turun tohumu (seed) olarak belirlemek
- Böylece sınırlı arama yinelemeleri içinde çeşitli optimizasyon stratejilerini keşfetmek ve paralel arama yapmak mümkün oluyor
Optimizasyon fikri örnekleri
- Bellek erişimi optimizasyonu: global/shared/register bellek hiyerarşisinin verimliliğini artırma
- Asenkron işleme ve gecikme gizleme: hesaplama ile veri taşımayı örtüştürme
- Veri tipi/hassasiyet optimizasyonu: FP16/BF16 kullanımı ve donanıma özgü işlemler
- Hesaplama ve komut optimizasyonu: işlem miktarı, komut sayısı ve donanıma özel komutların en verimli kullanımı
- Paralellik ve occupancy: SM’lerin (Streaming Multiprocessors) kullanımını en üst düzeye çıkarma
- Döngü/dallanma/indeksleme optimizasyonu: döngüleri azaltma, gereksiz indeks hesaplarını kaldırma
Kernel optimizasyonunun gerçek süreci (Conv2D örneği)
- Tur bazında optimizasyon fikirleri ve performans iyileştirme akışı
- İlk aşama (0. tur): basit CUDA portu (PyTorch’un %20 hızı)
- Sonraki turlar: → okuma önbelleği kullanımı → FP16 Tensor Core işlemleri (GEMM dönüşümü) → çift tamponlama/pipeline → önceden indeks hesaplama/paylaşımlı bellek → vektörleştirme → K-loop eşzamanlı tamponlama gibi ileri düzey GPU mimarisi kullanımı
- Nihai sonuç (13. tur): PyTorch’a göre %179.9 performans
- Gerçek kodda ileri seviye CUDA programlama teknikleri yoğun şekilde kullanılıyor
- Her turda yeni fikirler doğal dille üretiliyor, birden fazla uygulama paralel deneniyor ve en iyi kod seçiliyor
Çıkarımlar ve anlamı
- Yapay zeka tabanlı kernel üretimi, güçlü arama döngüleri ve doğal dil tabanlı çeşitli optimizasyon fikirlerinin birleşimiyle insan uzman seviyesini aşabilir
- Bazı güncel operatörlerde (FP16 matmul, Flash Attention) şu an için performans hâlâ PyTorch’un gerisinde
- Son dönem donanımlarda FP32 hesaplama, FP16/BF16’ya kıyasla görece daha az optimize edildiğinden, bu alanda performans avantajı mümkün görünüyor
- Sınırlı arama token’larıyla bile (girdi/çıktı toplam 7 milyon token) performansın sürekli arttığı doğrulandı
- AlphaEvolve, Gemini 2.5 Pro gibi son dönem araştırmalar da yoğun dallanma + doğrulama tabanlı aramanın yeniden eğitim olmadan da çarpıcı performans artışları sağlayabildiğine işaret ediyor
- Gelecekte bu yaklaşımın sentetik veri ve yüksek performanslı kernel’ları büyük ölçekte üretip, yapay zekanın kendini iyileştirdiği döngülere evrileceği öngörülüyor
Sonuç
- Yapay zeka tabanlı otomatik kernel üretimi ve optimizasyonu, uzmanların elle yazdığı seviyee zaten ulaşmış durumda; yakın gelecekte model + dallanma tabanlı arama + doğrulama birleşimiyle kendi kendini iyileştiren yapay zeka sistemleri mümkün olabilir
- PyTorch ve TensorFlow gibi framework’lerin performans sınırlarının yapay zeka tarafından bağımsız biçimde aşılabileceği ihtimali güçleniyor
Ek: Conv2D kernel’ının tam kodu
- Gerçek fonksiyon ve kernel’ın tam kaynak kodu yer alıyor (ayrıntılı kod burada atlanmıştır)
- Kod içindeki başlıca özellikler:
- paylaşımlı bellek vektörleştirmesi, K-dim hiyerarşik double-buffering, CUDA WMMA, warp-level output buffer vb.
- gerçek zamanlı dinamik indeks hesaplama, bias işleme, K döngüsü içinde gecikmeli veri eşzamanlı yükleme vb.
- Tam örnek kod ve örnek kernel’lar GitHub deposunda incelenebilir
2 yorum
Bir tür ansambl tekniği demek gerekir sanırım. Gerçekten etkileyici.
Hacker News görüşleri
Bu yazının yazarlarının "AI ajanları"na bakışını oldukça ilginç buluyorum
Çoğu insan ajanları insan çalışanlar gibi düşünme eğiliminde
Paralel çalışan az sayıda ajanı (çoğu zaman yalnızca bir tane) kurup, her birinin döngü içinde aynı anda sadece tek bir işle uğraşmasını sağlıyorlar
Hâlâ sabit sayıda personelin olduğu, çalışanların aynı anda yalnızca tek bir iş yapabildiği ve görev değiştirmenin yavaş olduğu bir dünyada kalmış durumdayız
Ama LLM'ler böyle değil
Pratikte istediğiniz kadar, neredeyse sonsuz sayıda ajanı istediğiniz anda oluşturabilirsiniz
LLM isteklerini seri işlemekle paralel işlemek arasında maliyet farkı yok
Bunu fark edince, her ajanın gerektiğinde kendini birçok alt ajana dallandırdığı bir örüntü doğal olarak ortaya çıkıyor
Yazarların denediği yöntem tam da bu
Ajanları "task" ya da "job" gibi görüp, Celery veya Sidekiq'tan öğrenilenleri uygulayan bir bakış açısı daha uygun gibi geliyor
"FP32, modern ML iş yüklerinde belirgin biçimde daha az kullanılıyor ve modern donanımda FP16 ya da BF16 kadar iyi optimize edilmiyor. Bu da FP32 kernel'lerinde PyTorch'tan daha iyi performans elde etmenin daha kolay olmasının nedenlerinden biri olabilir"
Geliştiriciler yıllar boyunca fp32 sürümü kernel'leri optimize etmeye neredeyse hiç zaman ayırmamış
Asıl ilginç olanın, gerçekten yoğun biçimde geliştirilen ve insanların fiilen kullandığı kernel'lerde performansı artırabilmek olacağını düşünüyorum
NVIDIA'nın GPU'lar hakkında yeterince ayrıntılı dokümantasyon vermemesi nedeniyle bu iyi sonucun kısmen açıklanabildiğini düşünüyorum
Mikromimarisi iyi belgelenmiş işlemcilerde programcılar ya da derleyiciler belirleyici biçimde en iyi programı yazabildiği için, zaten bilinen çözümleri yeniden bulmanın ötesinde ML/AI ile büyük iyileştirmeler elde etmek kolay olmaz
Buna karşılık NVIDIA GPU'ları gibi daha az belgelenmiş durumlarda, en iyi programı bulmak için daha önce optimize edilmiş program örneklerine bakarak rastgele arama yapmak ya da gerçek donanımın belirli durumlarda nasıl davrandığını tersine mühendislikle çözmek gerekebiliyor
Böyle durumlarda ML/AI potansiyel gösterebilir; iyi yazılmış programları veri olarak öğrenerek, insan programcıların da bulmakta zorlanacağı undocumented behavior kalıplarını yakalayabilir
Acaba fp16/bf16 kernel'leri için zaten bilinen iyileştirmeler sadece fp32'ye taşınmış olabilir mi diye merak ediyorum
"İnsanlar yıllardır fp32 kernel'lerine hiç dokunmamış mı yani?"
Vay, eğer öyleyse, AI'nın önceden hazır bir çözüm olmayan bir alanda yeni algoritmalar üretmiş olması gerçekten harika olurdu diye düşünüyorum
Benim çıkardığım sonuç şu: bu makale, Google'ın AlphaEvolve'u(burada) ve yakın zamanda o3'ün Linux kernel'inde bir zero day bulduğu haberi(burada) birlikte düşünüldüğünde
özellikle Gemini Pro 2.5 ve o3'ün, önceki modellerin yapamadığı fikirleri birden gerçekleştirebildiği yeni bir yetenek seviyesine ulaştığını hissettiriyor
Bence bu, bir şeyin bir anda mümkün hâle gelmesi değil
asıl olsa insanlardan çok daha hızlı yineleme ve test yapabilme kapasitesine ulaşıldı
ve anında çok büyük miktarda bilgiden yararlanılabiliyor
Yani devasa bilgi birikimi, ilerleme ve akıllıca uygulanmış brute force birleşiminin bazı uygulama alanlarında başarı vermeye başladığı bir noktaya gelmiş durumdayız
Bahsettiğin örneklerle buradaki sonucun gerçekten çok ortak yanı olduğunu düşünüyorum
Metinde de "test zamanı yineleme döngüsü, sırayla kod değişikliklerinin sonucunu kontrol eden etkileşimli bir chatbot'tan ziyade, açık optimizasyon hipotezlerine göre agresif paralel değerlendirme yapan yapılandırılmış bir arama biçimine daha yakındır" deniyor
Benim vardığım sonuç, artık LLM yeteneklerini temel alarak
değerlendirme fonksiyonu açık olan ya da benzer örüntülerle çözüm uzayını ciddi biçimde daraltabilen problemleri ele almayı öğrendiğimiz yönünde
Hangi model hangi modeli geçti, ya da sadece belli bir model çözer gibi model karşılaştırmaları asıl mesele değil
Bu tür uygulamaların artık açıkça ortaya çıkıyor olması bana daha anlamlı geliyor
Gemini Pro 2.5'in insanların gerçekten kullanabileceği ilk AI olduğunu hissettim ama sıkı anlamda bakınca ancak o eşiği geçmiş durumda
Başarı oranının %20'nin altına düştüğü durumlar hâlâ sık yaşanıyor
3.0 çıktığında... işte o zaman biraz korkutucu olmaya başlayabilir diye düşünüyorum
Bir dakika, ne demek istiyorsun? Bunun Linux kernel'iyle ilgisi yok, GPU programlamadaki "kernel"den bahsediliyor
Yoksa bütün metni yanlış mı anladın?
İlginç ama daha güçlü bir kanıt var mı? Tek seferlik bir sonuç tam olarak ikna edici değil
"Referans kod varsayılan olarak FP32 ve tolerans 1e-02"
Bu kadar hata payıyla bir "fp32" kernel'ini fp16 işlemlerle kolayca ikame edebilirsiniz
Bir adım daha düşününce, bu çalışmanın asıl özünün ilgili kernel'de mümkün olduğunca çok fp32 işlemini fp16'ya çevirmek olup olmadığını merak ediyorum
Böyle bir taşıma işinin pratikte ne kadar zor olduğunu doğrulamak gerekir ama
sezgisel olarak bana o kadar da etkileyici gelmiyor
Yanılıyor olabilirim; öyleyse yazarların bu noktayı açıkça ele almasını isterdim
Bu durumda sonuç anlamsız hâle gelir
Göreli hatayı kontrol edip etmediklerini bilmiyorum
float32'yi float16 ile değiştirmek anlamlı değil
Sonuçta float32 seçmenin tek nedeni hassasiyet sayılır
Bu özelliği kaybederseniz sürümler arasında da ayırt edici bir fark kalmaz
Başlık yüzünden AI'nın bir OS kernel'i ürettiğini sanıp yazıyı okuyan tek kişi ben miyim acaba?
%400 hız artışı etkileyici ama
bence asıl ilginç nokta şu: her yinelemede yalnızca basit işlem optimizasyonu yapmak yerine, dil tabanlı akıl yürütme aşamasını bilinçli olarak araya koyup arama çeşitliliği üretmeleri
Bu yaklaşımın gerçekten işe yaramış olması çok ilginç
Bence bu sadece sıradan bir memetik evrim
Gerçekten ilginç bir sonuç
Bu insanlar heyecanlanıp bunu blogda paylaşmış gibi görünüyor
Aslında yayımlamadan önce geri bildirim alma niyetleri de olmuş olabilir
Bunun "kendini iyileştirme (self improvement)" için efsanevi yol olup olmadığını bilmiyorum
ama böyle sonuçlar tam da o yolda görülecek türden şeyler gibi duruyor
Bu yöntemler ancak son derece açık bir değerlendirme fonksiyonu olduğunda işe yarıyor
Kendi deneyimimi paylaşayım: replication denemesinde LayerNorm kernel'inin sayısal olarak kararlı olmadığını gördüm, dolayısıyla doğrulanabilir sayılmaz
Testler yalnızca ortalama 0, standart sapma 1 olacak şekilde yapıldığı için numerical cancellation etkisi hemen ortaya çıkmamış
Ayrıca daha sonra sayısal olarak kararlı yeni bir sürüm yaptıklarını da gördüm
Bunu takdir ediyorum
Gerçekten harika bir sonuç
o3 ve Gemini 2.5 Pro kullanılmış ama
hangisinin daha iyi kernel ürettiği ne yazık ki belirtilmemiş
AI'nın ürettiği kodun fused kernel gibi daha geniş alanları nasıl ele aldığını gözlemlemek ilginç olurdu
Örneğin gemm + relu + gemm + normalization gibi şeyler olabilir
Bunları bir tuner ile baştan sona taramak ya da bir insanın tek tek yazması oldukça zahmetli olur
OS kernel'i olmadığı kesin