في 2026، الاستضافة الذاتية لنموذج لغوي كبير لم تعد فضولًا مختبريًا. أصبحت خيارًا ناضجًا، فعّالًا وقابلًا للدفاع اقتصاديًا لجزء متزايد من المشاريع التي نؤطرها. تبلغ النماذج المفتوحة مثل Mistral Large 2 وLlama 3.3 70B وQwen 2.5 72B أو DeepSeek V3 الآن 90 إلى 95 بالمئة من أداء GPT-4 Turbo أو Claude 3.7 Sonnet في غالبية الحالات القياسية: الاستخراج، التصنيف، التلخيص، التوليد المساعد، RAG. هذا الفارق في الجودة، الذي كان مانعًا في 2023، تقلّص لدرجة أن السؤال لم يعد «هل هي جيدة كفاية؟» بل «ما هي الموازنة الصحيحة لمجالنا؟».

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

لماذا يعود هذا السؤال بقوة في 2026

تتقارب ثلاث قوى. أولًا، يتشدد التنظيم: RGPD لأي بيانات شخصية، HDS لقطاع الصحة، NIS2 للمشغلين الأساسيين، AI Act للأنظمة عالية المخاطر، إضافة إلى المتطلبات التعاقدية الخاصة التي يفرضها الآن كبار العملاء على مقدمي الخدمة. كثير من هذه البنود تحظر صراحة النقل إلى واجهة برمجية ذكاء اصطناعي غير أوروبية، أو تتطلب تتبعًا كاملاً يستحيل ضمانه على واجهة طرف ثالث.

ثم، لحقت منظومة الأوزان المفتوحة بتأخرها. Mistral Large 2 (123B معامل)، Llama 3.3 70B، Qwen 2.5 72B وDeepSeek V3 (671B في MoE، ~37B نشط) هي اليوم نماذج صناعية. مقرونة بخوادم مثل vLLM أو TensorRT-LLM وبعتاد NVIDIA H100 أو A100 أو L40S، بل وحتى AMD MI300X، تقدم معدلات حقيقية من 30 إلى 80 رمزًا في الثانية لكل طلب، مع تجميع ديناميكي يسمح باستيعاب عدة مئات من المستخدمين المتزامنين على خادم واحد مُحجَّم بشكل صحيح.

1. تحديد معايير السيادة قبل أي شيء آخر

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

في مراجعاتنا، نفصل بشكل ممنهج ثلاث مستويات: بيانات عامة أو معتادة (API ملكي مقبول)، بيانات سرية داخلية (API أوروبي بـ DPA صارم أو استضافة ذاتية سحابية سيادية)، بيانات حساسة أو منظمة (استضافة ذاتية إلزامية، من الأمثل on-prem أو سحابة SecNumCloud / HDS). تتيح هذه الشبكة موضعة الحاجة وتجنب «الكل أو لا شيء» الذي يثقل غالبية لجان الذكاء الاصطناعي.

2. اختيار النموذج المفتوح الأوزان المناسب

يعتمد اختيار النموذج على أربعة معايير: الجودة على حالاتكم، الجودة الخاصة بالفرنسية، الحجم (وبالتالي تكلفة البنية التحتية)، والترخيص. يبقى Mistral Large 2 مرجعنا للحالات الفرنكوفونية المتطلبة: جودة التفكير، اتباع التعليمات، التوليد الطبيعي. يقدم Llama 3.3 70B علاقة ممتازة بين الجودة والحجم لكن ترخيصه (Acceptable Use Policy) يبقى مقيدًا لبعض الاستخدامات ويستبعد المنصات الكبرى جدًا. Qwen 2.5 72B قوي بشكل مفاجئ في البرمجة والرياضيات. DeepSeek V3، في MoE، يقدم جودة قريبة من GPT-4 بتكلفة خدمة معتدلة بفضل 37B معامل نشط.

منهجيتنا: لا نصدق أبدًا التصنيفات العامة من نوع MMLU أو Chatbot Arena. نبني معيارًا داخليًا من 50 إلى 200 موجه يمثل مجال العميل، ونقيس faithfulness، التنسيق، النبرة، الكمون والتكلفة على كل نموذج مرشح. إنها الطريقة الوحيدة للفصل بصدق.

  • Mistral Large 2 (123B): فرنسية ممتازة، ترخيص MRL واضح، نشر 2-4×H100
  • Llama 3.3 70B: أفضل علاقة بين الجودة والحجم، انتباه إلى AUP
  • Qwen 2.5 72B: قوي في البرمجة والتفكير، ترخيص Apache 2.0 جزئي
  • DeepSeek V3 (671B MoE): جودة من المستوى الأعلى، تكلفة خدمة معقولة رغم الحجم

3. تحجيم البنية التحتية GPU

التحجيم ليس بديهيًا. ثلاثة متغيرات تحسب: VRAM المتاحة، الكمون المستهدف (time to first token وtokens/second لكل مستخدم) والتزامن (مستخدمون متزامنون). لـ Llama 3.3 70B مُكمَّم INT4، يكفي H100 80GB واحد في النموذج الأولي لكنه يشبع بسرعة فوق 5-10 مستخدمين متزامنين. في FP8، يلزم اثنان من H100. لـ Mistral Large 2 في الإنتاج، ننطلق نموذجيًا من 2 إلى 4×H100 أو عقدة 8×L40S حسب ملف الحمولة.

