اللحظة التي يتحول فيها الترميز التخميني إلى خسارة في عناقيد GPU متعددة المستأجرين داخل المنشأة
لمن هذا المقال
نكتب هذا المقال للمهندسين الذين يشغّلون بأنفسهم خدمة استدلال نماذج اللغة الكبيرة، سواء داخل الشركة أو خارجها، ولا سيما من يتعامل منهم مع بيئات متعددة المستأجرين يشترك فيها عدة عملاء أو نماذج داخل عنقود GPU واحد. نفترض أن القارئ يعرف بالفعل ما هو الترميز التخميني، ونحاول هنا مساعدته على الإجابة عن سؤال عملي: هل سيحقق هذا الأسلوب فائدة حقيقية عند تطبيقه على عنقودنا نحن. الجواب المختصر هو أن الأمر يتوقف على مدى خلو العتاد فعلا من الحمل، وأن هذا القرار يجب أن تتخذه الجدولة لا النموذج المسودة.
مخطط مفاهيمي
المشكلة: الشروط التي تقوم عليها قصص النجاح تختلف عن شروطنا
يُعد الترميز التخميني اليوم الأداة الأساسية لخفض زمن استجابة خدمة نماذج اللغة الكبيرة. يقترح نموذج مسودة صغير ورخيص عدة مرشحين للرمز التالي مسبقا، ثم يتحقق منها النموذج الهدف في تمريرة أمامية واحدة. عند أحجام الدفعات المعتادة في أحمال العمل التفاعلية، تكون خطوة فك الترميز في الغالب محكومة بعرض النطاق الترددي للذاكرة، ما يترك وحدات الحساب خاملة في معظم الأحيان، وعمل التحقق هو الذي يملأ هذه القدرة الخاملة بالضبط، ولذلك يصبح توليد الرموز المقبولة أرخص بكثير من التوليد التسلسلي. تطور الأمر مؤخرا من المسودات الخطية إلى مسودات الأشجار، ثم إلى مسودات الأشجار المتوازية، مع ارتفاع مستمر في عائد الرموز المقبولة. أما JetSpec، وهو العمل السابق الذي تستهدفه هذه الورقة مباشرة، فقد أبلغ عن معدل معالجة يتجاوز 1,000 رمز في الثانية باستخدام مسودات الأشجار المتوازية.
المشكلة أن كل هذا التسريع يقوم على افتراض واحد فقط، وهو وجود قدرة حاسوبية فائضة تمتص عملية التحقق مجانا. والعنقود المشترك هو بالضبط ما يزيل هذه الوفرة. تشغّل ThakiCloud عناقيد داخل المنشأة سيادية البيانات لصالح الصناعات الخاضعة للتنظيم والمؤسسات محدودة الموارد التي لا يمكنها إخراج المطالبات إلى الخارج. تتميز هذه العناقيد بخاصيتين في آن واحد. الأولى هي تعدد المستأجرين، حيث توضع عدة نماذج وعملاء معا لتحقيق أقصى استفادة من المسرّعات الباهظة الثمن. والثانية هي عدم التجانس، أي مزيج من A100 وH100 وبطاقات GPU من فئة المستهلك تم شراؤها على فترات مختلفة. فإذا كانت بطاقة GPU مشبعة أصلا بطلبات مستأجرين آخرين، فإن وحدات الحساب لم تعد خاملة. في هذه الحالة، تصبح الرموز الإضافية التي يرسلها المتنبئ إلى النموذج الهدف للتحقق منها ليست مجانية، بل هي حمل حسابي حقيقي، يطيل زمن التمريرة الأمامية لكل الطلبات التي تشارك الدفعة نفسها. وهكذا يمكن أن ينقلب التسريع الملاحظ في حالة المستأجر الواحد إلى بطء إضافي في حالة تعدد المستأجرين، والأسوأ من ذلك أن هذا البطء الإضافي هو أثر خارجي يتحمله مستأجرون مجاورون لم يطلبوا التخمين أصلا.
المساهمة الأساسية: تحويل التسريع إلى قيمة تستطيع الجدولة حسابها
المساهمة الأولى لهذه الورقة هي التعبير الصريح عن التسريع الفعلي المتحقق $S_{real}$ كدالة في ثلاثة متغيرات تستطيع الجدولة رصدها والتحكم فيها مباشرة، وهي معدل القبول لكل رمز، والقدرة الحاسوبية الفائضة، وتداخل التجميع الدفعي. وعندما تُنمذج كلفة التحقق بهذه المتغيرات، يُشتق بشكل طبيعي الشرط الذي يتوقف عنده التخمين عن تحقيق أي فائدة كلما اقتربت القدرة الحاسوبية الفائضة من الصفر. ولأن عائد الرموز المقبولة يشبع عند نقطة معينة مهما زاد طول المسودة، بينما تستمر كلفة التحقق في المقام في الازدياد بشكل متناسب مع طول المسودة، فإنه يوجد دائما طول للمسودة يتحول عنده التخمين إلى خسارة على بطاقة GPU مشبعة. وميزانية المسودة المثلى المشتقة من ذلك تتقلص هي أيضا كلما تقلصت القدرة الحاسوبية الفائضة، وهي قيمة لم تكشف عنها الأنظمة السابقة المتمركزة حول المسودة للجدولة حتى الآن.
ثانيا، تصوغ هذه النمذجة تداخل التجميع الدفعي كأثر خارجي. فحين تكبّر رموز التحقق الخاصة بطلب يستخدم التخمين حجم الدفعة، يزداد أيضا زمن الاستجابة بين الرموز لبقية المستأجرين الذين يشاركون الدفعة نفسها. أي أن الأمر مسألة باريتو يجب أن تنظر معا في المكسب الذي يحققه طلب واحد والكلفة التي يتحملها عدة جيران، وليست مسألة يمكن حلها بالنظر إلى طلب واحد بمعزل عن غيره. وبناء على هذه الملاحظة، تضع الورقة شرطي قبول لتحديد أي الطلبات يُعالَج عبر التخمين ومتى. أولا، يجب أن يكون التخمين مفيدا للطلب نفسه. وثانيا، يجب ألا يتجاوز الأثر الخارجي الناتج عنه هامش أهداف مستوى الخدمة (SLO) الخاص ببقية المستأجرين المشتركين في الدفعة نفسها.
المساهمة الثالثة هي SovereignSpec، وهو تنفيذ فعلي لهذا النموذج في صورة سياسة قابلة للنشر. يتألف من ثلاث سياسات متعاونة مبنية فوق Kueue وKubernetes. الأولى هي قبول واعٍ بمعدل القبول، حيث تقرأ الجدولة في كل نبضة جدولة القدرة الحاسوبية الفائضة الآنية لبطاقات GPU المرشحة، وتطبق شرط القبول أعلاه، وإذا لم يتحقق الشرط فإنها لا ترفض الطلب بل تعالجه بفك ترميز عادي بلا تخمين. الثانية هي التوزيع غير المتجانس، حيث تُوجَّه الطلبات ذات معدل القبول المرتفع والحساسة لزمن الاستجابة إلى بطاقات GPU التي تملك قدرة حاسوبية فائضة كبيرة، بينما تُعالَج الطلبات ذات معدل القبول المنخفض أو الموجهة نحو الإنتاجية بفك ترميز عادي على البطاقات المشبعة أصلا. والثالثة هي التجميع الدفعي الحافظ للسيادة. فكثيرا ما يخضع المستأجر داخل المنشأة لقيد إقامة بيانات يمنعه من مشاركة عقدة أو ولاية قضائية معينة مع مستأجرين آخرين، ويعامل SovereignSpec هذا القيد كقيد صارم يُتحقق منه قبل حساب التسريع أصلا، بحيث يُستبعد أي توزيع يتجاوز حدود الثقة من الاعتبار منذ البداية، مهما بلغ التسريع المتوقع من كِبَر.
نتائج تحليل الأنظمة التي تعرضها الورقة مثيرة للاهتمام أيضا. ففي حالة الخمول، يظهر التسريع المألوف الذي يتجاوز الضعفين، لكن كلما التهم التجميع الدفعي المشترك القدرة الحاسوبية الفائضة، يتراجع التسريع بشكل مطرد، حتى ينخفض في حالة الإشباع، مع مسودة ضعيفة أو طول مفرط، إلى أقل من واحد، أي إلى خسارة صافية. وفي هذه الحالة، فإن الأسلوب التقليدي الذي ينفذ التخمين دون شرط يدفع ضريبة فك ترميز تتجاوز 20 بالمئة بينما يظن أنه يحقق تسريعا. كذلك أظهرت الورقة أن مجرد ضبط ميزانية المسودة بحسب القدرة الحاسوبية الفائضة، دون الحاجة إلى مسودة أفضل، يمكن أن يستعيد مكاسب نسبية في حدود 20 بالمئة اعتمادا على قرارات الجدولة وحدها، كما بيّنت بالأرقام أنه في غياب شرط الأثر الخارجي، تحدث فعلا حالات يُسرَّع فيها طلب واحد على حساب انتهاك أهداف مستوى الخدمة لعدة جيران.
ما الذي يعنيه هذا للشركة والمجتمع والعلم
بالنسبة لـThakiCloud، يشكل هذا البحث رافعة عملية يمكن وضعها مباشرة فوق حزمة خدمة الاستدلال القائمة على Kueue وKubernetes التي نشغّلها بالفعل. فالمؤسسات التي لا يمكنها إخراج المطالبات إلى الخارج لا تملك خيارا سوى شراء المسرّعات بإفراط، أو كسر مبدأ إقامة البيانات باللجوء إلى واجهة برمجية خارجية. وإذا أمكن، على غرار ما يسعى إليه SovereignSpec، إبقاء الترميز التخميني رابحا صافيا حتى تحت حمل متعدد المستأجرين، فإن العتاد نفسه من بطاقات GPU يمكنه خدمة عدد أكبر من المستأجرين مع خفض كلفة الطاقة لكل رمز، وهذا يمثل وسيلة ملموسة لتحسين اقتصاديات الخدمة داخل المنشأة دون المساس بحدود الثقة.
أما اجتماعيا، فإن هذا النوع من تحسين الجدولة يتيح للصناعات الخاضعة للتنظيم والمؤسسات محدودة الموارد خدمة نماذج اللغة الكبيرة بكلفة يمكن تحملها مع الحفاظ على سيادة البيانات، دون الاعتماد على واجهات برمجية ضخمة من مزودي الحوسبة فائقة النطاق. وهو عمل يذهب في اتجاه دحض الفكرة الشائعة القائلة إن هناك دائما مفاضلة حتمية بين سيادة البيانات وكفاءة الخدمة.
أما من الزاوية العلمية، فمدخل هذه الورقة مختلف. فقد سبق لعدة دراسات قياس أن أبلغت عن وجود فجوة كبيرة بين نظرية الترميز التخميني وأدائه الفعلي. وهذه الورقة تحدد المتغير الأساسي الذي يصنع هذه الفجوة، وهو القدرة الحاسوبية الفائضة، بوصفه قيمة يمكن للجدولة التعامل معها، وتعيد تعريف قرار التخمين بوصفه قرار جدولة لا قرار مسودة. وهي بذلك تسد بدقة الفراغ الذي تركته الأبحاث السابقة التي كانت تفترض بيئة أحادية المستأجر ومتجانسة العتاد فقط.
القيود والخطوات التالية
لا تخفي الورقة قيودها الذاتية. فهذا بحث مفاهيمي وتحليلي، ولا توجد بعد نتائج مقيسة على عنقود فعلي. كل الأرقام الواردة في الورقة هي قيم متوقعة من نموذج تم اشتقاقه من معاملات ضُبطت بالرجوع إلى معدلات قبول موثّقة وقياسات فصل مكونات موثّقة، وليست قيما مقيسة فعليا. ويحتاج ضبط المعاملات الأساسية، مثل وزن كلفة التحقق والقدرة الحاسوبية الفائضة، إلى تنميط لكل نموذج ونوع GPU على حدة، وأي خطأ في تقديرها يحمل خطر الموافقة على تخمين يشكل في الواقع خسارة صافية. كذلك فإن صيغة تداخل التجميع الدفعي هي تقريب من الرتبة الأولى يفترض منطقة الإشباع، ولذلك تحتاج منطقة الانتقال ذات القدرة الحاسوبية الفائضة المتوسطة إلى معايرة قائمة على القياس الفعلي. ولسد هذه الفجوة، يطرح فريق البحث خطة تقييم محددة، تشمل تنميط المعاملات على A100 وH100 وبطاقات GPU من فئة المستهلك، وتنفيذ الخوارزمية فعليا عبر إضافة فحص قبول في Kueue وخطافات جدولة في vLLM أو SGLang، ثم قياس التسريع الفعلي المتحقق إلى جانب زمن الاستجابة عند النسبة المئوية P99 والعدالة واستهلاك الطاقة لكل رمز.
يمكن الاطلاع على نص الورقة الكامل وبياناتها على Hugging Face. https://huggingface.co/datasets/thaki-AI/thaki-daily-papers/tree/main/papers/2026-07-05-sovereign-speculative-serving
أما تقديم الورقة إلى arXiv، فقد أعد خط الأتمتة بالفعل حزمة tar الخاصة بها، غير أن الرفع الفعلي يمر أولا بمراجعة بشرية، ولذلك فإن الحالة الراهنة هي جاهزة للتقديم وبانتظار الموافقة.