Kurangnya Performa AI pada AI PC: CPU Mengungguli NPU

 (github.com/usefulsensors)
1 poin oleh GN⁺ 2024-10-17 | 2 komentar | Bagikan ke WhatsApp
  • Hasil menjalankan benchmark NPU pada SoC berbasis Qualcomm Arm di Microsoft Surface Pro 11th Edition menunjukkan throughput yang jauh lebih rendah daripada performa akselerasi yang diklaim oleh Windows AI PC
  • Pengujian disusun dengan menjalankan operasi MatMul besar yang mirip dengan layer mahal pada model keluarga transformer, menggunakan Onnx Runtime dan execution provider Qualcomm QNN
  • Pada hasil contoh, CPU mencatat 821 Gigaops/s, sementara NPU mencatat 225 Gigaops/s pada konfigurasi kuantisasi dengan input/output float, dan 573 Gigaops/s pada konfigurasi yang juga menerapkan input/output 8-bit
  • 573 Gigaops/s pada NPU hanya sekitar 1,3% dibanding 45 Teraops/s dalam materi pemasaran Microsoft Surface Pro 11th Edition; menjalankan model yang sama di Nvidia Geforce RTX 4080 Laptop GPU menghasilkan 3,2 ms dan 2.160 Gigaops/s
  • Hasil saat ini berlaku per 2 Oktober 2024, dan meski ada harapan latensi dapat diturunkan melalui peningkatan di tingkat software, framework, dan driver, pada benchmark saat ini CPU lebih cepat daripada NPU

Tujuan benchmark NPU Qualcomm di Surface

  • Microsoft menjual tablet Surface dengan SoC berbasis Qualcomm Arm sebagai Windows AI PC, dan mempromosikannya sebagai perangkat yang dapat menjalankan model machine learning dengan lebih cepat dan efisien
  • Useful Sensors memandang hardware Qualcomm dan NPU secara positif, serta menginvestasikan waktu dan sumber daya untuk mem-porting aplikasi pihak ketiganya ke platform ini
  • Karena tidak banyak contoh kode atau benchmark yang menunjukkan cara bagi developer eksternal untuk memperoleh hasil cepat, mereka memublikasikan performa yang benar-benar diamati sebagai proyek kecil independen
  • Performa terukur jauh lebih rendah dari ekspektasi, dan karena ada pengalaman bahwa hardware yang sama bekerja efektif di platform lain seperti Android, mereka tetap membuka kemungkinan peningkatan di masa depan melalui perubahan aplikasi, framework, dan driver

Lingkungan eksekusi dan batasan instalasi

  • Pengujian menggunakan skrip Python di Windows
    • Per 2 Oktober 2024, Python dari Microsoft Store tidak mendukung arsitektur Arm, sehingga tidak cocok untuk menjalankan paket yang diperlukan untuk mengakses NPU Qualcomm
    • Hasil menggunakan installer Python 3.11.9 Arm64
  • Karena belum ada paket Onnx prebuilt untuk Windows on Arm, diperlukan CMake dan compiler Visual Studio
    • CMake diinstal dengan winget install cmake
    • Visual Studio menggunakan Visual Studio Community Edition, dengan memilih workload Desktop C++ Development saat instalasi
  • Paket Python diinstal dari folder repositori dengan py -m pip install -r requirements.txt
    • Branch Onnx adalah versi yang mem-backport perbaikan kompilasi launcher resmi py ke Onnx 1.16
    • Kombinasi ini digunakan karena Qualcomm Onnx Runtime menghasilkan error Unsupported model IR version pada Onnx terbaru
    • Paket Qualcomm Onnx Runtime menggunakan build nightly

Menjalankan benchmark dan menafsirkan output

  • Benchmark dijalankan dengan py benchmark_matmul.py
  • Onnx Runtime mencetak banyak log pada eksekusi awal
    • Sebagai contoh, muncul pesan cpuinfo bahwa model chip Snapdragon(R) X 12-core X1E80100 @ 3.40 GHz tidak dikenali
    • Log tahap finalisasi graf dan tahap penyelesaian juga dicetak
  • Hasil benchmark sebenarnya ditampilkan di bagian akhir
    • 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
  • Dua baris pertama menunjukkan selisih akurasi untuk memastikan hasil numerik CPU dan NPU saling cocok
  • Tiga baris terakhir menunjukkan waktu wall-clock untuk menjalankan model dari awal sampai akhir, serta jumlah operasi per detik yang dihitung dari latensi tersebut