من جهة البنية التحتية، يهيمن خياران: شراء مباشر (1×H100 80GB حول 30 إلى 40 ألف يورو خارج الضريبة، قابل للاستهلاك على 24-36 شهرًا) أو إيجار GPU سحابي عند Scaleway وOVHcloud وLambda Labs أو RunPod، بين 2,5 و4 يورو للساعة حسب المزود والالتزام. يبقى GPU سحابي أوروبي ذا صلة عند البحث عن التوفيق بين السيادة والمرونة، شريطة التحقق من السلطة القضائية الحقيقية للمزود ووضعه SecNumCloud إذا اقتضى الأمر.

4. اختيار حزمة الخدمة

أربعة خيارات تهيكل السوق. أصبح vLLM المرجع مفتوح المصدر: PagedAttention، continuous batching، دعم متوافق مع OpenAI، مجتمع ضخم. إنه اختيارنا الافتراضي. TGI (text-generation-inference من Hugging Face) يبقى متينًا جدًا، مدمجًا خاصة في منظومة HF، أقل أداء بقليل من vLLM في الإنتاجية لكنه ناضج جدًا في الإنتاج. TensorRT-LLM من NVIDIA يقدم أفضل أداء خام على عتاد NVIDIA، بثمن تعقيد التجميع والصيانة المرتفع جدًا، ذو صلة على نطاق كبير فقط. يقترح NVIDIA NIM مقاربة مُدارة on-prem، بخدمات مصغّرة في حاويات جاهزة للاستخدام: مثير للاهتمام عندما لا يكون لدى الفريق الداخلي ملف MLOps أقدم، أقل مرونة وأكثر تكلفة على المدى الطويل.

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

5. تأمين ومراقبة LLM في الإنتاج

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

المراقبة التقنية تحسب بنفس القدر: مراقبة GPU (الاستخدام، الذاكرة، الحرارة)، مقاييس الخدمة (TTFT، tokens/sec، حجم الصف)، التتبع التطبيقي (Langfuse، OpenLLMetry، أو حل محلي). بدون هذا القياس عن بُعد، لن تعرفوا متى تشبع بنيتكم، ولا متى ينحرف نموذج، ولا من أين يأتي تراجع في الجودة.

6. FinOps: نمذجة TCO بصدق

السؤال المالي لا يتلخص في سعر GPU. تشمل TCO الحقيقية لـ LLM مستضاف ذاتيًا استهلاك العتاد أو الإيجار، الكهرباء والتبريد إذا on-prem، الكفاءات MLOps الداخلية أو الخارجية، صيانة النماذج (تحديثات كل 3-6 أشهر على المفتوح الأوزان)، المراقبة، الأمن، ومراحل الترقية. على مشاريعنا، نبني دائمًا مقارنة على 24 شهرًا بين ثلاثة سيناريوهات: API ملكي صرف، هجين (API للذروة، استضافة ذاتية للمتكرر)، استضافة ذاتية كاملة.

كإشارة: Mistral Large 2 على 1×H100 80GB في خدمة vLLM مُحسَّنة يقدم حوالي 50 رمزًا/ثانية لكل طلب و1500 إلى 2500 رمز/ثانية في الإنتاجية الإجمالية حسب التجميع. على 30 يومًا كاملة، يمثل هذا حجمًا نظريًا من عدة مليارات من الرموز، مقابل فاتورة API مكافئة تُحسب بعشرات الآلاف من اليوروهات شهريًا على نفس الأحجام.

الفخاخ التي تُفشل مشاريع الاستضافة الذاتية

أربعة فخاخ تتكرر في مراجعات الإنقاذ لدينا. أولًا، الاستهانة بالمراقبة: بدون قياس عن بُعد، يقود الفريق بشكل أعمى وتصبح كل عطل كارثة. ثانيًا، إهمال أمن الشبكة: تنتقل نماذج أولية كثيرة إلى الإنتاج مع نقطة وصول vLLM مكشوفة في الواضح. ثالثًا، نسيان التكلفة المتكررة لتحديث النماذج: LLM مفتوح الأوزان من 2026 سيكون قديمًا في 2027، يجب توقع وتيرة الترقية منذ التأطير. رابعًا، عدم تدريب الفريق: LLM مستضاف ذاتيًا لا يُدار كخدمة مصغّرة كلاسيكية، الكفاءات MLOps وML engineering لا غنى عنها.

تضاف إلى هذه الفخاخ التقنية فخ استراتيجي: الخلط بين السيادة والأداء. الاستضافة الذاتية لا تجعل حالة استخدام سيئة جيدة. إذا كانت الحاجة الأعمالية سيئة التأطير، إذا أُهمل RAG، إذا غاب التقييم، سيفشل المشروع بالسيادة أو بدونها. الاستضافة الذاتية وسيلة، لا غاية.

ماذا الآن؟

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

  • تواصلوا معنا لتأطير مشروع سيادة (ورشة يومين، مخرج قراري)
  • تدقيقنا يغطي أيضًا بُعد رؤية منصة الذكاء الاصطناعي لديكم
  • اطلعوا على أسعارنا للصيغ التي تشمل تشغيل LLM

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