Show HN: LLM çıkarım hızını 2 kat artırma olasılığı (Speeding up LLM inference 2x times (possibly))

 (asciinema.org)
1 puan yazan GN⁺ 2024-04-19 | 1 yorum | WhatsApp'ta paylaş

Effort nedir?

  • Effort, bir işi başarmak veya bir hedefe ulaşmak için harcanan enerji, zaman ve kaynakları ifade eder
  • Bu, engelleri aşmak veya istenen sonuca ulaşmak için gereken çaba ve emeği anlatır
  • Effort fiziksel de olabilir, zihinsel de olabilir
    • Ağır bir nesneyi kaldırmak veya maraton koşmak için kullanılan enerji gibi fiziksel çaba
    • Karmaşık bir sorunu çözmek ya da yeni bir beceri öğrenmek için gereken odaklanma ve zihinsel güç gibi zihinsel çaba
  • Kişisel gelişim, iş hayatı, eğitim gibi yaşamın çeşitli alanlarında başarı elde etmek için temel bir unsurdur

GN⁺ görüşü

  • Effort, yalnızca harcanan zaman ya da enerji miktarı değil; süreklilik, odaklanma ve motivasyon gibi çeşitli unsurların birlikte etkilediği bir kavramdır. Bu nedenle çok çalışmak her zaman başarıyı garanti etmez
  • Özellikle zihinsel effort gerektiren işlerde burn out yaşamamaya dikkat etmek gerekir. Uygun dinlenme ve ödüllerle effortu sürdürebilmenin yollarını bulmak önemlidir
  • Effort gösterme biçimi kişiden kişiye değişebilir. Kimi kısa sürede yoğun biçimde, kimi ise uzun vadede istikrarlı şekilde effort harcayabilir. Kendinize uygun yöntemi bulmak daha etkilidir

İlgili okumalar

