الوحدة 10 — حدود التشغيل المحلّيّ
بعد تسع وحدات من مزايا Ollama، هذه الوحدة تعرض الوجه الآخر: ما لا يجيده التشغيل المحلّيّ، والحالات التي يجب أن نعترف فيها بحدوده. لا يوجد بائع سحابيّ يقول لك «لا تستعملنا»؛ هنا نقولها.
الجودة مقابل النماذج السحابيّة الكبيرة
أفضل نموذج مفتوح يعمل على محطّة بذاكرة 32 GB اليوم يبلغ ≈ 70 % من جودة GPT-4 أو Claude Opus على مهامّ استدلال معقّدة. الفارق يظهر أكثر في:
- الاستدلال المتعدّد الخطوات: حلّ مسألة تحتاج ثلاث فرضيّات متتالية.
- العربيّة الفصحى الدقيقة: النغمة القانونيّة الرسميّة، والتصريف السليم.
- البرمجة المعقّدة: نموذج شيفرة محلّيّ 7B يخطئ حيث لا يخطئ Claude Sonnet.
- السياق الطويل جدًّا: 200 K رمزًا يعمل في السحابة، ونادرًا محلّيّاً بجودة عالية.
للمهامّ البسيطة (تصنيف، استخراج، إعادة صياغة قصيرة)، الفارق ضئيل ولا يبرّر كلفة السحابة. للمهامّ الدقيقة، النموذج المحلّيّ يخدم كخيار احتياطيّ أو كمرشّح أوّليّ يوقف الطلبات البديهيّة، ثمّ يُمرِّر الصعبة إلى نموذج سحابيّ.
التزامن: العائق الأكبر عمليًّا
Ollama افتراضيًّا يعالج طلبًا واحدًا في وقت واحد على النموذج نفسه. OLLAMA_NUM_PARALLEL=4 يفتح أربعة معًا، لكنّ الأداء الفرديّ ينخفض وذاكرة الرسميّات ترتفع خطّيًّا مع السياق × عدد الطلبات.
مثال ملموس: نموذج 7B على RTX 4090 يعطي 130 رمزًا/ثانية لطلب واحد. أربعة طلبات متوازية: كلٌّ يحصل على ≈ 45 رمزًا/ثانية. عشرة طلبات: لا تسع الذاكرة، وتفشل.
قاعدة: بطاقة واحدة تخدم فريقًا من خمسة أشخاص بشكل مريح، عشرة على الحدّ، عشرين مستحيل. عند هذه العتبة، يجب:
- بط اقات متعدّدة على خادم واحد.
- أو مزوّد سحابيّ متخصّص (Together، Fireworks، Groq).
- أو خدمة API سحابيّة كبيرة (OpenAI، Anthropic).
التحديثات ومتابعة النماذج
في السحابة، النموذج يُحدَّث خلف الكواليس. محلّيّاً، أنت المسؤول:
- إصدار جديد من
qwen2.5كلّ بضعة أشهر: يجب جلبه وقياسه. - تحديثات Ollama نفسها (نُسخ متكرّرة): يجب تثبيتها ومتابعة تغييراتها.
- تعريفات NVIDIA وCUDA: تحديث تعريف قد يُخفض الأداء 20 % أو يُصلحه.
- Modelfile قد يحتاج إعادة تعديل عند تغيير النموذج الأساس.
كلفة مخفيّة: نصف يوم شهريًّا للصيانة الدنيا، يوم كامل لكلّ نموذج جديد يُقيَّم. المكتب الذي لا يخصّص هذا الوقت سيرى النظام يتقادم صامتًا.
أمان المحطّة نفسها
النموذج على المحطّة يعني أنّ أمن المحطّة صار حاسمًا:
- قفل الشاشة: من يجلس أمام المحطّة يستدعي المساعد بلا قيود.
- تشفير القرص: مسروق الحاسوب معه كلّ الأرشيف والفهرس والنماذج.
- الأذون: مجلّد
OLLAMA_MODELSقابل للقراءة من مستخدمين آخرين على النظام؟ - السجلّات: Ollama لا يُسجّل «من ناداه»؛ يجب أن يمرّ عبر وسيط ليُوجد سجلّ.
مقابل السحابة، حيث المزوّد يحمل عبء أمن البنية، هنا المكتب يحمله. للمكاتب الصغيرة بلا فريق تقنيّ، هذا عبء حقيقيّ يجب أن يُقارن بمزايا السرّيّة.
الصيانة اليوميّة
قائمة الملاحظة الدنيا:
- الحدّ الأدنى من الذاكرة الحرّة: تنبيه أوتوماتيكيّ إن نزل تحت 4 GB.
- درجة حرارة البطاقة: تشغيل مستمرّ فوق 80° يُقصّر عمرها.
- امتلاء
OLLAMA_MODELS: نموذج مجلوب صار غير مستعمل ولم يُحذف. - تحديثات الأمن على النظام: تأخيرها يفتح ثغرات.
هذه ليست عناصر سحريّة. مسؤول نظام يعرفها. المكتب الذي ليس فيه مسؤول نظام يستحسن أن يعرف قبل الالتزام.
متى الترقّي؟
إلى خادم مخصّص داخل المكتب
- تجاوز 10 مستخدمين متزامنين.
- الحاجة إلى نموذج كبير (34B أو 70B).
- توحيد Nginx وسجلّات ومصادقة.
- تكلفة: خادم بـ 2 × RTX 4090 أو H100، من 8000 إلى 40 000 دولار، زائد كهرباء وتبريد.
إلى مزوّد سحابيّ متخصّص
- ذروات نداء غير منتظمة (100 طلب في 5 دقائق أحيانًا).
- الحاجة إلى نموذج مفتوح كبير جدًّا (Llama 3.1 405B) بلا استثمار عتاديّ.
- الميزانيّة تفضّل OPEX (كلفة تشغيل) على CAPEX (كلفة استثمار).
- المزوّد يحفظ سرّيّة معقولة (اتّفاق معالجة بيانات، مواقع في الاتّحاد الأوروبيّ).
إلى واجهة سحابيّة كبيرة (OpenAI، Anthropic)
- الجودة القصوى ضروريّة لمهمّة معيّنة (صياغة رأي قانونيّ حسّاس مثلًا).
- الحجم ضئيل (بضع نداءات في اليوم).
- الاتّفاق مع المزوّد يحلّ إشكال السرّيّة (اتّفاقات مؤسّسيّة، عدم تخزين).
هذه ليست قرارات «كلّ شيء أو لا شيء». مكتب المحاماة يمكنه أن يستعمل Ollama محلّيّاً لـ 95 % من الطلبات، ويحوّل الـ 5 % الأصعب إلى واجهة سحابيّة موقَّع معها اتّفاق سرّيّة، إن كان الموكّل قبل ذلك.
قائمة قرار سريعة
| السؤال | إن نعم |
|---|---|
| هل الطلبات كلّها بسيطة (تصنيف، استخراج)؟ | Ollama محلّيّ يكفي |
| هل الفريق أكثر من عشرة؟ | خادم مخصّص أو سحابة |
| هل تحتاج نموذجًا أكبر من 34B؟ | خادم متعدّد GPU أو سحابة |
| هل السرّيّة مطلقة (بيانات صحّيّة، قانونيّة)؟ | محلّيّ إن أمكن، وسحابة سرّيّة إن لم يمكن |
| هل الميزانيّة تفضّل CAPEX؟ | محلّيّ أو خادم مخصّص |
| هل تحتاج ذروات مرنة؟ | سحابة |
الخيط الأحمر
بعد ستّة أشهر من التشغيل الفعليّ في المكتب، القسم ثبت هكذا:
- 95 % من الاستفسارات (تصنيف، تلخيص، صياغة، RAG على الأرشيف) على Ollama محلّيّاً.
- 4 % من الاستفسارات (مسائل استدلال طويل معقّد) تُوجَّه إلى Claude Sonnet عبر API مع موافقة الموكّل.
- 1 % (مسائل استثنائيّة) يعالجها المحامي يدويًّا كما قبل الأتمتة.
هذا التقسيم ليس هزيمة لـ Ollama بل قوّته الحقيقيّة: أخذ 95 % من العمل التكراريّ محلّيّاً، وترك 5 % للسحابة عن معرفة.
كثير من الفرق تحاول محاكاة كلّ ميزة سحابيّة على Ollama محلّيّاً: مقياس افتراضيّ، تحمّل ذروة عشرين نداءً في الثانية، توفّر 99.99 %. هذه الأهداف يمكن بلوغها لكن بكلفة عتاد وصيانة تفوق كلفة السحابة نفسها. Ollama نجاحه أن يقوم بما لا تفعله السحابة جيّدًا: تكلفة صفر لكلّ نداء، سرّيّة محلّيّة، تجربة بلا اتّصال.
الخلاصة
- النماذج المحلّيّة تبلغ ≈ 70 % من جودة أفضل النماذج السحابيّة على المهامّ الصعبة؛ أقرب للتعادل على المهامّ البسيطة.
- التزامن الحقيقيّ محدود ببطاقة واحدة إلى 5–10 مستخدمين؛ ما فوق ذلك يحتاج تعدّد GPU أو سحابة.
- الصيانة (تحديثات، أمان، سجلّات) عبء ثابت يستهلك يومًا شهريًّا لا يمكن التغافل عنه.
- استراتيجيّة هجينة (95 % محلّيّ + 5 % سحابة للحالات الصعبة) غالبًا أفضل من التطرّف نحو أيّ من الطرفين.