LiteRT.js, TensorFlow.js-কে ছাড়িয়ে যাচ্ছে

WebGPU-সহ LiteRT.js একটি MobileNetV2 ইনফারেন্স (inference) মাত্র 0.41 ms সময়ে সম্পন্ন করে, যা একটি M2 Max ডেস্কটপ GPU-তে 2,439 FPS প্রদান করে—একই হার্ডওয়্যারে TensorFlow.js-এর তুলনায় এটি 25 গুণের বেশি দ্রুত। বড় মডেলগুলোর ক্ষেত্রে এই ব্যবধান আরও বৃদ্ধি পায়, যা ওয়েব-ভিত্তিক মেশিন লার্নিংকে এমন এক পারফরম্যান্স স্তরে নিয়ে যাচ্ছে যা আগে কেবল নেটিভ অ্যাপের জন্য সংরক্ষিত ছিল।

কেন এই বেঞ্চমার্কটি গুরুত্বপূর্ণ

ডেভেলপাররা সাধারণত WebGL ব্যাকএন্ডের মাধ্যমে অন-ডিভাইস ইনফারেন্সের জন্য TensorFlow.js ব্যবহার করে আসছেন। WebGL টেন্সর অপারেশনগুলোকে (tensor ops) ব্রাউজারের 2-D গ্রাফিক্স পাইপলাইনের সাথে ম্যাপ করে; এটি সব জায়গায় কাজ করলেও ডিপ-লার্নিং মডেলগুলোর প্রয়োজনীয় ব্যাপক প্যারালেলিজমের (parallelism) জন্য এটি তৈরি করা হয়নি। পরবর্তী প্রজন্মের গ্রাফিক্স API, WebGPU, সরাসরি GPU কম্পিউট ইউনিটগুলোতে অ্যাক্সেস দেয়। LiteRT.js হলো প্রথম লাইব্রেরি যা TensorFlow-Lite মডেলগুলোর জন্য WebGPU-চালিত একটি ইনফারেন্স ইঞ্জিন প্রদান করে, এবং Google তিন গুণ গতি বৃদ্ধির কথা জানিয়েছে। স্বতন্ত্র পরীক্ষাগুলো আরও বড় ব্যবধান দেখিয়েছে, যা এই প্রশ্নটি জাগিয়ে তুলেছে যে WebGPU কি ওয়েব ML-এর জন্য ডিফল্ট পথ হয়ে উঠবে কি না।

পরীক্ষাটি কীভাবে চালানো হয়েছে

