LiteRT.js، TensorFlow.js کو پیچھے چھوڑ رہا ہے

WebGPU کے ساتھ LiteRT.js ایک MobileNetV2 انفرنس کو 0.41 ms میں مکمل کرتا ہے، جو M2 Max ڈیسک ٹاپ GPU پر 2,439 FPS فراہم کرتا ہے—جو اسی ہارڈ ویئر پر TensorFlow.js کے مقابلے میں 25 گنا سے زیادہ تیز ہے۔ بڑے ماڈلز کے لیے یہ فرق مزید بڑھ جاتا ہے، جس سے ویب پر مبنی مشین لرننگ ایک ایسی کارکردگی کی سطح پر پہنچ جاتی ہے جو پہلے صرف نیٹیو ایپس (native apps) کے لیے مخصوص تھی۔

یہ بینچ مارک کیوں اہم ہے

ڈویلپرز آن-ڈیوائس (on-device) انفرنس کے لیے TensorFlow.js کا استعمال کرتے رہے ہیں، جو عام طور پر WebGL بیک اینڈ کے ذریعے ہوتا ہے۔ WebGL ٹینسر آپریشنز (tensor ops) کو براؤزر کے 2-D گرافکس پائپ لائن پر منتقل کرتا ہے؛ یہ ہر جگہ کام کرتا ہے لیکن اسے ان بڑے پیمانے پر پیراللزم (parallelism) کے لیے نہیں بنایا گیا تھا جس کی ضرورت ڈیپ لرننگ ماڈلز کو ہوتی ہے۔ WebGPU، جو کہ اگلی نسل کی گرافکس API ہے، GPU کمپیوٹ یونٹس تک براہ راست رسائی فراہم کرتی ہے۔ LiteRT.js پہلی لائبریری ہے جو TensorFlow-Lite ماڈلز کے لیے WebGPU پر مبنی انفرنس انجن فراہم کرتی ہے، اور گوگل کے مطابق اس کی رفتار میں تین گنا اضافہ ہوا ہے۔ آزادانہ تجربات اس سے بھی زیادہ بہتری دکھاتے ہیں، جس سے یہ سوال پیدا ہوتا ہے کہ کیا WebGPU ویب ML کے لیے ڈیفالٹ راستہ بن جائے گا۔

ٹیسٹ کیسے کیا گیا

ہم نے دو امیج کلاسیفیکیشن ماڈلز—MobileNetV2 اور EfficientNet-Lite4—کا بینچ مارک کیا، جن دونوں کو TensorFlow-Lite میں تبدیل کیا گیا تھا۔ ٹیسٹ Apple-silicon M2 Max چپ پر کیے گئے۔ ہر ماڈل کے لیے ہم نے کئی تکراروں (iterations) پر ایک سنگل فارورڈ پاس کی لیٹنسی (latency) کی پیمائش کی اور فریمز فی سیکنڈ (FPS) رپورٹ کیا۔ ہم نے TensorFlow.js کو WebGL بیک اینڈ کے ساتھ اسی ماڈلز پر چلایا اور ہر لائبریری کے کولڈ اسٹارٹ (cold-start) وقت کو ریکارڈ کیا۔

نتائج: رفتار اور اسٹارٹ اپ

  • MobileNetV2

    • LiteRT.js (WebGPU): 0.41 ms لیٹنسی → 2,439 FPS
    • TensorFlow.js (WebGL): 10.82 ms لیٹنسی → 92 FPS

  • EfficientNet-Lite4

    • LiteRT.js (WebGPU): 0.62 ms لیٹنسی → 1,623 FPS
    • TensorFlow.js (WebGL): رپورٹ نہیں کیا گیا، لیکن MobileNetV2 پہلے ہی 25x سے زیادہ کا برتری دکھا رہا ہے۔

TensorFlow.js کو پہلی انفرنس سے پہلے اپنے WebGL شایڈرز (shaders) کو کمپائل کرنے کے لیے تقریباً 10 سیکنڈ (10,014 ms) درکار تھے۔ LiteRT.js 4.3 ms میں تیار تھا، جس نے انٹرایکٹو ایپس کے لیے کولڈ اسٹارٹ کے نقصان کو تقریباً ختم کر دیا۔

جب ہم نے ماڈل کا سائز پانچ گنا بڑھایا، تو لیٹنسی صرف 50% بڑھی، جس سے تصدیق ہوئی کہ GPU کا پیراللزم زیادہ تر اضافی کام کو خود سنبھال لیتا ہے۔ اس کا نتیجہ کارکردگی کی ایک ایسی نئی حد ہے جو براؤزر کو سرور کے چکر لگائے بغیر ریئل ٹائم ویڈیو اسٹریمز، AR اوورلے، یا ویژن ماڈلز کی تیز رفتار پروٹو ٹائپنگ کرنے کی اجازت دیتی ہے۔

