انخفاض تأخير أول توكن بنسبة 32.4%! خطوة شishi للتكنولوجيا الكبرى في جدولة العناقيد، ومزيد من الكفاءة للاستدلال المحلي

يون Chung من أه في سي، الكميّة | الحساب العام QbitAI

في عناقيد GPU، قد يحدث انتظار الطلبات وخمول الموارد في آن واحد.

خلال مؤتمر CCF الوطني للحوسبة عالية الأداء لعام 2026، أطلقت شishi للتكنولوجيا منتجاً جديداًإطار الجدولة الموزعة TokenFleetووضعت محور التحسين على توجيه الطلبات، والتنسيق عبر مراكز البيانات، وحوكمة الأحمال المختلطة، في محاولة لرفع المخرجات الفعلية لقوة الحوسبة الحالية.

إذا نظرنا إلى خدمة الاستدلال بوصفها "مصنعاً محلياً لتحسين التوكنات"، فGPU هي معدات الإنتاج، وحالات الاستدلال محطات العمل، وطلبات الأعمال هي أوامر متتالية. ويتولى TokenFleet مهمة مطابقة هذه الأوامر مع الطاقة الإنتاجية.

نفس مجموعة الأجهزة، بمهام مختلفة وطرق توزيع مختلفة، ستنتهي إلى أوقات انتظار ومخرجات مطابقة للمواصفات مختلفة. والخدمة على نطاق واسع تتطلب النظر في هذه الترتيبات الإنتاجية مجتمعة.

يركز TokenFleet على المخرجات الفعلية للعنقود

بعد اكتمال نشر النموذج، لا يزال العنقود بحاجة إلى التعامل مع أنواع متعددة من الأعمال في آن واحد.

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

التوزيع البسيط قد يجعل بعض الحالات تشكو طوابير طويلة بينما لا تُستغل طاقات مواقع أخرى في الوقت المناسب. وتضغط الطلبات الطويلة والمهام الدفعية على بعضها فيبطئ التفاعل الفوري؛ كما أن انتهاء المهلة والإلغاء والحساب المكرر تستهلك موارد دون تحقيق تسليم مطابق للمواصفات.

يحقق TokenFleet، في ظل اتساق جودة النموذج ومتطلبات الخدمة وميزانية الحوسبة، من خلالرفع المخرجات الفعلية من التوكنات وخفض تكلفة وحدة المخرجات الفعلية。

يتولى TokenPilot اختيار الحالة داخل نفس مجمع النماذج، وFleetMind موجه للتنسيق عبر مراكز البيانات، وSLOMax مسؤول عن القبول للأحمال المختلطة وحوكمة الطوابير وتوزيع السعة، ولكل من التقنيات الأساسية الثلاث دورها الخاص.

من يُسلَّم إليه الطلب، ومتى تدخل المهمة الطابور، وكيف تتنسق سعات مراكز البيانات، كلها تعود في النهاية إلى المؤشر ذاته: مخرجات التوكنات الفعلية المكتملة بنجاح والمستوفية لمتطلبات الخدمة.

TokenPilot يحسب عائد التخزين المؤقت وكلفة الانتظار معاً

لنبدأ باختيار نقطة الطلب. عند إرسال طلب ما، إلى أي حالة يجب توجيهه؟

سؤال قصير ومستند طويل، حتى إذا عُدّ كل منهما طلباً واحداً، قد يختلف استهلاك الحوسبة وذاكرة العرض بينهما كثيراً. والتوزيع بناءً على عدد الطلبات وحده يصعب معه موازنة الحمل الفعلي بين الحالات.

يضيف التخزين المؤقت بُعد موازنة آخر لهذه المسألة. فالطلبات ذات البادئة الطويلة نفسها، إذا أُرسلت إلى حالة احتفظت بذاكرة KV المؤقتة ذات الصلة، فستتاح فرصة إعادة استخدام نتائج الحساب السابقة وتقليل Prefill، أي الحساب المكرر عند معالجة محتوى المدخلات.

لكن الحالة ذات نسبة إصابة التخزين المؤقت العالية قد تعني أيضاً انتظاراً طويلاً. وإذا تدافت الطلبات نحو الموضع نفسه، فقد يُستهلك وقت الحساب الموفَّر في الانتظار.

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

وبناءً على ذلك، يقارن المجدول تكلفة المعالجة المتوقعة للحالات المختلفة، ويحكم على ما إذا كان الحساب الموفَّر من إعادة استخدام التخزين المؤقت يعوّض الانتظار الإضافي.

وفقاً لبيانات الضبط لـGLM5.3 التي قدمتها شishi للتكنولوجيا، وفي ظل ظروف عنقود بطاقات الرسوم والأحمال المُختبَرة، بعد اعتماد التوجيه بالتأخير المتوقع،انخفض تأخير أول توكن عند P95 بنسبة 32.4%، وانخفض تأخير أول توكن عند P50 بنسبة 71.3%。

