تشغيل نموذج لغوي محلي على معالجات Apple Silicon لفرز الأمان

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

لماذا على الجهاز، تحديدًا للفرز

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

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

MLX: إطار العمل الخاص بـ Apple نفسها

MLX هو إطار عمل للمصفوفات بناه فريق أبحاث تعلم الآلة في Apple خصيصًا لمعالجات Apple silicon، بواجهات برمجية بلغات Python وC++ وC وSwift. يصف توثيقه الخاص نموذج الذاكرة الموحَّدة بأنه خيار التصميم المحدِّد له: تعيش المصفوفات في MLX في ذاكرة مشتركة، ويمكن للعمليات عليها أن تعمل على أي جهاز مدعوم — وحدة المعالجة المركزية أو الرسومية — دون الحاجة إلى نسخ أوزان النموذج بين مجمَّعي ذاكرة منفصلين أولًا. وهذا مهم بشكل ملموس بالنسبة لحاسوب محمول: يتعين على جهاز ببطاقة رسومية منفصلة نسخ أوزان النموذج عبر ناقل إلى ذاكرة وحدة المعالجة الرسومية قبل أن يستطيع حساب أي شيء، ما يكلف وقتًا ويضاعف بصمة الذاكرة؛ أما على بنية الذاكرة الموحَّدة لجهاز Mac، فإن وحدتي المعالجة المركزية والرسومية تتشاركان الذاكرة الفعلية نفسها أصلًا، فلا يوجد ما يُنسخ.

تُثبَّت حزمة mlx-lm، الحزمة المرافقة لتشغيل النماذج اللغوية على MLX، بأمر واحد وتأتي مزوَّدة بنموذج افتراضي جاهز:

$ pip install mlx-lm
# runs the default model (mlx-community/Llama-3.2-3B-Instruct-4bit)
$ mlx_lm.generate --prompt "How tall is Mt Everest?"
# or name a specific quantized model from the mlx-community hub
$ mlx_lm.generate --model mlx-community/Mistral-7B-Instruct-v0.3-4bit --prompt "..."
# interactive chat session instead of a single prompt
$ mlx_lm.chat
# convert and quantize a model yourself
$ mlx_lm.convert --model mistralai/Mistral-7B-Instruct-v0.3 -q

llama.cpp: الخيار المحمول

llama.cpp هو الأقدم والأوسع نقلًا بين الاثنين، مكتوب بلغة C/C++ دون الحاجة إلى بيئة تشغيل Python وقت الاستدلال. يوضح ملف README الخاص به موقف المشروع من هذا العتاد مباشرة: تُعامَل معالجات Apple silicon، على حد تعبير المشروع، بوصفها «مواطنًا من الدرجة الأولى — مُحسَّنة عبر أطر ARM NEON وAccelerate وMetal»، ويؤكد توثيق البناء الخاص به أنه على macOS، تكون خلفية Metal الرسومية مفعّلة افتراضيًا، مع خيار وقت بناء لتعطيلها إن أردت تحديدًا استدلالًا يعتمد على وحدة المعالجة المركزية فقط.

$ git clone https://github.com/ggml-org/llama.cpp
$ cd llama.cpp
$ cmake -B build
$ cmake --build build --config Release
# Metal is on by default on macOS; add -DGGML_METAL=OFF to the first
# command above if you need to force CPU-only inference
$ llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF
# or run it as a local server instead of a one-shot command
$ llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

يعمل llama.cpp انطلاقًا من ملفات GGUF، وهو تنسيق نموذج بملف واحد يجمع الأوزان المُكمَّمة وكل ما يلزم لتشغيلها؛ يسحب الأمر أعلاه واحدًا مباشرة من مستودع Hugging Face بالاسم. أما MLX، في المقابل، فيبقى أقرب إلى سير عمل Python أصلي، محوِّلًا ومُكمِّمًا النماذج إلى تنسيقه الخاص مسبقًا. لا أفضلية قاطعة لأي منهما: llama.cpp هو الخيار الذي تلجأ إليه إن أردت ملفًا تنفيذيًا واحدًا مُصرَّفًا دون اعتمادية على Python، وMLX هو الخيار الذي تلجأ إليه إن كنت تبني بقية خط الأنابيب لديك أصلًا بلغة Python وتريد وصولًا من الدرجة الأولى إلى نموذج الذاكرة الموحَّدة الخاص بـ Apple من هناك.

المُكمَّمة: ما الذي تتنازل عنه فعليًا مقابل نموذج أصغر

تُخزِّن المُكمَّمة (quantization) كل وزن في النموذج ببتّات أقل من الـ16 أو 32 التي دُرِّب عليها النموذج، ما يقلّص كلًا من حجم الملف على القرص والذاكرة اللازمة لتشغيله، بتكلفة معينة في جودة المخرجات. يسرد توثيق أداة quantize في llama.cpp نفسه أرقامًا دقيقة لعدد البتّات لكل وزن لكل مخطط يدعمه، وهي طريقة أدق للتفكير في هذه المقايضة من الاختصار المعتاد «4-بت» أو «8-بت»:

