تقنية

عمال خدمة النموذج: هل يشتركون في عداد واحد؟

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

عمليات عمال خدمة النموذج يمكن أن تشغل التطبيق نفسه في أكثر من عملية. تشرح FastAPI أن العمليات عادة لا تشارك الذاكرة، ولكل منها متغيراتها وذاكرتها. [1]

الخلاصة السريعة

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

  • تصف FastAPI عمالًا متعددين يشغلون التطبيق نفسه، وتوضح أن العمليات عادة لا تتشارك الذاكرة؛ لا نعمم ذلك على نظام مشاركة صمم صراحة. [1]
  • في مثالنا لكل عامل عداد خاص يبدأ من صفر، وتزيده معالجة طلب واحد بواحد؛ نعلن مسار كل طلب قبل جمع الأعداد.
  • توزيع أربعة طلبات أ، ب، أ، أ يعطي العدادين 3 و 1؛ مجموعهما 4 لا يجعل أي عداد منفرد سجلًا لكل الطلبات.
  • اكتب نطاق الحالة وآلية أي مشاركة مقصودة، وافحص التوزيع الفعلي عند التشغيل؛ المثال لا يثبت سرعة أو ذاكرة أو تزامن تدريب.

العمال نسخ عمليات أم أجزاء نموذج؟

تشرح FastAPI إمكان تشغيل عمليات عمال متعددة للتطبيق نفسه، وأن كل عملية عادة تملك متغيراتها وذاكرتها دون مشاركة ذاكرة العمليات الأخرى. [1]

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

كما أن عبارة «عادة» مهمة: يمكن تصميم مشاركة صريحة أو استعمال مخزن خارجي. لا نستنتج من ذلك أن كل متغير محلي يصبح مشتركًا تلقائيًا؛ ينبغي وصف التصميم الذي يعتمد عليه هذا الادعاء.

حدد ما الذي يعده كل عامل

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

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

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

احسب الحالة دون دمجها ضمنيًا

بعد الأول يصبح عداد أ واحدًا ويبقى ب صفرًا. بعد الثاني يبقى أ واحدًا ويصبح ب واحدًا. ثم يرتفع أ إلى اثنين وبعده إلى ثلاثة، مع ب عند واحد.

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

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

ما بطاقة الحالة التي تحتاجها المراجعة؟

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

كذلك لا نحسب استهلاك RAM أو VRAM من عدد العمال وحده في هذه الورقة. لم نحدد أحجام النموذج أو طريقة تحميله أو تخزينه. الفصل بين العمليات لا يقدم قياسًا لمورد لم نختبره.

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

المصادر ومتابعة القراءة

  1. FastAPI: Deployment concepts (يفتح في نافذة جديدة)fastapi.tiangolo.com

أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.