Laya على Apple Silicon: ما الذي يوفره لك نقل MLX، وما الذي لا يوفره

Laya هو نموذج قرار لا يكتب جملة أبدًا. نشرت Convai Innovations أوزانه على Hugging Face في 2026-09-18، وفي اليوم التالي نشر مطوّر يُدعى mizorewww Laya-MLX — نقل مستقل يشغّل جميع نقاط التفتيش الثلاث لـ Laya أصليًا على Apple Silicon عبر MLX، دون PyTorch، ودون وقت تشغيل Transformers، ودون استدعاء سحابي. يُبلِغ ذلك النقل عن وسيط قدره 13.42 ms لسؤال إنجليزي قصير واحد على نقطة التفتيش 421M، و7.39 ms على نقطة التفتيش متعددة اللغات 322M، وصفر رموز إخراج، على M3 Max. وفي الوقت نفسه Kev، العائلة المفتوحة الأخرى التي تسعى إلى فكرة القرارات المُنمّطة نفسها، مبنيّ على Qwen3.5-4B-Base واحتاج إلى واجهة خلفية ثانية كاملة قبل أن يصبح قابلاً للاستخدام على Mac، لأن PyTorch لا يملك كيرنلات لطبقات DeltaNet الخاصة به على وحدة معالجة الرسومات لدى Apple. مشروعان، في الأسبوع نفسه، والهدف نفسه، وواحد فقط منهما جرى نقله بسلاسة. هذا الفرق هو القصة، وهي قصة وقت تشغيل لا قصة نموذج.

السبب الذي يجعل هذا الأمر يستحق مقالًا اليوم ليس أن Laya جديد. بل إنه حتى 2026-09-19 لم تكن هناك طريقة لتشغيل نموذج قرار مُحدَّد الأنواع على Mac دون جرّ منظومة PyTorch معه، والسؤال الذي يراود القارئ فعلًا — هل يمكنني تشغيل هذا على حاسوبي المحمول، وما الذي أتنازل عنه — صار له أخيرًا جواب قابل للقياس. لذا تتناول هذه القطعة مسار الخدمة، والأرقام وراءه، والمواضع التي تكف فيها الأرقام عن أن تعني ما تبدو عليه.

أولًا، ما لا تكونه Laya

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

هذا مهم لكيفية قراءتك لكل رقم في هذا المقال. عندما يُبلّغ المنفذ عن 13.42 ms، فهو لا يُبلّغ عن 13.42 ms لإنتاج بضع مئات من الرموز كما تفعل مقاييس التوليد. إنه يُبلّغ عن العملية بأكملها. مقارنة زمن استجابة نموذج قرار بمعدل الرموز في الثانية لدى نموذج لغوي كبير هي مقارنة بين مهمتين مختلفتين، وأي مقال يفعل ذلك — بما في ذلك المنشور المنتشر «أسرع 50x من Jev» الذي تداوله الناس بعد الإطلاق — يقدّم ادعاءً لا يدعمه العمل الأساسي.

ما قاسه المنفذ فعليًا

هذه الأرقام خاصة بمؤلف المنفذ، مأخوذة على جهاز مذكور، ويجب قراءتها مع الجهاز والطريقة المرفقين. قاستها Laya-MLX على جهاز M3 Max يضم 40 نواة GPU و128 جيبي بايت من الذاكرة الموحدة، عند FP16، مع استبعاد تحميل النموذج.

• سؤال قصير واحد، P50 — 13.42 ms على نقطة التحقق الإنجليزية 421M، و7.39 ms على نقطة التحقق متعددة اللغات 322M.

• سؤال قصير واحد، P95 — 13.92 مللي ثانية و7.79 مللي ثانية على التوالي.

• معدل نقل 50 سؤالًا — 146.8 سؤالًا في الثانية و395.0 سؤالًا في الثانية.

• ذروة تخصيص MLX — 943.6 MiB و687.6 MiB.