ضرب عدد معاملات النموذج في رقم البتّات لكل وزن يعطي تقديرًا تقريبيًا للذاكرة اللازمة للأوزان وحدها: نموذج بسبعة مليارات معامل عند 4.89 بتًا لكل وزن في Q4_K_M يحتاج تقريبًا 7,000,000,000 × 4.89 ÷ 8 بايت، أو نحو 4.3 جيجابايت، قبل احتساب نافذة السياق والتفعيلات الوسيطة، التي تضيف المزيد فوق ذلك بحسب كمية النص الذي تُدخله. هذا حساب مبني على رقم البتّات لكل وزن المذكور، لا رقم ينشره أي من المشروعين مباشرة، وسيكون استخدام الذاكرة الفعلي أعلى بمجرد تحميل طلب حقيقي وسياقه. التوجيه العملي المستخلَص من الجدول بسيط: بالنسبة لمهمة مثل تصنيف سطر سجل اتصال واحد في كل مرة، حيث يكون المُدخل قصيرًا والمخرج المطلوب حكمًا منظَّمًا صغيرًا، يكون نموذج من فئة Q4_K_M غالبًا هو المقايضة الصحيحة — أصغر وأسرع بشكل ملحوظ من Q8_0 أو F16، دون الانحدار إلى فئة الضغط الشديد حيث تتدهور جودة المخرجات بحدة أكبر.

لا ينشر أي من المشروعين متطلب ذاكرة لكل إعداد Mac، لذا فإن النهج العملي هو العمل عكسيًا انطلاقًا من التقدير أعلاه وترك هامش حقيقي: فـ macOS نفسه، ومتصفحك، وأي شيء آخر يعمل يحتاج جميعها أيضًا إلى الذاكرة الموحَّدة، ونموذج بالكاد يتّسع دون فتح أي شيء آخر سيتوقف أو يتباطأ بمجرد انتقالك إلى تطبيق آخر. على جهاز Mac بكمية متواضعة من الذاكرة الموحَّدة، يدعم ذلك البقاء نحو الطرف الأصغر من الجدول أعلاه — بضعة مليارات من المعاملات عند Q4_K_M بدلًا من نموذج أكبر بكثير بالمُكمَّمة نفسها — وحجز الخيارات الأكبر والأعلى دقة للأجهزة ذات الذاكرة الوفيرة. بالنسبة لمهمة تصنيف ضيقة النطاق مثل التي يتناولها هذا المقال، يميل نموذج أصغر يُطرح عليه سؤال دقيق إلى أن يكون أسرع، وفي الممارسة أكثر اتساقًا، من نموذج أكبر يُطرح عليه سؤال غامض.

كلا المشروعين قيد التطوير النشط، والمقارنة الصادقة أقرب إلى «أيهما يناسب خط أنابيبك» منها إلى «أيهما أفضل». يُصرَّف llama.cpp إلى ملف تنفيذي واحد دون الحاجة إلى بيئة تشغيل Python وقت الاستدلال، وهذا مهم إن أردت تضمينه داخل قطعة برمجية أخرى دون شحن مفسِّر Python معه. أما MLX فيفترض أنك تعمل أصلًا بلغة Python (أو Swift، التي يشحن روابط لها أيضًا)، ويكافئ ذلك بتكامل أوثق مع مكدس تعلم الآلة الخاص بـ Apple ونموذج الذاكرة الموحَّدة الموصوف أعلاه. أداة أمنية مبنية كتطبيق macOS مستقل، وهي الحالة التي يقع فيها FireAI نفسه، أقرب إلى طرف llama.cpp من هذا الطيف؛ ودفتر ملاحظات بحثي يستكشف أي نمط تعليمة يعمل بشكل أفضل أقرب إلى طرف MLX.

نمط تعليمة لفرز اتصال واحد

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

System: You review one outbound network connection at a time. You are
given only the fields listed below. Do not assume anything not stated.
Respond with exactly two lines: a verdict (allow, ask, or block) and a
one-sentence reason a non-expert could understand.

Connection:
  app: UpdaterHelper.app
  code_signature: unsigned
  destination: 91.203.xxx.xxx:4444
  protocol: TCP
  threat_feed_hit: none
  first_seen: yes (no prior rule for this app)

Verdict:

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

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

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

أين يفشل هذا

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

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

أين يندمج FireAI مع هذا النمط

يشحن FireAI، جدار الحماية الخاص بـ HisnLabs لأجهزة Mac، شيئًا مبنيًا على الفكرة نفسها، بنطاق أضيق من نموذج محادثة عام الغرض: نموذج محلي اختياري، تنزيل إضافي بحجم نحو 1.5 جيجابايت، يعمل بالكامل على جهاز الـ Mac ويراجع الاتصالات من تطبيقات لا توجد لها قاعدة بعد. يتطلب macOS 14 أو أحدث على معالجات Apple silicon، ويطبّق قوائم تهديدات عامة محليًا بدلًا من التحقق منها مقابل خدمة بعيدة، ويعرض سبب قراره في نافذة الإذن نفسها التي يستخدمها ليطلب منك السماح بالاتصال أو رفضه — يصبح كل قرار من هذه القرارات قاعدة مرئية وقابلة للتعديل، ويمكن التراجع عن أي منها. يستحق الأمر توخي الدقة بشأن ما هو وما ليس هو: إنه ليس نموذج المحادثة المفتوح النطاق ببضعة مليارات معامل الذي وصفه هذا المقال، وهو ليس برنامج مكافحة فيروسات ولا شبكة VPN — إنه يؤدي مهمة تصنيف ضيقة واحدة، محليًا، ويترك القرار النهائي لمن يقرأ نافذة الإذن.

دور FireAI وHisnLabs

FireAI’s own connection reviewer is this exact bet, made narrower still: an optional, roughly 1.5 GB on-device model, macOS 14 and up, Apple silicon only, reviewing one thing (should this unknown app reach this destination) with a visible reason and an undo button — and, like the triage pattern in this article, it still needs a person to confirm anything consequential.

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

يمكنك الاطلاع على القرارات التقنية وراء ذلك، أو تجربة FireAI لمدة 17 يومًا، على FireAI من HisnLabs.