आपका एज डिवाइस एक फॉरवर्ड पास पर बेंचमार्क किया गया था। आपका एजेंट एक लूप चलाएगा।

एज AI के बारे में हार्डवेयर चर्चा पिछले वर्ष में काफी अधिक ईमानदार हो गई है। इस साइट पर एक हालिया लेख ने तर्क दिया कि पुरानी डिजाइन पदानुक्रम — “थ्रूपुट को अधिकतम करें, फिर पावर और थर्मल को उसके चारों ओर प्रबंधित करें” — उलट गई है, और औद्योगिक तैनाती के लिए अब पावर शीर्ष पर है, जबकि कच्चा थ्रूपुट अंत में आता है। यह उसी तर्क का अनुसरण करता है जिसे यह प्रकाशन कुछ समय से प्रस्तुत कर रहा है: कि एज डिवाइस “थर्मल‑सीमित, न कि MIPS/कम्प्यूट‑सीमित” हैं, और स्मार्टफ़ोन पहले से ही उन सीमाओं पर हैं। दोनों वास्तविक सुधार हैं, और वे देर से आए हैं।

लेकिन इसमें अभी भी वह मान्यता शामिल है जिसे यह सुधार रहा है। उस पदानुक्रम में हर आइटम को एक अनुमानित कार्यभार के आधार पर बजट किया जाता है, और लगभग सभी लोग अभी भी जिस कार्यभार के आधार पर बजट बना रहे हैं वह एकल फ़ॉरवर्ड पास है: मॉडल इनपुट प्राप्त करता है, आउटपुट उत्पन्न करता है, और सिलिकॉन को ठंडा होने का एक क्षण मिलता है।

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

लूप तब तक अनिश्चित रहता है जब तक कोई संख्या नहीं दर्ज करता

यह कोई अलंकारिक रूप नहीं है; यह वही है जिससे फ्रेमवर्क वास्तव में निर्मित होते हैं। OpenAI’s Agents SDK में, रनर “लूप चलाता है”, और जब मॉडल टूल कॉल उत्पन्न करता है, तो रनटाइम “उन टूल कॉल को चलाएगा, परिणाम जोड़ देगा, और लूप को फिर से चलाएगा।” इसे रोकने वाली केवल टर्न सीमा है — max_turns को पार करने पर आपको एक अपवाद मिलता है — और दस्तावेज़ में कहा गया है कि आप max_turns=None पास करके सीमा को पूरी तरह अक्षम कर सकते हैं।

एक सर्वर पर, वह संख्या बिलिंग निर्णय होती है। कोई व्यक्ति बिल को देखता है।

एक डिवाइस पर, वह संख्या थर्मल निर्णय होती है, क्योंकि लूप की लंबाई ड्यूटी साइकिल होती है। और ड्यूटी साइकिल वह एकमात्र चर है जिससे निष्क्रिय कूलिंग बहस नहीं कर सकती।

सतत लोड फोन पर बेंचमार्क से अलग कुछ करता है

मार्च 2026 बेंचमार्क ने चार प्लेटफ़ॉर्म को ठीक इस प्रकार के लोड में रखा: एक क्वांटाइज़्ड 1.5‑बिलियन‑पैरामीटर मॉडल, एक स्थिर 258‑टोकन प्रॉम्प्ट, लगातार बीस रन, प्रत्येक पर थ्रूपुट, पावर और तापमान मापते हुए। यह एक प्री‑प्रिंट है, और यह एक मॉडल को चार डिवाइस पर बेंचमार्क करता है, इसलिए विशिष्ट संख्याओं को उन प्लेटफ़ॉर्म की विशेषता के रूप में देखें, न कि प्राकृतिक नियम के रूप में। परिणाम का आकार ही महत्वपूर्ण है।

iPhone 16 Pro ने अधिकतम 40.35 टोकन प्रति सेकंड हासिल किए, लेकिन इसे बनाए नहीं रख सका। दो इनफ़रेंस के भीतर गिरावट दिखाई दी। यह 22.56 टोकन प्रति सेकंड पर स्थिर हो गया — 44 % की कमी — और बेंचमार्क के 65 % समय तक थ्रॉटल्ड रहा। डायनामिक वोल्टेज और फ़्रीक्वेंसी स्केलिंग, वह तंत्र जो जंक्शन तापमान बढ़ने पर क्लॉक स्पीड घटाता है, ने बिल्कुल वही किया जिसके लिए वह मौजूद है।