اعداد و شمار کیا چھپاتے ہیں

  • Batching – زیادہ تر TensorFlow-Lite ماڈلز بیچ ڈائمینشن (batch dimension) کو 1 پر لاک کر دیتے ہیں۔ ایک ہی کال میں متعدد تصاویر فراہم کرنے کی سہولت براہ راست دستیاب نہیں ہے، جس کی وجہ سے ڈویلپرز کو Web Workers بنانے پڑتے ہیں یا دستی طور پر ان پٹس کو پائپ لائن کرنا پڑتا ہے۔
  • Memory management – LiteRT.js خودکار طور پر GPU ٹینسرز کی گاربیج کلیکشن (garbage-collect) نہیں کرتا۔ ڈویلپرز کو اپنے بنائے گئے ہر ٹینسر پر .delete() کال کرنا ہوگا، ورنہ چند سو انفرنسز کے بعد GPU میموری ختم ہونے کا خطرہ ہو سکتا ہے۔
  • Hardware reach – WebGPU ڈیسک ٹاپ Chrome اور Firefox پر مستحکم ہے۔ موبائل براؤزرز—بشمول Android پر Chrome اور iOS پر Safari—اس API کو صرف تجرباتی فلیگز (experimental flags) کے ذریعے یا بالکل بھی فراہم نہیں کرتے۔ ان پلیٹ فارمز پر WASM بیک اینڈ ہی واحد عالمی طور پر دستیاب راستہ ہے، لیکن یہ بڑے ماڈلز کے لیے نمایاں طور پر سست ہے۔

ان پابندیوں کا مطلب یہ ہے کہ اگرچہ خام رفتار متاثر کن ہے، لیکن اسے حاصل کرنے کے لیے انجینئرنگ کی کوششیں معمولی نہیں ہو سکتیں۔

حدود اور سمجھوتے

TensorFlow.js کا WebGL بیک اینڈ اب بھی تقریباً عالمگیر مطابقت (universal compatibility) پیش کرتا ہے۔ ایک ڈویلپر جو مکسڈ آڈینس—ڈیسک ٹاپ، Android، iOS—کو نشانہ بنا رہا ہے، وہ کوڈ کے ایک ہی راستے پر بھروسہ کر سکتا ہے جو ہر جگہ چلتا ہے، اگرچہ کم تھرو پٹ (throughput) پر۔ WASM بیک اینڈ تقریباً کسی بھی ہارڈ ویئر پر چلتا ہے لیکن یہاں ماپے گئے بڑے ماڈلز کے لیے WebGPU سے پیچھے رہ جاتا ہے۔

LiteRT.js اس وقت بہترین کارکردگی دکھاتا ہے جب ہدف WebGPU کے ساتھ فعال ڈیسک ٹاپ ماحول ہو۔ یہ براہ راست .tflite ماڈلز چلاتا ہے، جس سے ڈویلپرز کو بغیر کسی تبدیلی کے Hugging Face یا Kaggle سے ماڈلز لینے کی اجازت ملتی ہے، اور اصل کوانٹائزیشن (quantization) اور کارکردگی برقرار رہتی ہے۔ اس کا سمجھوتہ یہ ہے کہ اس کا استعمال محدود ہے اور وسائل (resources) کے محتاط انتظام کی ضرورت ہوتی ہے۔

ڈویلپرز کو کن باتوں پر غور کرنا چاہیے

  • Target platform – صرف ویب پر مبنی ڈیسک ٹاپ ٹول کے لیے (مثلاً ایک ڈیزائن ایپ جو ریئل ٹائم میں اسٹائل ٹرانسفر کا استعمال کرتی ہے)، LiteRT.js کے ساتھ WebGPU غالباً بہترین انتخاب ہے۔
  • Model size – بڑے اور کمپیوٹ کے لحاظ سے بھاری ماڈلز کو GPU پیراللزم سے سب سے زیادہ فائدہ ہوتا ہے؛ چھوٹے ماڈلز اضافی انجینئرنگ کا جواز پیش نہیں کر سکتے۔
  • Memory discipline – ٹینسرز کو واضح طور پر ڈیلیٹ کرنے کا منصوبہ بنائیں یا انفرنس کالز کو ایسے اسکوپ (scope) میں رکھیں جو خودکار طور پر وسائل کو آزاد کر دے۔
  • Fallback strategy – ان براؤزرز کے لیے WASM یا WebGL فال بیک (fallback) فراہم کریں جو WebGPU کو فعال نہیں کر سکتے، تاکہ ایپ وسیع تر آڈینس کے لیے فعال رہے۔

خلاصہ

LiteRT.js ثابت کرتا ہے کہ WebGPU ویب پر مبنی انفرنس (inference) کو سب ملی سیکنڈ (sub-millisecond) کی حد تک پہنچا سکتا ہے، جو ڈیسک ٹاپ GPUs پر TensorFlow.js کی رفتار سے 25 × سے زیادہ تیز ہے۔ یہ ٹیکنالوجی ابھی ترقی کے مراحل میں ہے، اور ڈویلپرز کو بیچنگ کی حدود، دستی میموری صفائی (manual memory cleanup)، اور محدود موبائل سپورٹ جیسے معاملات کو سنبھالنا ہوگا۔ ڈیسک ٹاپ پر مبنی تجربات کے لیے جن میں ریئل ٹائم کارکردگی کی ضرورت ہوتی ہے، یہ نئی لائبریری ایک پرکشش راستہ فراہم کرتی ہے؛ جبکہ کراس پلیٹ فارم تک رسائی کے لیے، پرانے WebGL اور WASM بیک اینڈز اب بھی ناگزیر ہیں۔