مُلخّص

الاستدلال الدفعي غير المتصل هو مهمة شائعة في الصناعة لتطبيقات التعلم العميق، ولكن قد يكون من الصعب ضمان الاستقرار والأداء عند التعامل مع كميات كبيرة من البيانات وأنابيب استدلال معقدة. تقدم هذه الورقة AntBatchInfer، وهو إطار عمل للاستدلال الدفعي المرن، تم تحسينه خصيصًا للمجموعات غير المخصصة. يعالج AntBatchInfer هذه التحديات من خلال توفير قدرات متعددة المستويات لتحمل الأعطال، مما يمكّن من تنفيذ مهام الاستدلال المتنوعة وطويلة الأمد بثبات. كما يعزز كفاءة الاستدلال من خلال التوصيل الأنبوبي، والتوسع داخل العقدة وبين العقد. ويعمل أيضًا على تحسين الأداء في سيناريوهات الاستدلال الدفعي المعقدة للنماذج المتعددة. من خلال تجارب مكثفة وإحصاءات واقعية، نظهر تفوق إطار عملنا من حيث الاستقرار والكفاءة. في التجربة، تفوق على الأساس بما لا يقل عن 2\(\times\) و 6\(\times\) في الاستدلال الدفعي للنموذج الفردي أو النماذج المتعددة. كما أنه يُستخدم على نطاق واسع في مجموعة Ant، مع آلاف الوظائف اليومية من سيناريوهات مختلفة، بما في ذلك DLRM، وCV، وNLP، مما يثبت قابليته للتطبيق في الصناعة.

المقدمة

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

للأسف، فإن معظم الأعمال والأنظمة الحالية مكرسة للاستدلال المتصل، بينما كانت هناك أعمال منهجية قليلة تأخذ في الاعتبار استدلال الدفعات في الإنتاج، والذي هو أيضًا حاسم للتطبيقات الصناعية. إحدى الطرق المباشرة هي تطبيق خط أنابيب الاستدلال المتصل على وظائف الدفعات. ومع ذلك، فإن الاستدلال غير المتصل له خصائص فريدة تميّزه عن الاستدلال المتصل، مثل أحمال العمل الضخمة غير الحساسة للزمن والتحكم في التكاليف (azure_batch_infer). على سبيل المثال، قد تصل العينات المراد معالجتها إلى تيرابايت في الصناعة. طريقة أخرى هي استخدام أنظمة معالجة الدفعات مثل MapReduce وSpark، والتي قادرة على معالجة مجموعات البيانات الضخمة مع ضمان الكفاءة وتحمل الأخطاء. ومع ذلك، فإنها لا تناسب جيدًا الاستدلالات الكبيرة أو المعقدة للنماذج. على سبيل المثال، غالبًا ما تحتاج نماذج التوصية بالتعلم العميق إلى تخزين معلمات كبيرة ونادرة عبر عدة خوادم للمعلمات (li2014scaling). علاوة على ذلك، فإن أنظمة معالجة الدفعات على غرار MapReduce غير مرنة عندما يتعلق الأمر بتنفيذ خطوط أنابيب استدلال النماذج المتعددة المعقدة حيث تختلف تعقيدات النماذج. لذلك، فإن الحل هو تدريب وخدمة هذه النماذج في مجموعة الحاويات، مثل مجموعة Kubernetes.

ومع ذلك، هناك مشكلتان رئيسيتان تواجهان أنظمة استدلال الدفعات الحالية في مجموعة K8S: الاستقرار (تحمل الأخطاء) والكفاءة. النهج التقليدي هو توزيع مجموعة البيانات بالتساوي على جميع العمال في الحاويات وأداء الحسابات النموذجية بطريقة موازية للبيانات. أولاً، تحمل الأخطاء أمر حيوي في استدلال الدفعات في المجموعة غير المخصصة (أو المجموعة المشتركة) على نطاق واسع، حيث قد يقوم المجدول بإخلاء وظائف الدفعات لضمان اتفاقية مستوى الخدمة للوظائف المتصلة (bernstein2014containers). بينما توفر معظم أنظمة استدلال الدفعات التي تقدمها شركات السحابة (aws_sagemaker, vertex_inference) تحمل الأخطاء على مستوى الوحدة ومرونة داخل العقدة (التوسع المرن للعقد أو تقليصها) لكنها لا تأخذ في الاعتبار تحمل الأخطاء على مستوى التطبيق في وقت التشغيل، مثل أخطاء التحميل، أو أخطاء المهلة. ثانيًا، لا تستفيد هذه الأنظمة بشكل كامل من الموارد الحاسوبية، خاصة في سيناريوهات استدلال النماذج المتعددة أو طرق الأنسجة. حل نموذجي هو تعيين عملية متنبئ النموذج إلى جهاز وحدة معالجة الرسومات، مما يؤدي إلى إهدار الموارد عندما يكون النموذج بسيطًا جدًا لاستخدام وحدة معالجة الرسومات بالكامل. بالإضافة إلى ذلك، ضع في اعتبارك سيناريو استدلال الدفعات للنماذج المتعددة، على سبيل المثال، التعرف على الوجه. بالنظر إلى نفس الصور المدخلة، يتطلب العملاء تنفيذ مرحلة الكشف عن الكائنات، تليها مرحلة تصنيف الصور للتنبؤ مرة واحدة. ومع ذلك، يتم دمج هذين النموذجين في نفس عملية المتنبئ في الأنظمة الحالية، مثل تحويل دفعات Azure (azure_batch_infer)، وVertex من Google (vertex_inference) بينما لهذين النموذجين أحمال عمل متباينة.

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

