- LLM in a Flash, DRAM’den daha büyük LLM parametrelerini flash bellekte tutup yalnızca gereken kısımları DRAM’e getirerek, sınırlı belleğe sahip cihazlarda da çıkarımı mümkün kılıyor
- Flash belleğin erişim özelliklerini dikkate alan çıkarım maliyeti modeli temelinde, aktarılan veri miktarını azaltıyor ve daha büyük, ardışık chunk okumalarını teşvik ediyor
- windowing, daha önce etkinleşmiş nöronları yeniden kullanırken, row-column bundling flash’ın sıralı erişim avantajından yararlanarak darboğazı azaltıyor
- İki teknik birleştirildiğinde kullanılabilir DRAM’in en fazla 2 katı büyüklüğündeki modeller çalıştırılabiliyor; basit yüklemeye kıyasla çıkarım CPU’da 4~5 kat, GPU’da 20~25 kat daha hızlı oluyor
- Seyreklik farkındalığı, bağlama uyarlanabilir yükleme ve donanım odaklı tasarım bir araya gelerek bellek sınırlı cihazlarda LLM çalıştırma olasılığını artırıyor
Flash bellek tabanlı LLM çıkarımı
- Büyük dil modelleri, çeşitli doğal dil işleme görevlerinde yüksek performans sunsa da hesaplama yükü ve bellek gereksinimleri büyük olduğundan DRAM kapasitesi sınırlı cihazlarda çalıştırılmaları zor
- LLM in a Flash, model parametrelerini flash bellekte saklayıp çıkarım sırasında yalnızca gerekli verileri isteğe bağlı olarak DRAM’e getirerek bu kısıtı ele alıyor
- Yaklaşımın merkezinde, flash belleğin çalışma biçimine göre uyarlanmış bir çıkarım maliyeti modeli var
- Flash’tan aktarılan veri miktarını azaltacak şekilde optimize ediyor
- Verileri daha büyük ve ardışık chunk’lar halinde okuyacak şekilde tasarlanıyor
Aktarım miktarını ve okuma desenlerini azaltan iki teknik
- windowing, daha önce etkinleşmiş nöronları yeniden kullanarak flash’tan DRAM’e taşınması gereken veri aktarım miktarını azaltıyor
- row-column bundling, flash belleğin sıralı veri erişiminde güçlü olması özelliğine uygun olarak flash’tan okunan veri chunk’larının boyutunu büyütüyor
- İki teknik birlikte kullanıldığında, kullanılabilir DRAM’den en fazla 2 kat daha büyük modeller çalıştırılabiliyor
- Basit yükleme yöntemiyle karşılaştırıldığında çıkarım hızındaki artış donanıma göre farklılık gösteriyor
- CPU’da 4~5 kat hızlanıyor
- GPU’da 20~25 kat hızlanıyor
- Bu tasarım, seyreklik farkındalığını, bağlama uyarlanabilir yüklemeyi ve donanım odaklı tasarımı bütünleştirerek sınırlı bellek ortamlarında LLM çıkarımını mümkün kılıyor
1 yorum
Hacker News yorumları
Makale, zaten oldukça karmaşık olan Deja Vu makalesinin seyreklikten yararlanma tekniğinin üzerine kurulduğu için anlaması zaman aldı.
Deja Vu, ağırlık seyrekliği düşük olan modellerin bile “bağlamsal seyrekliğinin (contextual sparsity)” yüksek olduğunu varsayıyor. Yani matris çarpımı sonucunda oluşan vektörde çok sayıda 0 ortaya çıkıyor, ancak hangi konumların 0 olacağı girdiye göre değişiyor.
Bu seyrekliği kullanarak matrisin bazı satırlarını yüklemeyi atlayabilirsiniz; performans kazancı elde etmek için hangi satırların atlanacağını önceden tahmin etmek gerekir ve bu tahmin düşük-ranklı bir matrisle yapılabilir.
Apple makalesi, bu bulgunun yalnızca RAM yükleme performansına değil, bant genişliğinden büyük ölçüde ödün vermeden flash bellekten yükleme yapmaya da yardımcı olduğunu öne sürüyor.
Attention matrisi görece hafif; seyrek biçimde yüklenmesi gereken kısım ise FFN. Ayrıca FFN girdisini değil de ReLU katmanının çıktısını tahmin ederseniz çok daha iyi seyreklik elde edilebiliyor. “Matris çarpımından sonra, ReLU’dan önce bu vektör yuvası negatif olacak” diye tahmin edebiliyorsanız ilgili matris sütununu yüklemeyip çıktı olarak 0 verebilirsiniz.
Öneri şu: FFN’deki satırların çoğunu hiç yüklemeye gerek yok; her FFN için son kullanılan satırlardan oluşan bir önbellek tutulur ve gerektiğinde flash’tan güncellenir. Parça yükleme ile projeksiyon katmanları arasındaki korelasyona dair başka ayrıntılar da var, ancak temel içgörü bu kısım gibi görünüyor.
FFN, Feed Forward Network’tür ve transformer’larda en büyük bloklardır.
Gerçek performans farkı ortaya çıkmaya başlamadan önce modelin ne kadarını yüklememeye dayanabileceğini merak ediyorum.
Örneğin tamamı RAM’e alındığında elde edilen performansın %90’ını korumak için belleğin yalnızca yarısını kullanmak yeterli mi, %90’ı mı gerekli, yoksa %95’i mi; bunu bilmek isterdim.
Sonuçta mesele, RAM’i azalttığınızda maksimum performansa kıyasla performansı ne kadar hızlı kaybettiğiniz. Grafik, az RAM bulunan durumda bu algoritmayla temel algoritmayı karşılaştırıyor; bu farklı bir şey ama yine de iyi bir soru.
8 GB’lık bir modelin tamamını telefon belleğine almadan iyi performans elde edilebiliyorsa bunun açıkça faydası var.
Makalenin tamamı okunmaya değer; oldukça ilginç bir çalışma: https://arxiv.org/pdf/2312.11514
Makalede vurgulanan nokta, veri aktarımını en aza indirmek ve flash bellek aktarım hızını en üst düzeye çıkarmak için iki tamamlayıcı teknik.
Windowing, yakın zamanda hesaplanan token’ların aktivasyon değerlerini yeniden kullanırken yalnızca son birkaç token için gereken parametreleri yükleyen bir yöntem; böylece ağırlık yükleme I/O isteklerinin sayısını azaltıyor.
Row-column bundling ise up-projection ve down-projection katmanlarının satır ve sütunlarını birbirine ekleyerek saklıyor; böylece flash’tan daha büyük, ardışık parçalar okunuyor ve büyük parçalar okunarak aktarım hızı artırılıyor.
Teorik olarak modelin bir kısmı flash’ta olduğunda tek token çıkarım süresi, tüm model RAM’deykenki çıkarım süresine flash’ta bulunan model kısmını yükleme süresinin eklenmesine eşit olmalı.
Flash’a geri yazmanın gerekmediğini varsayıyorum ama LLM uzmanı değilim, yanılıyor olabilirim.
Katman sayısı 10’dan çok fazlaysa RAM’de yalnızca küçük bir bölüm bırakıp katmanları tek tek yüklemek mümkün gibi görünüyor. Çoğu LLM’de onlarca katman olduğu için bu makul.
Çıkarım sırasında RAM darboğaz değilse, mevcut katmanın çıkarımı yapılırken bir sonraki katmanı flash’tan RAM’e DMA aktarımıyla taşımak da mümkün olabilir. Tek işlemcili sistemlerde RAM darboğazı nedeniyle pek işe yaramayacak gibi.
Çift işlemcili bir sistemde ise bir işlemci bir sonraki katmanı RAM’e yüklerken diğer işlemci önceki katmanın çıkarımını yapabilir; böylece az RAM’le bile çok büyük bir LLM çalıştırılabilir gibi geliyor.
Şu anda yeni bir LLM yapay zeka makinesi toplamak için kullanacağım parça yığınının yanında oturuyorum. z840 çift işlemcili; bu tür şeyleri bizzat kurcalamayı dört gözle bekliyorum.
Apple cihazlarının, rakiplerinin benzer cihazlarıyla karşılaştırıldığında RAM'inin çok az olduğu göze çarpıyor.
Bunun bir kısmı Apple yazılım ekiplerinin Objective-C gibi daha verimli diller kullanmasından, bir kısmı da iOS uygulamalarının çok çeşitli ekran çözünürlüklerini hedeflemek zorunda olmamasından kaynaklanıyor. Bu yüzden yüksek çözünürlüklü dokuları yükleyip sonra küçültme işi nispeten daha az oluyor.
Ayrıca Apple ölçeğinde satın alınsa bile RAM çok ucuzlamıyor; bu yüzden RAM'i artırmak, başka özellikler eklemeye kıyasla kâr marjına daha büyük darbe vuruyor.
Ancak LLM'ler doğası gereği çok RAM tükettiği için tüm bu tercihler geri tepiyor. Hangi bellek tasarrufu tekniği kullanılırsa kullanılsın, daha fazla RAM'e sahip rakipler daha büyük, daha iyi ve daha akıllı modeller koyabilecek.
Yakında bir Mac almak istiyorum ama ne kadar RAM sipariş etmem gerektiği konusunda gerçekten kararsızım. Bütçem sınırlı olduğu için daha da zor. Sınır olmasaydı en az 32 GB'a giderdim.
Apple'ın RAM fiyatlandırma politikasını değiştirmesini hâlâ umuyorum, ama muhtemelen boş bir beklenti.
İlgili uygulamaya da bakılabilir: https://opensource.apple.com/source/xnu/xnu-2050.18.24/libke...
Ayrıca Apple cihazları “jetsam” adlı bir özelliği destekliyor; bu özellik, yüksek öncelikli uygulamaların akıcı biçimde çalışmaya devam etmesi için kullanılmayan veya arka plandaki uygulamaları sonlandırarak bellek açıyor: https://developer.apple.com/documentation/xcode/identifying-...
Sessiz ya da neredeyse sessiz bir Linux dizüstü önerisine açığım. Çoğunda fanlar sert dönüyor; sessizlik uğruna CPU performansının bir kısmından memnuniyetle vazgeçebilirim. Sessiz modu kolayca açıp kapatabilmek de iyi olur.
Şimdiye kadar gördüklerim arasında MacBook Air'in sessizliğine yaklaşan olmadı; yanıldığımı gösterecek bir ürün varsa duymaktan memnun olurum.
Elbette daha ucuz olması ya da RAM'in değiştirilebilir olması gibi avantajlar da iyi olur. MacBook Air'i çoğunlukla web tabanlı servisler için ve büyük projeleri derlemek ile evde/kendi kendime barındırma işleri için kullandığım Linux sunucularına bağlandığım uzak terminal olarak kullanıyorum.
Takvimin öne çekildiği kesin, ama hipotezlerinin yanlış olduğunu düşünmüyorum.
Bu konuyu yalnızca sınırlı düzeyde anlıyorum; bu yöntemle telefonlarda çevrimdışı LLM çalıştırmanın mümkün olup olmayacağını merak ediyorum.
Mümkünse, gizli verileri sunucuya göndermeden yapay zeka destekli içerik moderasyonu yapmak gibi pek çok ilginç uygulamanın önü açılabilir.
Örneğin dün Apple A-series çiplerinde (iPhone) LLM çalıştırmayla ilgili bir GitHub Discussion burada paylaşılmıştı: https://news.ycombinator.com/item?id=38703161
Son yazıların “AI” değil LLM demesini seviyorum. Böylece bunun pazarlama abartısı değil, belirli bir teknoloji hakkında olduğu anlaşılıyor.
Bunun FlashAttention ile nasıl farklı olduğunu merak ediyorum. Benzer bir terim kullanıp özette farkı açıklamayınca kafa karıştırıyor.
Düzenleme: Görünüşe göre flash çerçevesi içinde iki farklı mekanizmayı genişletmişler. Makale başlığı daha iyi olabilirdi ama ilk birkaç sayfa içinde açıklanmış.
Sonuç bölümünde “bu özellik kullanıcıya nasıl sunulacak” gibi bir bölüm bekliyordum; ama muhtemelen makalenin kapsamı dışındadır.
Böyle bir özelliğin CoreML'in API çağrısı ya da ayarı olarak ortaya çıkıp örneğin use_flash bayrağının belirtilmesini mi gerektireceğini, yoksa kullanıcıya görünmeyen bir çalışma zamanı optimizasyonu mu olacağını merak ediyorum.
Apple'ın CoreML, Metal vb. geliştirme yol haritasını anlatan iyi bir sunum ya da konuşma bilen var mı, onu da merak ediyorum.
Apple bir İran şirketini mi satın aldı?
[0]: https://www.geekwire.com/2020/exclusive-apple-acquires-xnor-...
Yaklaşımların farklı olduğunu biliyorum ama ikisi de flash bellekten yararlandığı için bu makalenin FlashAttention [1]'dan en azından bahsetmesini beklerdim
[1] https://arxiv.org/abs/2205.14135
Anladığım kadarıyla FlashAttention, yerel belleği, özellikle de SRAM'i daha iyi kullanan erişim örüntüleriyle ilgili. Örneğin veriyi CPU L1 önbelleğinde ya da GPU'daki eşdeğer katmanda tutmak gibi
Başka bir deyişle FlashAttention, DRAM'den daha hızlı olan kısımla ilgili; bu makale ise DRAM'den daha yavaş olan kısma daha iyi offload etme sorununu ele alıyor
“OPT 6.7B modeli, örneğin FFN katmanı içinde belirgin bir %97 seyreklik gösteriyor” ifadesinde, bu metriğin tam olarak ne anlama geldiğini bilen var mı?
Katman değerlerinin %97'sinin 0 olduğu mu, yoksa boyutun %3'üne kadar sıkıştırılabileceği mi anlamına geliyor, merak ediyorum
Ancak etkinleşen %3 sabit olmadığı için kalan %97'yi tamamen ortadan kaldıramazsınız. Makale, etkin %3'ü oldukça doğru tahmin ederek doğruluktan çok fazla kaybetmeden bunu daha hızlı hale getirebileceğini söylüyor gibi görünüyor