कल्पना कीजिए कि आप एक कंप्यूटर पर एक विशाल, जटिल वीडियो गेम चलाने की कोशिश कर रहे हैं, लेकिन आपको इसे एक बहुत ही सख्त, सुरक्षा-जागरूक मैनेजर के माध्यम से चलाना होगा जो आपको सीधे हार्डवेयर को छूने नहीं देता है। यह आपके वेब ब्राउज़र के भीतर आर्टिफिशियल इंटेलिजेंस (विशेष रूप से लार्ज लैंग्वेज मॉडल्स, या LLMs) चलाने की दुनिया है। ये मॉडल उन चैटबॉट्स के पीछे के दिमाग हैं जो कहानियाँ लिख सकते हैं, गणित हल कर सकते हैं और बातचीत कर सकते हैं। इन्हें आपके लैपटॉप या फोन पर तेज़ी से चलाने के लिए, डेवलपर्स एक विशेष टूल का उपयोग करते हैं जिसे WebGPU कहा जाता है। WebGPU को एक सार्वभौमिक अनुवादक (universal translator) के रूप में समझें जो आपके ब्राउज़र को आपके कंप्यूटर के ग्राफिक्स कार्ड (उस हिस्से के साथ जो आमतौर पर वीडियो गेम रेंडर करता है) से बात करने देता है ताकि वह AI के लिए भारी गणितीय गणनाएं कर सके।

हालाँकि, इसमें एक पेंच है। अतीत में, जब डेवलपर्स ने इन AI मॉडल्स को तेज़ बनाने की कोशिश की, तो उन्होंने व्यक्तिगत गणितीय चरणों (जिन्हें "कर्नेल" कहा जाता है) को अधिक कुशल बनाने पर ध्यान केंद्रित किया, जैसे कि कार के इंजन को पॉलिश करना। लेकिन यह शोध पत्र एक अलग सवाल पूछता है: क्या होगा अगर कार ठीक है, लेकिन ड्राइवर वाहन में चढ़ने और उतरने में बहुत अधिक समय बिता रहा है? ब्राउज़र की दुनिया में, हर एक गणितीय चरण के लिए एक "डिस्पैच" (dispatch) की आवश्यकता होती है—एक अनुरोध जो ग्राफिक्स कार्ड को काम शुरू करने के लिए भेजा जाता है। बड़ा रहस्य यह था: वास्तव में कितना समय केवल इन अनुरोधों को भेजने में बर्बाद हो रहा है, बनाम वास्तविक गणित करने में? यह समझना महत्वपूर्ण है क्योंकि यदि हम केवल कंप्यूटर को काम करने के लिए कहने में बहुत अधिक समय बर्बाद करते हैं, तो चैटबॉट धीमा और सुस्त महसूस होगा, चाहे उसकी गणित कितनी भी स्मार्ट क्यों न हो।

"रुकने और चलने" वाला ट्रैफिक जाम

इस शोध पत्र के शोधकर्ता ने पाया कि हर कोई इन AI अनुरोधों की गति को मापने का तरीका गलत समझ रहा था। कल्पना कीजिए कि आप एक डिलीवरी ड्राइवर द्वारा पैकेज छोड़ने में लगने वाले समय को माप रहे हैं। यदि आप उन्हें गोदाम से निकलने, घर तक जाने, पैकेज छोड़ने और फिर अगला पैकेज लेने के लिए वापस गोदाम तक जाने के पूरे चक्कर के समय को मापते हैं, तो आप पूरे राउंड ट्रिप को माप रहे हैं। लेकिन AI की वास्तविक दुनिया में, ड्राइवर हर एक पैकेज के बाद वापस गोदाम नहीं जाता है। वे एक बार में पैकेजों का पूरा ढेर गिरा देते हैं, और केवल अंत में एक बार वापस जाते हैं।

शोध पत्र दिखाता है कि पिछले माप इस तरह थे जैसे कि हर एक पैकेज के लिए उस पूरे राउंड ट्रिप को मापा जा रहा हो। वे अनुरोध भेजने के समय (डिस्पैच) को कंप्यूटर के "ठीक है, मैं काम पूरा कर चुका हूँ" कहने के इंतज़ार (सिंक्रोनाइज़ेशन) के समय के साथ मिला रहे थे। यह "इंतज़ार का समय" बहुत बड़ा है—यह लगभग 450 माइक्रोसेकंड का ठहराव है। जब शोधकर्ताओं ने इस प्रतीक्षा समय को हर चरण में जोड़ा, तो उन्हें लगा कि अनुरोध भेजने की लागत वास्तव में होने वाली लागत से लगभग 20 गुना अधिक थी।