1 yorum

 
GN⁺ 2024-04-19
Hacker News görüşleri

  • Algoritmanın özü, çalışma sırasında parametreleri budamak ve her grup içinde budanacak ağırlıkların mutlak değer sıralamasına göre daha az önemli ağırlıkları belirleyip bunları 0 yaparak ağırlık matrisini seyrekleştirmek gibi görünüyor.
    Model budama diye aratınca çok sonuç çıkıyor; https://arxiv.org/abs/2305.11627 de “büyüklük tabanlı budama”yı temel çizgi olarak ele alıyor ve https://arxiv.org/pdf/2301.00774.pdf çalışmasına atıf yapıyor.
    Makalelerin temel çizgiyi özensiz uygulayıp kendi yöntemlerini övmesi ya da bir sürü matematik terimiyle paketlemesi pek hoş değil. Asıl yazıdaki blog yazısı, arka plan bilgisi neredeyse olmayan birine bile yöntemi çok daha kolay anlatıyor.

    • Geçen ayı araştırmayı olabildiğince yeniden üretilebilir ve güvenilir hale getirmeye harcadım. İlk uygulama çok verimsizdi; Metal/GPU matris çarpımı işlemi hızlandıktan sonra bile, kıyaslama kolay olsun diye uygulamanın geri kalanını mümkün olduğunca Llama.cpp’ye yaklaştırmaya çok zaman harcadım.
      Bahsettiğin makalelerdeki yaklaşım statik gibi görünüyor ve %20–50 sonuçlarla gerçek hesaplamayı hızlandıran bir algoritma ortaya koymamışlar gibi. Zor kısmın büyük bölümü buydu. Bir gün zaman ayırıp ilgili literatürü düzgünce taramayı düşünüyorum.
      Sonunda insanların yorumlarda paylaştığı makalelerle birlikte bir atıflar sayfası eklemek istiyorum. Yakında birilerinin bu algoritmayı zaten derli toplu anlatan bir yazı bulabileceğini de düşünüyorum.
      Geliştirme sırasında gpt-4’e de sordum, Google’da da aradım; ama bulduklarım genelde statikti ya da tüm boyutları/katmanları rastgele kaldırıp yeniden eğitme yönündeydi. Bu fikirle tam olarak örtüşen bir şey bulamadım.
    • “Bir sürü matematik terimiyle kendi yöntemini paketleyip temel çizgiyi kötü uygulamak” bana kötü makale işareti gibi geliyor.
      Yazı ne kadar yoğun ve anlaşılması zorsa, içinde kötü bilimi saklıyor olma ihtimali de o kadar artıyor.

  • GPU uygulaması bölümündeki şu cümleyi sevdim:
    “GPU programlamaya yeni başlayan okur şimdi şöyle sorabilir: Bu nasıl çalışıyor?
    GPU programlama deneyimi olan okur ise şöyle sorabilir: Bu nasıl oluyor da çalışıyor?”

    • Anladığım kadarıyla bellek okumayı ve birkaç şeyi, genelde doğru yaklaşım sayılan yöntemin tersi olacak şekilde uygulamak gerekti.
      Metal’i gerçekten iyi bilen birinin bu kodu incelemesi güzel olurdu. Bu benim ilk GPU programlama denememdi.

  • “Matrisi ters çevirelim, öğeleri satır bazında sıralayalım ve çarpmaya bu yönden yeniden bakalım. Akıllı insanlar buna sıkıştırılmış seyrek satır (CSR) biçimi der. Şimdi çarpmak için vektördeki 1’i alıp 256 ile çarpar ve çıktı vektörünün 3. satırına ekleriz; böyle devam eder. Şimdi en düşük değerlerin bulunduğu son sütunu kesersek ne olduğuna bakalım.”
    CSR’nin çarpma sayısını azaltma biçimiyle bunun nasıl örtüştüğünü merak ediyorum.

    • Sorunu yeniden ifade edebilir misin? Tam anlayamadım.

  • Bu yöntem yarı-yapısal seyreklik, yani 2:4 seyreklik denilen şeye benziyor; bu yüzden açıkça karşılaştırmaya değer. Göz attığım kadarıyla bu teknik Apple Silicon için optimize edilmiş; %75 seyreklikte yaklaşık 2 kat hız, girdiye bağlı olarak çalışma zamanında uygulanan dinamik bir yöntem ve seyreklik derecesi seçilebiliyor.
    Buna karşılık 2:4 yarı-yapısal seyreklik, seyrek tensor çekirdekleri olan GPU’lar, yani Nvidia Ampere ve sonrası için optimize edilmiş; %50 seyreklikte yaklaşık 2 kat hız, modelin depolanmış halinde uygulanan statik bir yöntem ve %50 seyreklikte bu tekniğe göre sonuçlarının daha kötü olma ihtimali yüksek.
    Görmek istediğim karşılaştırma, yarı-yapısal seyrekliğin %50 seyreklik ve 2 kat hızlanma sonucu ile bu tekniğin %75 seyreklik ve 2 kat hızlanma sonucu.

    • Kontrol ettiğin için teşekkürler. Ben de daha fazla testin bir an önce çıkmasını bekliyorum.
      Apple Silicon’ı seçmemin nedeni geliştirmesinin kolay olmasıydı. Bu algoritmanın başka mimarilerde de iyi performans gösterme ihtimali var.

  • CSR kullanmış biri olarak bu şaşırtıcı değil. Daha yeni biçimler arasında block ELL gibi donanım özelliklerine daha iyi uyanlar da olabilir.
    Bu tür biçimler birleştirilemeyen okumaları ya da gather işlemlerini önler, ama kodu daha zor hale getirir.

    • Sonunda CSR deneyimi olan biriyle karşılaştığıma sevindim.
      bucketMul’da birleştirilemeyen okuma neredeyse yok ve normal CSR’den farklı bir veri yapısı kullanıyor. Burada açıklanıyor: https://kolinko.github.io/effort/bucketmul.html
      Her matris satırını 16 parçaya bölüyor ve hangi parçaların okunacağını seçiyor. Yazmalar tamamen doğrusal.
      Gerçi şu an söylediklerim mantıklı mı pek emin değilim. Bugün biraz geç oldu ve uzun bir gündü.

  • İyi bir fikir ve yazı. Ben de sinir ağı çıkarımında seyreklik alanıyla uğraşıyorum; bilinmesinde fayda olan birkaç nokta aklıma geliyor
    Yoğun matris-vektör çarpımı uygulamasıyla karşılaştırıldığında, bu algoritma algoritmik karmaşıklık ekliyor ama bellek trafiğini azaltıyor. Matris-vektör çarpımı genelde bellek darboğazına takılır; bellek erişimini azaltmak da verimi artırır. Ancak batch boyutu 1’in üzerine çıktığında bellek erişimi artık darboğaz olmaktan çıkar ve hız artışının çok hızlı kaybolması olasıdır
    Karşılaştırma için yalnızca aynı modeli değil, 2 kat daha hızlı mimariye sahip başka bir modeli de görmek isterdim. Örneğin bu yöntemin 13B parametreli bir LLM’e %50 seyreklikle uygulandığında 7B parametreli bir LLM’e kıyasla nasıl olduğunu, ya da temel bit genişliğinin yarısına kuantize edilmiş aynı LLM ile karşılaştırıldığında nasıl olduğunu merak ediyorum. Aynı süre içinde mevcut çıkarım framework’lerinden daha yüksek doğrulukta çıktı gösterebilirse ilginç bir makale konusu olabilir
    Çarpımları atladığı için yaklaşım hatası büyük olasılıkla gerçek sonuca göre mutlak değerce hep daha küçük olma yönünde sapacaktır. Bu sistematik hatayı düzelten bir düzeltme terimi eklenebilirse performans biraz daha iyi olabilir

    • Algoritmik karmaşıklık aslında artmıyor. Çarpım O(effrt * inDim * outDim), dispatch hesaplaması O(inDim), cutoff noktasını bulmak O(~inDim * log inDim)
      Big-O gösterimi GPU işleri için pek uygun değil, ama bu durumda kabaca doğru
      Asıl sorun GPU’nun mimari sınırları. Bu algoritma geleneksel yönteme göre daha fazla register/thread group/cache belleği gerektiriyor ve ana darboğaz da bu oluyor. Ayrıca tüm çarpımlar farklı bucket’lar kullandığı için işi MoE modellerindeki gibi paralelleştirmek basit değil
      Daha büyük mimariler için, fiilen 13B bir model olan Mixtral üzerinde çok test yaptım ve bana göre orada çok daha iyi dayanıyor. Effort’a göre çıkarım hızı da korunuyor; effort’a göre kalite ise %20–25 değil, %12–16’ya kadar okunabilir sonuçları koruyor. Testler sınırlıydı ve Mistral uygulamasını eklerken Mixtral uygulamasını bozduğum için kesin verim yok, ama yakında düzelteceğim
      Sezgisel olarak model büyüdükçe effort’ın daha fazla kırpılabileceğini düşünüyorum
      Çarpımları atlamanın bias yaratacağını ben de başta tahmin etmiştim, ama sezgilerin aksine öyle olmadı. Birkaç grafiğim var ama henüz yayımlamaya hazır değil
      Matris değerleri pozitif ve negatiflere dengeli dağıldığı için, belirli bir eşik değerinden sonra sonuç değerinde büyük bir drift olmuyor

  • Harika görünüyor. Yalnız 15ms gecikme, 60Hz dikey senkronizasyonun 16,7ms’sine benziyor
    Her token’da ekranı güncelliyorsanız, bir yerde senkronizasyona takılmasının nedeni bu olabilir

    • Değil. CPU ve GPU işlerini ayrı ölçüyorum; 15ms, kernel çağrıları arasında oluşuyor. Metin çıktısı vermesem de oluyor
      Yine de fikir için teşekkürler. Bunu ilk topluluk katkısı olarak kabul edeceğim :D

  • Gerçekten harika ve açık bir katkı. llama.cpp’nin bunu uygulayıp uygulamayacağını yakından izleyeceğim
    CPU çıkarımını hızlandırmanın yollarını arıyordum; effort fikrini gerçekten sevdim

    • Bunu geliştirmek maraton gibiydi, ana sayfaya çıkmasına sevindim
      İsmi chatgpt önerdi. Bu yaklaşımı tanıyamadığını söylediğine göre gerçekten yeni bir şey olma ihtimali var
      llama.cpp ve diğer projelerle iletişime geçmek istiyorum; uygulanırsa güzel olur. Kendim llama’ya patch yazmayı da düşündüm ama C++ ve o projenin ölçeği bana ağır geldi
      CPU çıkarımı da aynı şekilde hızlanacaktır. Üstelik ağırlıkların yalnızca bir kısmını, örneğin daha az önemli olanları atlayıp sadece %70’ini yükleyebileceğiniz için modeli eskisinden daha az VRAM ile çalıştırmak mümkün olacaktır. Ancak Q8 uygulaması hâlâ gerekli
      İlginçtir, llama.cpp ile benchmark karşılaştırması yapmaya çalıştığımda MB Air 16GB’de 7B/FP16 hızını bulamadım. Çünkü normal yöntemle çalıştırmak mümkün değil. Effort ile mümkün
      Benzer şekilde 96GB M2’de tam çözünürlükte ama kırpılmış Mixtral çalıştırdım. Normalde 114GB RAM gerekir, fakat ağırlıkların yalnızca %75’ini yükleyince akıcı çalıştı. Şu anda uygulamayı biraz bozduğum için çöp çıktı üretiyor; düzeltmem gerekiyor

  • İyi yazı. Basit kuantizasyonla karşılaştırınca VRAM başına performansın nasıl olduğunu gerçekten merak ediyorum
    Cross-platform bir sürüm uygulama planınız olup olmadığını da merak ediyorum

    • VRAM başına performans çok daha iyi değil. Çünkü hâlâ tüm ağırlıkları kullanan, ama her zaman hepsini kullanmayan bir yapı
      Elbette daha az ağırlık yüklemek de mümkün, ama ağırlıkları %20–30’dan fazla azaltınca kalite hızla kötüleşiyor gibi görünüyor
      Başka bir deyişle bu algoritma çıkarım süresini VRAM kullanımından ayırıyor
      Yine de effort kullanınca %75’e kırpılmış Q8’in Q6’dan daha iyi sonuç verip veremeyeceğini ben de merak ediyorum
      Ancak uygulamayı yeterince iyileştirip düzgün test etmek için sanırım birkaç hafta daha gerekecek

  • Bu yöntem yeniden eğitim yapmıyor; ama böyle bir yaklaşımı kuantizasyon ile birlikte kullanıp sonradan ek eğitim yapılırsa kaybedilen kalitenin bir kısmı geri kazanılabilir mi merak ediyorum
    Böyle şeyleri görmek güzel; performans ve maliyetin ileride ne kadar iyileşebileceğini kafada canlandırmak hoş. Açık kaynak olarak geliştirdiğiniz için teşekkürler

    • İlk bakışta mümkün görünüyor. Okuduğum kadarıyla kuantizasyonda kalitenin bir kısmını geri kazanmanın iki ana yolu var
      Biri sonradan yapılan post-training, diğeri ise eğitim sırasında kuantizasyon yapıp aktivasyonları ve gradyanları tam hassasiyette bırakan kuantizasyon farkındalıklı eğitim