एक त्रिसुत्री प्राधान्य शेड्युलर (three-layer priority scheduler) ऑन-डिव्हाइस लँग्वेज-मॉडेलची लॅटन्सी (latency) एका सेकंदापेक्षा जास्तवरून दोन दशांश सेकंदाच्या खाली आणते, ज्यामुळे फोन बॅकग्राउंड कामात व्यस्त असतानाही चॅट ॲप्स प्रतिसादक्षम राहतात. ३ अब्ज पॅरामीटर असलेल्या मॉडेलवर चालणाऱ्या Tensor G3 चिपसाठी तयार केलेले हे शेड्युलर, बॅकग्राउंड जॉब्स थांबवल्याशिवाय लॅटन्सी १,४२० ms वरून १६१ ms पर्यंत कमी करते.

ऑन-डिव्हाइस LLMs का संघर्ष करतात

मोबाईल प्रोसेसरवर लार्ज लँग्वेज मॉडेल चालवणे म्हणजे संसाधनांची (resources) मोठी कमतरता आहे. Tensor G3 वर, ३ B मॉडेल आधीच न्यूरल-प्रोसेसिंग युनिट (NPU) चे सुमारे ८५% वापरते. जेव्हा एखादे कमी-प्राधान्य असलेले काम—जसे की ऑफलाइन इंडेक्सर—वापरकर्ता चॅट विंडो उघडत असतानाच सुरू होते, तेव्हा प्रतिसादाचा वेळ (response time) साधारण १४० ms वरून १,४०० ms पर्यंत वाढतो, जो दहापट स्लोडाउन वापरकर्त्यांना लगेच जाणवतो.

समस्या फक्त वेगाची नाही. मोबाईल उपकरणांना UI स्मूथनेस, बॅटरी लाईफ आणि संगणकीय शक्ती (compute) मागवणारे अनेक ॲप्स यांचा समतोल साधावा लागतो. कामांवर क्रमाने प्रक्रिया करणारी साधी क्यू (naïve queue) UI थ्रेडला बॅकग्राउंड कामाची वाट पाहायला भाग पाडते, ज्यामुळे संवादात्मक असिस्टंटचा अनुभव संथ होतो.

त्रिसुत्री शेड्युलर कसे कार्य करते

नवीन शेड्युलर इन्फरन्स पाईपलाईनमध्ये (inference pipeline) तीन समन्वित घटक समाविष्ट करते:

१. Priority Queue – एक min-heap जे येणाऱ्या कामांना त्यांच्या स्थिर महत्त्वाच्या पातळीनुसार (static importance level) क्रमवारी लावते. २. Preemption Controller – जेव्हा उच्च-प्राधान्य असलेली विनंती येते, तेव्हा ते कमी-प्राधान्य असलेली कामे काढून टाकण्याऐवजी ती थांबवते (pause). ३. Token Budget Governor – ॲपच्या लाइफसायकल स्थितीनुसार एखादे काम किती टोकन्स तयार करू शकते यावर मर्यादा घालते.

एकत्रितपणे, हे घटक फोरग्राउंड चॅट विनंतीला रांगेत सर्वात पुढे आणू देतात, तर बॅकग्राउंड कामे 'पार्क्ड' स्थितीत राहतात आणि संसाधने उपलब्ध झाल्यावर पुन्हा सुरू होण्यासाठी तयार असतात.

प्राधान्य टियर्स आणि प्रीएम्प्शन

काय व्यत्यय आणता येऊ शकतो हे चार टियर्स (tiers) ठरवतात:

टियर वर्णन
Foreground Chat महत्त्वपूर्ण UI संवाद
Inline Suggestion ऑटोकम्प्लीट-शैलीतील हिंट्स
Background Summary वेळोवेळी मजकुराचा सारांश
Offline Indexing मोठ्या प्रमाणावरील डेटा प्रोसेसिंग