Model yang diukur dan metode kuantisasi

  • Benchmark dirancang untuk mereproduksi 6 perkalian matriks besar yang mirip dengan layer yang memakan banyak waktu pada model transformer seperti OpenAI Whisper
    • Bentuk input adalah (6, 1500, 256) X (6, 256, 1500)
    • Bentuk hasil adalah (6, 1500, 1500)
    • Model terdiri dari satu node MatMul dengan 2 input dan 1 output
  • Model dibuat secara langsung dengan framework model Onnx lalu diberikan ke Onnx Runtime
  • Model acuan adalah versi float murni dan hanya dijalankan di CPU
  • Agar NPU berjalan efektif, umumnya diperlukan model terkuantisasi, sementara dukungan float16 terbatas
  • Pendekatan NPU pertama menggunakan metode resmi ORT quantize_static()
    • Demi kemudahan, tensor input dan output tetap berupa float 32-bit
    • Konversi runtime dilakukan di awal dan akhir graf, sedangkan sisa komputasi berjalan dalam 8-bit
  • Pada konfigurasi ini, operasi konversi NPU sangat lambat, dan di npu_quant_profile.csv konversi menyumbang lebih dari 75% total waktu
  • Pendekatan kedua menyusun secara programatis graf model ekuivalen dengan input dan output 8-bit
    • Metode quantized compute and I/O ini biasanya sekitar 3 kali lebih cepat daripada versi float I/O
    • Dalam profiling, sebagian besar waktu digunakan untuk perkalian matriks sesuai ekspektasi

Variabel yang dipertimbangkan dalam pengukuran performa

  • Bentuk matriks dibuat lebih mendekati persegi dengan mempertimbangkan apakah beban bersifat compute bound
    • Model transformer modern, berbeda dari model convolution lama, berbasis perkalian matriks besar
    • Jika layer makin mendekati perkalian matriks-vektor, reuse bobot berkurang dan pengambilan nilai dari DRAM dapat menjadi bottleneck
    • Dimensi k pada matriks asli tiny Whisper adalah 64, tetapi pada benchmark ini dinaikkan menjadi 256 untuk memperluas peluang optimasi SIMD
  • Pengaturan daya disetel ke arah performa lebih tinggi
    • Pengaturan energi Windows diupayakan semuanya berada pada Best Performance
    • Benchmark dijalankan saat tablet terhubung ke daya
    • Opsi sesi htp_performance_mode pada Qualcomm Onnx Runtime disetel ke sustained_high_performance, yang dalam eksperimen menghasilkan latensi total terendah
  • Struktur model dibatasi pada satu perkalian matriks agar mudah ditafsirkan
    • Beberapa layer, convolution, dan bobot statis juga memungkinkan, tetapi untuk merefleksikan struktur transformer yang banyak digunakan pada LLM dan model modern, dipilih satu MatMul dengan input dinamis
  • Kemungkinan kesalahan konfigurasi juga masih ada
    • Digunakan kuantisasi unsigned 8-bit dan elemen qdq di dalam graf
    • Mereka berupaya mengikuti praktik terbaik dokumentasi, tetapi ada kemungkinan konfigurasi ini keluar dari jalur cepat implementasi driver atau akselerator
  • Pilihan API untuk mengakses akselerasi AI di Windows juga ditinjau
    • DirectML tampaknya hanya mendukung akses GPU
    • OpenVino tampaknya tidak berjalan pada hardware Arm tersebut
    • Penggunaan langsung Qualcomm QNN SDK juga menunjukkan hasil performa yang serupa
    • TensorFlow Lite tidak mendukung Windows for Arm
    • Dalam investigasi dan eksperimen ini, Onnx tampak sebagai framework yang paling sesuai untuk memperoleh performa akselerasi NPU, karena didukung oleh Microsoft maupun Qualcomm

