AI PC'lerde yapay zeka performansı yetersiz: CPU, NPU'yu geride bırakıyor

 (github.com/usefulsensors)
1 puan yazan GN⁺ 2024-10-17 | 2 yorum | WhatsApp'ta paylaş
  • Microsoft Surface Pro 11th Edition'ın Qualcomm Arm tabanlı SoC'sinde yapılan NPU benchmark testinde, Windows AI PC'lerin öne çıkardığı hızlandırma performansından çok daha düşük bir işlem hacmi ölçüldü
  • Test, Onnx Runtime ve Qualcomm QNN execution provider kullanılarak transformer ailesi modellerde maliyeti yüksek katmanlara benzer büyük MatMul işlemlerini çalıştıracak şekilde kurgulandı
  • Örnek sonuçlarda CPU 821 Gigaops/s, NPU ise float giriş/çıkış kuantizasyon yapılandırmasında 225 Gigaops/s, 8-bit giriş/çıkışın da uygulandığı yapılandırmada 573 Gigaops/s değerine ulaştı
  • NPU'nun 573 Gigaops/s sonucu, Microsoft Surface Pro 11th Edition pazarlama materyallerinde yer alan 45 Teraops/s değerinin %1,3'ü seviyesinde; aynı model Nvidia Geforce RTX 4080 Laptop GPU üzerinde çalıştırıldığında 3.2ms ve 2,160 Gigaops/s elde ediliyor
  • Mevcut sonuçlar 2 Ekim 2024 itibarıyla geçerli; yazılım, framework ve sürücü düzeyindeki iyileştirmelerle gecikmenin düşmesi beklenebilir, ancak mevcut benchmark'ta CPU, NPU'dan daha hızlı

Surface'in Qualcomm NPU benchmark'ının amacı

  • Microsoft, Qualcomm Arm tabanlı SoC içeren Surface tabletleri Windows AI PC olarak satıyor ve makine öğrenimi modellerini daha hızlı ve verimli çalıştırabildiğini öne sürüyor
  • Useful Sensors, Qualcomm donanımı ve NPU'ya olumlu bakıyor ve kendi üçüncü taraf uygulamasını bu platforma taşımak için zaman ve kaynak ayırdı
  • Harici geliştiricilerin hızlı sonuç almasına yardımcı olacak çok sayıda kod örneği veya benchmark bulunmadığından, fiilen gözlemlenen performans küçük ve bağımsız bir proje olarak paylaşıldı
  • Ölçülen performans beklentinin belirgin biçimde altında kaldı; Android gibi başka platformlarda aynı donanımın etkili çalıştığı deneyimlendiği için, ileride uygulama, framework ve sürücü değişiklikleriyle iyileşme olasılığı açık bırakılıyor

Çalışma ortamı ve kurulum kısıtları

  • Testlerde Windows üzerinde Python betikleri kullanıldı
    • 2 Ekim 2024 itibarıyla Microsoft Store'daki Python, Arm mimarisini desteklemediğinden Qualcomm NPU erişimi için gerekli paketleri çalıştırmaya uygun değil
    • Sonuçlarda Python 3.11.9 Arm64 kurulum dosyası kullanıldı
  • Windows on Arm için önceden derlenmiş Onnx paketleri henüz bulunmadığından CMake ve Visual Studio derleyicisi gerekiyor
    • CMake, winget install cmake ile kuruluyor
    • Visual Studio olarak Visual Studio Community Edition kullanılıyor ve kurulum sırasında Desktop C++ Development workload'u seçiliyor
  • Python paketleri depo klasöründe py -m pip install -r requirements.txt komutuyla kuruluyor
    • Onnx branch'i, resmi py launcher derleme düzeltmesinin Onnx 1.16'ya backport edildiği sürüm
    • Qualcomm Onnx Runtime, daha yeni Onnx sürümlerinde Unsupported model IR version hatası verdiği için bu kombinasyon kullanılıyor
    • Qualcomm Onnx Runtime paketi olarak nightly build kullanıldı

