6 أسطر فقط: تشغيل نماذج LLM على أجهزة React Native بلا API

مقدمة تحليلية

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

لكن المشهد يتغير بسرعة بفضل الابتكارات التي تمكّن من تشغيل نماذج اللغة الكبيرة (LLMs) مباشرةً على الأجهزة المحمولة. هذه القفزة النوعية، التي لا يزال العديد من مطوري React Native يعتبرونها غريبة، أصبحت الآن واقعًا عمليًا. مع ظهور مكتبات مثل react-native-executorch، المبنية على بيئة تشغيل ExecuTorch من Meta، أصبح بإمكان المطورين دمج قدرات الذكاء الاصطناعي القوية في تطبيقاتهم بستة أسطر فقط من الكود، ودون الحاجة لأي مكالمات API خارجية. وهذا يفتح الأبواب أمام تطبيقات أكثر أمانًا، تعمل دون اتصال، وأقل تكلفة، مما يعيد تعريف ما هو ممكن في تطوير تطبيقات الجوال.

التحليل التقني

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

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

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

المتطلبات الأساسية

• بنية React Native الجديدة فقط: لا تدعم المكتبة بنية RN القديمة. إذا كان تطبيقك لا يزال عليها، فهذه هي أول عملية ترحيل يجب عليك القيام بها.
• Expo SDK 54+ (موصى به): الإصدارات الأقدم لا تعمل مع واجهات برمجة تطبيقات نظام الملفات التي تعتمد عليها المكتبة الآن.
• بناء تطوير مخصص، وليس Expo Go: تعتمد المكتبة على وحدات Native Modules، وExpo Go لن يقوم بتحميلها. هذه النقطة تخدع الجميع في المرة الأولى.
• جهاز iOS حقيقي لإصدارات الإنتاج: نظرًا لأن ExecuTorch يعمل بشكل Native، لا يمكنك إنتاج إصدار iOS للإنتاج يستهدف المحاكي. يمكن تصحيح الأخطاء على المحاكي، لكن اختبار الإصدار يتطلب جهازًا فعليًا.

إعداد المكتبة

عملية التثبيت تتكون من خطوتين: تثبيت الحزمة الأساسية، ثم إضافة محول جلب الموارد (resource fetcher adapter). بعد تثبيت react-native-executorch، يجب تثبيت المحول المناسب لمشروعك، سواء كان مشروع Expo (react-native-executorch-expo-resource-fetcher) أو مشروع React Native عادي (react-native-executorch-bare-resource-fetcher). الأهم من ذلك، وقبل استدعاء أي API آخر، يجب تهيئة ExecuTorch بهذا المحول، مرة واحدة فقط، عند نقطة دخول تطبيقك (مثل App.tsx أو index.js). هذا يضمن جاهزية البيئة قبل تحميل أي نموذج. خطأ شائع هنا هو نسيان هذه التهيئة، مما يؤدي إلى خطأ ResourceFetcherAdapterNotInitialized عند أول محاولة تحميل نموذج.

بالنسبة للمطورين الذين يخططون لتضمين النموذج مع التطبيق عبر require() بدلاً من تنزيله، يجب إضافة امتدادات الملفات الثنائية (.pte للنموذج و .bin للمحلل اللغوي tokenizer) إلى Metro Config لتجنب مشاكل التحميل.

تحميل نموذج

تتم عملية تحميل نموذج اللغة الكبيرة ببساطة باستخدام الـ hook useLLM وتحديد النموذج المطلوب من المصنع models.llm.*. هذا المصنع يوفر مجموعة من النماذج المصدرة مسبقًا والجاهزة للتشغيل، ويضمن تجميع النموذج نفسه بصيغة ExecuTorch الخاصة (.pte)، والمحلل اللغوي المطابق، وإعدادات المحلل اللغوي.

تستضيف Software Mansion المجموعة الكاملة من النماذج على HuggingFace، مما يسهل على المطورين الاختيار. تتضمن النماذج المتوفرة نماذج نصية مثل Qwen 3 (0.6B / 1.7B / 4B)، Llama 3.2 (1B / 3B)، Phi 4 Mini، SmolLM 2، Hammer 2.1، بالإضافة إلى نماذج قادرة على معالجة الرؤية مثل Gemma 4 وLFM2.5-VL. يُنصح بالبدء بالنماذج الصغيرة لأن النماذج الأكبر حجمًا (مثل 4B) قد تكون أذكى ولكنها أكثر عرضة لمشاكل نقص الذاكرة على الأجهزة ذات الموارد المحدودة.

يوفر الـ hook llm أيضًا معلومات حالة مفيدة لدفع واجهة المستخدم، مثل llm.downloadProgress (لتتبع تقدم التنزيل)، llm.isReady (للدلالة على جاهزية النموذج)، llm.error (في حال حدوث خطأ)، llm.isGenerating (أثناء توليد الرموز)، وllm.response (النص الذي يتم إنشاؤه، والذي يتحديث رمزًا برمز).

ربط شاشة الدردشة

هناك طريقتان رئيسيتان لاستخدام هذا الـ hook: الوضع 'الوظيفي' (Functional) والوضع 'المُدار' (Managed). في الوضع الوظيفي، يدير المطور حالة الرسائل بالكامل، ويمرر مصفوفة الرسائل في كل مرة، ويحصل على دفق من الرموز. هذا الوضع مثالي للمهام ذات الطلقة الواحدة (one-shot transforms) مثل تلخيص نص أو إعادة كتابته.