Interpretasi hasil

  • Hasil berlaku per 2 Oktober 2024 dan diukur pada Microsoft Surface Pro 11th Edition
    • SoC-nya adalah Snapdragon(R) X 12-core X1E80100 @ 3.40 GHz
  • Bahkan setelah mengecualikan konversi float, hasil NPU lebih lambat daripada CPU
    • Dari sudut pandang akselerator, ini tidak ideal
    • Namun kemungkinan adanya keunggulan pada efisiensi energi atau performa berkelanjutan tidak dikesampingkan
  • Performa NPU tertinggi yang terukur, yaitu 573 billion ops/s, adalah 1,3% dibanding 45 trillion ops/s dalam materi pemasaran Microsoft Surface Pro 11th Edition
  • Menjalankan model yang sama di Nvidia Geforce RTX 4080 Laptop GPU memerlukan 3,2 ms
    • Ini setara dengan 2.160 billion ops/s
    • Throughput ini hampir 4 kali lebih tinggi daripada hasil pengukuran NPU Surface

Bacaan terkait

2 komentar

 
bungker 2024-10-18

Saya kira NPU Ryzen memang sedikit lebih cepat daripada CPU, tapi sekarang keinginan untuk Snapdragon langsung turun drastis.
 
GN⁺ 2024-10-17
Opini Hacker News

  • Melihat hasilnya, secara keseluruhan sepertinya pemanfaatan sumber daya komputasi kurang baik. Kalau CPU 8,4 ms dan GPU 3,2 ms, selisihnya terlalu kecil; di sini orang mungkin mengharapkan perbedaan 10–20 kali lipat.
    Penyebabnya bisa jadi onnxruntime. Tampaknya ada beberapa vendor hardware yang hanya menyediakan unit komputasinya, sementara dukungan yang layak belum menyusul; kita perlu melihat seberapa cepat ini berubah.
    Selain itu, banyak orang salah memahami tujuan NPU sebagai “kecepatan”, padahal intinya adalah daya rendah. Jika mengejar kecepatan, bottleneck memori harus dihilangkan, dan pada akhirnya kita akan merancang ASIC dengan memorinya sendiri. NPU di kebanyakan perangkat ditempelkan pada SoC di sekitar CPU untuk meng-offload komputasi AI.
    Akan menarik jika benchmark ini dijalankan dalam loop tanpa henti di tiga perangkat CPU/NPU/GPU lalu konsumsi dayanya diukur. Saya memperkirakan NPU paling rendah dan juga punya komputasi per watt terbaik.

    • Saya curiga alasan sebenarnya NPU mungkin adalah marketing. Bisa jadi alurnya seperti, “NVDA bernilai 3,3 triliun dolar, jadi mari masukkan sesuatu berbau AI ke produk kita.”
    • NPU juga sangat penting untuk tujuan offload. Tergantung penggunaannya, CPU dan GPU bisa saja sibuk dengan pekerjaan lain, jadi NPU menjadi bandwidth tambahan yang bisa dipakai tanpa saling berebut.
      Misalnya pada filter foto AI, GPU kemungkinan sibuk merender pratinjau, sementara CPU sibuk menangani UI dan input pengguna.
    • Inilah moat Nvidia. Hampir semuanya punya kernel yang dioptimalkan untuk CUDA, dan dalam beberapa kasus ada Apple Accelerate.
      Apple Accelerate pada dasarnya adalah satu-satunya jalur untuk mengakses unit matriks CPU sebelum M4 dan NPU. Kalau ingin memakai hal lain, Anda harus siap mengirim patch ke framework machine learning pilihan Anda, atau siap menulis sendiri kode training dan inference.
    • Saya membuat aplikasi dalam C murni memakai onnxruntime, dan performanya jauh lebih baik daripada aplikasi serupa yang dibuat dengan Python. Masih banyak peningkatan performa yang bisa didapat.
      Pada akhirnya Python memang memanggil C juga, tetapi cukup menarik melihat seberapa banyak performa yang hilang.
    • Sepertinya pengukuran timing-nya tidak dilakukan dengan benar, dan “waktu” yang umumnya dipasarkan juga sering berbeda dari metrik yang dibayangkan orang. Meski begitu, angka marketing kadang lebih mudah dibandingkan.
      Jika memakai GPU, perlu dipertimbangkan apakah pekerjaan asinkron termasuk dalam timing.
      Jika memakai time.time() secara naif, CPU hanya mencatat waktu, dan model(input.cuda()).cuda() mengirim data ke memori GPU serta memulai komputasi, tetapi karena bersifat asinkron, waktu selesai bisa tercatat tanpa memperhatikan apakah hasilnya benar-benar sudah siap.
      Ini perilaku yang sulit diharapkan jika tidak memahami sistem dan hardware-nya. Bukan hanya Python; sebagian besar bahasa dirancang agar dikompilasi menjadi bentuk yang lebih optimal daripada kode yang ditulis, dan karena tidak ada lock, pekerjaan CPU tidak diblokir.
      Untuk benar-benar mengukur pekerjaan GPU, lihat timer event CUDA. Di PyTorch, caranya memakai torch.cuda.Event(enable_timing=True).
      Selain itu, ukuran dan bentuk memori juga rumit. Benchmark ini memakai bentuk yang tidak menguntungkan bagi NPU. NPU dan GPU biasanya menginginkan channels last, jadi [1,1500,1500,6] lebih tepat daripada [1,6,1500,1500].
      Angka 1500 dan 6 juga janggal sehingga kurang bagus untuk NPU, dan mengingat perangkat seperti ini masih baru, kehilangan performanya bisa cukup besar.
      Saya menuliskan detail lebih lanjut di https://news.ycombinator.com/item?id=41864828

  • NPU seperti ini memakan area silikon yang cukup besar, jadi kalau pada akhirnya jarang dipakai, itu benar-benar disayangkan. Saya tidak menemukan analisis die Snapdragon X yang memisahkan NPU-nya, tetapi untuk AMD yang punya target serupa sekitar 50 TOPS bisa dilihat di sini, dan areanya setara kira-kira 3 core CPU performa tinggi.
    https://www.techpowerup.com/325035/amd-strix-point-silicon-p...

    • Semoga tren LLM berakhir sehingga sebagian akal sehat dan efisiensi kembali. Secara pribadi saya tidak punya kegunaan untuk hardware tambahan ini, dan “GenAI” tidak membantu saya sama sekali maupun mendukung pekerjaan terkait kantor.
      Lebih buruk lagi, tampaknya kebanyakan orang juga tidak membutuhkannya, dan survei terbaru bahkan menunjukkan sentimen negatif terhadap penetrasi AI lebih dominan. Kita tidak seharusnya membayar biaya tambahan untuk hal seperti ini; seharusnya opsional.
      Dengan begitu, angka penjualan akan menunjukkan betapa sedikitnya orang yang ingin membayar premium “AI”, dan akan jelas betapa berlebihan serta tidak perlunya hal ini.
    • Chip modern harus menyisakan sebagian persentase die sebagai dark silicon. Kalau tidak, chip akan meleleh atau mengalami throttling sampai tidak berguna. Komponen seperti ini juga termasuk dalam persentase tersebut.
      Jadi tujuan komponen seperti ini adalah dipakai, tetapi tidak dipakai terlalu banyak.
      Transistor dan ruang die itu memang bisa saja dipakai untuk berbagai hal lain selain NPU, tetapi mereka mungkin tidak akan menambahkan core CPU performa tinggi. Itu akan membuat kepadatan daya terlalu tinggi dan menimbulkan masalah panas yang sulit diatasi tanpa throttling permanen.
      [1] https://en.wikipedia.org/wiki/Dark_silicon
    • Saya juga berpikiran sama. Saat ini, untuk membeli sistem dengan NPU masih harus sengaja dicari, jadi saya belum punya, tetapi saya khawatir ke depannya akan disertakan secara default.
      Bagi orang yang tidak akan menjalankan model, ini terlihat seperti pemborosan, dan saya penasaran apakah ada cara memakainya untuk tujuan lain.
    • Snapdragon X tetap 12-core, dan semuanya core yang sama dalam struktur homogen. Strix Point juga 12-core, tetapi konfigurasinya 4+8, dan core “kecil”-nya pun tidak mengorbankan performa sampai kehilangan alasan keberadaan seperti core kecil pada desain ARM.
      Software konsumen tidak melakukan scaling sampai sejauh itu, jadi saya bertanya-tanya apa yang bisa dilakukan dengan mengalokasikan lebih banyak transistor ke CPU.
      Ini mirip dengan alasan Apple memasukkan banyak video engine ke SoC. Dengan anggaran transistor yang tersedia, tidak banyak tempat lain yang jelas untuk memakainya. Peningkatan performa single-thread tidak lagi dibatasi hanya oleh jumlah transistor, dan software buruk dalam memanfaatkan multithreading.

  • Saya kira tujuan perangkat seperti ini bukan untuk cepat, melainkan menjalankan model kecil dengan daya sangat rendah. Saya memakai laptop AMD terbaru yang punya NPU; saat menyalakan efek video yang katanya berjalan di NPU, konsumsi dayanya tidak berubah, tetapi ketika memakai Nvidia Studio Effects konsumsi daya naik
    NPU tampaknya ditujukan untuk model yang sangat dioptimalkan untuk tugas-tugas kecil seperti eye contact, blur latar belakang, model koreksi otomatis, transkripsi, dan OCR. Khususnya di Windows, saya melihatnya menjalankan OCR seluruh layar dan embedding untuk pencarian demi fitur rewind

    • Apalagi jika perangkat itu adalah Xilinx FPGA. Yang dipasang pada Ryzen mobile terbaru juga performanya 5 kali lebih baik
      AMD belakangan ini melakukan pekerjaan yang sangat bagus, tetapi sepertinya tidak terlalu banyak menggembar-gemborkannya. Ini khususnya menarik: https://lore.kernel.org/lkml/DM6PR12MB3993D5ECA50B27682AEBE1...
      Sunting: ternyata bukan FPGA. Baru tahu hari ini
    • Pemahaman saya juga begitu. Intinya adalah daya rendah dan latensi rendah
      Ini bisa dicek dengan mengevaluasi model CoreML di macOS. ANE membutuhkan waktu sekitar setengah dari GPU, dan GPU membutuhkan waktu sekitar setengah dari CPU. Rasio sebenarnya bergantung pada model
    • Menurut saya daya rendah berarti token yang lebih murah, dan berujung pada penggunaan yang lebih terjangkau dan berkelanjutan. Di situlah manfaat bagi konsumen secara umum. GPU yang boros daya tampaknya lebih cocok untuk riset, komersial, dan enterprise
      Chip yang akan mengancam Nvidia adalah chip dan memori yang cukup murah untuk menjalankan model yang cukup layak di perangkat pribadi seperti smartphone
      Jika masyarakat umum sepakat bahwa LLM berguna dan bersedia membayar sedikit premium pada harga perangkat, masa depan teknologi ini pada dasarnya adalah model pribadi yang menyediakan privasi
      Jumlah informasi pribadi yang dicurahkan orang ke tempat seperti ChatGPT benar-benar mengejutkan. Kalau melihat Reddit, pecandu aplikasi pacar virtual AI tampaknya sering menyerahkan selera tergelap, pengakuan rentan, bahkan percakapan yang bisa jadi kriminal kepada perusahaan aplikasi anonim
      Google juga menyatakan bahwa jika riwayat Gemini diaktifkan, mereka dapat meninjau isi percakapan
      Prediksi token yang kompleks yang membutuhkan model lebih besar mungkin bisa ditanyakan ke LLM cloud, tetapi bagi konsumen privasi harus benar-benar dijamin
      Untuk asisten pribadi sehari-hari, chat, dan pencarian informasi, saya tidak melihat perlunya penalaran mutakhir atau LLM yang bersifat gimmick
    • Dari apa yang saya dengar saat peluncuran pengenalan suara on-device di Pixel, dan dari pengalaman menjalankan pekerjaan ONNX di Apple Neural Engine dan CPU setelah keluar dari Google, saya rasa pernyataan ini benar
      Namun kesimpulan spesifik tulisan itu agak saya ragukan. Itu ONNX milik Qualcomm, dan mungkin sudah lama. Di sisi Android, rekayasa perangkat lunak Qualcomm sering sekali dikritik
      Meski begitu arahnya benar. Sebagian besar klaim akselerasi AI pada hardware konsumen hampir secara universal mendekati omong kosong, dengan pengecualian jika A) memakai software 1P atau B) ada orang internal 1P yang benar-benar ingin Anda memanfaatkan fitur itu
    • Benar. Namun Anda mungkin tidak ingin memprogram perangkat seperti ini dengan Python. Apalagi karena ini perangkat baru, kemungkinan optimasinya belum terporting dengan baik, sehingga sulit mengharapkan performa bagus
      Bahkan memakai sesuatu seperti TensorRT pun tidak akan secepat menulis sendiri dari awal, dan ada alasan mengapa Nvidia mengerahkan banyak orang untuk itu. Namun tetap bisa cukup mendekati dan sangat mengurangi waktu penulisan
      Perangkat seperti ini pada umumnya dioptimalkan untuk tugas-tugas serupa yang berulang. Karena itu saya rasa sebagian informasi yang dikumpulkan di sini bisa tidak akurat
      Saya belum pernah memakai langsung chip NPU ini, tetapi timing-nya sulit dipercaya. Timing CUDA di bagian akhir kemungkinan besar tidak diukur dengan benar di kode. Mengukur timing tidak semudah yang dikira
      Jumlah operasi yang diiklankan hanya menghitung operasi yang dilakukan langsung di NPU, sementara tulisan asli mungkin memasukkan pekerjaan CPU dalam pengukuran NPU dan GPU. Dokumentasinya memiliki alat benchmarking, jadi kemungkinan mereka memakai pendekatan serupa, dan saya juga penasaran bagaimana variansnya setelah warm-up
      Format datanya juga tampaknya salah. Di sini diperlukan channels last. Dokumentasinya juga mengonfirmasi hal ini
      Angka 1500 juga terasa janggal sehingga bisa memunculkan kesalahan tambahan. Pada 1536, 2048, 256, atau nilai yang lebih kecil, hasilnya bisa berbeda. Model nyata tidak memproses gambar beresolusi penuh, dan jika arsitektur dioptimalkan untuk model, informasi shape menjadi penting. Dalam machine learning, optimasi shape cukup penting
      Jika melihat sekilas dokumentasi, konfigurasinya juga tampak kurang tepat. Di “Model Workflow” tertulis bahwa datanya diinginkan dalam floating point 8-bit atau 16-bit, tetapi floating point pun ada beberapa jenis. bfloat di PyTorch tidak sama dengan torch.half atau torch.float16
      Mixed precision masih merupakan topik yang membingungkan, jadi jika ada masalah seperti ini, layak diperiksa dengan benar. Saya tidak merekomendasikan hanya menjalankan prosedur quantization standar lalu selesai. Itu bagus sebagai titik awal, tetapi jika belum “cukup baik”, jangan berhenti di sana
      Meski begitu saya tidak menganggap hasil ini tidak berguna. Hanya saja perlu diperbaiki. Pekerjaan seperti ini lebih rumit daripada kelihatannya, dan sebagian besarnya karena teknologinya baru serta detail-detailnya masih sedang dirapikan
      Saat membandingkan dengan CPU atau GPU, khususnya CUDA, perlu diingat bahwa sudah ada ratusan ribu person-hour yang dicurahkan, dan bahkan library tingkat tinggi seperti Python pun setidaknya sudah menerima puluhan ribu person-hour. Perangkat-perangkat ini belum sepenuhnya siap dipakai langsung pada tingkat abstraksi bahasa yang disukai pengguna rata-rata, tetapi cukup berguna jika Anda bersedia bekerja lebih dekat ke hardware
      Untuk mengukur pekerjaan GPU asinkron di PyTorch, gunakan CUDA event dan torch.cuda.synchronize(), bukan membungkus output model dengan timer CPU
      [1] https://www.thonking.ai/p/what-shapes-do-matrix-multiplicati...

  • Untuk menerapkan model ke NPU, dibutuhkan cukup banyak optimasi berbasis profil. Jika model yang berjalan baik di CPU dibawa begitu saja tanpa dioptimalkan untuk NPU, hasilnya biasanya mengecewakan

    • Keindahan CPU adalah ia bisa mengunyah kode berantakan seperti apa pun dengan kecepatan yang masuk akal
    • Setiap kali berbicara dengan orang-orang yang menangani hal seperti IREE atau OpenXLA, saya mendapat kesan bahwa memahami dan menggunakan compiler dan runtime semacam itu sendiri sudah merupakan sebuah pekerjaan

  • Deskripsi di repositori GitHub jauh lebih informatif daripada blognya
    Jika menjalankan perkalian matriks int8 dengan onnx, performanya sekitar 0.6TF
    https://github.com/usefulsensors/qc_npu_benchmark

  • Katanya matriks input dibuat lebih mendekati persegi agar tiling dan reuse dimungkinkan, tetapi tidak mengherankan kalau cukup banyak optimasi yang memungkinkan tidak masuk ke Onnx
    Qualcomm tampaknya tidak memberi akses langsung ke NPU, dan mengharapkan pengguna mengonversi model lewat framework lalu menyerahkannya. Menurut pengalaman saya, tool konversi umumnya kurang bagus sehingga banyak optimasi terlewat
    Jadi ini mungkin bukan “NPU-nya kurang bagus”, melainkan “tool konversinya kurang bagus”. Saya akan menunggu sampai bisa mengaksesnya langsung, dan tidak mempercayai tool konversi
    Menurut saya NPU bagus untuk model machine learning yang sangat kecil dan aproksimasi fungsi yang sangat cepat. Itulah penggunaan yang saya maksud. LLM memang sedang panas saat ini, tetapi ada sangat banyak tugas khusus yang benar-benar berguna untuk model kecil

    • Bisa beri contoh tugas khusus yang model kecilnya berguna? Kalau bisa, contoh yang model kecilnya berjalan terus-menerus sampai layak tetap berada di cache, dan cukup bernilai bagi banyak pengguna untuk membenarkan okupansi cache itu
      Bukan berarti hal seperti itu tidak ada, tetapi jujur saya tidak tahu apa contohnya dan ingin tahu
    • Saya juga datang untuk mengatakan ini. Saya belum pernah memakai Elite X, tetapi pada perangkat generasi sebelumnya, terutama 865, compute DSP sebagai akselerator dan NPU yang jauh lebih kecil membutuhkan pengaturan yang sangat spesifik, kompilasi toolchain khusus, komunikasi RPC, dan semacamnya
      Saya berharap NPU Elite X menjadi lebih mudah diakses karena Copilot+, tetapi intinya, tidak mungkin semudah “kalau menjalankan model general-purpose, pasti secara ajaib akan diteleportasi ke NPU”

  • RTX 4080 seharusnya mampu sekitar 40 TFLOPS, tetapi di sini hanya melaporkan 216 miliar operasi per detik. Rasanya benchmark ini perlu ditinjau ulang
    Kemungkinan besar ada kesalahan serius dalam pengukuran FLOPS. CPU bisa saja mengalahkan NPU, tetapi untuk perbandingan yang benar, beberapa perkalian matriks harus di-benchmark tanpa sinkronisasi aplikasi

    • Itu hanya sebagian. Bahkan dari membaca sekilas dokumennya, inferensi CPU juga tidak dilakukan dengan cara yang sebanding

  • Benchmark ini adalah perkalian matriks berbentuk (6, 1500, 256) X (6, 256, 1500), yang di dunia AI bukan ukuran yang terlalu besar. Dengan matriks yang jauh lebih besar, selisihnya akan makin besar
    Misalnya Llama 3.1 8B, salah satu model kecil, pun memiliki perkalian matriks seperti (batch, 14336, 4096) x (batch, 4096, 14336)
    Menurut saya benchmark ini tidak cukup realistis

  • Saya mencoba menjalankan qprof, profiler NPU Qualcomm, pada benchmark ini. Dari hasil profil, pekerjaan dialokasikan ke vector core, bukan tensor core yang menyediakan sebagian besar daya komputasi NPU
    Jika dihitung kasar, HMX tampaknya 30 kali lebih kuat daripada HVX
    Beban kerjanya relatif kecil, sehingga kapasitas hardware tidak termanfaatkan penuh karena overhead kuantisasi/dekuantisasi I/O dan pemetaan NCHW-NHCW. Melakukan padding bobot dan input ke kelipatan 64 juga akan membantu performa
    Grafik profiling: https://imgur.com/a/2OKR93e
    Estimasi performa komputasi HVX adalah 4 * 2 * 1.43 * 1024 / 8 = 1.46TOPS pada int8. Di sini 4 adalah jumlah vector core, 2 adalah jumlah operasi per siklus, 1.43GHz adalah frekuensi HVX, 1024bit adalah lebar register vektor, dan 8bit adalah presisi

    • Format rumusnya salah, dan seharusnya 4 * 2 * 1.43 * 1024 / 8

  • Judul artikel sebenarnya seharusnya “Benchmarking Qualcomm's NPU on the Microsoft Surface Tablet”
    Ini bukan tulisan tentang NPU secara umum, melainkan melihat NPU tertentu dengan benchmark tertentu dan kombinasi library/framework tertentu. Jadi pada dasarnya tidak membuktikan apa pun