शेड्युलर कमी-प्राधान्य असलेले काम कधीही रद्द करत नाही. त्याऐवजी, ते मॉडेलचा की-व्हॅल्यू (KV) कॅशे—एक अशी रचना जी मध्यवर्ती अटेंशन रिझल्ट्स (attention results) साठवते—त्याचा स्नॅपशॉट घेते आणि काम थांबवते. जेव्हा उच्च-प्राधान्य असलेली विनंती पूर्ण होते, तेव्हा कंट्रोलर स्नॅपशॉट पुन्हा पूर्ववत करतो आणि बॅकग्राउंड टास्क जिथे थांबला होता तिथूनच सुरू करू देतो. हा “pause-and-resume” दृष्टिकोन काम शून्यापासून पुन्हा सुरू केल्यास होणारी खर्चिक पुनर्गणना (recomputation) टाळतो.

पार्शियल KV-कॅशे इव्हिक्शनमुळे (Partial KV-cache eviction) वाया जाणारी संसाधने अधिक कमी होतात. स्टॅटिक सिस्टम प्रॉम्प्ट कॅशेमध्ये राहतो, तर फक्त डायनॅमिक संवादाचे टर्न्स काढून टाकले जातात. याचा परिणाम म्हणजे थांबल्यानंतर मॉडेल पुन्हा री-प्रीफिल (re-prefilling) करण्याचा खर्च ४०%–६०% ने कमी होतो.

टाइमर्सशिवाय टोकन बजेटचे व्यवस्थापन

अनेक अंमलबजावणी (implementations) एखादे काम कधी CPU किंवा NPU वेळ सोडून द्यावे याचा अंदाज घेण्यासाठी टाइमर्सवर अवलंबून असतात. टाइमर्स हे अनिश्चित असतात; ते एकतर UI ला अडथळा आणू शकतात किंवा चिपचा अपुरा वापर करू शकतात. शेड्युलर टाइमर्सच्या जागी Android चे ProcessLifecycleOwner वापरते, जे लाइफसायकल इव्हेंट्स (lifecycle events) पाठवते, ज्यामुळे ॲप फोरग्राउंडमध्ये आहे की बॅकग्राउंडमध्ये आहे हे विश्वसनीयपणे समजते.

  • ON_RESUME – ॲपला पूर्ण कम्प्युट बजेट पुन्हा मिळते, ज्यामुळे प्रलंबित फोरग्राउंड कामे कोणत्याही अडथळ्याशिवाय चालू शकतात.
  • ON_STOP – ॲप बॅकग्राउंड टास्कना त्यांच्या सामान्य टोकन बजेटच्या सुमारे २५% पर्यंत मर्यादित करते, ज्यामुळे कोणत्याही अचानक येणाऱ्या UI विनंतीसाठी जागा (headroom) शिल्लक राहते.

संसाधनांचे वाटप लाइफसायकल इव्हेंट्सशी जोडल्यामुळे, सिस्टम मनमानी टाइम स्लाईसऐवजी वापरकर्त्याच्या वास्तविक वर्तनानुसार प्रतिसाद देते.

कामगिरीतील सुधारणा आणि तडजोड

साध्या 'प्रथम येणाऱ्यास प्रथम सेवा' (first-come-first-served) क्यू अंतर्गत, बॅकग्राउंड टास्कमुळे फोरग्राउंड चॅटची लॅटन्सी सुमारे १,४२० ms पर्यंत वाढते. प्राधान्य शेड्युलर सक्रिय असताना, तीच चॅट विनंती साधारण १६१ ms मध्ये पूर्ण होते, जो दहापट सुधार आहे आणि यामुळे वापरकर्त्याचा अनुभव पुन्हा सुरळीत होतो.

थांबवलेले काम पुन्हा सुरू केल्यामुळे त्याच्या एकूण एक्झिक्युशन टाइममध्ये (execution time) सुमारे २२% वाढ होते. बॅकग्राउंड कामे गैर-महत्त्वाची असल्याने, हा तडजोड (trade-off) स्वीकारार्ह आहे, विशेषतः जेव्हा UI जलद राहते.