MoE ومزيج الخبراء: ما الذي تعنيه المعلمات النشطة فعلًا؟

يمكن لنموذج مزيج الخبراء (MoE) أن يقلّل العمليات الحسابية لكل توكن، مع بقاء حجمه هائلًا عند استضافته. فنموذج اللغة Kimi K3.1 Pro من Moonshot AI يضم 2.8T من المعلمات إجمالًا، لكنه يفعّل 104B لكل توكن، وفق منشور إطلاقه الرسمي. يساعد الرقم الأصغر على فهم حجم الحسابات، لكن الرقم الأكبر يظل حاسمًا حين تحتاج إلى تخزين الأوزان في الذاكرة.

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

ما هو مزيج الخبراء MoE؟

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

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

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

كيف تعمل بنية مزيج الخبراء؟

يختار الموجّه مسارات داخل النموذج، ثم تُدمج نتائجها. يعالج المحوّل (Transformer) العلاقات السياقية بين التوكنات. وفي محوّلات MoE الشائعة، تحل شبكات خبراء متعددة محل كتلة تغذية أمامية. تحوّل هذه الكتلة التمثيل العددي الداخلي للتوكن، بينما تتيح له آلية الانتباه، وهي آلية مستقلة، الاستفادة من السياق المحيط.

تجري العملية على النحو التالي:

1. يصل التمثيل الحالي للتوكن إلى طبقة MoE.
2. يمنح موجّه تعلّم أثناء التدريب، ويُسمّى أيضًا بوابة، درجة لكل خبير.
3. يختار الموجّه مجموعة فرعية، غالبًا من الخبراء الأعلى درجة. وهذا هو توجيه top-k، حيث تشير k إلى عدد الخبراء المختارين.
4. يعالج الخبراء المختارون ذلك التمثيل. ثم تُوزن مخرجاتهم وتُدمج قبل مواصلة المعالجة.

تتكرر هذه العملية في طبقات MoE داخل النموذج، ولذلك قد تختلف مجموعة الخبراء المختارة باختلاف التوكن والطبقة. يشرح عرض PyTorch لهذه البنية كيفية الدمج الموزون، وتبيّن الورقة البحثية للنموذج من Mistral كيف تتغير الاختيارات بين الطبقات.

ماذا يعني مزيج الخبراء المتناثر؟

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

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

نموذج مزيج الخبراء يظل نموذجًا واحدًا

يختلف التوجيه داخل MoE عن الاختيار بين نماذج تُتاح عبر API، أو طلب تصويت عدة روبوتات محادثة. يُدرَّب الموجّه والخبراء بوصفهم مكوّنات لشبكة واحدة. ويرسل التطبيق عادةً طلبه إلى تلك الشبكة؛ ولا يختار خبيرًا كما يختار منتجًا من قائمة.

يمنع هذا التمييز المطوّر من بناء تصميمه على افتراض مضلّل: اختيار نموذج MoE لا يمنح التطبيق فريقًا من الوكلاء المتخصصين يمكنه التحكم فيه.

كيف تقرأ أعداد المعلمات في نماذج مزيج الخبراء؟

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

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

Kimi K3.1 Pro: جزء نشط صغير من نموذج بالغ الضخامة

يوضح Kimi K3.1 Pro لماذا لا يصلح عدد المعلمات «النشطة» لتحديد حجم النموذج الذي ستستضيفه. عند تحويل الإجمالي الذي أعلنته Moonshot إلى الوحدة نفسها نحصل على 2,800B. وتصبح العملية 104 ÷ 2,800 × 100 = 3.7%، بعد التقريب.

هذا يعني أن العدد النشط المُعلَن يمثّل جزءًا صغيرًا من الإجمالي. لكنه لا يعني أن نظام تقديم النموذج يستطيع الاستغناء عن بقية الأوزان، أو أن زمن استجابة API يساوي هذه النسبة من زمن استجابة نموذج كثيف. فالمسار يتغيّر بتغيّر التوكنات والطبقات.

تصف مدونة الإطلاق من Moonshot نموذج Pro بأنه K3 خضع لتدريب لاحق، وتستخدم الوصف التقريبي «3T-class». أما منشور الإطلاق الرسمي فيحدّد الرقمين بدقة: 2.8T / 104B. اعتمد هذه المواصفات الصريحة عند تفسير حجم النموذج.

بالنسبة إلى المطوّر الذي يستخدم API، فهذا نموذج مرشّح للتقييم. أما مشغّل الاستضافة، فعليه أولًا التحقق من إتاحة الأوزان: في تاريخ التحقق، كانت Moonshot قد وعدت بإتاحة الأوزان كاملةً بحلول 4 نوفمبر 2026. والوعد بالإصدار لا يوفّر بعد ملفات قابلة للنشر. يتناول شرح Kimi K3.1 Pro قرار الاختيار الخاص بهذا الإصدار.

Qwen3-235B-A22B: العدد النشط لا يحل محل الإجمالي