"सीक्वेंशियल-डिस्पैच" (sequential-dispatch) नामक एक नई विधि का उपयोग करके, लेखक ने यह पता लगाने का तरीका निकाला कि बिना बीच के लंबे इंतज़ार के केवल अनुरोध भेजने की क्रिया को कैसे समयबद्ध किया जाए। उन्होंने पाया कि वास्तविक लागत बहुत कम है: कुछ सिस्टमों (Vulkan) पर 24–36 माइक्रोसेकंड और अन्य पर (Metal) 32–71 माइक्रोसेकंड। दिलचस्प बात यह है कि यह लागत "float32" या "float16" संख्याओं (दशमलव संख्याओं को संग्रहीत करने के दो अलग-अलग तरीके) का उपयोग करने पर भी समान रहती है, जो यह साबित करता है कि यह देरी ब्राउज़र के नियमों के कारण है, न कि गणित के कारण।

असली बाधा: बहुत अधिक रुकना

एक बार जब उन्हें एक एकल अनुरोध की वास्तविक लागत का पता चल गया, तो टीम ने पूछा: "क्या यह वास्तव में मायने रखता है?" यह पता लगाने के लिए, उन्होंने एक नियंत्रित प्रयोग किया। उन्होंने एक मानक AI मॉडल लिया और उसे अलग तरह से पैक किया। एक टेक्स्ट के एक शब्द को प्रोसेस करने के लिए ग्राफिक्स कार्ड को 876 छोटे अनुरोध भेजने के बजाय, उन्होंने कुछ चरणों को "फ्यूज" (गोंद की तरह जोड़ना) कर दिया ताकि कार्ड को केवल 564 अनुरोध प्राप्त करने हों।

यहाँ मुख्य बात यह है: उन्होंने अनुरोधों के अंदर के गणित को तेज़ नहीं बनाया। उन्होंने कोड को स्मार्ट नहीं बनाया या मेमोरी का कम उपयोग नहीं किया। उन्होंने बस यह संख्या कम कर दी कि ब्राउज़र को कितनी बार ग्राफिक्स कार्ड का दरवाज़ा खटखटाना पड़ता है।

परिणाम क्या रहा? AI 53% तेज़ हो गया। एक प्रतिक्रिया का पहला शब्द उत्पन्न करने में लगने वाला समय 71.4 ms से घटकर 41.6 ms रह गया।

इस प्रयोग ने साबित कर दिया कि सबसे सामान्य सेटिंग (एक समय में एक शब्द प्रोसेस करना, जिसे "बैच साइज 1" कहा जाता है) पर, सबसे बड़ी समस्या यह नहीं है कि गणित बहुत धीमा है या मेमोरी बहुत भरी हुई है। समस्या केवल ग्राफिक्स कार्ड के दरवाजे पर बहुत अधिक "दस्तक" देने की है। लेखक ने स्पष्ट रूप से इस विचार को खारिज कर दिया कि बेहतर गणित कोड या कम मेमोरी उपयोग ही इस गति वृद्धि का कारण था। एकमात्र चीज़ जो बदली थी, वह थी डिस्पैच की संख्या।

यह भविष्य के लिए क्या मायने रखता है

शोध पत्र निष्कर्ष निकालता है कि यदि हम चाहते हैं कि ब्राउज़र में AI चैटबॉट्स सुचारू रूप से चलें, तो हमें हर एक गणितीय चरण को पूर्ण बनाने के बजाय उन्हें एक साथ समूहबद्ध करने पर ध्यान केंद्रित करना चाहिए। यह यह समझने जैसा है कि डिलीवरी ट्रक को घर तक तेज़ी से पहुँचाने के लिए, आपको ड्राइवर को तेज़ दौड़ने के लिए नहीं कहना चाहिए; बल्कि आपको बस यह सुनिश्चित करना चाहिए कि वह एक बड़ा बॉक्स ले जाए ताकि उसे कम चक्कर लगाने पड़ें।

लेखक सुझाव देते हैं कि समाधान "डिस्पैच एम्ोर्टाइजेशन" (dispatch amortization) में निहित है—एक फैंसी तरीका यह कहने का कि हमें उन "दस्तकों" की लागत को कई कार्यों पर फैलाना होगा ताकि देरी नुकसान न पहुँचा सके। वे बताते हैं कि इसके लिए न केवल AI चलाने वाले सॉफ़्टवेयर में, बल्कि संभावित रूप से WebGPU के नियमों में भी बदलाव की आवश्यकता हो सकती है, शायद ब्राउज़र को एक "कमांड ग्राफ" (एक पूर्व-नियोजित मार्ग) स्वीकार करने की अनुमति देकर, बजाय इसके कि वह हर एक चरण की व्यक्तिगत रूप से जाँच करे।

हालाँकि ये निष्कर्ष विशिष्ट हार्डवेयर (जैसे NVIDIA RTX 5090) और AI चलाने के एक विशिष्ट तरीके पर आधारित हैं, संदेश स्पष्ट है: फिलहाल, आपके ब्राउज़र में तेज़ AI चलाने का रहस्य तेज़ इंजन नहीं है; यह कम रुकना है।