AI PC में AI परफॉर्मेंस की कमी: CPU ने NPU को पछाड़ा

 (github.com/usefulsensors)
1 पॉइंट द्वारा GN⁺ 2024-10-17 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Microsoft Surface Pro 11th Edition के Qualcomm Arm-आधारित SoC पर NPU बेंचमार्क चलाने के परिणाम में, Windows AI PC द्वारा प्रचारित acceleration performance की तुलना में बहुत कम throughput मापा गया
  • टेस्ट को Onnx Runtime और Qualcomm QNN execution provider का उपयोग करके transformer-श्रेणी के मॉडल की high-cost layers जैसी बड़ी MatMul operations चलाने के लिए तैयार किया गया
  • उदाहरण परिणामों में CPU ने 821 Gigaops/s, NPU ने float input/output quantization configuration में 225 Gigaops/s, और 8-bit input/output तक लागू की गई configuration में 573 Gigaops/s दर्ज किए
  • NPU का 573 Gigaops/s, Microsoft Surface Pro 11th Edition के marketing material में बताए गए 45 Teraops/s का 1.3% है, जबकि वही मॉडल Nvidia Geforce RTX 4080 Laptop GPU पर चलाने पर 3.2ms और 2,160 Gigaops/s देता है
  • मौजूदा परिणाम 2 अक्टूबर 2024 के आधार पर हैं, और software·framework·driver स्तर के सुधारों से latency कम होने की संभावना मानी गई है, लेकिन इस बेंचमार्क में CPU, NPU से तेज है

Surface के Qualcomm NPU बेंचमार्क का उद्देश्य

  • Microsoft, Qualcomm Arm-आधारित SoC वाले Surface टैबलेट को Windows AI PC के रूप में बेचता है और प्रचार करता है कि वे machine learning models को अधिक तेज और कुशल तरीके से चला सकते हैं
  • Useful Sensors, Qualcomm hardware और NPU को सकारात्मक रूप से देखता है, और अपने third-party app को इस platform पर port करने में समय और संसाधन लगा रहा है
  • बाहरी developers के लिए जल्दी परिणाम पाने के तरीके दिखाने वाले code examples या benchmarks ज्यादा नहीं हैं, इसलिए वास्तव में देखी गई performance को एक छोटे independent project के रूप में सार्वजनिक किया गया
  • मापी गई performance उम्मीद से काफी कम थी, और Android जैसे दूसरे platforms पर वही hardware प्रभावी रूप से काम करता देखा गया है, इसलिए future में application·framework·driver बदलावों से सुधार की संभावना खुली रखी गई है

execution environment और installation constraints

  • टेस्ट में Windows पर Python script का उपयोग किया गया
    • 2 अक्टूबर 2024 तक Microsoft Store का Python Arm architecture को support नहीं करता, इसलिए Qualcomm NPU तक पहुंच के लिए जरूरी packages चलाने के लिए यह उपयुक्त नहीं है
    • परिणामों के लिए Python 3.11.9 Arm64 installer का उपयोग किया गया
  • Windows on Arm के लिए prebuilt Onnx package अभी उपलब्ध नहीं है, इसलिए CMake और Visual Studio compiler की जरूरत है
    • CMake को winget install cmake से install किया जाता है
    • Visual Studio के लिए Visual Studio Community Edition का उपयोग किया गया, और installation के समय Desktop C++ Development workload चुना गया
  • Python packages को repository folder में py -m pip install -r requirements.txt से install किया जाता है
    • Onnx branch वह version है जिसमें official py launcher compile fix को Onnx 1.16 में backport किया गया है
    • Qualcomm Onnx Runtime में नए Onnx पर Unsupported model IR version error आने के कारण यह combination इस्तेमाल किया गया
    • Qualcomm Onnx Runtime package का nightly build उपयोग किया गया

