LiteRT डेलिगेट

डेलिगेट, LiteRT मॉडल की हार्डवेयर से तेज़ी लाने की सुविधा को इनके ज़रिए चालू करते हैं डिवाइस पर मौजूद ऐक्सेलरेटर की मदद लेना, जैसे कि जीपीयू और डिजिटल सिग्नल प्रोसेसर (DSP).

LiteRT, डिफ़ॉल्ट रूप से ऐसे सीपीयू कर्नेल का इस्तेमाल करता है जिन्हें ARM के लिए ऑप्टिमाइज़ किया जाता है नियॉन निर्देश सेट होता है. हालांकि, सीपीयू मल्टी-पर्पज़ प्रोसेसर है, जो यह ज़रूरी है कि मशीन में पाए जाने वाले भारी अंकगणित के हिसाब से ऑप्टिमाइज़ की गई हो लर्निंग मॉडल (उदाहरण के लिए, कॉन्वलूशन और सघनता वाला मैट्रिक्स गणित लेयर).

दूसरी ओर, ज़्यादातर आधुनिक मोबाइल फ़ोन में ऐसे चिप होते हैं जो मैनेज करने में मदद करने के लिए किया जा रहा है. न्यूरल नेटवर्क ऑपरेशन में इनका इस्तेमाल करना इस सुविधा का इस्तेमाल करने पर, इंतज़ार का समय और बिजली की बचत होती है. उदाहरण के लिए, जीपीयू से ज़्यादा से ज़्यादा 5x पॉइंट मिल सकते हैं स्पीड बढ़ाना इंतज़ार का समय.

इनमें से हर एक ऐक्सेलरेटर से जुड़े एपीआई होते हैं, जो कस्टम कंप्यूटेशन, जैसे कि OpenCL या OpenGL मोबाइल जीपीयू के लिए ES. आम तौर पर, आपको का इस्तेमाल करें. जब आप यह सोचते हैं कि प्रत्येक एक्सेलरेटर के पास फ़ायदे और न्यूरल नेटवर्क में हर कार्रवाई को एक्ज़ीक्यूट नहीं किया जा सकता है. TensorFlow Lite का प्रतिबंध API, TFLite के बीच एक पुल का काम करता है और इस समस्या को हल करता है रनटाइम और इन लोअर लेवल एपीआई की मदद से इन एपीआई का इस्तेमाल करता है.

प्रतिनिधि चुनना

LiteRT, कई डेलिगेट के साथ काम करता है. हर डेलिगेट को इनके लिए ऑप्टिमाइज़ किया जाता है कुछ खास प्लैटफ़ॉर्म और खास तरह के मॉडल की ज़रूरत होती है. आम तौर पर, आपके इस्तेमाल के उदाहरण में, एक से ज़्यादा डेलिगेट के वोट हैं. ये दो मुख्य शर्तों पर निर्भर करते हैं: आपका टारगेट किया गया प्लैटफ़ॉर्म (Android या iOS?) और मॉडल-टाइप (फ़्लोटिंग-पॉइंट या क्वांटाइज़्ड?) जिसे तेज़ी से बढ़ाने की कोशिश की जा रही है.

प्लैटफ़ॉर्म के हिसाब से, संपर्कों का ऐक्सेस देने वाले लोगों की संख्या

क्रॉस-प्लैटफ़ॉर्म (Android और iOS)

• GPU डेलिगेट - जीपीयू डेलिगेट का इस्तेमाल Android और iOS, दोनों पर किया जा सकता है. यह को 32-बिट और 16-बिट फ़्लोट आधारित मॉडल पर चलने के लिए ऑप्टिमाइज़ किया गया हो, जहां जीपीयू उपलब्ध हैं. यह 8-बिट वाले क्वांटाइज़्ड मॉडल के साथ भी काम करता है और जीपीयू की सुविधा देता है की परफ़ॉर्मेंस, फ़्लोट वर्शन की तुलना में काफ़ी ज़्यादा है. जीपीयू के बारे में जानकारी प्रतिनिधि के तौर पर, GP पर LiteRT देखें.

iOS

• नए iPhone और iPad के लिए कोर एमएल डेलिगेट - नए iPhone और जिन iPads में Neural Engine उपलब्ध है, उन्हें इन कामों के लिए Core ML डेलिगेट का इस्तेमाल किया जा सकता है 32-बिट या 16-बिट फ़्लोटिंग-पॉइंट मॉडल के लिए, अनुमान को तेज़ बनाएं. Neural इंजन, A12 SoC या उसके बाद के वर्शन वाले Apple मोबाइल डिवाइसों पर उपलब्ध है. किसी कोर एमएल डेलिगेट की खास जानकारी और सिलसिलेवार निर्देश देखें. LiteRT Core ML डेलिगेट.

मॉडल टाइप के हिसाब से डेलिगेट