Galaxy S24 Ultra ने अलग तरह से, और अधिक बुरे तरीके से विफलता दिखाई। गिरावट के बजाय, Android थर्मल गवर्नर ने छठे इटरेशन पर 78.3 °C पर एक कठोर GPU फ़्रीक्वेंसी फ़्लोर लागू कर दिया, और इनफ़रेंस रुक गया। लेखक यहाँ वह बिंदु स्पष्ट करते हैं जो मैं बेहतर नहीं कह सकता: एजेंट तैनाती के लिए, यह “सौम्य गिरावट से अधिक विघटनकारी” है, क्योंकि सिस्टम धीमा नहीं होता; यह अनुपयोगी बन जाता है।

अब उस विवरण को देखें जो इसे केवल रोचक नहीं बल्कि निंदनीय बनाता है। उन बीस रन में से प्रत्येक ने एक ही प्रॉम्प्ट का उपयोग किया। यह वह सबसे अनुकूल कार्यभार है जो एक एजेंट के हार्डवेयर को कभी मिलेगा, और दो फ़्लैगशिप फ़ोन इसे बीस बार तक बनाए नहीं रख सके। यह कोई नई खोज नहीं है — MELTing पॉइंट, 2024 में MobiCom में प्रस्तुत, ने ऊर्जा और थर्मल कारणों से निष्कर्ष निकाला कि “LLM की निरंतर निष्पादन अभी भी कठिन है।” दो साल और कई प्रोसेस नोड्स के अंतर के बाद, वही बाधा बनी हुई है।

दो वक्र एक-दूसरे की ओर बढ़ते हैं, और आपका उत्पाद जहाँ वे मिलते हैं वहाँ टूटता है

एक एजेंट का लूप एक दोहराए गए प्रॉम्प्ट से विशिष्ट, यांत्रिक तरीके से अधिक ख़राब है।

डिकोडिंग मेमोरी‑बैंडविड्थ‑बाउंड है: थ्रूपुट इस बात से निर्धारित होता है कि मॉडल अपनी की‑वैल्यू कैश को कितनी तेज़ी से पढ़ सकता है, न कि चिप कितनी सिद्धांततः ऑपरेशन कर सकती है। वह कैश संदर्भ के साथ बढ़ता है। प्रत्येक लूप चरण टूल परिणाम, एक अवलोकन, एक आंशिक योजना जोड़ता है — इसलिए दसवें चरण में टोकन उत्पन्न करना पहले चरण की तुलना में बहुत बड़े कैश के विरुद्ध होता है।

इस बीच डिवाइस गर्म हो रहा है, और गवर्नर क्लॉक्स को घटा रहा है।

इसलिए प्रति‑चरण लागत उसी क्षण बढ़ती है जब डिवाइस की वह लागत वहन करने की क्षमता घटती है। दो वक्र मिलते हैं, और जहाँ वे मिलते हैं, वहीँ आपका उत्पाद विफल होता है। यह कभी भी पहला चरण नहीं होता। पहला चरण वह है जहाँ आपने परीक्षण किया था।

इसके नीचे एक स्केल समस्या भी है। जनरेटिव कार्य बस एक अलग खर्च क्रम है जो एज सिलिकॉन ने एक दशक तक चलाते हुए खर्च किया: 88 मॉडलों पर मापा गया, टेक्स्ट वर्गीकरण की लागत लगभग 0.002 kWh प्रति हजार इनफ़रेंस है, जबकि टेक्स्ट जनरेशन के लिए 0.047 kWh — लगभग बीस गुना अधिक, किसी भी लूप के गुणा से पहले। ये माप डेटा‑सेंटर GPU पर किए गए थे, न कि हैंडसेट पर, इसलिए इन्हें आपके डिवाइस की पावर फ़िगर के बजाय कार्य प्रकारों के अनुपात के रूप में पढ़ें। स्केल के लिए, वही अध्ययन एक पूर्ण स्मार्टफ़ोन चार्ज को 0.022 kWh बताता है।

जूल प्रति पूर्ण कार्य पर खरीदें, टोकन प्रति सेकंड पर नहीं

उस 2026 बेंचमार्क में सबसे उपयोगी परिणाम वह है जो सबसे कम प्रभावशाली दिखता है।

एक Hailo‑10H NPU ने 2 वॉट से कम पर 6.9 टोकन प्रति सेकंड संभाले। धीमा — वास्तव में धीमा, और लेखकों ने भी यही कहा। लेकिन इसका थ्रूपुट कोएफ़िशिएंट ऑफ़ वैरिएशन 0.04 % था, जो परीक्षण किए गए किसी भी अन्य चीज़ से दो क्रम magnitude अधिक स्थिर था। उसी अध्ययन में लैपटॉप GPU ने 34.1 वॉट पर 131.7 टोकन प्रति सेकंड प्रदान किए।

