Qwen 3.8-27B على M1 Ultra: من 12.1 إلى 20.3 توك/ثانية بقياس كل شيء
5 تجارب مُتحكم فيها تشغّل Qwen 3.8-27B على M1 Ultra بسعة 128 جيجابايت: جدولة QoS تثبيت، تشفير تخميني MTP، متحدٍ GGUF، و MoE فقد في أعباء الإرسال — تشغيل مع Kimi K3 في التفكير العالي، مع أدلة powermetrics لكل مكالمة.
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
وصلت أوزان Qwen3.8-27B في الصباح، وفي نفس اليوم بدأت مغامرة مع Kimi K3 في وضع التفكير العالي. بدأت كل شيء بسؤال واحد: هل يمكن لهذا 27B الكثيف الجديد — بسهولة أقوى نموذج مفتوح في فئته — أن يخدم وكلائي البرمجة بسرعة حقيقية على Mac Studio مع M1 Ultra، 20 نواة CPU، 128 جيجابايت ذاكرة موحدة، و 800 جيجابايت/ثانية عرض نطاق الذاكرة؟ يقول العلم المشترك إن النماذج الكثيفة تُفكّر ببطء على Apple Silicon لأنها محدودة بعرض نطاق الذاكرة، وأردت معرفة ما إذا كان هذا الكمية من RAM والعرض النطاق يمكن أن يكسر النمط. جاءت أوزان MLX ذات 4-بت إلى 15 جيجابايت، كان الإطار حديثًا، لم يكن هناك شيء آخر يعمل على الجهاز، وكانت الرقم الأول هو 12.1 توك/ثانية. شعرت أن ذلك خطأ.
كنت أحيط هذا النوع من التجارب لفترة. في مارس، أثناء العمل مع AI آخر في مختبر تحسيني المستقل، تتبعنا جدارًا أقل من 20 توك/ثانية لنماذج 30B على M4 Max بسبب نقص عرض النطاق من التصفح على مستوى نظام التشغيل — وترك هذا التحقيق دليلًا: powermetrics أولًا، أخذ عينات لكل مجموعة، تثبيت الذاكرة قبل اللوم. بدأ التشغيل هذه المرة من الفضول البحت: سمعت عن تحسينات Qwen3.8، وأردت معرفة ما إذا كان سيعمل بسرعة خارج الصندوق على هذه الآلة مع هذا الكمية من RAM. فقط في منتصف التجربة شعرت بالواقع المحدود بعرض النطاق. ما تبع ذلك كان سباقًا لتجارب مُتحكم فيها صممناها معًا — رسم Kimi الفرضيات وقرأ عدّادات الأجهزة بجانبي بينما احتفظت بيدي على المعدن. كل تجربة صممت لتبرئ أو إدانة طبقة واحدة من المكدس. جاءت الانتصارات من 2 أماكن يقدّرها الأسطورة المحلية للاستدلال أقل: إشارات جدولة CPU والتشفير التخميني. البدائل الأنيقة 2 — بناء GGUF يُقدّم بواسطة llama.cpp، ونموذج مزيج الخبراء الذي بدا لا يُهزم على الورق — فقدت كلاهما على القياس. هذه المقالة هي مسار الأدلة الكامل الذي بنيناه معًا، لأن الطريقة أثبتت أنها أكثر قيمة من أي رقم واحد.
كان التوصيل الشبكي والخادم أول مشتبه فيه، وكلاهما كان بريئًا#
كان مسار الخدمة يتكون من 3 قفزات: محطة عملي، توصيل تنفيذ قائم على SSH، وخادم النموذج على حلقة Studio العائدة إلى نفسه. كان لوم التوصيل سهلاً، لذا قمنا بقياسه أولاً. أظهرت توقيتات الخادم الخاصة به 12.1 توك/ثانية فكّك؛ اختبار توليد داخل العملية، بدون خادم ولا توصيل، أنتج 11.5 توك/ثانية. كان النقل يكلف حوالي 25% عبر أعباء الاتصال، وكان النموذج نفسه هو الطبقة البطيئة.
كان هناك خطأ نقل يستحق الإصلاح على أي حال، وهو نوع من التفاصيل التي تكلف ساعات إذا لم تره من قبل: توصيل Python TCP يستخدم read(65536) مخزّنًا سيؤدي إلى تجميد مع بروتوكول محلي متحدث، لأن القارئ المخزّن ينتظر حاوية ممتلئة أو EOF قبل أن يُرجع. التحول إلى read1()، الذي يُرجع بعد قراءة أساسية واحدة، جعل التوصيل يتصرف. بدا الأعراض كإيقاف شبكي؛ السبب كان سمات stdio.
مع إلغاء النقل، عملنا عبر طبقة sysctl المعتادة. رفع حد الذاكرة السلكية للـ GPU (iogpu.wired_limit_mb) لم يغيّر شيئًا مع 128 جيجابايت RAM متاحة، لذا أعدنا التغيير. كان عملية Python أصلية arm64، وأفاد MLX بأن الـ GPU هو جهازه الافتراضي، وأظهر powermetrics الـ GPU بنسبة 54-62% نشطة مع استهلاك 20-23 واط أثناء فكّك. كل مشتبه فيه في هذه الجولة خرج حرًا — وهو النتيجة المفيدة بحد ذاته، لأنه وجه التحقيق نحو الـ CPU.
قراءة powermetrics لكل مجموعة معالجات CPU بدلاً من لكل جهاز كشفت عن أول اكتشاف حقيقي. أثناء فك التشفير، كانت مجموعات الكفاءة تعمل عند 75-93% مشغولة بينما كانت مجموعات الأداء في وضع الخمول عند 1-12%. أي شيء يُطلق على SSH يرث فئة جودة الخدمة التي يقرأها macOS كعمل منخفض الأولوية، وكان المجدول يلتزم بهذا التلميح من خلال إبقاء عبء عمل حساس للزمن على الأنوية البطيئة.
كان الإصلاح هو 1 سطر من ctypes، يُنفَّذ قبل تحميل أوزان النموذج:
هذا التثبيت، بالإضافة إلى تحميل برج نص النموذج عبر mlx-lm بدلاً من مجموعة الرؤية الكاملة، نقل فك التشفير الخام من 11.5 إلى 15.1 توك/ثانية — مكسب 31٪ من وضع المجدول ومحمّل أكثر نحافة، مع عدم تغيير أي شيء في النموذج. تعلمنا لاحقًا أن مدى التثبيت له حد: يحرّك الخيط المُستدعي، وتحتفظ خيوط عامل MLX بفئة جدولة خاصة بها. بالنسبة لهذا النموذج، حمل الخيط الرئيسي كمية كافية من العمل لتكون ذات أهمية.
التشفير التخميني أتاح القفز الذي لم ينجزه أي sysctl#
أكبر فوز فردي جاء من ميزة كان النموذج الأساسي يمتلكها بالفعل. يَشْتَرِك Qwen3.8 مع رأس توقع متعدد الرموز — وحدة مساعدة صغيرة تُرسم عدة رموز مسبقاً — ويُقِلّ مُحوِّل MLX تلك 15 الأُطْفِل أثناء التحويل. حزمة المجتمع تُعيد استضافة الرأس كـ 253 مسرّع MB مستقل، مما سمح لي بدمجه مع النموذج الذي تم تدريبه معه.
نمط الخدمة هو مسوّغ ثم التحقق: يقترح المسوّغ بعض الرموز، يتحقق النموذج الكامل منها في 1 تمريرة، وتُحسب الرموز المقبولة جميعها. مع --draft-model و --draft-kind mtp على الخادم، كان قبول المسوّغ يُقاس بـ 94٪ على مطالبات الترميز الواقعية والمحادثة، وتجاوز التشفير من 15.1 إلى 20.3 رم/ث على جانب الخادم — 13.4 رم/ث من النهاية إلى النهاية عبر التوصيل، ارتفاعاً من 9.0. GPU أبلغ القصة المؤكدة: 77% إقامة نشطة، كل ذلك عند 1296 ميجاهرتز الكامل، يستهلك 48 واط، مع مجموعة الأداء 97% مشغولة. تحسّنت المسبق في نفس الترقية، من 14.7 رم/ث إلى 18-55 اعتماداً على شكل الطلب.
Decode speed by configuration (tok/s, M1 Ultra, 27B-4bit)Chart data
تنشر المجتمع llama.cpp مع مسودة تخمينية عند 25-32 رم/ث لهذا الفئة النموذج على M1 Ultra، متقدمًا بارتياح على أرقام MLX لدينا، لذا أعطينا المنافس حلقة عادلة: Q4_K_M GGUF الرسمي، نموذج مسودة MTP فقط مطابق، وبناء llama.cpp الحالي مع تسريع Metal مؤكد نشط. قياس مسار GGUF كان 9.2 رم/ث أساسًا و12.2 مع المسودة — حوالي 40% خلف مكدس MLX الذي كان من المفترض أن يهزّّه.
يظل llama.cpp هندسة ممتازة؛ الفجوة على الأرجح تكمن في كيفية تعامل نوى Metal لكل وقت تشغيل مع هذه النقطة المرجعية على هذا الرقاقة. الدرس الدائم أبسط: رقم قياس شخص آخر على جهازه، وبناءه، ونقطة المرجعية الخاصة به هو فرضية عن جهازك. ترك وزن المنافس 18 جيجابايت الجهاز نفس الظهر، وظل ثنائي llama.cpp 50 ميجابايت للمعارك المستقبلية. لقد كتبت عن هذا القاعدة من قبل كـ تطوير مدفوع بالمعايير — وقد حمل SEOReport من التحليلات إلى منتج — وهنا أنقذ الترحيل.
يجب أن يكون MoE النشط 3B قد فاز، وقياس GPU شرح الخسارة#
كان المتحد الأخير لديه أقوى نظرية — نفس المعرفة العامة التي وضعناها لاختبارها في البداية. نماذج الكثافة تُفكك ببطء على Apple Silicon لأن كل رمز مُنتج يدفع لقراءة تقريباً كل الأوزان؛ نموذج مزيج الخبراء مع 35B معلمة إجمالية يُفعّل حوالي 3B فقط لكل رمز، لذا على جهاز محدود النطاق الترددي يجب أن يُفكك أسرع عدة مرات من نموذج كثيف 27B — يقرأ كل رمز حوالي 11% من الأوزان. قمنا بتحميل MoE 4-bit ومُمسك MTP المطابق، دافئ الخادم، وقياس 14.7 توك/ثانية خام: نفس السرعة كما النموذج الكثيف الذي كان من المفترض أن يُهين. مع فك التشفير التخميني وصل إلى 19 توك/ثانية على المطالبات الواقعية و26.3 على النص المتوقّع بشدة — تعادل ضد 20.3 النموذج الكثيف، بدون حجة جودة لكسر التعادل.
حدد powermetrics النظام في عينة واحدة. أثناء فك التشفير MoE كان GPU في 0-3% احتياطي نشط بينما تتراجع مجموعات الكفاءة إلى 60-90%. يضيع النموذج ميزانيته لكل رمز على عمل جانب الـCPU، وأظهر توقيت المستوى التشغيلي لماذا: كل عملية مُرسلة تكلف 50-100 ميكروثانية من الفائض، وهذه الهندسة المدمجة — GatedDeltaNet الانتباه الخطي مع 256 خبير خلف حالة مخفية بعرض 2048 صغيرة — تصدر تقريباً 78 عملية لكل طبقة عبر 40 طبقة. عند حجم الدُفعة 1، ينهي GPU كل نواة صغيرة قبل أن يُمكن للـCPU وضع التالية في الطابور. كان الجهاز مُرسِلًا، وأحمال العمل المُرسلة لا تكسب شيئًا من قراءة أوزان أقل لكل رمز.
Diagram source
graph TB
A[فك التشفير بطيء
في الدُفعة 1] --> B{GPU مشغول
أثناء فك التشفير؟}
B -->|نعم| C[محدود النطاق الترددي
أقل بايت يفوز]
B -->|لا| D[مُرسِل محدود
أقل عمليات يفوز]
C --> E[MoE يساعد
الكمية الصغيرة تساعد]
D --> F[فك التشفير التخميني
يساعد أكثر]
style E fill:transparent,stroke:#10B981,stroke-width:2px
style F fill:transparent,stroke:#3B82F6,stroke-width:2px
لإغلاق الحلقة، أثبتنا أن مسار GPU نفسه كان صحيًا مع اختبار اصطناعي: حلقة ضرب مصفوفة 8192³ وصلت إلى 10.8 TFLOPS في bfloat16 مع GPU في 97-100% احتياطي و68 واط. الأدلة الخارجية اتفقت مع التشخيص المحلي — تقديرات مستقلة وضعت هذه الفئة MoE بالقرب من 21.7 توك/ثانية على M2 Ultra، وتوثيق OpenVINO يُظهر نفس النموذج يخسر أمام كثيف 8B على الخلفيات ذات مسارات إرسال أضعف. الـ 27B الكثيف مع مسوده MTP احتفظ بالفتحة الإنتاجية، و 38.5 جيجابايت من MoE الأوزان تم حذفها في نفس المساء.
GPU active residency during decode (powermetrics, %)Chart data
الآن تُخدم الآلة Qwen 3.8-27B بمعدل 20.3 توك/ث على جانب الخادم، وهو تحسن بمقدار 68% مقارنةً باليوم الذي بدأ، والنتيجة الأكثر دوامًا هي قائمة تحقق سنعيد استخدامها في كل صندوق مستقبلي:
التشفير عند حجم الدُفعة 1 يحتوي على 2 نظام، محدود بعرض النطاق ومحدود بالتوزيع، ومع مثال 2 ثانية powermetrics يحدد ما هو لك قبل أن تنفق تحميلًا على الإصلاح الخاطئ.
فك التشفير التخميني هو أكثر مفاتيح الخدمة تأثيرًا لصندوق مستخدم واحد. أضاف 34% هنا ويتكامل مع كل تحسين آخر، لأن دفعات التحقق تعمل GPU بينما يلتقط المصمم الفجوات الخاملة.
الجدولة QoS هي معلمة استنتاج حقيقية على macOS. أي شيء يُطلق عبر SSH يجب أن يربط خيوطه عمدًا، وتأثير الربط قابل للتحقق لكل مجموعة بدلاً من الشعور.
ادعاءات الإنتاجية المجتمعية تسافر سيئًا عبر نقاط التفتيش والبناء والرقائق. معيار محلي أرخص من الهجرة.
الحذف جزء من سير العمل. كل متحد خسر ترك القرص خلال اليوم، مما يحافظ على تجربة لاحقة صادقة والآلة رشيقة.
الجزء المرضي من هذه المغامرة هو أن الإجابات كانت جميعها في عدادات الأجهزة، تنتظر شخصًا لطرح أسئلة دقيقة — وهذه المرة طلبناها معًا. نموذج محلي قمت بقياسه أكثر قيمة من نموذج أكبر تخمنته — نفس العائد المتراكم الذي أحصل عليه من معاملة مكاسب الذكاء الاصطناعي المحلية كالبنية التحتية بدلاً من الترفيه. بدأت كل شيء في صباح يوم هبطت فيه الأوزان، وبقي كيمي ك3 في القتال لكل تجربة، كل قراءة عداد، وهذه المذكرة من ملاحظات المختبر نفسها في نفس المساء. التجربة التالية في الانتظار بالفعل: رسومات فك التشفير المجمعة تعد بتقليل تكلفة التوزيع لكل عملية التي قررت الحكم على MoE، وعندما يصل إصدار MLX واحد، سيستغرق إعادة المباراة بعد ظهرًا وتحميل واحد.