أما في الوضع المُدار، فالمكتبة هي التي تدير حالة المحادثة، بما في ذلك سجل الرسائل وإعدادات التوليد عبر sendMessage وmessageHistory وconfigure. هذا الوضع هو الأنسب لبناء واجهات الدردشة التفاعلية التي تتطلب تذكر السياق. من المهم ملاحظة أن configure يؤثر فقط على المسار المُدار، بينما تتطلب الدالة generate() في الوضع الوظيفي تمرير الإعدادات مباشرةً.

السياق وتأثير السوق

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

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

تأثير السوق كبير، حيث يمكن للشركات الآن خفض نفقات التشغيل المرتبطة باستضافة نماذج الذكاء الاصطناعي بشكل كبير، مما يحرر الموارد للابتكار. كما أن مشاركة شركات مثل Meta ببيئة ExecuTorch وSoftware Mansion بتطوير react-native-executorch يدل على توجه صناعي أوسع نحو دمج الذكاء الاصطناعي بشكل عميق وفعال في الحوسبة الطرفية (edge computing)، مما يجعل الذكاء الاصطناعي ليس فقط أكثر قوة ولكن أيضًا أكثر انتشارًا ومتاحًا للجميع.

رؤية Glitch4Techs

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

أولًا، تشكل عملية إيقاف تشغيل النموذج أثناء توليد الرموز خطرًا حقيقيًا على استقرار التطبيق. فإذا قام المستخدم بالتنقل بعيدًا أو إغلاق التطبيق بينما لا يزال النموذج يولد نصًا، فسيؤدي ذلك إلى تعطل التطبيق بالكامل. الحل يكمن في استخدام الدالة llm.interrupt() والانتظار حتى تصبح llm.isGenerating false قبل تفكيك المكون أو السماح بالانتقال.

ثانيًا، يجب على المطورين أن يكونوا على دراية بأن النماذج الكبيرة (تتراوح من 700 ميجابايت إلى أكثر من 1 جيجابايت) يتم تنزيلها عند التشغيل الأول. هذا يتطلب تصميمًا دقيقًا لواجهة المستخدم لتقديم مؤشر تقدم التنزيل (downloadProgress) لمنع المستخدم من الشعور بأن التطبيق معلق. عدم وجود شاشة تحميل واضحة سيؤدي حتمًا إلى قيام المستخدمين بإغلاق التطبيق قسرًا، مما يؤثر سلبًا على التجربة الأولية.

ثالثًا، غالبًا ما تكون الذاكرة العشوائية (RAM) هي العامل المحدد، وليس سرعة المعالج (CPU). العديد من الأعطال على الأجهزة منخفضة التكلفة تحدث بسبب نقص الذاكرة. لذلك، يُنصح بشدة باستخدام النماذج المكممة (quantized models) وتحسين استخدام الذاكرة. إذا واجهت أعطالًا على محاكي Android، فمن الحكمة زيادة ذاكرة المحاكي قبل الشروع في تصحيح أخطاء الكود.

رابعًا، من الأهمية بمكان التأكيد مرة أخرى على أن Expo Go لا يدعم الوحدات Native Modules المطلوبة لتشغيل هذه المكتبة. يتطلب التنفيذ الناجح بناء تطوير مخصص، وتجاهل هذه الحقيقة يمكن أن يكلف المطورين وقتًا ثمينًا في التشخيص. خامسًا، تدور بنية المكتبة حول مثيل نموذج نشط واحد في كل مرة. محاولة تشغيل مكونين useLLM جنبًا إلى جنب لن ينجح. وأخيرًا، يجب الاهتمام بتجميع الرموز (token batching) لمنع تجمد واجهة المستخدم، خاصةً مع النماذج السريعة التي يمكنها إنتاج 60 رمزًا في الثانية أو أكثر. يمكن تعديل outputTokenBatchSize وbatchTimeInterval في generationConfig لتحسين الأداء البصري.

تفتح هذه التقنية آفاقًا واسعة لتطبيقات تتجاوز مجرد الدردشة، مثل استدعاء الأدوات (Tool Calling) لتنفيذ وظائف محددة، والحصول على مخرجات منظمة (Structured Output) بتنسيق JSON، ومعالجة الرؤية والصوت (Vision and Audio) لإنشاء مساعدين صوتيين غير متصلين بالإنترنت أو أدوات ترجمة فورية بالكاميرا. كما يمكن دمجها مع تقنيات RAG (Retrieval-Augmented Generation) المحلية، مما يتيح للنماذج الإجابة على الأسئلة بناءً على مستندات المستخدم الخاصة، كل ذلك دون اتصال بالإنترنت.

في الختام، ننصح المطورين بالبدء بالتحقق من صحة التنفيذ على جهاز حقيقي، ودراسة تطبيقات مفتوحة المصدر مثل Private Mind من Software Mansion لفهم أفضل لممارسات الإنتاج. الأهم هو بناء شاشة التحميل الأولية قبل شاشة الدردشة نفسها، وتأخير تحميل النموذج باستخدام preventLoad لتجنب استهلاك الذاكرة قبل الحاجة الفعلية. إن النموذج ليس سوى قطعة واحدة؛ أما المنتج الحقيقي، فهو التجربة الشاملة التي تبنيها حوله.