حدود القياس الزمني هي الجزء الذي يستحق القراءة مرتين. فهي تشمل إعداد الطلب (prompt)، والترميز (tokenization)، وبناء التنسورات، والاستدلال المتزامن، والمعايرة، وتنسيق النتائج. ولا تشمل تحميل النموذج. استخدم تشغيل معدل الإنتاجية المكوّن من 50 سؤالًا batch_size=64، بينما القيمة الافتراضية لواجهة API هي 16، لذا يصف هذان الرقمان حمل عمل مُجمَّعًا عمدًا، لا تكلفة نداء تفاعلي واحد. اختلاف أطوال المدخلات، واختلاف أعداد الأسئلة، واختلاف ظروف التشغيل، كلها تغيّر النتيجة. وهذه التحفظات هي الفرق بين رقم وقياس معياري، والـport يذكرها بنفسه.

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

فحص الدقة هو النتيجة الأكثر إثارة للاهتمام

إن نسخة منقولة سريعة تجيب بشكل مختلف عن النموذج الذي تنقله لا قيمة لها، وهنا قام المشروع بالعمل المهم. طابقت نقاط التحقق الثلاث كلها الإجابة المختارة من المنبع في 63 من أصل 63 سؤالًا من أسئلة التحقق في كل من FP32 وFP16 — 378 من أصل 378 مقارنة. كما شغّلت كل تهيئة 100 نداء متكرر وحتمي دون نمو مقيس في الذاكرة النشطة، واجتازت جميع ملفات الأوزان المنشورة الـ36 التحقق الصارم عن بُعد من قيم checksum.

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

مستقل، يُصان من المجتمع، ولا يزال ليس على القائمة

تقول النسخة المنقولة هذا عن نفسها، مرتين: إنها نسخة منقولة مستقلة لـ MLX، وليست إصدارًا رسميًا من Convai Innovations. يبقى تدريب RLCD والضبط الدقيق في المنبع. تُنسب الأوزان إلى Convai Innovations. Apache-2.0 على الجانبين.

طريقة تعامل المشروع الأصلي معه أكثر دلالة من أي إخلاء مسؤولية. يحتوي ملف README الخاص بـ Laya على قائمة أدوات المجتمع، واعتبارًا من 2026-09-23 تضم أربعة مدخلات: omp-laya-judge، laya-adk-toolkit، laya-Ascend لوحدات Huawei Ascend NPU، وlaya-apple — بيئة تشغيل لـ Apple Silicon تستخدم وحدة معالجة الرسومات MLX ومحرك Neural Engine. وصل هذا المدخل الرابع عبر طلب السحب #260، الذي دُمج في 2026-09-23. المنفذ الذي تتناوله هذه المقالة ليس ضمن الأربعة. توجّه قائمة المشروع الأصلي الآن قراء Apple Silicon إلى مشروع مجتمعي مختلف عن الذي صدر أولًا ويملك مقاييس الأداء.

متتبع المشكلات الخاص بـ Upstream نفسه يقول الباقي. المشكلة #50، "منافذ Apple silicon"، المفتوحة في 2026-09-21، لا تزال مفتوحة؛ أجاب المشرف في اليوم نفسه بأن دعم Apple Silicon قيد التتبع، وبأن منافذ مجتمعية مثل Laya-MLX تستكشف استدلال Metal الأصلي، ثم أجاب مجددًا في 2026-09-23 بسطر يستحق الاقتباس حرفيًا: "يبقى منفذ MLX مُدارًا من المجتمع." الإصلاح من جهة PyTorch — MPS autocast وتصحيح transformers 4.x RoPE — وصل كطلب سحب #273، وتم دمجه في 2026-09-23، مع مراجع في ذلك الخيط أشار إلى أنه لا يزال يحتاج إلى دمجه مع إعادة هيكلة autocast المنفصلة في #109، التي لا تزال مفتوحة. والمشكلة #52، المفتوحة في 2026-09-21، تُفيد بوجود sidecar من Laya-MLX نما إلى نحو 21.7 GB من ذاكرة Metal على مدى عدة ساعات من التشغيل، مع vmmap الذي يعزو نحو 21.4 GB إلى النظام الفرعي للرسومات بدلًا من كومة Python؛ ويقترح تقييد ذاكرة التخزين المؤقت للمُخصِّص ومسحها بعد كل استدلال، ولا يزال مفتوحًا.

