· kaynak Hacker News – Front Page (native)
NEON kernel yaması, Arm CPU'larda llama.cpp prompt işleme hızını 6,5 kata kadar artırıyor
164 satırlık bir yama, llama.cpp'nin tiled K-quant matmul rutinine eksik olan Arm NEON kernelini ekliyor ve Arm sunucu çekirdeklerinde düşük bitli quantize modellerin prompt işleme verimini 6,5 kata kadar yükseltiyor.
Eksik olan kernel, artık yazıldı
llama.cpp, prompt işlemek için kullandığı matris çarpım rutinine yerel bir Arm kerneli kazandı; bu, Arm sunucu çekirdeklerinde düşük bitli quantize modellerin verimini 6,5 kata kadar artırıyor. Çalışma, Hacker News ana sayfasında görünen ve kerneli, llama.cpp v0.9.0'a karşı bir yamayı, benchmark verilerini ve araçları içeren silicon-forge-arm-neon-study adlı bir GitHub deposu olarak yayımlandı.
Depoya göre llama.cpp, düşük bitli quantize modellerde promptları Arm CPU'larda x86'ya kıyasla birkaç kat daha yavaş işliyor ve bunun nedeni tek bir rutin. Eylül 2026'da llama.cpp PR #27851 ile jbooth ve bartowski tarafından eklenen tiled K-quant matmul, yalnızca x86 için iç kernellerle geldi: AVX-512 VNNI, AVX2 ve düz AVX. Arm'da kendi kerneli olmayan formatlar — Q3_K, Q2_K ve IQ ailesi — her nokta çarpımı için ağırlık verilerini yeniden açan genel bir yola geri düşüyordu.
Yama ne yapıyor
Yama, SDOT nokta çarpımı talimatı etrafında kurulmuş bir NEON kerneli ekliyor ve derleyici dot-product uzantısına sahip bir Arm CPU'yu hedeflediğinde onu etkinleştiriyor. Bilinçli olarak küçük: iki dosyaya eklenen 164 satır; rutinin taşınabilir sürücüsü, tile formatı, açıcıları ve testleri olduğu gibi bırakıldı.
Depodaki yazıya göre hızlanmayı iki tasarım noktası sağlıyor. Desteklenen her biçimde ağırlık kodu, sapması (bias) çıkarıldığında işaretli bir bayta sığıyor; dolayısıyla kernel yükleme sırasında sapmayı çıkarıyor ve tek bir işaretli nokta çarpımı, sapma düzeltilmiş toplamı tam tamsayı aritmetiğiyle üretiyor. Ayrıca bir aktivasyon bandının 16 satırı yerinde birbirine örülüyor — x86 VNNI kernelinin kullandığı düzenin aynısı — böylece tek bir şerit başına SDOT talimatı dört farklı satırın kısmi toplamlarını biriktiriyor ve sonradan indirgenecek bir şey kalmıyor.
Ölçülen kazanımlar
Benchmarklar, AWS Graviton2, Graviton3 ve Graviton4 olarak kiralanan (Neoverse N1, V1 ve V2) üç Arm sunucu neslinde 4 iş parçacığı ve 512 tokenlık bir promptla Qwen2.5 1.5B-Instruct kullanıldı:
- IQ3_M: N1'de saniyede 11,5'ten 74,5 tokene (6,5x); V1'de 16,6'dan 80,8'e (4,9x); V2'de 21,7'den 92,6'ya (4,3x)
- IQ3_XS: N1'de 12,6'dan 74,9'a (5,9x)
- IQ2_M: N1'de 13,9'dan 60,6'ya (4,4x)
- Q3_K_M: N1'de 31,4'ten 64,5'e (2,1x)
- Q2_K: N1'de 25,7'den 50,6'ya (2,0x)
Eski bir yeniden paketleme yoluyla zaten Arm kerneli olan biçimler — Q4_K_M, Q5_K_M, Q6_K ve Q8_0 — değişiklik göstermiyor ve üretim (generation) hızı değişmiyor, çünkü üretim bu rutini kullanmıyor. Öncesi ve sonrası rakamlar aynı ikili dosyadan geliyor: GGML_CPU_TILED_MM=0 ortam değişkeni rutini kapatıyor ve Arm'da stok v0.9.0 davranışını yeniden üretiyor.
Doğrulama ve sınırlar
Kernel, rutin için llama.cpp'nin kendi testini geçiyor — üç çipte de 15 testin 15'i, ayrıca rastgele fuzz modunda 88'in 88'i — ve depo, hiçbir doğruluk hatası bulmayan satır satır bir okuma incelemesini belgeliyor. Yazarın kendi ifadesiyle eksik olanlar: insan bir kernel mühendisi tarafından inceleme, sanitizer derlemeleri ve gerçek promptlarda model çıktısının karşılaştırılması.
Belirtilen sınırlar kapsamlı. Yalnızca kiralık Arm sunucular ölçüldü; telefonlar, Apple Silicon veya Windows on Arm değil — yine de kullanılan talimat, Cortex-A55 ve A75'ten itibaren telefon çekirdeklerinde mevcut. Tek küçük model test edildi, 4 ve 8 iş parçacığıyla; inceleyen kişi, kazanımların yaklaşık 16 iş parçacığının üzerinde daralmasını, hatta tersine dönmesini bekliyor. Yalnızca prompt işleme yarar sağlıyor ve Arm verimi, çok iyileşmiş olsa da hâlâ x86 referansının altında — şimdi onu neyin sınırladığı profil edilmiş değil. Yalnızca 128-bit NEON kullanılıyor; SVE ve I8MM kullanılmıyor. İlgili proje ik_llama.cpp bu biçimler için kendi NEON kernellerini zaten sunuyor; burada benchmarklanmadılar.
Bilinçli olarak upstream'e gönderilmedi
Depo, yamanın llama.cpp'ye gönderilmediğini belirtiyor: projenin katkı kuralları, yapay zekâ tarafından üretilmiş koda yalnızca bir insan katkıcının her satırı anlaması ve pull request'i kendisinin yazması durumunda izin veriyor ve otonom ajanlara göndermemelerini söylüyor. Bu kurallara uyan herkes işi ileri görmeye davetli. Rutinin yazarının ayrıca, kodu mimari başına klasörlere ayıran ve bu yamanın üzerine yeniden uyarlanması gerekecek açık bir pull request'i var: #30200.
Köken notu alışılmadık: depo, kerneli, benchmarkları ve çalışmayı, Orbofi üzerinde Claude Fable 5.2 çalıştıran Nikita adlı bir yapay zekâ ajanına atfediyor; 2026-11-11'de test edildi ve ölçüldü.
Neden önemli
Prompt işleme — üretim başlamadan önce girdiyi hazmetten prefill aşaması — uzun bağlamları, getirilmiş belgeleri veya ajan geçmişlerini küçük yerel modellere beslerken çoğu zaman baskın maliyettir. Arm donanımında 2 ve 3 bit quantize modeller çalıştıran herkes için, model biçimlerinde hiçbir değişiklik olmadan 2x ile 6,5x arası bir prefill hızlanması anında pratik. Hikâye ayrıca açık kaynak altyapı çalışmalarında yeni bir örüntüyü gösteriyor: yapay zekâ tarafından yazılmış bir kernel, upstream projenin kendi test takımıyla doğrulanıyor ve açıkça yayımlanıyor — ama otonom ajanların bunu kendilerinin göndermesini yasaklayan bir proje politikasına saygı gösterilirken.
- #llama-cpp
- #arm
- #neon
- #quantization
- #llm-inference