Benchmark'ı çalıştırma ve çıktıyı yorumlama

  • Benchmark, py benchmark_matmul.py ile çalıştırılıyor
  • Onnx Runtime ilk çalıştırma sırasında çok sayıda log üretiyor
    • Örnek olarak, Snapdragon(R) X 12-core X1E80100 @ 3.40 GHz çip modelinin tanınmadığını belirten cpuinfo mesajı görülebiliyor
    • Grafiği sonlandırma ve tamamlanma aşamalarına ait log'lar da yazdırılıyor
  • Gerçek benchmark sonuçları en sonda gösteriliyor
    • NPU quantized compute, float I/O accuracy difference is 0.0100
    • NPU quantized compute and I/O accuracy difference is 0.0060
    • CPU took 8.42ms, 821,141,860,688 ops per second
    • NPU (quantized compute, float I/O) took 30.63ms, 225,667,671,183 ops per second
    • NPU (quantized compute and I/O) took 12.05ms, 573,475,650,364 ops per second
  • İlk iki satır, CPU ve NPU'nun sayısal sonuçlarının birbiriyle ne kadar uyumlu olduğunu gösteren doğruluk farkını ifade ediyor
  • Son üç satır ise modelin baştan sona çalıştırılması için geçen gerçek süreyi ve bu gecikmeden hesaplanan saniye başına işlem miktarını gösteriyor

Ölçülen model ve kuantizasyon yöntemi

  • Benchmark, OpenAI Whisper gibi transformer modellerde zaman alan katmanlara benzer 6 büyük matris çarpımını yeniden üretecek şekilde tasarlandı
    • Giriş şekli (6, 1500, 256) X (6, 256, 1500)
    • Sonuç şekli (6, 1500, 1500)
    • Model, 2 giriş ve 1 çıkışa sahip tek bir MatMul düğümünden oluşuyor
  • Model, Onnx model framework'ü ile anlık olarak oluşturulup ardından Onnx Runtime'a veriliyor
  • Referans model saf float sürümü ve yalnızca CPU'da çalışıyor
  • NPU'nun verimli çalışabilmesi için ağırlıklı olarak kuantize model gerekiyor; float16 desteği sınırlı
  • NPU için ilk yaklaşım, resmi ORT quantize_static() metodunu kullanıyor
    • Kolaylık için giriş ve çıkış tensörleri 32-bit float olarak bırakılıyor
    • Çalışma zamanı dönüşümleri grafiğin başında ve sonunda yapılıyor, geri kalan hesaplamalar 8-bit olarak yürütülüyor
  • Bu yapılandırmada NPU'nun dönüşüm işlemleri çok yavaş kaldı ve npu_quant_profile.csv içinde dönüşümlerin toplam sürenin %75'inden fazlasını aldığı görüldü
  • İkinci yaklaşım, 8-bit giriş ve çıkışa sahip eşdeğer model grafiğini programatik olarak oluşturuyor
    • Bu quantized compute and I/O yöntemi, float I/O sürümünden genellikle yaklaşık 3 kat daha hızlı
    • Profillemede zamanın çoğu beklendiği gibi matris çarpımına harcanıyor

