إحدى أولى القرارات الفعلية في أي مشروع ذكاء اصطناعي هي تحديد نوع النموذج الذي ستبني عليه المشروع: إما نموذج مفتوح المصدر يمكنك تنزيله وتشغيله بنفسك، أو نموذج مغلق تتمّ الوصول إليه عبر واجهة برمجة تطبيقات (API). وقد ضاقت الفجوة بين النوعين بشكل كبير جدًّا — إذ أصبحت النماذج المفتوحة تنافسية حقًّا الآن — ما يجعل الاختيار أكثر صعوبةً، وأكثر إثارةً، مما كان عليه في السابق.
يقدِّم هذا الدليل مقارنةً بينهما استنادًا إلى العوامل التي تقرّر السؤال فعليًّا.
أبرز الاستنتاجات
- النماذج المغلقة (مثل GPT وClaude وGemini) تتفوّق في أقصى قدرة أداء، وهي الأسهل في البدء بها.
- النماذج المفتوحة (لاما، كوين، ديب سيك، ميسترال، جيما) تتفوق في التكلفة عند التوسع والخصوصية والتحكم.
- انخفضت فجوة القدرة بشكل ملحوظ — إذ تُنافس أفضل النماذج المفتوحة الآن النماذج المغلقة في معظم المهام.
- اختر النماذج المغلقة للنتائج المطلقة الأفضل دون الحاجة إلى بنية تحتية؛ واختر النماذج المفتوحة لضمان خصوصية البيانات، والتخصيص، وقابلية التنبؤ بالتكلفة.
تعريف سريع
يعني مصطلح «مفتوح المصدر» في عالم النماذج اللغوية الكبيرة عادةً «أوزانًا مفتوحة»: أي أنَّ معاملات النموذج المدرَّب تُنشَر علنًا، لذا يمكنك تنزيل النموذج وتشغيله على أجهزتك الخاصة، وتخصيصه (Fine-tune)، وفحصه. ومن أبرز الأمثلة عليه نماذج Llama من شركة Meta، وQwen من شركة Alibaba، والنماذج من DeepSeek وMistral، وGemma من Google. (وبشكل دقيق، فإن العديد منها يُصنَّف رسميًّا على أنه «ذو أوزان مفتوحة» بدلًا من كونه «مفتوح المصدر تمامًا»، لأن بيانات التدريب والشفرة البرمجية لا تُنشر دائمًا — لكن وجود الأوزان المفتوحة هو ما يهم عمليًّا.)
النماذج المغلقة يتم الوصول إليها فقط عبر واجهة برمجة تطبيقات (API) تقدّمها الجهة الموفِّرة. ولا ترى أوزان النموذج أبدًا، ولا يمكنك استضافته ذاتيًّا. وأبرز النماذج المغلقة هي GPT من OpenAI، وClaude من Anthropic، وGemini من Google.
المقارنة
القدرة الأداء
لا تزال النماذج المغلقة تحتل المرتبة الأولى في قوائم الترتيب — إذ تحقِّق أفضل النتائج على الإطلاق في أصعب مهام الاستنتاج والبرمجة والمهام متعددة الوسائط، وعادةً ما تأتي هذه النتائج من نموذج مغلق رائد. لكن الهامش الفاصل بينها وبين النماذج المفتوحة أصبح ضئيلًا الآن. فبالنسبة للغالبية العظمى من المهام الواقعية، فإن أفضل نموذج مفتوح كافٍ تمامًا، ولا يمكن تمييزه عن النماذج المغلقة في الاستخدام اليومي العادي. الميزة: للنماذج المغلقة، وبفارق ضئيل.
التكلفة
وهنا تتألق النماذج المفتوحة — خاصةً عند التوسّع. فالنموذج المغلق يفرض رسومًا لكل رمز (Token) بشكل دائم؛ وبالتالي تزداد الفاتورة بلا حدود عند الحجم الكبير. أما النموذج المفتوح فيتبع نمط تكلفة مختلفًا: فأنت تدفع مقابل الأجهزة (أو الإيجار)، لكن عملية التوليد نفسها لا تتضمّن أي رسوم لكل رمز. ولذلك تكون واجهات برمجة التطبيقات المغلقة أرخص عند الحجم المنخفض أو المتقطّع (لعدم الحاجة إلى بنية تحتية)، بينما قد تكون النماذج المفتوحة أرخص بكثير عند الحجم العالي المستمر. الميزة: للنماذج المفتوحة عند التوسّع، وللمغلقة عند الحجم المنخفض.
الخصوصية والتحكم في البيانات
عند استخدام واجهة برمجة تطبيقات مغلقة، تغادر مدخلاتك (Prompts) وبياناتك بنيتك التحتية لتنتقل إلى طرف ثالث. وعلى الرغم من أن موفري الخدمة يقدمون اتفاقيات تجارية وضوابط بيانات، فقد لا يكون ذلك مقبولًا بالنسبة للبيانات شديدة الحساسية — مثل البيانات الطبية أو القانونية أو المالية أو الخاضعة للتنظيم. أما النموذج المفتوح فيمكن تشغيله بالكامل داخل بيئتك الخاصة، بحيث لا تغادر البيانات حدودها أبدًا. الميزة: للنماذج المفتوحة، وبوضوح تام.
التخصيص والتحكم
يمكن تخصيص النماذج المفتوحة بحرية تامة، وتعديلها، وتصغير حجمها (Quantization)، ونشرها بالضبط بالطريقة التي تريدها. كما أنك تتحكم في إدارة الإصدارات — فلا يتغيّر النموذج فجأةً دون علمك. أما النماذج المغلقة فتقدم فقط درجة التخصيص التي يسمح بها الموفّر، ويمكن تحديثها أو إيقافها وفق جدول الموفّر الخاص. الميزة: للنماذج المفتوحة.
سهولة الاستخدام
النماذج المغلقة أسهل بكثير في البدء: سجّل الاشتراك، واحصل على مفتاح واجهة برمجة التطبيقات (API key)، ثم أجرِ استدعاءً واحدًا — دون الحاجة إلى وحدات معالجة الرسومات (GPUs)، أو عمليات النشر، أو إدارة التوسّع. أما تشغيل نموذج مفتوح في بيئة الإنتاج فيتطلّب التعامل مع البنية التحتية، والتحسين، واستمرارية التشغيل بنفسك (أو دفع تكلفة لمزوِّد خدمات الاستضافة لإدارتها نيابةً عنك). الميزة: للنماذج المغلقة.
الموثوقية والدعم
تتولّى الجهات الموفِّرة للنماذج المغلقة مسؤولية استمرارية التشغيل، والتوسّع، والتحسينات، مع تقديم دعم رسمي. أما الاستضافة الذاتية للنموذج المفتوح فتجعل مسؤولية الموثوقية من اختصاصك — رغم أن خدمات الاستضافة المدارة للنماذج المفتوحة تقلّل هذه الفجوة إلى حدٍّ كبير. الميزة: للنماذج المغلقة.
ملخّص جانبي جانبي
| عامل | النماذج اللغوية الكبيرة مفتوحة المصدر | النماذج اللغوية الكبيرة مغلقة المصدر |
|---|---|---|
| أقصى قدرة أداء | ممتاز | أفضل ما هو متاح |
| التكلفة عند الحجم المنخفض | أعلى (تكاليف البنية التحتية) | أقل |
| التكلفة عند الحجم الكبير | أقل بكثير | قد تكون مرتفعة جدًّا |
| خصوصية البيانات | كاملة — تعمل في بيئتك الخاصة | تغادر البيانات إلى مزوِّد الخدمة |
| إمكانية التخصيص | كاملة (تعديل دقيق، وتعديل عام) | محدودة باختيارات المزوِّد |
| سهولة البدء | أصعب (تتطلب بنية تحتية) | سهلة جدًّا (مفتاح واجهة برمجية) |
| مراقبة الإصدارات | أنت تقرِّر | يقرِّر المزوِّد |
أيُّهما يجب أن تختار؟
اختر نموذجًا مغلقًا إذا كان:
- تريد أفضل جودة ممكنة دون أي جهد في إعداد البنية التحتية.
- حجم استخدامك منخفض أو متقطع أو غير متوقع.
- أنت في مرحلة النماذج الأولية وتريد التحرك بسرعة.
- بياناتك ليست حساسة بما يكفي لتتطلَّب معالجة داخلية (on-premise).
اختر نموذجًا مفتوح المصدر إذا كان:
- خصوصية البيانات أمرٌ بالغ الأهمية — ويجب ألا تغادر البيانات الحساسة بيئتك أبدًا.
- تعمل عند حجم عالٍ ومستمر، حيث ستتضخَّم تكاليف الواجهة البرمجية لكل رمز (token) بشكل كبير.
- تحتاج إلى تخصيص عميق أو تحكم كامل في إصدار النموذج.
- تريد الاستقلال عن سياسات التسعير والمسار التطويري لأي مزوِّد واحد.
ليست هناك حاجة للاختيار بين أحدهما فقط
في الواقع، تستخدم العديد من الفرق في عام 2026 كلا النوعين. ومن الأنماط الشائعة: البدء بالنماذج المغلقة عبر واجهة برمجية لتسريع عملية النماذج الأولية والتعلُّم مما ينجح، ثم الانتقال إلى النماذج المفتوحة للمهام عالية الحجم أو الحساسة من حيث الخصوصية بعد وضوح المتطلبات. وأنماط أخرى تشمل توجيه كل طلب وفق الحاجة — باستخدام نموذج مفتوح رخيص للمهام الروتينية، ونموذج مغلق حدّي (frontier) للتحديات الأصعب. فتعامل مع هذا الاختيار باعتباره قرارًا استثماريًّا متنوعًا، وليس اختبار ولاء.
الترخيص والشروط القانونية: الفخ المُخبَّأ في العلن
تلقى القدرات والتكلفة الاهتمام الأكبر، لكن الترخيص هو البُعد الذي يقرِّر بصمت ما إذا كان بإمكانك إطلاق المنتج قانونيًّا أم لا. فعبارة «مفتوح المصدر» ليست مصطلحًا موحَّدًا، وقد تخفي العلامة الترخيصية التصريحية على بطاقة النموذج التزامات فعلية. لذا، قبل أن تبني أي تطبيق على نموذج ما، اقرأ الترخيص الفعلي — وليس ما تروِّج له الشركة.
أما على الجانب المفتوح، فتتفاوت الشروط أكثر مما يفترضه الناس. الترخيصات التصريحية حقًّا licenses like Apache 2.0 and MIT grant unrestricted commercial use, modification, and redistribution — including of fine-tuned derivative weights. ديب سيك V4 (DeepSeek V4) ships under MIT; the Qwen3 open-weight family and Google’s Gemma 4 (which switched to Apache 2.0 in April 2026) sit under Apache 2.0; Mistral’s open models are similarly permissive. If you build on these, your obligations are essentially attribution and keeping the license text intact.
ثم هناك رُخص المجتمع «شبه المفتوحة»، حيث يُعد نموذج لاما من ميتا أبرز مثال عليها. فرخصة مجتمع لاما ليست رخصة مفتوحة المصدر معتمدة من منظمة OSI. فهي تضيف قيودًا فعلية: مثل شرط ذكر «مُبنًى على لاما» كإسناد، وشرط أن يحمل أي نموذج تقوم بتدريبه أو تحسينه باستخدام مواد لاما اسم «لاما» في بدايته، وحدٌّ عتبة يتطلَّب الحصول على رخصة منفصلة من ميتا حال تجاوز منتجك ٧٠٠ مليون مستخدم نشيط شهريًّا. كما أن أوزان لاما ٤ متعددة الوسائط تحمل قيدًا إضافيًّا: فحقوق الترخيص لا تُمنَح للأفراد المقيمين في الاتحاد الأوروبي أو الشركات التي تقع مقراتها الرئيسية فيه (مع إعفاء المستخدمين النهائيين للمنتجات المبنية على تلك النماذج). ولا يهم هذا كله في مشروع هواية — لكنه قد يكون عقبة كأداء أمام شركة ناشئة ممولة أو مؤسسة خاضعة للتنظيم، وقد يكتشفه المحامون لديك في وقت متأخر.
النماذج المغلقة تُعيد ترتيب المعادلة. فلن تحصل على أوزان النموذج ولا على حقوق إعادة التوزيع، لكن موفري الخدمات الرئيسيين يقدمون شيئًا لا يمكن للنماذج المفتوحة الوزن تقديمه: ضمان قانوني ضد انتهاكات الملكية الفكرية (IP indemnification) على المخرجات في الطبقات التجارية المدفوعة. وتلتزم شركات جوجل (عبر منصة Vertex AI) وAnthropic وOpenAI في اتفاقياتها الخاصة بالعملاء المؤسسيين وواجهات برمجة التطبيقات (API) بشكل عام بحماية العملاء التجاريين من دعاوى الطرف الثالث المتعلقة بحقوق الملكية الفكرية الناشئة عن المحتوى الذي يولّده النموذج — عادةً بشرط استخدام مرشحات الأمان المقدمة من المزوِّد وعدم الانتهاك المتعمَّد. أما في حالة النماذج المفتوحة التي تستضيفها ذاتيًّا، فإن هذا الخطر القانوني يقع بالكامل عليك.
- تحقق من بنود عدد المستخدمين الشهريين النشطين (MAU) والقيود المتعلقة بالإقامة الجغرافية داخل الاتحاد الأوروبي قبل أن تبني عملك كاملاً على نموذج مُرخَّص تحت مسمى «المجتمع».
- تأكد من حقوقك في إنشاء أوزان مشتقة وقواعد تسمية النماذج المشتقة — إذ قد تنطبق بعض الشروط على النماذج التي تقوم بضبطها يدويًّا (fine-tunes) وتنتقل معها إلى ما بعد ذلك.
- قدِّر قيمة الضمان القانوني (indemnification) بتقدير واقعي: إنه سببٌ حقيقيٌّ يدفع الفرق الخاضعة للتنظيم إلى دفع مقابل لاستخدام واجهات برمجة التطبيقات المغلقة.
الأسئلة الشائعة
هل نماذج اللغات الكبيرة مفتوحة المصدر تساوي النماذج المغلقة من حيث الجودة؟
بالنسبة لمعظم المهام الواقعية، نعم — فأفضل النماذج المفتوحة أصبحت قريبة جدًّا من نظيراتها المغلقة لدرجة أن الفرق لا يُلاحَظ غالبًا في الاستخدام اليومي. ومع ذلك، ما زالت النماذج المغلقة الحدّية تتقدَّم في أصعب مهام الاستنتاج والبرمجة والمهام متعددة الوسائط، لكن الفجوة ضئيلة وتستمر في التقلُّص.
ما أفضل نماذج اللغات الكبيرة مفتوحة المصدر؟
تشمل أبرز عائلات النماذج مفتوحة الوزن في عام 2026 نماذج «لاما» (Llama) من شركة «ميتا»، و«كوين» (Qwen) من شركة «علي بابا»، ونماذج «ديبسيك» (DeepSeek)، ونماذج «ميسترال» (Mistral)، و«جيما» (Gemma) من شركة «غوغل». وهي تتوفر بمجموعة متنوعة من الأحجام، بدءًا من النماذج الصغيرة التي تعمل على أجهزة اللابتوب، وصولًا إلى النماذج الكبيرة التي تُنافس أنظمة النماذج الحدّية المغلقة.
هل استخدام نماذج اللغات الكبيرة مفتوحة المصدر أرخص؟
يعتمد ذلك على الحجم. فعند الاستخدام المنخفض أو المتقطع، تكون واجهات البرمجة المغلقة أرخص لأنك تتفادى تكاليف البنية التحتية. أما عند الاستخدام العالي والمستمر، فإن النماذج المفتوحة غالبًا ما تكون أرخص بكثير لأنها لا تفرض رسومًا لكل رمز (token)، بل تدفع فقط مقابل الأجهزة.
هل نماذج اللغات الكبيرة مفتوحة المصدر أكثر خصوصية؟
نعم. إذ يمكن تشغيل النموذج المفتوح بالكامل داخل بيئتك الخاصة، وبالتالي لا تغادر المدخلات والبيانات أبدًا بنية التحتية الخاصة بك. أما النماذج المغلقة فهي تتطلَّب إرسال البيانات إلى المزوِّد. ولذلك، فإن النماذج المفتوحة توفر مستوى من الخصوصية لا يمكن لواجهات البرمجة المغلقة تحقيقه، خاصةً بالنسبة للبيانات الحساسة أو الخاضعة للتنظيم.
هل ينبغي للمبتدئين استخدام نماذج لغوية كبيرة مفتوحة أم مغلقة؟
ابدأ بواجهة برمجية مغلقة. فهي لا تتطلَّب أي أجهزة أو عمليات نشر — بل مجرد مفتاح واجهة برمجية — مما يسمح لك بالتركيز على التعلُّم والبناء. ثم انتقل إلى النماذج المفتوحة لاحقًا إذا ظهرت لديك احتياجات محددة تتعلق بالخصوصية أو التكلفة عند التوسع أو التخصيص العميق.
هل نموذج Llama مفتوح المصدر حقًّا؟
ليس كذلك من الناحية الصارمة. فنموذج Meta Llama يُوزَّع بموجب رخصة «مجتمع Llama»، وهي رخصة غير معتمدة من قبل منظمة معايير المصادر المفتوحة (OSI). وتسمح هذه الرخصة باستخدام تجاري واسع النطاق، لكنها تفرض شروطًا لا ترد أبدًا في رخصة مفتوحة المصدر حقيقية — مثل اشتراط ذكر عبارة «مُبنًى باستخدام Llama» كإسناد، وقاعدة تُلزم أي نموذج مشتق بأن يبدأ اسمه بعبارة «Llama»، وضرورة الحصول على موافقة من شركة Meta عند تجاوز عدد المستخدمين الشهريين النشطين (MAU) 700 مليون مستخدم، والقيود الجغرافية على أوزان الإصدار متعدد الوسائط (multimodal) من Llama 4 والتي تقتصر على الكيانات المقيمة في الاتحاد الأوروبي. وللغالبية العظمى من المستخدمين يتصرف هذا النموذج كما لو كان مفتوح المصدر؛ أما بالنسبة للشركات الكبيرة أو تلك المقيمة في الاتحاد الأوروبي، فإن البنود الدقيقة تكتسب أهمية بالغة. أما النماذج المرخَّصة برخصة Apache 2.0 أو MIT مثل Qwen3 وDeepSeek وGemma 4 فهي الخيارات الحقيقية غير المقيدة إطلاقًا.
من يتحمَّل المسؤولية القانونية إذا أنتج نموذج لغوي كبير (LLM) محتوىً منسوخًا أو منتهكًا لحقوق الملكية؟
يعتمد ذلك على المسار الذي اخترته. ففي حالة النموذج المفتوح الوزن الذي تستضيفه ذاتيًّا، يقع الخطر القانوني بالكامل عليك — فلا يوجد مورِّد يقف خلف المخرجات ويحميها قانونيًّا. أما في حالة واجهة برمجة التطبيقات المغلقة، فإن الموفِّرين الرئيسيين (جوجل عبر Vertex AI، وAnthropic وOpenAI في طبقاتهما المؤسسية وواجهات برمجة التطبيقات) يتعهدون عقدياً بتقديم ضمان قانوني (indemnification) للعملاء التجاريين المدفوعين ضد مطالبات الأطراف الثالثة المتعلقة بحقوق الملكية الفكرية على المحتوى المُولَّد، وذلك عمومًا بشرط استخدامك لمرشحات الأمان المقدمة من المزوِّد وعدم انتهاكك المتعمَّد للحقوق. أما الطبقات الاستهلاكية أو المجانية فلا تتضمَّن عادةً هذا النوع من الحماية. وإذا كانت مخاطر انتهاك حقوق الملكية تمثِّل مصدر قلق حقيقي في حالتك الاستخدامية، فإن هذا الضمان القانوني يُعدُّ أحد أقوى الحجج العملية الداعمة لاعتماد نموذج مغلق.
هل يمكنني ضبط نموذج مفتوح المصدر يدويًّا (fine-tune) وبعدها بيع النتيجة؟
نعم، عادةً ما يجوز ذلك، لكن تأكَّد أولًا من الرخصة المطبَّقة. فالنماذج المرخَّصة برخصة Apache 2.0 أو MIT تسمح صراحةً بالاستفادة التجارية من الأوزان المشتقة، مع التزام وحيد هو الإسناد (attribution). أما النماذج المرخَّصة برخصة «المجتمع» مثل Llama فهي أكثر تعقيدًا: فقد تنطبق الشروط على نموذجك المُعدَّل يدويًّا وتنتقل معه إلى ما بعد ذلك، وتبقى عبارة «مُبنًى باستخدام Llama» إلزامية كإسناد، ويجب أن يبدأ اسم أي نموذج مشتق تقوم بتوزيعه بعبارة «Llama»، كما تظل بنود عدد المستخدمين الشهريين النشطين (MAU) والقيود الجغرافية في الاتحاد الأوروبي سارية المفعول. وعليك دائمًا التحقق مما إذا كانت القيود تتعلَّق فقط بملف الأوزان الأصلي (checkpoint) أم أنها تشمل كل نموذج مشتق يتم إنشاؤه منه — فهذه المفارقة تحدد تمامًا ما يجوز لك شرعًا طرحه في السوق.
الخلاصة
يتمحور اختيار النموذج المفتوح مقابل المغلق حول مقايضة واضحة. النماذج المغلقة توفر لك أعلى قدرة وأسهل بداية، لكن بتكلفة الرسوم لكل رمز (token) وإرسال البيانات إلى طرف ثالث. النماذج المفتوحة توفر لك الخصوصية والتحكم وانخفاض التكلفة عند التوسع، لكن بتكلفة إدارة البنية التحتية بنفسك.
للمشاريع النموذجية والاستخدام المنخفض الحجم، ابدأ بالنماذج المغلقة. أما للإنتاج ذي الأولوية العالية للخصوصية أو ذي الحجم الكبير، فاعتمد على النماذج المفتوحة. ولا تنسَ أنك لست مُقيَّدًا باختيار واحد — فالفرق الأكثر ذكاءً في عام 2026 تستخدم كلا النوعين، وتُطابق كل مهمة مع النموذج الأنسب لها.
