Qwen 3.5 على MacBook Pro: مقارنة ثمانية خوادم محلية للعمل الجماعي

لم يعد تشغيل النماذج الكبيرة محليًا على أجهزة Mac لعبة للمتحمسين منذ زمن طويل، لكن قصة Qwen 3.5 35B تظهر أن هناك مسافة كبيرة بين "يعمل" و"يصلح كواجهة برمجية لفريق". أخذ المؤلف جهاز MacBook Pro M2 Max بذاكرة 64 غيغابايت واختبر ليس النموذج بحد ذاته، بل البنية التحتية حوله: أي خادم MLX يستطيع التعامل مع حمل عمل حقيقي، لا ينتج أرقامًا لطيفة في السجلات فقط وليس ينهار عندما يصل مستخدمان في نفس الوقت.

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

تم التركيز بشكل خاص على تقييم ليس سرعة الذروة في المختبر، بل سلوك النظام في ظروف قريبة من العمل الحقيقي: مع الردود المتدفقة والحمل الإضافي للشبكة وشروط القياس المتكررة.

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

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

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

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

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

يظهر هذا المقياس شيئًا بسيطًا: يجب تقييم الكومة المحلية لـ Qwen 3.5 كبنية تحتية، وليس كعرض توضيحي. خلاف ذلك، قد ينتهي بك الحال مع نظام يبدو "سريع" في الاختبارات المفردة لكن في الاستخدام الفعلي يحول جهاز MacBook القوي إلى طابور مكلف من الطلبات.