बेंचमार्क execution और output की व्याख्या

  • बेंचमार्क को py benchmark_matmul.py से चलाया जाता है
  • Onnx Runtime शुरुआती execution के दौरान काफी log output देता है
    • उदाहरण के लिए, cpuinfo संदेश आता है कि Snapdragon(R) X 12-core X1E80100 @ 3.40 GHz chip model को पहचाना नहीं जा सका
    • graph finalization और completion stage के logs भी प्रदर्शित होते हैं
  • वास्तविक बेंचमार्क परिणाम अंत में दिखाए जाते हैं
    • 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
  • पहली दो पंक्तियां CPU और NPU के numerical results के बीच मेल देखने के लिए accuracy difference दिखाती हैं
  • आखिरी तीन पंक्तियां model को शुरू से अंत तक चलाने का wall-clock time और उस latency से निकाला गया operations per second दिखाती हैं

मापे गए मॉडल और quantization तरीका

  • बेंचमार्क को OpenAI Whisper जैसे transformer models में समय लेने वाली layers जैसे 6 बड़े matrix multiplications को दोहराने के लिए डिजाइन किया गया
    • input shape (6, 1500, 256) X (6, 256, 1500) है
    • result shape (6, 1500, 1500) है
    • मॉडल एक single MatMul node से बना है, जिसमें 2 inputs और 1 output है
  • मॉडल को Onnx model framework में तुरंत generate करके Onnx Runtime को दिया जाता है
  • baseline model pure float version है और सिर्फ CPU पर चलता है
  • NPU को प्रभावी ढंग से चलाने के लिए मुख्य रूप से quantized model की जरूरत होती है, जबकि float16 का support सीमित है
  • पहला NPU approach official ORT quantize_static() method का उपयोग करता है
    • सुविधा के लिए input और output tensors को 32-bit float में रखा गया
    • graph की शुरुआत और अंत में runtime conversion किया जाता है, और बाकी computation 8-bit में चलता है
  • इस configuration में NPU की conversion operations बहुत धीमी थीं, और npu_quant_profile.csv में conversion कुल समय का 75% से अधिक लेता है
  • दूसरा approach 8-bit inputs और outputs वाले equivalent model graph को programmatically बनाता है
    • यह quantized compute and I/O तरीका float I/O version की तुलना में आम तौर पर लगभग 3 गुना तेज है
    • profiling में अधिकांश समय उम्मीद के मुताबिक matrix multiplication में खर्च होता है

performance measurement में विचार किए गए variables

  • Compute bound होने की संभावना को देखते हुए matrix shape को अधिक square के करीब रखा गया
    • आधुनिक transformer models, पुराने convolution models के विपरीत, बड़े matrix multiplications पर आधारित होते हैं
    • यदि layer matrix-vector multiplication के करीब हो जाए, तो weight reuse घटता है और DRAM से values लाना bottleneck बन सकता है
    • tiny Whisper की मूल matrix में k dimension 64 था, लेकिन इस बेंचमार्क में SIMD optimization की गुंजाइश बढ़ाने के लिए इसे 256 किया गया
  • power settings को performance बढ़ाने वाली दिशा में सेट किया गया
    • Windows energy settings को सभी जगह Best Performance पर रखने की कोशिश की गई
    • टैबलेट को power से connected स्थिति में रखकर बेंचमार्क चलाया गया
    • Qualcomm Onnx Runtime के htp_performance_mode session option को प्रयोगों में सबसे कम कुल latency देने वाले sustained_high_performance पर सेट किया गया
  • model structure को व्याख्या आसान रखने के लिए single matrix multiplication तक सीमित रखा गया
    • कई layers, convolution, और static weights भी संभव थे, लेकिन LLMs और आधुनिक models में व्यापक transformer structure को दिखाने के लिए dynamic input वाले single MatMul को चुना गया
  • configuration error की संभावना भी बनी हुई है
    • unsigned 8-bit quantization और graph के भीतर qdq elements का उपयोग किया गया
    • documentation की best practices का पालन करने की कोशिश की गई, लेकिन संभव है कि driver या accelerator implementation के fast path से बाहर चले गए हों
  • Windows में AI acceleration तक पहुंचने के API विकल्पों की भी जांच की गई
    • DirectML केवल GPU access support करता हुआ दिखता है
    • OpenVino इस Arm hardware पर चलता हुआ नहीं दिखा
    • Qualcomm QNN SDK को सीधे उपयोग करने पर भी समान performance results देखे गए
    • TensorFlow Lite, Windows for Arm को support नहीं करता
    • इस जांच और प्रयोग में Onnx, Microsoft और Qualcomm दोनों द्वारा supported होने के कारण NPU acceleration performance पाने के लिए सबसे उपयुक्त framework दिखाई दिया