وبجمع ذلك معًا، تكون الإجابة العملية هي: بيئة التشغيل هذه ليست مُبارَكَة من المنبع upstream، بل تُصان مجتمعيًا بحسب وصف المشرف نفسه، والمسألة الوحيدة المتعلقة بالذاكرة التي تهم في sidecar طويل التشغيل يجري العمل عليها علنًا بدلًا من إصلاحها في إصدار.

هل يمكنني تشغيله على حاسوبي المحمول، وما الذي سأتخلى عنه؟

التثبيت يتم بأمر pip واحد، والنسخة المنقولة تنشر أوزان FP16 محوّلة مسبقًا، لذا لا تحتاج إلى تحويل أي شيء بنفسك:

pip install laya-mlx

ثم import laya_mlx as laya، agent = laya.load("aac6fef/laya-mlx")، واستدعِ agent.predict(state, questions). المتطلبات هي Apple Silicon وPython 3.11+ وmacOS 14+. كانت البيئة المقاسة macOS 27.2 وPython 3.12.13 وMLX 0.32.2 — وتشير ملاحظات الترحيل إلى أن إصدار MLX الذي استخدمته جاء بحزم macOS 14 و15 و26 بينما اختار المُثبِّت حزمة 26، وأن إصدارات macOS المدعومة الأقدم لم تُختبر على ذلك الجهاز.

ما الذي تتخلى عنه، بُعدًا ببُعد:

• FP16 مقابل FP32 — FP16 هو الافتراضي ومصدر كل رقم رئيسي أعلاه. يوفّر FP32 اتفاقًا عدديًا أقرب مع المنبع، وقد تختلف الاحتمالات قليلًا بين الدقات حتى عندما تتوافق التسمية المختارة. يمكن طلب BF16 لكنه ليس جزءًا من مصفوفة التحقق المنشورة، لذا تعامل معه على أنه غير مُختبَر.

• الحد الأدنى للذاكرة مقابل الهامش المتاح — أقل من 1 GiB من ذروة تخصيص MLX لسؤال قصير يُعدّ مريحًا على أي Mac من سلسلة M. وهو ليس تصريحًا عن حمل خادم مستمر، والمشكلة #52 هي سبب توخي الحذر إذا كنت تخطط لتشغيل هذا كـ sidecar طويل الأمد بدلًا من استدعاء مكتبة.

• متعدد اللغات مقابل الإنجليزية — نقطة التفتيش متعددة اللغات 322M هي الأسرع بين الاثنين، وهي التي تغطي أكثر من 100 لغة، لكن المنفذ ينقل عمداً تحذير المنبع إلى الأمام: نقاط التفتيش الإنجليزية ليست بدائل لنقطة التفتيش متعددة اللغات. التوجيه بينهما هو النمط المقصود، وليس ترفاً.

• معتمد من المنبع مقابل مصان من المجتمع — إنه الثاني. لا شيء في ملاحظات إصدار المنبع يَعِد بأن تظل هذه النسخة المنقولة تعمل عبر تغييرات المنبع.

• السرعة مقابل المعايرة — النقل السريع لا يُصلح دلو معايرة يُشحن بثقة مفرطة. المنبع يحصر درجات الحرارة المُلائمة في [0.5, 5.0]، والدلو المشحون choice:11+ هو 0.1006، ما من شأنه أن يشحذ اللوجيتات بنحو عشرة أضعاف ويُبلّغ عن رمية عملة على أنها شبه يقين. توجد درجات حرارة المعايرة المُلائمة لسبب؛ لائمها على بياناتك المحجوزة الخاصة بك قبل أن تبني قرارك على احتمال.