تحليل المشكلة

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

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

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

إطار عملنا

هندسة الإطار

لضمان استقرار وكفاءة الاستدلال الدفعي، نقترح إطار عمل AntBatchInfer. كما هو موضح في الشكل [fig:arch]، يتألف هذا الإطار من أربع وحدات: خدمة تقسيم البيانات الحالية (Stateful DDS)، معالج البيانات، المتحكم المرن، وجدولة المتنبئ المرن. تم تصميم النظام بناءً على هندسة السيد-العامل، حيث تقع خدمة تقسيم البيانات الحالية والمتحكم المرن على عقدة سيد منفصلة، بينما تقع الوحدات المتبقية على كل عقدة عامل.

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

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

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

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

التحسين من أجل الاستقرار

تشرح هذه الفقرة قدرة تحمل الأخطاء متعددة المستويات في AntBatchInfer. نصنف قدرتنا على تحمل الأخطاء إلى ثلاثة مستويات: تحمل أخطاء الوحدة، وتحمل أخطاء التطبيق، وتحمل أخطاء البيانات.

تحمل أعطال الوحدة

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

تحمل الأخطاء في التطبيق

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

تحمل أعطال البيانات

يقوم معالج البيانات في العامل الجديد أولاً بجلب شظايا “TODO” من خدمة DDS وقراءة العينات من مصدر البيانات. يتم تمييز الشظية بـ “DOING” عندما تبدأ الاستدلالات الدفعيه. بعد ذلك، يقوم المتنبئ بأداء حساب النموذج استنادًا إلى شظية البيانات المسحوبة. يقوم معالج البيانات بالإبلاغ عن حالة الشظية بعد أن تم تسجيل نتائج التنبؤ في نظام التخزين، وتقوم DDS بتمييز هذه الشظايا بـ “DONE” عندما تتلقى إشعارات من معالج البيانات. عندما يكتشف المتحكم المرن أي تعطل في العقدة ناتج عن أعطال أو أحداث توسع، سيتم تمييز الشظية المخصصة “DOING” للعامل بـ “TODO” من قبل خدمة DDS، وتقوم DDS بإعادة إدخال الشظية في نهاية قائمة البيانات. بهذه الطريقة، نضمن سلامة البيانات في حالات الفشل أو المرونة.

التحسين من أجل الكفاءة

تقليل الوقت الكلي لإتمام العمل

يقلل نظام توزيع البيانات الحالي (DDS) من الوقت الكلي لإتمام العمل ويوفر موارد الحوسبة من خلال تخصيص عينات البيانات بشكل مرن لكل عامل بناءً على معدل الإنتاجية الفعلي. هذا يحقق توازن الأحمال بين العمال بشكل طبيعي. إنه يقلل من الوقت الكلي لإتمام العمل الذي يتحدد بناءً على الآلات الأبطأ مقارنة باستراتيجية تقسيم البيانات المتساوية في مشكلة العقد ذات الذيل الطويل. بالإضافة إلى ذلك، يقوم المتحكم المرن بزيادة عدد عقد العمال لتحسين كفاءة التدريب عندما يكون العنقود غير نشط.

تسريع الاستدلال الدفعي لنموذج واحد

يحسن AntBatchInfer الاستدلال الدفعي لنموذج واحد من خلال فصله إلى ثلاث مراحل: تحميل البيانات، التنبؤ، والكتابة. تُحاط هذه المراحل في خيوط أو عمليات منفصلة ويقوم المجدول داخل العقدة بتغيير مقياس هذه المراحل في مستويات مختلفة من التزامن بناءً على خوارزمية تقديرية. يتم تداخل تنفيذ هذه المراحل (التي يحددها المستخدمون) في الجدول الزمني وتنسيق هذه المراحل من خلال قائمة انتظار خالية من الإقفال. على وجه التحديد، يزيد المجدول عدد عمليات أو خيوط تحميل البيانات عندما تكون قائمة الانتظار للاستدلال بالنموذج شبه فارغة ويزيد عدد المتنبئين بالنموذج عندما تكون قائمة الانتظار ممتلئة ووحدة المعالجة المركزية/وحدة معالجة الرسومات غير مستغلة بالكامل. يتم زيادة خيط الكتابة عندما تكون قائمة الكتابة ممتلئة بسبب طول التسلسل الناتج. يتداخل هذا النهج هذه الأحمال العمل المكثفة للإدخال/الإخراج والمكثفة لوحدة المعالجة المركزية أو وحدة معالجة الرسومات في خط أنابيب الاستدلال الدفعي لتعظيم الإنتاجية.