Performans ölçümünde dikkate alınan değişkenler

  • Compute bound olup olmadığını görmek için matris şekilleri daha kareye yakın seçildi
    • Modern transformer modeller, eski convolution modellerinden farklı olarak büyük matris çarpımlarına dayanıyor
    • Katmanlar matris-vektör çarpımına yaklaştıkça ağırlıkların yeniden kullanımı azalıyor ve DRAM'den veri çekmek darboğaz haline gelebiliyor
    • tiny Whisper'ın orijinal matrislerinde k boyutu 64'tü, ancak bu benchmark'ta SIMD optimizasyonu için daha fazla alan bırakmak adına 256'ya çıkarıldı
  • Güç ayarları performansı artıracak şekilde yapılandırıldı
    • Windows enerji ayarlarının tamamı Best Performance olarak tutulmaya çalışıldı
    • Benchmark, tablet prize bağlıyken çalıştırıldı
    • Qualcomm Onnx Runtime'ın htp_performance_mode oturum seçeneği, denemelerde toplam gecikmeyi en aza indiren sustained_high_performance olarak ayarlandı
  • Model yapısı, yorumlamayı kolaylaştırmak için tek matris çarpımıyla sınırlandırıldı
    • Birden fazla katman, convolution ve statik ağırlık da kullanılabilirdi; ancak LLM'lerde ve modern modellerde yaygın transformer yapısını yansıtmak için dinamik girişli tek MatMul seçildi
  • Yapılandırma hatası olasılığı da tamamen dışlanmıyor
    • unsigned 8-bit kuantizasyon ve grafik içi qdq öğeleri kullanıldı
    • Belgelerdeki en iyi uygulamalar izlenmeye çalışıldı, ancak sürücü veya hızlandırıcı implementasyonunun hızlı yolunun dışına çıkılmış olabilir
  • Windows'ta AI hızlandırmaya erişim için API seçenekleri de değerlendirildi
    • DirectML yalnızca GPU erişimini destekliyor gibi görünüyor
    • OpenVino ilgili Arm donanımında çalışmıyor gibi görünüyor
    • Qualcomm QNN SDK doğrudan kullanıldığında da benzer performans sonuçları görüldü
    • TensorFlow Lite, Windows for Arm'ı desteklemiyor
    • Bu inceleme ve deneylerde, hem Microsoft hem de Qualcomm tarafından desteklendiği için Onnx, NPU hızlandırma performansı elde etmek açısından en uygun framework gibi görünüyor

Sonuçların yorumu

  • Sonuçlar 2 Ekim 2024 itibarıyla geçerli ve Microsoft Surface Pro 11th Edition üzerinde ölçüldü
    • SoC, Snapdragon(R) X 12-core X1E80100 @ 3.40 GHz
  • Float dönüşümleri hariç tutulsa bile NPU sonucu CPU'dan daha yavaş
    • Bu, hızlandırıcı perspektifinden ideal bir sonuç değil
    • Ancak enerji verimliliği veya sürdürülebilir performans açısından avantaj olasılığı tamamen dışlanmıyor
  • Ölçülen en yüksek NPU performansı olan 573 billion ops/s, Microsoft Surface Pro 11th Edition pazarlama materyalindeki 45 trillion ops/s değerinin %1,3'üne karşılık geliyor
  • Aynı model Nvidia Geforce RTX 4080 Laptop GPU üzerinde çalıştırıldığında 3.2ms sürüyor
    • Bu da 2,160 billion ops/s anlamına geliyor
    • Surface'in ölçülen NPU değerinden neredeyse 4 kat daha yüksek işlem hacmi sunuyor

İlgili okumalar

2 yorum

 
bungker 2024-10-18

Ryzen NPU'nun CPU'dan biraz daha hızlı olduğunu sanıyordum ama Snapdragon hevesim bir anda söndü
 