परिणामों की व्याख्या

  • परिणाम 2 अक्टूबर 2024 के आधार पर हैं, और Microsoft Surface Pro 11th Edition पर मापे गए
    • SoC है Snapdragon(R) X 12-core X1E80100 @ 3.40 GHz
  • float conversion हटाने के after भी NPU परिणाम CPU से धीमे हैं
    • accelerator के दृष्टिकोण से यह आदर्श नहीं है
    • हालांकि, energy efficiency या sustained performance में लाभ की संभावना से इनकार नहीं किया गया है
  • मापी गई सर्वोच्च NPU performance 573 billion ops/s है, जो Microsoft Surface Pro 11th Edition marketing material में बताए गए 45 trillion ops/s का 1.3% है
  • वही मॉडल Nvidia Geforce RTX 4080 Laptop GPU पर चलाने पर 3.2ms लेता है
    • यह 2,160 billion ops/s के बराबर है
    • यह throughput, Surface के NPU measurement से लगभग 4 गुना अधिक है

संबंधित पढ़ाई

2 टिप्पणियां

 
bungker 2024-10-18

मुझे लगा था कि ryzen npu, cpu से थोड़ा तेज़ है, लेकिन इससे Snapdragon लेने का मन पूरी तरह ठंडा पड़ गया।
 