△ الجدول 1 نتائج ضبط تأخير أول توكن في TokenPilot. مصدر البيانات: مواد عرض شishi للتكنولوجيا في المؤتمر. حُسبت نسبة التحسين وفق (القيمة الأساسية − القيمة المحسّنة) ÷ القيمة الأساسية؛ وانخفاض التأخير لا يعني بالضرورة انخفاض التكلفة.

يعكس P50 المستوى الوسيط، ويعكس P95 حالة انتظار الطلبات في الذيل. تُظهر هذه المجموعة من البيانات تحسّن الاستجابة في الظروف المقاسة؛ ولا يزال تقييم العائد مقابل التكلفة يتطلب الجمع بين الإنتاجية واستهلاك الموارد.

FleetMind يحسب أيضًا سعة الخدمة عبر مراكز البيانات المتعددة

عند توسيع وجهة النظر من موديل واحد إلى عدة مراكز بيانات، يضيف التوزيع طبقة إضافية من الحكم على السعة.

وجود وحدات GPU خاملة لا يعني بالضرورة القدرة على استقبال الطلبات فورًا. فما إذا كان النموذج المستهدف منشورًا، وهل الإصدار متطابق، وهل نقطة الخدمة جاهزة، وكم يستغرق نقل البيانات عبر الشبكة، كلها عوامل تؤثر في فعالية توزيع الحمل.

يهتم FleetMind بـسعة خدمة النماذج المتاحة فعليًا. في تصميم TokenFleet، يقوم بتجميع توافر النماذج والسعة الفورية وحالة الشبكة في مراكز البيانات كافة، فيختار أولًا مركز التنفيذ، ثم يختار محرك القرار المحلي في ذلك المركز مثيل الاستدلال المحدد.

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

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

لتنسيق السعة أيضاً مقاييس زمنية مختلفة: على المدى القصير يُعدَّل توجيه الطلبات الجديدة، وعلى المدى الطويل يُعدَّل عدد نسخ النموذج ومواقع التسخين المسبق، مع الجمع بين حجز السعة، والوعي بحدود الأحمال، والتراجع التلقائي، لتقليل عدم تطابق السعة.

△ الشكل 3: إطار التنفيذ عبر مراكز البيانات في FleetMind. توضيح: المنطقة A هي مدخل الأعمال ولا تُحتسب ضمن تجمع سعة GPU؛ المنطقة B هي العنقود الحالي، والمنطقتان C وD هما مركزا التوسعة.

TokenPilot وSLOMax موجّهان للعناقيد الحالية، بينما FleetMind موجّه لتوسعة مراكز الحوسبة الجديدة لاحقاً. الهدف من التنسيق عبر مراكز البيانات هو تمكين السعات الموزعة المستوفية لقيود الأعمال من استيعاب الطلبات الساخنة، وتقليل عدم تطابق السعة والحجز المكرر.

SLOMax ينظّم الإنتاج وفق متطلبات الخدمة

تدخل الطلبات إلى العنقود نفسه، غير أن متطلبات التسليم تختلف من طلب لآخر.

المحادثة الفورية تهتم بزمن استجابة أول Token وسرعة التوليد المستمرة، بينما تعتمد مهام السياق الطويل أكثر على قدرة معالجة المدخلات وسعة KV، أما مهام المعالجة الدفعية غير المتصلة فتُعنى بموعد الإنجاز ومعدل الإنتاجية. وضعها جميعاً في طابور واحد سهّل يسبب التنافس على الموارد.

عمليات Prefill الطويلة، وضغط سعة KV، والأحمال الدفعية، جميعها قد تضغط على الطلبات التفاعلية. كما أن انتهاء المهلة والإلغاء والتنفيذ المكرر يجعل جزءاً من الحوسبة لا يتحول إلى تسليم فعّال.

يحدد SLOMax نوع العمل بالاعتماد على طول المدخلات وميزانية المخرجات ونوع المهمة وأهداف خدمة المستأجر، ثم يطبّق القبول حسب الأولوية والانتظار في تجمعات منفصلة وينسّق السعة. ويتعين عليه ضمان سعة التفاعل والتحكم في التزامن والتداخل المتبادل بين الطلبات الطويلة والقصيرة.

△ الشكل 4: إطار طوابير التصنيف والتغذية الراجعة للسعة في SLOMax. توضيح: تُستخدم تغذية التأثير الراجعة لضبط السعة والقبول، ولا يفترض الإطار وجود قدرة على مصادرة المهام أثناء التشغيل.