फिर दोनो को ऊर्जा के आधार पर तुलना करें, गति के बजाय: छोटे NPU पर टोकन प्रति 270.5 मिलीजूल, जबकि GPU पर 297.3 मिलीजूल। थ्रूपुट में उन्नीस गुना अंतर के बावजूद, छोटे भाग ने प्रति जूल थोड़ा अधिक गणना की — और यह लगभग बिना किसी वैरिएशन के किया।

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

ईमानदार आपत्ति, और यह क्या हल नहीं करती

स्पष्ट उत्तर यह है कि यह एक अस्थायी समस्या है: सिलिकॉन सुधरता है, NPU परिपक्व होते हैं, और 2026 के फ़ोन के बारे में लिखा गया कोई भी चीज़ पुरानी लगेगी। या, अधिक व्यावहारिक रूप से, महंगे चरणों को सर्वर पर ऑफ़लोड करें।

मैं स्वयं हार्डवेयर पर दांव लगाऊँगा। लेकिन ऑफ़लोडिंग वही राउंड‑ट्रिप है जिसे आप एज पर ले जाने से बचना चाहते थे, और एक एजेंट इसे एक बार नहीं, बल्कि प्रत्येक लूप चरण में भुगतान करता है, और लूप की लंबाई वह चीज़ है जिसे आप पूर्वानुमान नहीं कर सकते। हाइब्रिड डिज़ाइन वैरिएशन को नहीं हटाते; वे इसे नेटवर्क पर स्थानांतरित करते हैं।

गहरी असममिति प्रोसेस नोड्स के साथ नहीं बदलती। डिवाइस का बजट डिजाइन समय पर निश्चित होता है। एजेंट की मांग रन‑टाइम पर तय होती है, उपयोगकर्ता की मांग के अनुसार। बेहतर सिलिकॉन छत को ऊपर उठाता है, लेकिन यह एजेंट को नहीं बताता कि छत कहाँ है।

तो इसे बताइए। टर्न सीमा को कोड रिव्यू में खोजने के बजाय उत्पाद विनिर्देश में निर्धारित करें, और थर्मल एन्क्लोज़र से संख्या चुनें: तय करें कितने चरण फिट होते हैं, फिर एजेंट को इस सीमा पर अपना सर्वश्रेष्ठ उपलब्ध उत्तर देने के लिए डिज़ाइन करें, न कि मनमानी सीमा पर आदर्श उत्तर देने के लिए। इसे लक्ष्य नहीं, बल्कि समय‑सीमा के रूप में देखें।

फिर एजेंट को बजट इनपुट के रूप में दें। शेष हेडरूम, बैटरी की स्थिति, प्लेटफ़ॉर्म ने पहले ही थ्रॉटलिंग शुरू कर दी है या नहीं — यह संदर्भ में होना चाहिए, जैसे वर्तमान समय। एक एजेंट जो जानता है कि वह दस में से आठवें चरण पर है, सारांश बना सकता है और कमिट कर सकता है। जो नहीं जानता, वह तब तक खोजता रहेगा जब तक ऑपरेटिंग सिस्टम उसकी ओर से निर्णय नहीं ले लेता।

और मध्य नहीं, बल्कि अंत को परीक्षण करें, जो भौतिक डिवाइस पर सिमुलेशन में परीक्षण करने के बराबर है। विफलता केस कभी भी साफ़ रन नहीं होता। यह वह रन है जो चौदह चरण लेता है क्योंकि टूल ने तीसरे चरण में अस्पष्ट कुछ लौटाया, और आप उन चरणों को हाथ से गिन नहीं सकते एक ऐसे फ़ोन पर जिसे प्रत्येक प्रयास के बीच ठंडा होना पड़ता है। मेरे अपने सिस्टम मुख्यतः सिमुलेशन के विरुद्ध प्रशिक्षित होते हैं इस कारण से: रोचक व्यवहार लंबी रन में होता है, और लंबी रन वही हैं जो हार्डवेयर आपको हाथ से सैंपल नहीं करने देता।

इनमें से किसी को भी तेज़ चिप की आवश्यकता नहीं है। यह स्वीकार करने की जरूरत है कि कार्यभार का आकार बदल गया है। कोई भी ऐसा डिवाइस नहीं भेजता जिसकी बैटरी एक फ़ोटो के लिए पर्याप्त हो। हम अभी भी ऐसे डिवाइस भेज रहे हैं जिनका थर्मल बजट एक इनफ़रेंस के लिए निर्धारित है।