हर एक्सेलरेटर को डेटा की कुछ खास चौड़ाई को ध्यान में रखकर डिज़ाइन किया गया है. अगर आपको ऐसे प्रतिनिधि को फ़्लोटिंग-पॉइंट मॉडल उपलब्ध कराना जो सिर्फ़ 8-बिट क्वांटिफ़ाइड ऑपरेशन के बाद, यह अपने सभी ऑपरेशन को अस्वीकार कर देगा और मॉडल पूरी तरह से CPU. ऐसी हैरान करने वाली चीज़ों से बचने के लिए, नीचे दी गई टेबल में मॉडल टाइप के आधार पर डेलिगेट की सहायता:

परफ़ॉर्मेंस की पुष्टि की जा रही है

इस अनुभाग में दी गई जानकारी ये लोग आपके ऐप्लिकेशन को बेहतर बना सकते हैं. हालांकि, यह जानना ज़रूरी है कि हर प्रतिनिधि के पास कार्रवाइयों का एक पहले से तय सेट होता है और वह मॉडल और डिवाइस के आधार पर, यह अलग-अलग तरह से काम करता है. इसलिए, आम तौर पर का सुझाव दिया जाता है कि आप कुछ मानदंड लागू करें, ताकि यह पता लगाया जा सके कि वह प्रतिनिधि कितना काम का है आपकी ज़रूरतों के लिए. यह वैल्यू, बाइनरी साइज़ में बढ़ोतरी को सही ठहराने में भी मदद करती है. LiteRT रनटाइम में किसी डेलिगेट को अटैच करना.

LiteRT में, परफ़ॉर्मेंस और सटीक होने के आकलन वाले टूल का बहुत ज़्यादा इस्तेमाल किया गया है इससे डेवलपर को अपने ऐप्लिकेशन में, अपने ईमेल खाते का ऐक्सेस देकर लोगों का भरोसा जीतने में मदद मिल सकती है. अगले सेक्शन में इन टूल के बारे में बताया गया है.

आकलन करने के लिए टूल

इंतज़ार का समय और मेमोरी फ़ुटप्रिंट

LiteRT के मानदंड टूल का इस्तेमाल इनके साथ किया जा सकता है औसत अनुमान के साथ-साथ मॉडल की परफ़ॉर्मेंस का अनुमान लगाने के लिए सही पैरामीटर इंतज़ार का समय, इनीशियलाइज़ेशन ओवरहेड, मेमोरी फ़ुटप्रिंट वगैरह. यह टूल, कई फ़्लैग को फ़्लैग कर सकता है. इसके लिए उदाहरण के लिए, जीपीयू को मापने के लिए, --use_gpu के साथ --gpu_backend=gl तय किया जा सकता है OpenGL के साथ निष्पादन. इस्तेमाल किए जा सकने वाले डेलिगेट पैरामीटर की पूरी सूची यह है विवरण दस्तावेज़ में दिया गया है.

यहां adb के ज़रिए जीपीयू के साथ क्वांटाइज़ किए गए मॉडल के लिए रन का उदाहरण दिया गया है:

adb shell /data/local/tmp/benchmark_model \
  --graph=/data/local/tmp/mobilenet_v1_224_quant.tflite \
  --use_gpu=true

Android के 64-बिट ARM वाले डिवाइस के लिए, इस टूल का पहले से मौजूद वर्शन डाउनलोड किया जा सकता है आर्किटेक्चर यहां (ज़्यादा विवरण देखें).

सटीक जानकारी और सटीक जानकारी

आम तौर पर, प्रतिनिधि अपने सीपीयू से अलग सटीक तरीके से कंप्यूटेशन करते हैं मिलते-जुलते टूल. इस वजह से, सटीक जानकारी पाने में (आम तौर पर बहुत कम) फ़र्क़ देखने को मिलता है हार्डवेयर त्वरण के लिए डेलिगेट का इस्तेमाल करने से जुड़ा है. ध्यान दें कि यह हमेशा सही नहीं होता; उदाहरण के लिए, जीपीयू फ़्लोटिंग-पॉइंट प्रिसिज़न का इस्तेमाल करके क्वांटिफ़ाइड मॉडल का इस्तेमाल करते हैं, तो सटीक होने में थोड़ा सुधार हो सकता है (उदाहरण के लिए, <1% - ILSVRC इमेज क्लासिफ़िकेशन में टॉप-5 सुधार).

LiteRT पर दो तरह के टूल मौजूद हैं. इनकी मदद से, यह पता लगाया जा सकता है कि किसी व्यक्ति को यह दिए गए मॉडल के लिए काम करता है: टास्क-आधारित और टास्क-एग्नोस्टिक. सभी टूल इस सेक्शन में बताई गई बातों के साथ-साथ, बेहतर तरीके से मैनेज करने की सुविधा पैरामीटर जिसका इस्तेमाल पिछले सेक्शन के मानदंड टूल में किया गया है. ध्यान दें कि नीचे दिए गए सब-सेक्शन, डेलीगेट की समीक्षा पर फ़ोकस करते हैं (क्या डेलिगेट, CPU जैसा है?) न कि मॉडल मूल्यांकन (क्या मॉडल अपने आप में सही है टास्क?).

टास्क के हिसाब से आकलन करना