يظهر هذا الفرق في اسم Qwen3-235B-A22B نفسه. تذكر بطاقة النموذج الأصلية من Qwen أن النموذج يضم 235B إجمالًا، منها 22B تُفعَّل، مع 128 خبيرًا، يُفعَّل منهم 8.

حساب نسبة المعلمات هو 22 ÷ 235 × 100 = 9.4%، بعد التقريب. إذا كنت تبني مساعدًا خاصًا للتعامل مع المستندات، فهذا مؤشر إلى طريقة الحد من الحسابات لكل توكن. لكن خطة الذاكرة يجب أن تستوعب نسخة الأوزان المختارة كاملةً، إلى جانب حالة الطلبات التي تخدمها.

لا تفسّر «22B نشطة» على أنها «تحتاج إلى ذاكرة نموذج كثيف بحجم 22B». واربط الأرقام دائمًا بنسخة الأوزان المحددة؛ فاسم العائلة وحده لا يكفي لاختيار ملفات الأوزان والدقة العددية وإعدادات تقديم النموذج.

Mixtral 8x7B: لماذا لا يعطي ضرب أرقام الاسم الحجم الصحيح؟

يضم Mixtral 8x7B مكوّنات مشتركة، ولذلك لا ينبغي التعامل مع اسمه كعملية ضرب. تذكر مدونة الإطلاق من Mistral أن النموذج يضم 46.7B إجمالًا، ويستخدم 12.9B لكل توكن. وضرب الأرقام الواردة في الاسم يعامل المكوّنات المشتركة كما لو كانت أجزاءً من نماذج كاملة ومنفصلة.

تصف ورقة Mistral البحثية شبكات تغذية أمامية للخبراء إلى جانب آلية انتباه مشتركة. وفي كل طبقة، يختار الموجّه 2 من أصل 8 خبراء. وهؤلاء ليسوا ثمانية نماذج كاملة ومستقلة.

باستخدام عددي المعلمات المنشورين نحصل على 12.9 ÷ 46.7 × 100 = 27.6%، بعد التقريب. أما اختيار 2 من أصل 8 خبراء فيعني 25% من الخبراء، وهو حساب بمقام مختلف. والمكوّنات المشتركة أحد أسباب اختلاف نسبة الخبراء عن نسبة المعلمات.

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

لماذا لا تعني الحسابات الأقل زمن استجابة أقصر بالضرورة؟

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

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

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

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

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

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

المفاضلات التي تنعكس على تشغيل الخدمة

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

الذاكرة: كل خبير يحتاج إلى مكان

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

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

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

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

الإنتاجية: تحميل النموذج ليس سوى الخطوة الأولى

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

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

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

اختلالات التوجيه: الخبراء الأكثر استخدامًا قد يصبحون عنق زجاجة

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

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

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

كيف تختار نموذجًا لغويًا ببنية مزيج الخبراء: API أم استضافة ذاتية؟

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

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

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

وبالنسبة إلى المشترين المسؤولين عن الالتزام بمستوى خدمة، فالسؤال هو: هل ينجز النموذج المرشّح العمل المقبول ضمن زمن الاستجابة المستهدف على البنية التحتية المخططة؟ عبارة «تريليونات إجمالًا، ومليارات نشطة» تصف البنية، ولا تضمن مستوى خدمة.

1. 1

   حدّد حمل العمل قبل مقارنة النماذج

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

2. 2

   اختبر مسار التشغيل الذي ستستخدمه

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

3. 3

   اختبر السعة والجودة معًا

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

4. 4

   انتقل إلى النموذج حين تثبت فائدته في حمل عملك

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

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

أين تقع المبالغة في الحديث عن MoE؟

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

ليس مضمونًا أن يكون الخبراء متخصصين في مجالات معرفية. وجد تحليل Mistral لنموذج Mixtral أنماط توجيه لا تفصل التخصصات الأكاديمية بوضوح. فالخبير المتعلّم ليس متخصصًا ذا مؤهلات، واختيار الموجّه لا يفسّر سبب صحة الإجابة.

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

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

الورقة البحثية التي أسّست لآلية مزيج الخبراء المتناثر

صاغت ورقة Shazeer وزملائه عام 2017 طبقة MoE مؤثرة ذات بوابات متناثرة، زادت سعة النموذج من دون زيادة متناسبة في الحسابات. وتُعدّ ورقة «شبكات عصبية بالغة الضخامة: طبقة مزيج الخبراء ذات البوابات المتناثرة» المرجع الأساسي لهذه الآلية. كما يذكّر نقاشها لموازنة الأحمال والأداء الموزّع بأن المفاضلات التشغيلية كانت جزءًا من الفكرة منذ البداية.

أسئلة المطوّرين عن MoE

ما المقصود بمزيج الخبراء في النماذج اللغوية الكبيرة؟

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

هل يستخدم GPT-4 بنية مزيج الخبراء؟

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

ما الذي ينبغي مراعاته عند الضبط الدقيق لمزيج الخبراء؟

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

ما الخطوة التالية في قرار النشر؟

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

لشروح عملية عن البنية التحتية التي تقوم عليها منتجات الذكاء الاصطناعي، اشترك في النشرة البريدية.