GN⁺ 2024-10-17
Hacker News की राय

  • नतीजे देखकर लगता है कि कुल मिलाकर compute resources का उपयोग ठीक से नहीं हुआ। CPU 8.4ms, GPU 3.2ms का अंतर बहुत छोटा है, जबकि यहाँ शायद 10–20 गुना अंतर की उम्मीद रही होगी।
    वजह onnxruntime हो सकता है। लगता है कुछ hardware कंपनियाँ केवल compute units दे देती हैं, लेकिन सही support अभी नहीं जोड़तीं; देखना होगा यह कितनी जल्दी बदलेगा।
    साथ ही, NPU का मकसद “speed” समझ लेना आम गलतफहमी है; असली बात low power है। Speed चाहिए तो memory bottleneck हटाना होगा, और अंततः अपनी memory वाले ASIC design करने पड़ेंगे। ज़्यादातर devices के NPU, CPU के आसपास के SoC से जुड़े होते हैं और AI compute को offload करने के काम आते हैं।
    अगर CPU/NPU/GPU तीनों devices पर यह benchmark infinite loop में चलाकर power consumption मापा जाए तो दिलचस्प होगा। उम्मीद है NPU सबसे कम power लेगा और operations per watt भी सबसे अच्छा होगा।

    • शक होता है कि NPU की असली वजह शायद marketing ही हो। “NVDA की value 3.3 trillion dollar है, तो अपने product में भी कोई AI चीज़ डालते हैं” जैसा trend हो सकता है।
    • NPU का बड़ा मकसद offload भी है। Use case के हिसाब से CPU और GPU दूसरे कामों में व्यस्त हो सकते हैं, इसलिए NPU एक अतिरिक्त bandwidth बन जाता है जिसे आपस में छीने बिना इस्तेमाल किया जा सकता है।
      उदाहरण के लिए AI photo filter में GPU preview rendering कर रहा होगा, और CPU UI व user input संभालने में व्यस्त हो सकता है।
    • यही Nvidia की moat है। लगभग हर चीज़ के पास CUDA के लिए optimized kernels हैं, और कुछ मामलों में Apple Accelerate जैसा विकल्प है।
      Apple Accelerate, M4 से पहले के CPU matrix units और NPU तक पहुँचने का लगभग अकेला रास्ता था। अगर आप कुछ और इस्तेमाल करना चाहते हैं, तो चुने हुए machine learning framework में patch भेजने के लिए तैयार रहें, या training और inference code खुद लिखने के लिए तैयार रहें।
    • onnxruntime इस्तेमाल करके pure C में app बना रहा हूँ, और performance Python में बने मिलते-जुलते app से काफी बेहतर थी। अभी भी काफी performance improvement निकाली जा सकती है।
      आखिरकार Python भी C को call करता है, लेकिन कितनी performance गायब हो जाती है, यह काफी दिलचस्प है।
    • लगता है timing सही तरीके से measure नहीं की जा रही, और आम तौर पर marketed “time” भी अक्सर उस measurement से अलग होता है जो लोग सोचते हैं। फिर भी marketing numbers कभी-कभी comparison आसान बना देते हैं।
      अगर GPU इस्तेमाल कर रहे हैं, तो यह देखना होगा कि timing में asynchronous work शामिल है या नहीं।
      time.time() को naïve तरीके से इस्तेमाल करने पर CPU सिर्फ time record करता है, और model(input.cuda()).cuda() data को GPU memory में भेजकर computation शुरू करता है, लेकिन यह asynchronous होता है, इसलिए result सच में तैयार हुआ या नहीं, इससे अलग end time record हो सकता है।
      System और hardware को जाने बिना ऐसा behavior expect करना मुश्किल है। सिर्फ Python नहीं, बल्कि ज़्यादातर languages आपके लिखे code से ज़्यादा optimized रूप में compile होने के लिए design की गई हैं, और lock न होने से CPU work block नहीं होता।
      GPU work को सच में measure करना हो तो CUDA event timer देखना चाहिए। PyTorch में इसका तरीका torch.cuda.Event(enable_timing=True) इस्तेमाल करना है।
      इसके अलावा memory size और shape भी जटिल हैं। यह benchmark NPU के लिए disadvantageous shape इस्तेमाल कर रहा है। NPU और GPU आम तौर पर channels last चाहते हैं, इसलिए [1,6,1500,1500] के बजाय [1,1500,1500,6] सही है।
      1500 और 6 भी awkward numbers हैं, इसलिए NPU के लिए अच्छे नहीं हैं; और यह देखते हुए कि ऐसे devices अभी नए हैं, performance loss काफी बड़ा हो सकता है।
      ज़्यादा details मैंने https://news.ycombinator.com/item?id=41864828 पर लिखी हैं।

  • ऐसे NPU काफी silicon area घेर रहे हैं, इसलिए अगर आखिर में उनका ज़्यादा इस्तेमाल नहीं हुआ तो सच में अफसोस होगा। Snapdragon X में सिर्फ NPU को अलग दिखाने वाला die analysis नहीं मिला, लेकिन लगभग 50 TOPS target वाले मिलते-जुलते AMD वाले को यहाँ देखा जा सकता है, और यह high-performance CPU cores के करीब 3 cores जितना area लेता है।
    https://www.techpowerup.com/325035/amd-strix-point-silicon-p...

    • उम्मीद है LLM craze खत्म हो और फिर कुछ हद तक common sense और efficiency वापस आए। निजी तौर पर मुझे इस extra hardware का कोई उपयोग नहीं है, “GenAI” मेरे किसी काम की नहीं है और काम से जुड़ी tasks में भी मदद नहीं करती।
      इससे भी बुरी बात यह है कि ज़्यादातर लोगों को भी इसकी जरूरत नहीं लगती, और हाल के surveys में AI की घुसपैठ के प्रति विरोध ज्यादा दिखा है। ऐसी चीज़ के लिए extra cost नहीं देनी चाहिए, यह optional होना चाहिए।
      ऐसा करने पर sales से पता चल जाएगा कि “AI” premium देने को तैयार लोग कितने कम हैं, और यह साफ हो जाएगा कि यह कितना बढ़ा-चढ़ाकर पेश किया गया और अनावश्यक है।
    • Modern chips को die का एक निश्चित हिस्सा dark silicon के रूप में छोड़ना पड़ता है। वरना वे पिघल जाएँगे या इतने throttle होंगे कि बेकार हो जाएँगे। ऐसे components भी उसी हिस्से में शामिल हैं।
      इसलिए ऐसे parts का मकसद है कि वे इस्तेमाल हों, लेकिन बहुत ज्यादा इस्तेमाल न हों।
      NPU की जगह उन transistors और die space को कई कामों में लगाया जा सकता था, लेकिन high-performance CPU cores और नहीं जोड़े जाते। ऐसा करने से power density बहुत ज्यादा हो जाती और permanent throttling के बिना सुलझाना मुश्किल thermal problem पैदा होती।
      [1] https://en.wikipedia.org/wiki/Dark_silicon
    • मेरा भी यही विचार है। अभी NPU वाला system खरीदने के लिए जानबूझकर ढूँढना पड़ता है, इसलिए मेरे पास अभी नहीं है, लेकिन आगे चलकर यह default में शामिल हो सकता है।
      जो लोग models नहीं चलाएँगे, उनके लिए यह waste जैसा लगता है, और सोचता हूँ कि इसे दूसरे कामों में इस्तेमाल करने के क्या तरीके हो सकते हैं।
    • Snapdragon X अभी भी 12-core है, और सारे cores समान core वाली homogeneous structure में हैं। Strix Point भी 12-core है, लेकिन 4+8 configuration है, और “छोटे” cores भी ARM design के छोटे cores की तरह इतने performance-compromised नहीं हैं कि उनका कोई मतलब ही न रहे।
      Consumer software उस स्तर तक scale नहीं होता, तो transistors को CPU के लिए और allocate करके आखिर किया क्या जा सकता है?
      यह कुछ वैसा ही है जैसे Apple अपने SoC में बहुत सारे video engines डालता है। Affordable transistor budget में उन्हें लगाने के लिए और बहुत सी जगहें नहीं हैं। Single-thread performance improvement अब सिर्फ transistor count से सीमित नहीं है, और software multithreading में अच्छा नहीं है।

  • मुझे लगा था कि ऐसे डिवाइस का मकसद तेज़ होना नहीं, बल्कि छोटे मॉडल को बहुत कम बिजली में चलाना है। मैं NPU वाला नया AMD लैपटॉप इस्तेमाल करता हूं, और NPU पर चलने वाला बताया गया वीडियो इफेक्ट ऑन करने पर भी power usage नहीं बदलता, लेकिन Nvidia Studio Effects इस्तेमाल करने पर power usage बढ़ जाता है।
    NPU ऐसे बहुत optimized models के लिए लगता है जो eye contact correction, background blur, auto-correction model, transcription, OCR जैसे छोटे काम करते हैं। खासकर Windows में, मुझे लगा था कि rewind feature के लिए full-screen OCR और search embeddings चलाए जाते हैं।

    • खासकर अगर वह डिवाइस Xilinx FPGA हो तो यह और भी सही लगता है। नए mobile Ryzen में जो लगाया गया है, उसकी performance भी 5 गुना बेहतर है।
      AMD आजकल शानदार काम कर रहा है, लेकिन लगता है वह इसका ज़्यादा शोर नहीं मचाता। यह खास तौर पर दिलचस्प है: https://lore.kernel.org/lkml/DM6PR12MB3993D5ECA50B27682AEBE1...
      सुधार: यह FPGA नहीं था। आज सीखा।
    • मेरी समझ भी यही है। मुख्य बात कम power और कम latency है।
      macOS में CoreML model evaluate करके इसे देखा जा सकता है। ANE को GPU के मुकाबले लगभग आधा समय लगता है, और GPU को CPU के मुकाबले लगभग आधा समय लगता है। असली ratio model पर निर्भर करता है।
    • कम power का मतलब सस्ते tokens भी है, और इससे इस्तेमाल ज़्यादा affordable और sustainable होता है। consumers को कुल मिलाकर फायदा यही है। ज़्यादा power खाने वाले GPU research, commercial और enterprise use के लिए ज़्यादा उपयुक्त लगते हैं।
      Nvidia को खतरा देने वाली chip शायद वह होगी जो smartphone जैसे personal devices पर पर्याप्त अच्छे models चलाने के लिए काफी सस्ती chip और memory दे सके।
      अगर आम लोग LLM की usefulness से सहमत हों और device price पर थोड़ा premium देने को तैयार हों, तो इस technology का भविष्य मूल रूप से privacy-preserving personal models में दिखता है।
      लोग ChatGPT जैसी जगहों पर जितनी personal information डाल देते हैं, वह हैरान करने वाली है। Reddit देखने पर लगता है कि AI virtual girlfriend apps के addicts अक्सर अपनी सबसे dark preferences, vulnerable confessions, यहां तक कि संभावित रूप से criminal conversations भी किसी बेनाम app company को सौंप देते हैं।
      Google भी साफ कहता है कि अगर Gemini history चालू हो, तो वह conversations review कर सकता है।
      जटिल token prediction के लिए, जिसमें बड़े model की जरूरत हो, cloud LLM से पूछा जा सकता है, लेकिन consumers के लिए privacy protection अनिवार्य होना चाहिए।
      रोज़मर्रा के personal assistant, chat और information discovery के लिए मुझे नहीं लगता कि state-of-the-art reasoning या stunt-like LLM की जरूरत है।
    • Pixel पर on-device speech recognition launch होते समय जो सुना था, और Google छोड़ने के बाद Apple Neural Engine और CPU पर ONNX jobs चलाकर जो देखा, उसके हिसाब से यह बात सही लगती है।
      हालांकि article के specific conclusions पर थोड़ा शक है। यह Qualcomm का ONNX है, और शायद पुराना भी हो सकता है। Android side में लोग Qualcomm software engineering को काफी कोसते थे।
      फिर भी direction सही है। consumer hardware में AI acceleration के ज्यादातर दावे लगभग universally bluff जैसे हैं; exceptions हैं A) 1P software इस्तेमाल करना या B) 1P के अंदर कोई सचमुच चाहता हो कि आप उस feature का फायदा उठाएं।
    • सही। हालांकि आप ऐसे डिवाइस को Python में program करना नहीं चाहेंगे। खासकर क्योंकि यह नया device है, optimizations शायद ठीक से port नहीं हुए होंगे, इसलिए अच्छी performance की उम्मीद करना मुश्किल है।
      TensorRT जैसी चीज़ इस्तेमाल करने पर भी यह शुरुआत से खुद लिखने जितना तेज़ नहीं होगा, और Nvidia इतने लोगों को इस पर लगाने की वजह भी यही है। फिर भी यह काफी करीब पहुंच जाता है और लिखने का समय बहुत घटा देता है।
      ऐसे devices आम तौर पर repetitive और मिलते-जुलते tasks के लिए optimized होते हैं। इसलिए यहां जुटाई गई कुछ जानकारी inaccurate हो सकती है।
      मैंने इन NPU chips को खुद इस्तेमाल नहीं किया है, लेकिन timing पर भरोसा करना मुश्किल है। अंत में CUDA timing शायद code में ठीक से measure नहीं की गई। timing measurement जितना लगता है उससे कठिन है।
      advertise किए गए operations की संख्या केवल NPU पर directly performed operations को गिनती है, जबकि original post ने NPU और GPU measurements में CPU work भी शामिल कर लिया हो सकता है। docs में benchmarking tool है, तो शायद similar method इस्तेमाल किया गया होगा; और warmup के बाद variance कैसा होता है, यह भी जानना चाहूंगा।
      data format भी गलत लगता है। यहां channels last चाहिए। docs भी इसकी पुष्टि करते हैं।
      1500 का number भी अजीब है, इसलिए additional misses हो सकते हैं। 1536, 2048, 256, या इससे छोटे values पर results अलग हो सकते हैं। असली model full-resolution images process नहीं करते, और अगर architecture को model के लिए optimize किया जाए तो shape information महत्वपूर्ण हो जाती है। machine learning में shape optimization काफी महत्वपूर्ण है।
      docs पर जल्दी नज़र डालने से settings भी inappropriate लगती हैं। “Model Workflow” में कहा गया है कि data 8-bit या 16-bit floating point में चाहिए, लेकिन floating point के भी कई प्रकार होते हैं। PyTorch का bfloat torch.half या torch.float16 जैसा नहीं है।
      mixed precision अब भी confusing topic है, इसलिए ऐसे issues हों तो ठीक से जांचना worth it है। सिर्फ standard quantization procedure चला कर खत्म कर देना recommended नहीं है। starting point के तौर पर ठीक है, लेकिन अगर “good enough” नहीं है तो वहीं रुकना नहीं चाहिए।
      फिर भी मुझे नहीं लगता कि यह result बेकार है। बस इसमें improvement की जरूरत है। ऐसे काम सोच से ज्यादा complex होते हैं, और इसका बड़ा हिस्सा इसलिए है कि technology नई है और details अभी settle हो रही हैं।
      CPU या GPU, खासकर CUDA से तुलना करते समय याद रखना चाहिए कि इसमें सैकड़ों हजार person-hours लगे हैं, और Python जैसी high-level libraries में भी कम से कम tens of thousands person-hours लगे हैं। ये devices अभी average user की पसंद के language abstraction level पर सीधे इस्तेमाल के लिए पूरी तरह ready नहीं हैं, लेकिन अगर आप hardware के करीब जाकर काम करने को तैयार हैं, तो ये काफी useful हैं।
      PyTorch में GPU asynchronous work measure करने के लिए, CPU timer से model output को wrap करने के बजाय CUDA events और torch.cuda.synchronize() इस्तेमाल करना चाहिए।
      [1] https://www.thonking.ai/p/what-shapes-do-matrix-multiplicati...

  • NPU पर मॉडल deploy करने के लिए profile-based optimization काफी ज़रूरी होती है। CPU पर अच्छी तरह चलने वाले मॉडल को NPU के लिए optimize किए बिना उठा लाएँ, तो आम तौर पर नतीजे निराशाजनक होते हैं

    • CPU की खूबसूरती यह है कि वह किसी भी तरह के उलझे हुए code को भी ठीक-ठाक speed से चबा कर process कर देता है
    • IREE या OpenXLA जैसी चीज़ों पर काम करने वाले लोगों से जब भी बात हुई, मुझे यही लगा कि ऐसे compiler और runtime को समझना और इस्तेमाल करना अपने-आप में एक job है

  • GitHub repository का description blog से कहीं ज़्यादा उपयोगी है
    onnx से int8 matrix multiplication चलाने पर performance करीब 0.6TF है
    https://github.com/usefulsensors/qc_npu_benchmark

  • कहा गया है कि input matrices को ज़्यादा square-like बनाया गया ताकि tiling और reuse संभव हो सके, लेकिन यह हैरानी की बात नहीं होगी अगर संभावित optimizations का बड़ा हिस्सा Onnx में न गया हो
    Qualcomm NPU तक direct access नहीं देता, और लगता है कि users से उम्मीद करता है कि वे model को framework से convert करके pass करें। मेरे अनुभव में conversion tools आम तौर पर खास अच्छे नहीं होते, इसलिए बहुत सारी optimizations छूट जाती हैं
    इसलिए यह “NPU खराब है” से ज़्यादा “conversion tool खराब है” हो सकता है। मैं तब तक इंतज़ार करूँगा जब direct access मिल सके, और conversion tools पर भरोसा नहीं करता
    मुझे लगता है NPU बहुत छोटे machine learning models और बहुत तेज़ function approximation के लिए अच्छा है। मेरा intended use वही है। LLM आजकल hot हैं, लेकिन छोटे models के वाकई उपयोगी specialized tasks बहुत बड़ी संख्या में हैं

    • क्या छोटे models के उपयोगी specialized tasks के उदाहरण दे सकते हो? हो सके तो ऐसा उदाहरण अच्छा होगा जहाँ छोटा model भी cache में रहने लायक लगातार चलता रहे, और उस cache occupancy को justify करने लायक बहुत सारे users के लिए valuable हो
      मेरा मतलब यह नहीं कि ऐसी चीज़ें नहीं हैं, लेकिन सच कहूँ तो मुझे नहीं पता कि वे क्या हैं, इसलिए जानना चाहता हूँ
    • मैं भी यही कहने आया था। मैंने Elite X इस्तेमाल नहीं किया है, लेकिन पिछली generation के devices, मुख्यतः 865 में accelerator यानी compute DSP और उससे काफी छोटा NPU, बहुत specific settings, dedicated toolchain compilation, RPC communication जैसी चीज़ें माँगते थे
      उम्मीद है कि Copilot+ की वजह से Elite X के NPU तक access आसान हुआ होगा, लेकिन मुद्दा यह है कि यह इतना आसान नहीं हो सकता कि “general-purpose model चलाओ और वह जादू से NPU पर teleport हो जाएगा”

  • RTX 4080 को करीब 40 TFLOPS देने में सक्षम होना चाहिए, लेकिन यहाँ सिर्फ 216 billion operations per second report किए गए हैं। इस हिसाब से benchmark को दोबारा देखना चाहिए लगता है
    FLOPS measurement में गंभीर error होने की संभावना बड़ी है। CPU का NPU को हराना संभव है, लेकिन सही comparison के लिए application synchronization के बिना कई matrix multiplications को benchmark करना होगा

    • वह तो सिर्फ एक हिस्सा है। docs को सरसरी तौर पर देखने पर भी CPU inference भी comparable तरीके से नहीं किया गया था

  • benchmark (6, 1500, 256) X (6, 256, 1500) आकार का matrix multiplication है, जो AI world में बहुत बड़ा size नहीं है। अगर matrices बहुत बड़े हों तो gap और बढ़ेगा
    उदाहरण के लिए छोटे models में से एक Llama 3.1 8B में भी (batch, 14336, 4096) x (batch, 4096, 14336) जैसे matrix multiplications होते हैं
    मुझे यह benchmark पर्याप्त realistic नहीं लगता

  • इस benchmark पर Qualcomm NPU profiler qprof चलाकर देखा। profile results के अनुसार काम tensor cores पर नहीं, जो NPU compute power का बड़ा हिस्सा देते हैं, बल्कि vector cores पर allocate हुआ था
    मोटे तौर पर calculation करने पर HMX, HVX से 30 गुना शक्तिशाली दिखता है
    workload अपेक्षाकृत छोटा है, इसलिए input/output quantization/dequantization और NCHW-NHCW mapping के overhead के कारण hardware capacity का पर्याप्त इस्तेमाल नहीं हो पाता। weights और inputs को 64 के multiple में padding करना भी performance में मदद करेगा
    profiling graph: https://imgur.com/a/2OKR93e
    अनुमानित HVX compute performance int8 में 4 * 2 * 1.43 * 1024 / 8 = 1.46TOPS है। यहाँ 4 vector cores की संख्या है, 2 operations per cycle है, 1.43GHz HVX frequency है, 1024bit vector register width है, और 8bit precision है

    • formula formatting गलत है, और 4 * 2 * 1.43 * 1024 / 8 होना चाहिए

  • असली लेख का title “Benchmarking Qualcomm's NPU on the Microsoft Surface Tablet” होना चाहिए
    यह NPU general के बारे में लेख नहीं है, बल्कि एक specific NPU को specific benchmark और specific library/framework combination से देखने की बात है। इसलिए असल में यह कुछ भी साबित नहीं करता