GN⁺ 2024-10-17
Hacker News yorumları

  • Sonuçlara bakınca genel olarak hesaplama kaynaklarının kullanımı pek iyi değil gibi görünüyor. CPU 8,4 ms, GPU 3,2 ms ise fark çok küçük; burada 10-20 kat fark beklenmiş olabilir.
    Bunun nedeni onnxruntime olabilir. Bazı donanım üreticileri yalnızca hesaplama birimlerini sunup düzgün desteği henüz eklemiyor gibi görünüyor; bunun ne kadar hızlı değişeceğini görmek gerekecek.
    Ayrıca NPU’nun amacı çoğu zaman “hız” sanılıyor ama asıl mesele düşük güç tüketimi. Hız hedefleniyorsa bellek darboğazını ortadan kaldırmak gerekir; bu da sonunda kendi belleğine sahip bir ASIC tasarlamaya götürür. Çoğu cihazdaki NPU, CPU çevresindeki SoC’ye bağlı olup yapay zeka hesaplamalarını offload etmek için kullanılır.
    Bu benchmark’ı CPU/NPU/GPU olmak üzere üç cihazda sonsuz döngüde çalıştırıp güç tüketimini ölçmek ilginç olurdu. NPU’nun en düşük güç tüketimine ve watt başına en iyi hesaplama performansına sahip olmasını beklerim.

    • NPU’nun gerçek nedeni pazarlama olabilir diye şüpheleniyorum. “NVDA 3,3 trilyon dolar değerinde mi? Bizim ürünümüze de yapay zekalı bir şeyler koyalım” gibi bir akış olabilir.
    • NPU’nun offload amacı da büyük. Kullanıma göre CPU ve GPU başka işlerle meşgul olabilir; NPU, birbirlerinden kaynak çalmadan kullanılabilecek ek bant genişliği sağlar.
      Örneğin yapay zeka fotoğraf filtresinde GPU önizlemeyi render ederken, CPU’nun arayüz ve kullanıcı girdisini işlemekle meşgul olma ihtimali yüksektir.
    • Bu, Nvidia’nın hendek avantajı. Neredeyse her şeyin CUDA için optimize edilmiş çekirdekleri var; bazı durumlarda da Apple Accelerate mevcut.
      Apple Accelerate, M4 öncesi CPU matris birimlerine ve NPU’ya erişmenin fiilen tek yoluydu. Bunun dışında bir şey kullanmak istiyorsanız, seçtiğiniz makine öğrenimi framework’üne patch göndermeye ya da eğitim ve çıkarım kodunu doğrudan yazmaya hazır olmanız gerekir.
    • onnxruntime kullanarak saf C ile bir uygulama geliştiriyorum; Python ile yapılmış benzer bir uygulamadan oldukça daha iyi performans gösterdi. Hâlâ elde edilebilecek çok performans iyileştirmesi var.
      Sonuçta Python da C çağırıyor, ama ne kadar performansın kaybolduğu epey ilginç.
    • Zamanlamayı düzgün ölçmüyor gibi görünüyorlar; genel olarak pazarlanan “süre” de çoğu zaman insanların düşündüğü ölçümle aynı olmayabiliyor. Yine de pazarlama rakamları bazen karşılaştırmayı kolaylaştırıyor.
      GPU kullanılıyorsa zamanlamaya asenkron işlerin dahil olup olmadığını hesaba katmak gerekir.
      time.time() safça kullanılırsa CPU yalnızca zamanı kaydeder; model(input.cuda()).cuda() ise veriyi GPU belleğine gönderip hesaplamayı başlatır, fakat işlem asenkron olduğu için sonuç gerçekten hazır olsun olmasın bitiş zamanı kaydedilebilir.
      Sistemi ve donanımı bilmiyorsanız beklemesi zor bir davranış. Yalnızca Python değil, çoğu dil yazdığınız koddan daha optimize bir biçime derlenecek şekilde tasarlanmıştır; kilit olmadığı için CPU işini engellemez.
      GPU işini gerçekten ölçmek için CUDA event timer’larına bakmak gerekir. PyTorch’ta bunun yolu torch.cuda.Event(enable_timing=True) kullanmaktır.
      Ek olarak bellek boyutu ve düzeni de karmaşıktır. Bu benchmark, NPU için dezavantajlı bir düzen kullanıyor. NPU ve GPU genelde channels last ister; bu yüzden [1,6,1500,1500] yerine [1,1500,1500,6] daha doğrudur.
      1500 ve 6 da tuhaf sayılar olduğu için NPU açısından iyi değildir; bu tür cihazların hâlâ yeni olduğu düşünülürse performans kaybı epey büyük olabilir.
      Daha ayrıntılı olarak şurada yazdım: https://news.ycombinator.com/item?id=41864828

  • Bu NPU’lar kayda değer miktarda silikon alanı kaplıyor; sonunda pek kullanılmazlarsa gerçekten yazık olur. Snapdragon X’te yalnızca NPU’yu ayıran bir die analizi bulamadım, ama benzer şekilde yaklaşık 50 TOPS hedefleyen AMD tarafı burada görülebiliyor ve yaklaşık 3 yüksek performanslı CPU çekirdeği kadar alan kaplıyor.
    https://www.techpowerup.com/325035/amd-strix-point-silicon-p...

    • Umarım LLM furyası biter de bir miktar sağduyu ve verimlilik geri gelir. Kişisel olarak bu ek donanımı kullanacağım bir iş yok; “GenAI” bana hiçbir fayda sağlamıyor ve işle ilgili görevlerimi de desteklemiyor.
      Daha da kötüsü, çoğu insan için de gerekli görünmüyor; yakın tarihli anketlerde yapay zekanın her yere sızmasına karşı tepkinin baskın çıktığı da görüldü. Böyle şeyler için ek ücret ödememeliyiz; isteğe bağlı olmalı.
      Böyle olursa “yapay zeka” primi ödemek isteyenlerin ne kadar az olduğu satışlardan ortaya çıkar ve bunun ne kadar abartılı ve gereksiz olduğu netleşir.
    • Modern çipler die’ın belirli bir oranını dark silicon olarak bırakmak zorunda. Aksi halde erirler ya da işe yaramayacak kadar throttling’e girerler. Bu tür bileşenler de o orana dahil.
      Bu yüzden bu parçaların amacı kullanılmak, ama fazla kullanılmamaktır.
      NPU yerine o transistörler ve die alanı çeşitli amaçlarla kullanılabilirdi, ama muhtemelen daha fazla yüksek performanslı CPU çekirdeği konmazdı. O zaman güç yoğunluğu çok artar ve kalıcı throttling olmadan çözülmesi zor ısıl sorunlar oluşurdu.
      [1] https://en.wikipedia.org/wiki/Dark_silicon
    • Ben de aynı fikirdeyim. Şu anda NPU’lu bir sistem almak için özellikle aramak gerekiyor, bu yüzden henüz bende yok; ama ileride varsayılan olarak dahil edilecek gibi görünüyor.
      Model çalıştırmayacak kişiler için israf gibi duruyor; başka hangi amaçlarla kullanılabileceğini merak ediyorum.
    • Snapdragon X hâlâ 12 çekirdekli ve hepsi aynı çekirdeklerden oluşan homojen bir yapı. Strix Point de 12 çekirdekli ama 4+8 düzeninde; “küçük” çekirdekler de ARM tasarımlarındaki küçük çekirdekler gibi varlık nedenini ortadan kaldıracak kadar performanstan feragat etmiyor.
      Tüketici yazılımları o seviyeye kadar ölçeklenmiyor; transistörleri CPU’ya daha fazla ayırarak ne yapılabilir ki diye düşünüyorum.
      Bu, Apple’ın SoC’lerine çok sayıda video motoru koymasının nedenine de benziyor. Karşılanabilir transistör bütçesiyle kullanacak pek fazla başka yer yok. Tek iş parçacıklı performans iyileştirmesi artık yalnızca transistör sayısıyla sınırlı değil ve yazılımlar çok iş parçacığını iyi kullanamıyor.

  • Bu tür cihazların amacının hızlı olmak değil, küçük modelleri çok düşük güçle çalıştırmak olduğunu düşünmüştüm. NPU’lu yeni bir AMD dizüstü kullanıyorum; NPU’da çalıştığı söylenen video efektini açsam da güç tüketimi değişmiyor, ama Nvidia Studio Effects kullanınca güç tüketimi artıyor.
    NPU, göz teması, arka plan bulanıklaştırma, otomatik düzeltme modelleri, transkripsiyon, OCR gibi küçük işler yapan, çok optimize edilmiş modellere yönelik görünüyor. Özellikle Windows’ta rewind özelliği için tam ekran OCR ve arama amaçlı embedding çalıştırdığını sanmıştım.

    • Özellikle de o cihaz Xilinx FPGA ise bunun daha da doğru olduğunu düşünüyorum. Yeni mobil Ryzen’e eklenenin performansı da 5 kat daha iyi.
      AMD son zamanlarda çok iyi işler yapıyor, ama bunu pek yüksek sesle duyurmuyor gibi. Şu özellikle ilginç: https://lore.kernel.org/lkml/DM6PR12MB3993D5ECA50B27682AEBE1...
      Düzenleme: FPGA değilmiş. Bugün öğrendim.
    • Benim anladığım da bu. Esas mesele düşük güç ve düşük gecikme.
      macOS’ta CoreML modellerini değerlendirince bunu görebiliyorsunuz. ANE, GPU’nun yaklaşık yarısı kadar zaman alıyor; GPU da CPU’nun yaklaşık yarısı kadar zaman alıyor. Gerçek çarpan modele göre değişiyor.
    • Düşük güç, doğrudan daha ucuz token demek ve daha karşılanabilir, daha sürdürülebilir kullanıma yol açıyor diye düşünüyorum. Tüketicinin genel olarak elde ettiği fayda burada. Çok güç tüketen GPU’lar araştırma, ticari kullanım ve kurumsal alanlara daha uygun görünüyor.
      Nvidia’yı tehdit edecek çip, akıllı telefon gibi kişisel cihazlarda yeterince iyi modeller çalıştırabilecek kadar ucuz bir çip ve bellek olacaktır.
      Genel kitle LLM’lerin faydasını kabul eder ve cihaz fiyatına küçük bir prim ödemeye istekli olursa, bu teknolojinin geleceğinin özünde mahremiyet sağlayan kişisel modeller olduğunu düşünüyorum.
      İnsanların ChatGPT gibi yerlere döktüğü kişisel bilgi miktarı şaşırtıcı. Reddit’e bakınca, yapay zeka sanal kız arkadaş uygulamalarına bağımlı kişilerin en karanlık zevklerini, savunmasız itiraflarını, hatta suç sayılabilecek konuşmalarını bile isimsiz uygulama şirketlerine teslim ettiği sıkça görülüyor.
      Google da Gemini geçmişi açıksa konuşma içeriklerini inceleyebileceğini açıkça belirtiyor.
      Daha büyük modeller gerektiren karmaşık token tahminleri için bulut LLM’lere sorulabilir, ama tüketici için mahremiyetin mutlaka garanti edilmesi gerekir.
      Günlük kişisel asistan, sohbet ve bilgi arama için en ileri düzey akıl yürütmeye ya da gösteri amaçlı LLM’lere ihtiyaç olduğunu düşünmüyorum.
    • Pixel’de cihaz üzerinde konuşma tanıma yayınlanırken duyduklarım ve Google’dan ayrıldıktan sonra Apple Neural Engine ile CPU’da ONNX işleri çalıştırırken gördüklerim, bunun doğru olduğunu düşündürüyor.
      Yine de yazının somut sonuçlarından biraz şüpheliyim. Qualcomm’un ONNX’i ve eski olabilir. Android tarafında Qualcomm yazılım mühendisliğine çok sövülürdü.
      Yine de yön doğru. Tüketici donanımındaki yapay zeka hızlandırma iddialarının çoğu neredeyse evrensel olarak abartıya yakın; istisnalar ise A) 1P yazılım kullanmanız ya da B) 1P içinde birinin gerçekten o özelliği kullanmanızı istemesi.
    • Doğru. Ancak böyle cihazları Python ile programlamak istemezsiniz. Özellikle yeni bir cihaz olduğundan optimizasyonların iyi taşınmamış olma ihtimali yüksek; bu yüzden iyi performans beklemek zor.
      TensorRT gibi şeyler kullansanız bile en baştan elle yazmak kadar hızlı olmayacaktır; Nvidia’nın buna çok sayıda insan ayırmasının da bir nedeni var. Yine de oldukça yaklaşır ve yazma süresini çok azaltır.
      Bu cihazlar genelde yinelenen benzer işlere optimize edilmiştir. Bu yüzden burada toplanan bilgilerin bir kısmının hatalı olabileceğini düşünüyorum.
      Bu NPU çiplerini bizzat kullanmadım, ama zamanlamaya güvenmek zor. Sondaki CUDA zamanlaması kodda düzgün ölçülmemiş olma ihtimali yüksek. Zaman ölçmek sanıldığından daha zor.
      Reklamı yapılan işlem sayıları yalnızca NPU üzerinde doğrudan yapılan işlemleri sayarken, asıl yazı NPU ve GPU ölçümlerine CPU işlerini de dahil etmiş olabilir. Belgelerde bir benchmark aracı var; muhtemelen benzer bir yöntem kullanmıştır. Isınmadan sonra varyansın nasıl olduğunu da merak ediyorum.
      Veri biçimi de yanlış gibi. Burada channels last gerekiyor. Belgeler de bunu doğruluyor.
      1500 sayısı da tuhaf; bu yüzden ek hatalar ortaya çıkabilir. 1536, 2048, 256 ya da daha küçük değerlerde sonuçlar değişebilir. Gerçek modeller tam çözünürlüklü görüntüleri işlemez; mimariyi modele göre optimize ediyorsanız şekil bilgisi önem kazanır. Makine öğreniminde şekil optimizasyonu oldukça önemlidir.
      Belgelere hızlıca bakınca ayarlar da uygunsuz görünüyor. “Model Workflow” veriyi 8 bit veya 16 bit kayan nokta olarak istediğini söylüyor, ama kayan noktanın da farklı türleri var. PyTorch’taki bfloat, torch.half veya torch.float16 ile aynı şey değil.
      Karma hassasiyet hâlâ kafa karıştırıcı bir konu; böyle bir sorun varsa düzgünce incelemeye değer. Yalnızca standart kuantizasyon prosedürünü çalıştırıp bırakmayı önermem. Başlangıç noktası olarak iyidir, ama “yeterince iyi” değilse orada durmamak gerekir.
      Yine de bu sonuçların işe yaramaz olduğunu düşünmüyorum. Sadece iyileştirilmesi gerekiyor. Bu tür işler sanılandan karmaşık ve bunun önemli bir kısmı teknolojinin yeni, ayrıntıların da hâlâ oturmakta olmasından kaynaklanıyor.
      CPU veya GPU, özellikle de CUDA ile karşılaştırırken, bunlara yüz binlerce insan-saat harcandığını; Python gibi yüksek seviyeli kütüphanelere bile en az on binlerce insan-saat girdiğini unutmamak gerekir. Bu cihazlar ortalama kullanıcının tercih ettiği dil soyutlama seviyesinde doğrudan kullanılmaya henüz pek hazır değil, ama donanıma yakın çalışmaya istekliyseniz oldukça faydalılar.
      PyTorch’ta GPU’nun asenkron işlerini ölçmek için CPU zamanlayıcısıyla model çıktısını sarmak yerine CUDA event’leri ve torch.cuda.synchronize() kullanmak gerekir.
      [1] https://www.thonking.ai/p/what-shapes-do-matrix-multiplicati...

  • NPU’ya model dağıtmak için ciddi ölçüde profil tabanlı optimizasyon gerekir. CPU’da iyi çalışan bir modeli NPU için optimize etmeden taşırsanız genelde hayal kırıklığı yaratan sonuçlar çıkar

    • CPU’nun güzelliği, ne kadar berbat olursa olsun her türlü kodu makul bir hızda öğütüp işleyebilmesinde
    • IREE veya OpenXLA gibi şeylerle uğraşan insanlarla her konuştuğumda, bu tür derleyicileri ve çalışma zamanlarını anlayıp kullanmanın başlı başına bir iş olduğu izlenimini edindim

  • GitHub deposundaki açıklama blogdan çok daha bilgilendirici
    onnx ile int8 matris çarpımı çalıştırıldığında performans yaklaşık 0.6TF
    https://github.com/usefulsensors/qc_npu_benchmark

  • Girdi matrislerini döşemeye ve yeniden kullanıma imkân verecek şekilde kareye daha yakın hâle getirdiklerini söylüyorlar ama olası optimizasyonların önemli bir kısmının Onnx’e girmemiş olmasına şaşırmam
    Qualcomm, NPU’ya doğrudan erişim sağlamıyor; kullanıcıların modeli bir framework ile dönüştürüp vermesini bekliyor gibi görünüyor. Benim deneyimime göre dönüştürme araçları genelde pek iyi değil ve birçok optimizasyonu kaçırıyor
    Dolayısıyla sorun “NPU kötü” olmaktan çok “dönüştürme aracı kötü” olabilir. Doğrudan erişim mümkün olana kadar bekleyeceğim ve dönüştürme araçlarına güvenmiyorum
    NPU’ların çok küçük makine öğrenimi modelleri ve çok hızlı fonksiyon yaklaşımı için iyi olduğunu düşünüyorum. Benim amaçladığım kullanım da bu. LLM’ler bugünlerde gözde olsa da, küçük modellerin gerçekten yararlı olduğu muazzam sayıda uzmanlaşmış iş var

    • Küçük modellerin yararlı olduğu uzmanlaşmış işlere örnek verebilir misin? Mümkünse küçük modelin bile önbellekte kalacak kadar sürekli çalıştığı ve o önbellek işgalini haklı çıkaracak kadar çok kullanıcıya değer sunduğu bir örnek iyi olur
      Böyle bir şey yok demek istemiyorum ama açıkçası ne olduğunu pek bilmiyorum, öğrenmek isterim
    • Ben de bunu söylemeye gelmiştim. Elite X’i kullanmadım ama önceki nesil cihazlarda, özellikle 865’te, hızlandırıcı olan compute DSP ve çok daha küçük NPU; çok özel ayarlar, özel toolchain derlemesi, RPC iletişimi gibi şeyler gerektiriyordu
      Umarım Elite X’in NPU’suna Copilot+ nedeniyle erişmek daha kolay hâle gelmiştir; ama asıl nokta şu: “Genel amaçlı bir modeli çalıştırınca sihirli biçimde NPU’ya ışınlanır herhâlde” diyecek kadar kolay olması mümkün değil

  • RTX 4080’in yaklaşık 40 TFLOPS yapabilmesi gerekirken burada yalnızca saniyede 216 milyar işlem raporlanmış. Bu durumda benchmark’ın yeniden incelenmesi gerekmez mi diye düşünüyorum
    FLOPS ölçümünde ciddi bir hata yapılmış olma ihtimali yüksek. CPU’nun NPU’yu yenmesi mümkün, ama düzgün bir karşılaştırma için uygulama senkronizasyonu olmadan birden çok matris çarpımı benchmark edilmeliydi

    • Bu sadece bir kısmı. Belgelere hızlıca göz atınca CPU inference’ın da karşılaştırılabilir şekilde yapılmadığı görülüyor

  • Benchmark (6, 1500, 256) X (6, 256, 1500) biçiminde bir matris çarpımı; yapay zeka dünyasında bu çok büyük bir boyut değil. Çok daha büyük matrislerde fark daha da açılır
    Örneğin küçük modellerden biri olan Llama 3.1 8B bile (batch, 14336, 4096) x (batch, 4096, 14336) gibi matris çarpımlarına sahip
    Bu benchmark’ın yeterince gerçekçi olmadığını düşünüyorum

  • Bu benchmark üzerinde Qualcomm NPU profilleyicisi qprof’u çalıştırdım. Profil sonucuna göre iş, NPU işlem gücünün büyük kısmını sağlayan tensor core’lara değil, vector core’lara dağıtılmış
    Kabaca hesaplayınca HMX’in HVX’ten 30 kat güçlü olduğu görülüyor
    İş yükü nispeten küçük olduğu için giriş/çıkış kuantizasyonu/dekuantizasyonu ve NCHW-NHCW eşlemesinin ek yükü nedeniyle donanım kapasitesi yeterince kullanılamıyor. Ağırlıkları ve girdileri 64’ün katlarına padding yapmak da performansa yardımcı olur
    Profil grafiği: https://imgur.com/a/2OKR93e
    Tahmini HVX işlem performansı int8’de 4 * 2 * 1.43 * 1024 / 8 = 1.46TOPS. Burada 4 vector core sayısı, 2 çevrim başına işlem sayısı, 1.43GHz HVX frekansı, 1024bit vektör register genişliği, 8bit ise hassasiyet

    • Formül formatı yanlış; 4 * 2 * 1.43 * 1024 / 8 olmalı

  • Asıl yazı başlığı “Benchmarking Qualcomm's NPU on the Microsoft Surface Tablet” olmalıydı
    Bu NPU’lar genelinde bir yazı değil; belirli bir NPU’ya, belirli bir benchmark ve belirli bir kütüphane/framework kombinasyonuyla bakıyor. Bu yüzden pratikte hiçbir şeyi kanıtlamıyor