لقياس فعالية هذا الجدولة، يعتبر TokenFleet المُنتَج المطابق للمعايير هدفاً للتحسين.

Goodput، أي معدل إنتاجية المخرجات المطابقة للمعايير، يحسب: إجمالي عدد رموز Token الناتجة من الطلبات المكتملة بنجاح والمستوفية لمتطلبات الخدمة المتفق عليها خلال فترة الاختبار الكاملة، مقسوماً على مدة الاختبار. ويلزم تعريف عتبات المطابقة لكل فئة من المهام بشكل منفصل وعرض النتائج لكل منها.

يُغذّي النظام الجدولة بمعدلات الإنتاجية المطابقة والفشل والإلغاء والتنفيذ المكرر، ويستمر في ضبط نسب القبول والسعة. مدى انشغال GPU ومدى ارتفاع الإنتاجية الإجمالية، كلاهما يجب النظر إليهما مع التسليم النهائي المطابق للمعايير.

في مثال تقدير عوائد GLM5.3 المقدَّم من Shistone Technology، وبعد تبنّي الجدولة المنسّقة مع التحكم في التدفق، زادت إنتاجية المخرجات الإجمالية بنحو 1.5%،وارتفعت إنتاجية المخرجات المطابقة للمعايير بنحو 29.4%وارتفعت نسبة المطابقة من نحو 67% إلى نحو 86%.

△ الجدول 2: مثال تقدير عائد إنتاجية Token الفعالة في SLOMax. مصدر البيانات: مواد عرض المؤتمر من Shistone Technology. هذا الجدول مثال لتقدير العوائد؛ وتُستخدم في نسبة المطابقة القيم المقربة الواردة في النص الأصلي، مع تغير بنحو 19 نقطة مئوية.

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

من إجمالي مخرجات مماثل في الحجم، إذا أمكن تقليل حالات انتهاء المهلة والإلغاء والحساب المكرر، تتحسن فرصة تسليم المزيد من رموز Token المطابقة للمعايير. ويدرج SLOMax هذه النتائج في التغذية الراجعة لضبط توزيع الموارد اللاحق.

كفاءة مصنع تحسين Token المحلي يتوقف أيضاً على الجدولة

يدفع TokenFleet تحسين خدمات الاستدلال إلى مستوى العنقود. كيفية توزيع أداء النسخ على الطلبات المختلفة، وكيفية مشاركة سعات مراكز البيانات المتعددة في الخدمة، كلها تحتاج إلى جدولة تصل الموارد بمتطلبات الأعمال.

شركة Shistone Technology (METASTONE) هيمشغّل مستقل من الطرف الثالث لسعات الحوسبة متكاملة الحزمةلا ترتبط بأي مصنّع نماذج لغوية كبيرة بعينه، وتقدم للعملاء خدماتتسليم سعة حوسبة متكاملة الحزمة شاملة الأجهزة والشبكات والجدولة والتحسين والتشغيل بنقرة واحدة。

وبفضل الخبرة الغنية المستمدة من مراكز الحوسبة الوطنية، تصل اتفاقية مستوى الخدمة (SLA) لتشغيل عناقيد قوة الحوسبة لديها إلى أكثر من 99.95%. وحالياً، أدرت شركة Shistone Technology (是石科技) بالفعل أكثر من 20000P+ من موارد قوة الحوسبة، وتشغّل أكثر من 10 مراكز حوسبة فائقة الذكاء، من بينها 2 مركز وطني للحوسبة الفائقة؛ وقد حاز أعضاء الفريق 3 جوائز غوردون بيل، وراكموا خبرة في الخدمات الفنية متكاملة الحزمة للعناقيد فائقة الحجم.

حول مصنع تحسين Token المحلي، تعمل Shistone Technology على صقل قدراتها البرمجية باستمرار من خلال تطويرها الذاتي واستخدامها الذاتي، على أمل جعل خدمات الاستدلال العامة عالية التكرار أكثر اقتصادية، وتمكين الحوسبة المحلية من إظهار قدرات أكبر.

محرك الاستدلال الفعّال Meta-Infer الذي أُصدر سابقاً ركّز على رفع كفاءة تنفيذ نسخة الاستدلال الواحدة. أما TokenFleet هذه المرة فيضع التركيز علىجدولة العنقودمن خلال توزيع الطلبات وتنسيق السعة وحوكمة الأحمال المختلطة، لتنظيم الخدمة على نطاق واسع.

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

يركّز TokenFleet اتجاه التحسين الإضافي على كيفية تخصيص كل طلب وكيفية استخدام كل وحدة من السعة.

*تم نشر هذا المقال على منصة قناتوانغوي (量子位) بإذن، وتمثل الآراء الواردة فيه ملكًا لمؤلفها الأصلي وحده.