LiteRT में ऐसे टूल हैं जिनकी मदद से इमेज पर आधारित दो टास्क के सटीक होने का आकलन किया जा सकता है:

• ILSVRC 2012 (इमेज वर्गीकरण) top-K के साथ सटीक जानकारी

• COCO ऑब्जेक्ट की पहचान (बाउंडिंग बॉक्स के साथ) औसत सटीक वैल्यू” के साथ (mAP)

साथ ही, इन टूल (Android, 64-बिट ARM आर्किटेक्चर) की पहले से बनी बाइनरी दस्तावेज़ यहां उपलब्ध हैं:

• ImageNet इमेज क्लासिफ़िकेशन (ज़्यादा जानकारी) * COCO ऑब्जेक्ट पहचान करना (ज़्यादा जानकारी)

नीचे दिया गया उदाहरण इमेज क्लासिफ़िकेशन के बारे में बताता है आकलन Pixel 4 में जीपीयू के साथ:

adb shell /data/local/tmp/run_eval \
  --model_file=/data/local/tmp/mobilenet_quant_v1_224.tflite \
  --ground_truth_images_path=/data/local/tmp/ilsvrc_images \
  --ground_truth_labels=/data/local/tmp/ilsvrc_validation_labels.txt \
  --model_output_labels=/data/local/tmp/model_output_labels.txt \
  --output_file_path=/data/local/tmp/accuracy_output.txt \
  --num_images=0 # Run on all images. \
  --use_gpu=true

अनुमानित आउटपुट 1 से 10 तक की टॉप-K मेट्रिक की सूची में शामिल हो सकता है:

Top-1 Accuracy: 0.733333
Top-2 Accuracy: 0.826667
Top-3 Accuracy: 0.856667
Top-4 Accuracy: 0.87
Top-5 Accuracy: 0.89
Top-6 Accuracy: 0.903333
Top-7 Accuracy: 0.906667
Top-8 Accuracy: 0.913333
Top-9 Accuracy: 0.92
Top-10 Accuracy: 0.923333

टास्क-एग्नास्टिक इवैलुएशन

उन टास्क के लिए जिनमें डिवाइस पर आकलन करने वाला टूल मौजूद नहीं है या जब कस्टम मॉडल के साथ प्रयोग कर रहे हैं, तो LiteRT के पास अनुमान है फ़र्क़ टूल. (Android, 64-बिट ARM बाइनरी आर्किटेक्चर बाइनरी यहां देखें)

अनुमान अंतर, LiteRT के एक्ज़िक्यूशन की तुलना करता है (इंतज़ार का समय और आउटपुट-वैल्यू का विचलन) दो सेटिंग में:

• सिंगल-थ्रेड वाले सीपीयू का अनुमान
• उपयोगकर्ता का तय किया गया अनुमान - इन पैरामीटर से तय किया जाता है

ऐसा करने के लिए, यह टूल रैंडम गॉसियन डेटा जनरेट करता है और उसे TFLite अनुवादक - एक सिंगल-थ्रेड वाले सीपीयू कर्नेल चल रहा है और दूसरा उपयोगकर्ता के तर्कों से पैरामीटर किया जाता है.

यह दोनों की प्रतीक्षा अवधि के साथ-साथ दोनों के बीच के संपूर्ण अंतर को मापता है हर एलिमेंट के आधार पर, हर इंटरप्रिटर से आउटपुट टेंसर.

एक आउटपुट टेंसर वाले मॉडल के लिए, आउटपुट ऐसा दिख सकता है:

Num evaluation runs: 50
Reference run latency: avg=84364.2(us), std_dev=12525(us)
Test run latency: avg=7281.64(us), std_dev=2089(us)
OutputDiff[0]: avg_error=1.96277e-05, std_dev=6.95767e-06

इसका मतलब यह है कि इंडेक्स 0 के आउटपुट टेंसर के लिए, एलिमेंट औसतन 1.96e-05 का सीपीयू आउटपुट, डेलिगेट आउटपुट से अलग होता है.

ध्यान दें कि इन संख्याओं को समझने के लिए, मॉडल की गहरी जानकारी होना ज़रूरी है. हर आउटपुट टेंसर क्या बताता है. अगर यह एक आसान रिग्रेशन है, जो किसी तरह का स्कोर या एम्बेड करने का तरीका चुनने पर, अंतर कम होना चाहिए (अन्यथा यह और ऐक्सेस देने की सीमा तय करने में गड़बड़ी हुई). हालांकि, 'detection class' जैसे आउटपुट एक से एसएसडी मॉडल को समझना थोड़ा मुश्किल होता है. उदाहरण के लिए, यह में क्या अंतर है, लेकिन इसका यह मतलब नहीं कि कोई समस्या है प्रतिनिधि: दो (नकली) क्लास पर विचार करें: "टीवी (आईडी: 10)", "मॉनिटर (आईडी:20)" - अगर जिनका प्रतिनिधि सुनवाई से थोड़ा दूर है और टीवी के बजाय मॉनिटर दिखाता है, इस टेंसर के आउटपुट का अंतर 20-10 = 10 जितना ज़्यादा हो सकता है.