ثمة حدّان إضافيان يجدر أخذهما في الحسبان، وكلاهما من متتبِّع upstream نفسه. action.act_probability لا يحمل حاليًا أي إشارة قابلة للاستخدام — فهو يعطي 1.0 تقريبًا لكل مدخل، وقد جاءت logits الخام الخاصة به مقابل الصواب عند AUROC قدره 0.30 عبر 396 قرارًا موسومًا (المسألة #185). اعتمد على confidence بدلًا من ذلك، والذي يبلغ 0.77 على العناصر نفسها. وnoul يمكن للأسئلة أن تتبع تسميات خياراتها بدلًا من الحالة (المسألة #156) — فبطاقة upstream نفسها تُبلغ عن "لا" واثقة عند إدخال موجب بوضوح، وبأقوى ما يكون على نقطة التحقق الإنجليزية. الحل البديل الذي تقترحه ليس اللجوء إلى نموذج مختلف بل إعادة تشكيل السؤال: اطرحه في صيغة اختيار من خيارين بمفاتيح محايدة (A/B) وصياغة نعم/لا لديك كوصفَي الخيارين.

لماذا يُنقل أحد نموذجي القرار بسلاسة بينما لا يُنقل الآخر

التباين هنا معماري، وهو أكثر شيء مفيد في هذا المقال لأي شخص يختار بين العائلتين.

العمود الفقري لـ Laya هو ModernBERT-large، وهو مُشفِّر ثنائي الاتجاه مبني بالكامل من الانتباه. الانتباه هو ما يتفوق فيه مكدس GPU لدى Apple، وهو ما أنفقت MLX جهدها عليه. لذا فإن النقل هو إعادة تنفيذ لطبقات كانت لديها بالفعل مسارات سريعة: المُشفِّر، وطبقات Transformer في رأس القرار، ورأس التقييم ورأس الإجراء تعمل جميعها في MLX، ولا يزال تقسيم الرموز يجري عبر مُرمِّز Rust التابع لـ Hugging Face.

الهياكل الأساسية لـ Kev هي نماذج Qwen3.5 الأساسية، وQwen3.5 يخلط طبقات الانتباه مع طبقات Gated DeltaNet. DeltaNet تكرارية وتتجاهل أقنعة الانتباه. لذلك نتيجتان. أولاً، يجب تشغيل كل سؤال كصف خاص به بدلاً من مشاركة تسلسل مقنّع واحد، وهو ما يعالجه مشروع Kev عبر حساب الحالة مرة واحدة وإعادة استخدام ذاكرتها المؤقتة لكل صف. ثانياً — وهذا هو الجزء المؤلم على Mac — لم تكن هناك نوى PyTorch لتلك الطبقات على وحدة معالجة الرسوميات من Apple، فتراجعت PyTorch إلى التعليمات البرمجية المرجعية. أما بطاقة النموذج jaredpalmer/kev-4b فلا تزال تحمل الحد الناتج بلغة واضحة: إن طلباً من خمسة أسئلة يستغرق 0.17 ثانية على إصدار Qwen3 من Kev-4B يستغرق 0.78 ثانية بصيغة bf16 على M5.

تحقق من الصياغة الحالية قبل الاقتباس من ذلك، لأنها تغيّرت. يقول ملف README الخاص بمستودع Kev الآن إن الخادم يشغّل نماذج Qwen3.5 عبر MLX على Apple Silicon بدلاً من ذلك، وينشر أرقامه الخاصة على M5 لطلب من خمسة أسئلة بثلاثة خيارات لكل سؤال على حالة من نحو 270 رمزًا: Kev-4B عند 721 مللي ثانية على حالة جديدة و136 مللي ثانية على حالة مُعادة عبر ذاكرة التخزين المؤقت للبادئة، مقابل 3,302 مللي ثانية و847 مللي ثانية على مسار PyTorch bf16 MPS. ويسجل Kev-0.8B 149 مللي ثانية و28 مللي ثانية. لا تزال نماذج Qwen3 من الجيل السابق تعمل على PyTorch MPS العادي، ويصفها المشروع بأنها خيار جيد على Mac.

احرص ألا تحوّل ذلك إلى نتيجة سباق. فهذه ليست قياسات وجهاً لوجه. إن 13.42 مللي ثانية الخاصة بـ Laya-MLX هي سؤال قصير واحد على M3 Max؛ أما 721 مللي ثانية الخاصة بـ Kev فهي خمسة أسئلة بثلاثة خيارات لكل منها على حالة بطول نحو 270 رمزًا على M5. أعداد مختلفة من الأسئلة، وأعداد مختلفة من الخيارات، وأطوال مختلفة للحالات، وأجهزة مختلفة، وبيئات تشغيل مختلفة. ما يمكن التحقق منه ويستحق المقارنة هو شكل المشكلة، لا الفائز: فمشفّر انتباه خالص يُنقل إلى Apple Silicon دون صعوبة، بينما احتاج نموذج هجين بانتباه خطي إلى واجهة خلفية ثانية كاملة قبل أن يصبح قابلاً للاستخدام هناك.

ما الغرض الفعلي من نموذج القرار

بعيداً عن المعايير، فإن حالة الاستخدام الصادقة ضيقة، والمشروع يقول ذلك بنفسه: Laya هي قاعدة سريعة للتخصص، وليست محرك قرارات بدون أمثلة. في معيار typed-decisions الخاص بـ Convai، حققت نقطتا التفتيش الأساسيتان 0.362 و0.342 بدون أمثلة، مقابل خط أساس 0.461 لفئة الأغلبية و0.318 للعشوائي. وهما أقل من الخط الذي ستحصل عليه إذا أجبت دائمًا بالتصنيف الأكثر شيوعًا. الرقم الرئيسي 0.766 يعود إلى laya-typed-decisions، نقطة التفتيش المضبوطة ضبطًا دقيقًا على مجموعة تدريب ذلك المعيار نفسه، ولا ينبغي أبدًا الاقتباس منها كقدرة عامة.

تستحق المقارنة المنشورة من Convai مع TypeSafe Jev 1.13.0 القراءة لهذا السبب تحديدًا، وهي مُعلَّمة بعناية من جانبهم: كل رقم لـ Laya هو ما يعيده الموجّه فعليًا، وأرقام Jev هي أرقام منشورة من طرف ثالث لم تقم Convai بقياسها أبدًا لأنها لا تملك وصولًا إلى TypeSafe API. في تلك المقارنة، تحصل Laya الموجّهة على 0.766 مقابل 0.727 لـ Jev في typed-decisions، مع ECE بعد درجة الحرارة 0.081 مقابل 0.246، وزمن استجابة p50 يبلغ 32.8 مللي ثانية مقابل 236–276 مللي ثانية على Tesla T4 — فرق 7.8x في سؤال واحد. هذا هو الرقم الذي يجب الاستشهاد به. رقم «أسرع 50x من Jev» الذي انتشر على وسائل التواصل الاجتماعي لا يظهر في وثائق المشروع أو معاييره القياسية، والمقارنة المنشورة للمشروع نفسه لا تدعمه. ويتقدّم Jev أيضًا حيث يتقدّم: في Banking77، يحصل Jev على 0.870 مقابل 0.425 لـ Laya، لأن خيارات Laya تتشارك ميزانية رموز ثابتة، و77 تسمية تترك لكل منها حوالي ثلاثة إلى أربعة رموز.

إذن، شكل النشر الحقيقي هو رأس قرار رخيص ومحلي وضيق النطاق — يوجّه تذكرة، ويقيّم درجة الإلحاح، ويجيب عن بوابة نعم/لا — مع شيء توليدي خلفه للجزء الذي يحتاج إلى الكتابة. يتخذ نموذج القرار الاستدعاء المحدد النوع في غضون مللي ثانية ثم يصعّد. النصف التوليدي نموذج مختلف على بيئة تشغيل مختلفة، وهنا يكسب الراوتر مكانته:أكثر من 200 نموذج خلف مفتاح واحد بسعر قائمة المزوّد دون أي هامش ربح، لذا يصبح أي تغيير في سعر المورّد ساريًا في اليوم نفسه، وتجاوز الفشل التلقائي عندما يتراجع أداء مزوّد أثناء التشغيل. لا يقدّم OrcaRouter خدمة Laya، ولا يقدّم Kev أو Jev — عائلة Qwen3.5 موجودة في قائمة نماذجنا، أما نماذج القرار نفسها فليست كذلك. ما نغطّيه هو النصف التوليدي من تلك المنظومة، وهو النصف الذي تستدعيه في كل طلب يصعّده رأس القرار.

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

من ينبغي أن يديره، ومن ينبغي أن ينتظر

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

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