يقلل مجدول أولويات ثلاثي الطبقات من زمن استجابة النماذج اللغوية على الجهاز من أكثر من ثانية إلى أقل من عُشرَي جزء من الثانية، مما يحافظ على استجابة تطبيقات الدردشة حتى عندما يكون الهاتف مشغولاً بالعمل في الخلفية. صُمم هذا المجدول لشريحة Tensor G3 التي تشغل نموذجاً بـ 3 مليارات معلمة، حيث يقلص زمن الاستجابة من 1,420 مللي ثانية إلى 161 مللي ثانية دون إيقاف مهام الخلفية.

لماذا تواجه النماذج اللغوية الكبيرة (LLMs) على الأجهزة صعوبات

إن تشغيل نموذج لغوي كبير على معالج محمول يمثل ضغطاً كبيراً على الموارد. ففي شريحة Tensor G3، يستهلك النموذج ذو الـ 3 مليارات معلمة بالفعل حوالي 85% من وحدة المعالجة العصبية (NPU). وعندما تعمل مهمة منخفضة الأولوية — مثل فهرس غير متصل بالإنترنت — في نفس الوقت الذي يفتح فيه المستخدم نافذة دردشة، يقفز زمن الاستجابة الملحوظ من حوالي 140 مللي ثانية إلى 1,400 مللي ثانية، وهو تباطؤ بمقدار عشرة أضعاف يلاحظه المستخدمون على الفور.

المشكلة لا تقتصر على السرعة فحسب؛ إذ يجب على الأجهزة المحمولة الموازنة بين سلاسة واجهة المستخدم، وعمر البطارية، وتعدد التطبيقات التي تطلب جميعها قدرات حوسبية. إن استخدام طابور بسيط يعالج المهام حسب ترتيب وصولها يجبر خيط واجهة المستخدم (UI thread) على انتظار مهام الخلفية، مما يحول المساعد الحواري إلى تجربة بطيئة.

كيف يعمل المجدول ثلاثي الطبقات

يدرج المجدول الجديد ثلاثة مكونات منسقة في مسار الاستدلال:

  1. Priority Queue (طابور الأولويات) – عبارة عن min-heap يقوم بترتيب المهام الواردة حسب مستوى أهمية ثابت.
  2. Preemption Controller (متحكم الاستباق) – عند وصول طلب ذي أولوية أعلى، يقوم بإيقاف المهام ذات الأولوية الأقل مؤقتاً بدلاً من التخلص منها.
  3. Token Budget Governor (منظم ميزانية الرموز) – يضع حداً أقصى لعدد الرموز (tokens) التي يمكن للمهمة إنتاجها بناءً على حالة دورة حياة التطبيق.

تتيح هذه المكونات معاً لطلب الدردشة في الواجهة الأمامية القفز إلى مقدمة الطابور، بينما تظل مهام الخلفية في حالة توقف مؤقت، جاهزة للاستئناف عند توفر الموارد.

مستويات الأولوية والاستباق

تحدد أربعة مستويات ما يمكن مقاطعته:

المستوى الوصف
Foreground Chat تفاعل حيوي مع واجهة المستخدم
Inline Suggestion تلميحات بأسلوب الإكمال التلقائي
Background Summary تلخيص دوري للمحتوى
Offline Indexing معالجة البيانات الضخمة

لا يقوم المجدول أبداً بإلغاء مهمة منخفضة الأولوية. بدلاً من ذلك، يأخذ لقطة (snapshot) لذاكرة التخزين المؤقت للمفاتيح والقيم (KV cache) الخاصة بالنموذج — وهي بنية تحتفظ بنتائج الانتباه الوسيطة — ويوقف المهمة مؤقتاً. وعندما ينتهي الطلب ذو الأولوية العالية، يستعيد المتحكم اللقطة ويسمح لمهمة الخلفية باستئناف العمل من حيث توقفت. يتجنب نهج "الإيقاف والاستئناف" هذا عملية إعادة الحوسبة المكلفة التي كانت ستحدث لو تم بدء المهمة من الصفر.

كما يساهم الإخلاء الجزئي لذاكرة KV-cache في تقليل الهدر بشكل أكبر. حيث تظل مطالبة النظام (system prompt) الثابتة في ذاكرة التخزين المؤقت، بينما يتم إخلاء تحولات المحادثة الديناميكية فقط. والنتيجة هي تقليل بنسبة 40% إلى 60% في تكلفة إعادة التعبئة المسبقة للنموذج بعد التوقف.

إدارة ميزانيات الرموز بدون مؤقتات

تعتمد العديد من التطبيقات على المؤقتات لتخمين الوقت الذي يجب أن تتنازل فيه المهمة عن وقت وحدة المعالجة المركزية (CPU) أو وحدة المعالجة العصبية (NPU). وتعتبر المؤقتات أداة غير دقيقة؛ إذ يمكنها إما حرمان واجهة المستخدم من الموارد أو عدم استغلال الشريحة بشكل كامل. يستبدل المجدول المؤقتات بـ ProcessLifecycleOwner الخاص بنظام Android، والذي يرسل أحداث دورة الحياة التي تشير بدقة إلى ما إذا كان التطبيق في الواجهة الأمامية أو الخلفية.

  • ON_RESUME – يستعيد التطبيق ميزانية الحوسبة الكاملة، مما يسمح لمهام الواجهة الأمامية المعلقة بالعمل دون عوائق.
  • ON_STOP – يقوم التطبيق بتقليل مهام الخلفية إلى حوالي 25% من ميزانية الرموز العادية، مما يوفر هامشاً لأي طلب مفاجئ من واجهة المستخدم.

من خلال ربط تخصيص الموارد بأحداث دورة الحياة، يستجيب النظام لسلوك المستخدم الحقيقي بدلاً من فترات زمنية عشوائية.

مكاسب الأداء والمقايضات

في ظل وجود طابور بسيط يعتمد مبدأ "من يأتي أولاً يُخدم أولاً"، تدفع مهمة الخلفية زمن استجابة الدردشة في الواجهة الأمامية إلى حوالي 1,420 مللي ثانية. ومع تفعيل مجدول الأولويات، يكتمل طلب الدردشة نفسه في حوالي 161 مللي ثانية، وهو تحسن بمقدار عشرة أضعاف يعيد سلاسة تجربة المستخدم.

يؤدي استئناف مهمة متوقفة إلى زيادة قدرها حوالي 22% في إجمالي وقت تنفيذها. وبما أن عمل الخلفية ليس حرجاً، فإن هذه المقايضة تظل مقبولة، خاصة عندما تظل واجهة المستخدم سريعة الاستجابة.