تسريع خط أنابيب الاستدلال الدفعي للنماذج المتعددة

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

العرض التوضيحي

في عرضنا التوضيحي، نعرض واجهة المستخدم البسيطة لـ AntBatchInfer ونستعرض حالة استخدام باستخدام الاستدلال الدفعي على مهمة تصنيف الصور باستخدام AntBatchInfer كما هو موضح في الشكل 3. يمكن تطبيق هذه التكوينات بسهولة على مهام الاستدلال الدفعي الأخرى. 1) يحدد EngineConfig موارد الأجهزة. يمكن للمستخدمين تحديد معامل الأولوية لتمكين مرونة العقدة الفاصلة، حيث يمثل 0.6 أن 60% من موارد الحوسبة حسب الطلب والباقي موارد مؤقتة. 2) يوفر كائن DataHandler تكوين مصدر البيانات، بما في ذلك num_workers للتحكم في التزامن. يتجاوز كائن DataLoader في Pytorch وكائن Dataset في Tensorflow. 3) يحدد WriterConfig نظام تخزين الإخراج المستهدف وعدد خيوط الكتابة. 4) يحدد ElasticPredictionRunner Config ملف النموذج وعدد المتنبئين. يمكن للمستخدمين تحديد قائمة بوظائف المعالجة المسبقة، وظائف المعالجة اللاحقة، والنماذج للاستدلال الدفعي لنموذج واحد أو لعدة نماذج. لاحظ أن المستخدمين يمكنهم تحديد عدد العمليات يدويًا أو تشغيل ميزة التوسع التلقائي داخل العقدة. بالإضافة إلى ذلك، لدينا واجهة مستخدم رسومية على الويب تتيح للمستخدمين ذوي الخبرة البرمجية القليلة استخدام AntBatchInfer بفعالية. سيتم عرض المزيد من التفاصيل في مقاطع الفيديو التوضيحية اللاحقة.

التجارب

في هذا القسم، نعرض كفاءة AntBatchInfer، مع عروض إضافية لتحمل الأعطال متعددة المستويات والمرونة المتاحة في مقاطع الفيديو التوضيحية التي تستخدم TensorFlow، PyTorch، وONNX كواجهات خلفية. أولاً، نقيم أداء AntBatchInfer في وظيفة استدلال دفعي لنموذج واحد لشبكة عصبية مخططة، TGAT (xu2020inductive)، مع نصف مليار عقدة و(6) مليار حافة. تؤدي هذه الوظيفة إلى استدلال دفعي لـ(260) مليون عينة على مجموعة CPU غير مخصصة كل يوم. تظهر النتائج أن AntBatchInfer أسرع على الأقل مرتين من الأساس فيما يتعلق بمعدل الاستعلامات في الثانية، والذي يبلغ (550) و(1200) على التوالي. الأساس يعطل تدفق العمل الأنبوبي ويميزه التوسع التلقائي داخل العقدة. ثانيًا، نؤدي استدلال دفعي في سيناريو نموذج متعدد على Nvidia A100s، حيث المرحلة الأولى هي الكشف عن الأجسام باستخدام متغير من نموذج SCRFD (guo2021sample)، والمرحلة الثانية هي تصنيف الصور بناءً على ResNet (he2016deep). تظهر النتائج أن AntBatchInfer يحقق معدل استعلامات في الثانية أسرع بما يقرب من ست مرات من الأساس، والذي يبلغ (68) و(398) على التوالي. الأساس يجمع نموذجين في مرحلة واحدة بشكل تسلسلي. ثالثًا، نقارن أيضًا وقت إكمال الوظيفة بين استراتيجية البيانات المتساوية والطريقة المبنية على DDS في سيناريو النموذج المتعدد. تظهر النتائج أن الطريقة المبنية على DDS تحقق تسريعًا من (12%) إلى (30%) مقابل الأساس حتى على A100s. وذلك لأن تعقيد البيانات المختلفة وتعقيد النموذج يصنعان الفرق. الفجوة أكبر بكثير في المجموعة غير المخصصة وفقًا لتجربتنا. أخيرًا، تظهر النتائج أن AntBatchInfer يتسع خطيًا عند إضافة ما يصل إلى (120) عقدة CPU، حيث يمتلك كل عقدة (20) نواة. هذا يؤكد أن تكلفة التزامن بين DDS الحالة وعقد العمال ضئيلة.