আমরা দুটি ইমেজ-ক্লাসিফিকেশন মডেল—MobileNetV2 এবং EfficientNet-Lite4—বেঞ্চমার্ক করেছি, যে দুটিকেই TensorFlow-Lite-এ রূপান্তরিত করা হয়েছে। পরীক্ষাগুলো একটি Apple-silicon M2 Max চিপে চালানো হয়েছে। প্রতিটি মডেলের জন্য আমরা অনেকগুলো ইটারেশনের (iterations) মাধ্যমে একটি সিঙ্গেল ফরওয়ার্ড পাসের ল্যাটেন্সি (latency) পরিমাপ করেছি এবং ফ্রেম-পার-সেকেন্ড (FPS) রিপোর্ট করেছি। আমরা WebGL ব্যাকএন্ডে TensorFlow.js-এর মাধ্যমে একই মডেলগুলো চালিয়েছি এবং প্রতিটি লাইব্রেরির কোল্ড-স্টার্ট (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 ইতিমধ্যেই >25× সুবিধা দেখাচ্ছে।

প্রথম ইনফারেন্সের আগে TensorFlow.js-এর তার WebGL শেডারগুলো (shaders) কম্পাইল করতে প্রায় ১০ সেকেন্ড (১০,০১৪ ms) সময় লেগেছিল। LiteRT.js মাত্র ৪.৩ ms সময়ে প্রস্তুত ছিল, যা মূলত ইন্টারঅ্যাক্টিভ অ্যাপগুলোর জন্য কোল্ড-স্টার্ট পেনাল্টি বা বিলম্ব প্রায় দূর করে দিয়েছে।

যখন আমরা মডেলের আকার পাঁচ গুণ বৃদ্ধি করেছি, তখন ল্যাটেন্সি মাত্র ৫০% বেড়েছে, যা নিশ্চিত করে যে GPU-এর প্যারালেলিজম অতিরিক্ত কাজের বেশিরভাগ অংশ সামলে নিতে পারে। এর ফলে এমন এক পারফরম্যান্সের দিগন্ত উন্মোচিত হয়েছে যা ব্রাউজারকে সার্ভারের সাহায্য ছাড়াই রিয়েল-টাইম ভিডিও স্ট্রিম, AR ওভারলে, বা ভিশন মডেলের দ্রুত প্রোটোটাইপিং করার সুযোগ দেয়।

সংখ্যাগুলো যা লুকিয়ে রাখে

  • Batching – বেশিরভাগ TensorFlow-Lite মডেলের ব্যাচ ডাইমেনশন (batch dimension) ১-এ লক করা থাকে। একটি সিঙ্গেল কলে একাধিক ইমেজ ইনপুট দেওয়া সরাসরি সমর্থিত নয়, যার ফলে ডেভেলপারদের Web Workers ব্যবহার করতে হয় অথবা ম্যানুয়ালি ইনপুট পাইপলাইন করতে হয়।
  • Memory management – LiteRT.js স্বয়ংক্রিয়ভাবে GPU টেন্সরগুলোর গারবেজ-কালেক্ট (garbage-collect) করে না। ডেভেলপারদের প্রতিটি তৈরি করা টেন্সরের জন্য .delete() কল করতে হবে, অন্যথায় কয়েকশ ইনফারেন্সের পর GPU মেমরি শেষ হয়ে যাওয়ার ঝুঁকি থাকে।
  • Hardware reach – ডেস্কটপ Chrome এবং Firefox-এ WebGPU স্থিতিশীল। মোবাইল ব্রাউজার—Android-এর Chrome এবং iOS-এর Safari সহ—এই API-টি কেবল এক্সপেরিমেন্টাল ফ্ল্যাগ (experimental flags) এর মাধ্যমে বা একেবারেই প্রদান করে না। সেই প্ল্যাটফর্মগুলোতে WASM ব্যাকএন্ডই একমাত্র সর্বজনীনভাবে উপলব্ধ পথ, তবে বড় মডেলগুলোর ক্ষেত্রে এটি উল্লেখযোগ্যভাবে ধীরগতির।

এই সীমাবদ্ধতাগুলোর মানে হলো, যদিও কাঁচা গতি (raw speed) চিত্তাকর্ষক, তবে এটি অর্জনের জন্য প্রয়োজনীয় ইঞ্জিনিয়ারিং প্রচেষ্টা মোটেও সহজ নয়।

সীমাবদ্ধতা এবং আপস (Trade-offs)

TensorFlow.js-এর WebGL ব্যাকএন্ড এখনও প্রায় সর্বজনীন সামঞ্জস্যতা (compatibility) প্রদান করে। একজন ডেভেলপার যদি ডেস্কটপ, Android এবং iOS-এর মতো মিশ্র অডিয়েন্সকে লক্ষ্য করেন, তবে তিনি একটি মাত্র কোড পাথের ওপর নির্ভর করতে পারেন যা সব জায়গায় চলে, যদিও এর থ্রুপুট (throughput) কম। WASM ব্যাকএন্ড প্রায় যেকোনো হার্ডওয়্যারে চলে কিন্তু এখানে পরিমাপ করা বড় মডেলগুলোর ক্ষেত্রে WebGPU-এর তুলনায় পিছিয়ে থাকে।

LiteRT.js তখন চমৎকার কাজ করে যখন লক্ষ্য হলো WebGPU সক্ষম একটি ডেস্কটপ এনভায়রনমেন্ট। এটি সরাসরি .tflite মডেল চালাতে পারে, যা ডেভেলপারদের কোনো কনভার্সন ছাড়াই Hugging Face বা Kaggle থেকে মডেল নিয়ে আসার সুযোগ দেয় এবং মূল কোয়ান্টাইজেশন (quantization) ও পারফরম্যান্স বজায় রাখে। এর বিনিময়ে (trade-off) ডেপ্লয়মেন্টের ক্ষেত্র কিছুটা সীমিত এবং রিসোর্স হ্যান্ডলিংয়ের ক্ষেত্রে সতর্ক থাকতে হয়।

ডেভেলপারদের যা বিবেচনা করা উচিত

  • Target platform – শুধুমাত্র ওয়েব-ভিত্তিক ডেস্কটপ টুলের জন্য (যেমন, রিয়েল-টাইমে স্টাইল ট্রান্সফার প্রয়োগকারী একটি ডিজাইন অ্যাপ), LiteRT.js-এর সাথে WebGPU সম্ভবত সেরা পছন্দ।
  • Model size – বড় এবং কম্পিউট-ভারী মডেলগুলো GPU প্যারালেলিজম থেকে সবচেয়ে বেশি উপকৃত হয়; ছোট মডেলগুলোর ক্ষেত্রে অতিরিক্ত ইঞ্জিনিয়ারিং করা হয়তো যুক্তিসঙ্গত নাও হতে পারে।
  • Memory discipline – টেন্সর ডিলিট করার জন্য সুনির্দিষ্ট পরিকল্পনা রাখুন অথবা ইনফারেন্স কলগুলোকে এমন একটি স্কোপের (scope) মধ্যে রাখুন যা স্বয়ংক্রিয়ভাবে রিসোর্স মুক্ত করে দেয়।
  • Fallback strategy – যেসব ব্রাউজারে WebGPU সক্রিয় করা সম্ভব নয়, তাদের জন্য একটি WASM বা WebGL ফলব্যাক (fallback) ব্যবস্থা রাখুন, যাতে অ্যাপটি বৃহত্তর অডিয়েন্সের জন্য কার্যকর থাকে।

সারসংক্ষেপ (Takeaway)

LiteRT.js প্রমাণ করে যে WebGPU ওয়েব-ভিত্তিক ইনফারেন্সকে সাব-মিলি-সেকেন্ড পর্যায়ে নিয়ে যেতে পারে, যা ডেস্কটপ GPU-তে TensorFlow.js-এর তুলনায় ২৫ × এরও বেশি গতি প্রদান করে। প্রযুক্তিটি এখনও পরিপক্ক হচ্ছে, এবং ডেভেলপারদের ব্যাচিং লিমিট, ম্যানুয়াল মেমরি ক্লিনআপ এবং সীমিত মোবাইল সাপোর্টের মতো বিষয়গুলো মোকাবিলা করতে হবে। রিয়েল-টাইম পারফরম্যান্স প্রয়োজন এমন ডেস্কটপ-ফার্স্ট অভিজ্ঞতার জন্য এই নতুন লাইব্রেরিটি একটি চমৎকার পথ প্রদর্শন করে; তবে ক্রস-প্ল্যাটফর্ম বিস্তারের জন্য পুরনো WebGL এবং WASM ব্যাকএন্ডগুলো এখনও অপরিহার্য।