Ollama أم LM Studio: أيهما لتشغيل الذكاء الاصطناعي محلياً

الفيصل بين Ollama وLM Studio ليس شكل الواجهة بل ما تنوي فعله بالنموذج بعد تشغيله. إن كنت ستبني أتمتة وسكربتات وخدمات تستهلك النموذج عبر API، أو ستنشره في حاوية أو على خادم لينكس، فوجهتك Ollama. وإن كنت تريد اكتشاف النماذج المفتوحة وتجربتها والدردشة معها وضبط إعداداتها بصرياً، فوجهتك LM Studio. أما ثنائية «سطر الأوامر مقابل الواجهة الرسومية» فقد سقطت في 2026: Ollama أطلق تطبيقاً رسومياً منتصف 2025 لماك وويندوز، وLM Studio صار يعمل بلا واجهة إطلاقاً عبر أداة lms. كلاهما يشغّل ملف GGUF نفسه على عتادك، والفرق الحقيقي في التفاصيل التي تظهر بعد أسبوع من الاستخدام: من يدير الذاكرة وكيف، ومن يقصّ سياقك بصمت، ومن يترك خادمك مكشوفاً.

رخصة MIT مقابل برنامج مغلق مجاني: ماذا يعني ذلك عملياً

كلاهما مجاني بلا اشتراك ولا بطاقة دفع دولية ولا قيود توفر إقليمية — وهذه وحدها ميزة معتبرة للمستخدم العربي الذي يصطدم كثيراً بجدران الدفع والحظر الجغرافي في الخدمات السحابية. لكن «مجاني» لا تختصر القصة: نواة Ollama — سطر الأوامر والخادم — مفتوحة المصدر برخصة MIT، شيفرة تدقّقها وتعدّلها وتدمجها في منتجك بحرية. LM Studio مغلق المصدر، وإن صار مجانياً للاستخدام الشخصي والتجاري معاً منذ منتصف 2025 بعد إلغاء اشتراط الترخيص التجاري، بل إن أداة lms نفسها مرخّصة برخصة MIT. فإن كانت منشأتك تشترط شيفرة قابلة للتدقيق لأسباب امتثال أو أمن، فالكفة تميل لصالح Ollama قبل أي مقارنة تقنية.

وعلى صعيد المنصات: Ollama يعمل على الأنظمة الثلاثة (ويبقى على لينكس سطر أوامر)، بينما يشترط LM Studio على أجهزة ماك معالجات Apple Silicon وmacOS 14 فما فوق، ولا يدعم أجهزة Intel Mac إطلاقاً.

من التنزيل إلى أول استجابة: الأوامر كما تكتبها فعلاً

في Ollama تكفي دقائق: ollama pull لتنزيل نموذج من مكتبته، ثم ollama run للدردشة، وollama serve لتشغيل الخادم، وollama ps لمعرفة النماذج المحمّلة في الذاكرة الآن، وollama stop لتفريغ نموذج. والميزة الأقل شهرة أنك لست حبيس مكتبة Ollama: أي ملف GGUF على Hugging Face يعمل مباشرة بأمر مثل ollama run hf.co/bartowski/Llama-3.2-1B-Instruct-GGUF، ويختار تكميم Q4_K_M افتراضياً.

في LM Studio تتصفح النماذج من داخل الواجهة وتنزّلها بنقرة، لكن المسار البرمجي موجود أيضاً عبر lms: الأمر lms server start يشغّل الخادم، وlms load مع خيار --gpu=max يحمّل نموذجاً محدداً على كرت الشاشة، وlms ps يعرض المحمّل، وlms unload --all يفرّغ كل شيء، وlms get ينزّل النماذج من الطرفية. الفارق في التجربة الأولى صار صغيراً؛ الفوارق الكبيرة تأتي لاحقاً.

من يحمّل النموذج ومتى يفرّغه: فلسفتان لإدارة الذاكرة

القاعدة التقريبية للذاكرة واحدة عند الطرفين: بين 0.6 و0.7 غيغابايت لكل مليار معامل عند تكميم 4-بت، فنموذج 7B يحتاج إلى 4-5GB عند Q4، زائد هامش للسياق. وقبل أي شيء يحسم العتاد ما يمكنك تشغيله أصلاً؛ دليلنا عن متطلبات كرت الشاشة لتشغيل نموذج محلياً يفصّل الحسبة ومتى ينقذك التكميم. لكن ما بعد التحميل يختلف جذرياً.

Ollama يبقي النموذج محمّلاً 5 دقائق افتراضياً بعد آخر طلب ثم يفرّغه، وتضبط ذلك بمتغير البيئة OLLAMA_KEEP_ALIVE أو بحقل keep_alive في الطلب نفسه، وقيمة سالبة تعني بقاءً دائماً في الذاكرة. وللخوادم المزدحمة هناك OLLAMA_NUM_PARALLEL للطلبات المتوازية (قيمته الافتراضية 1) وOLLAMA_MAX_LOADED_MODELS لتحميل عدة نماذج معاً.

LM Studio يعمل بمنطق معاكس: النموذج المطلوب عبر API يُحمَّل عند أول طلب، ومهلة خموله الافتراضية 60 دقيقة تُضبط بحقل ttl أو بخيار lms load --ttl، أما المحمّل يدوياً من الواجهة فيبقى حتى تفرّغه بنفسك. وخاصية الإخلاء التلقائي المفعّلة افتراضياً تفرّغ النموذج السابق المحمَّل قبل تحميل الجديد، فلا تمتلئ الذاكرة خلسة.

وحين يرفض Ollama التحميل برسالة “model requires more system memory”، تذكّر أنه يقارن حاجة النموذج (الأوزان والسياق وهامش) بالذاكرة المتاحة حالياً لا المثبّتة في الجهاز؛ إغلاق بعض التطبيقات أو خفض طول السياق يحلّ المشكلة أحياناً دون ترقية عتاد.

القص الصامت: لماذا ينسى النموذج تعليماتك الأولى في Ollama

هذه أكثر مشكلة عملية يصطدم بها مستخدمو Ollama دون أن يدركوا سببها. حين يتجاوز مدخلك نافذة السياق المضبوطة، يقتطع Ollama بدايته بصمت تام: لا خطأ يصل للعميل، فقط سطر “truncating input prompt” في سجل الخادم لن تراه إلا إن بحثت عنه. العرض الظاهري أن «النموذج نسي التعليمات الأولى» أو تجاهل موجّه النظام، فتظن العيب في النموذج، والعيب في الإعداد.

الأدهى أن توثيق Ollama نفسه متضارب حول القيمة الافتراضية: مرجع Modelfile يقول 2048، والأسئلة الشائعة تقول 4096، وصفحة السياق تربط القيمة بذاكرة كرت الشاشة. فالأسلم ألا تثق بالافتراضي أبداً وأن تضبطه صراحة: متغير OLLAMA_CONTEXT_LENGTH عند تشغيل الخادم، أو معامل num_ctx في تعريف النموذج، أو /set parameter num_ctx 8192 داخل الجلسة التفاعلية. وانتبه لفخ إضافي: num_ctx ليس حقلاً قياسياً في مسار OpenAI المتوافق، فلا يمرَّر عبره — وهذا سبب شائع لتعثر أدوات الوكلاء التي تحشد سياقاً طويلاً ثم تنهار نتائجها مع Ollama تحديداً.

في LM Studio لا وجود لهذا الفخ: طول السياق معروض صراحة في إعدادات تحميل النموذج، وما تراه هو ما تحصل عليه.

Modelfile مقابل Presets: حفظ إعداداتك وإعادة استخدامها

يتيح Ollama تعريف نسخة مخصصة من أي نموذج بملف نصي أشبه بـ Dockerfile للنماذج:

FROM llama3.2
PARAMETER temperature 0.8
PARAMETER num_ctx 8192
SYSTEM "أنت مساعد تقني يجيب بالعربية الفصحى وبإيجاز."

ثم ollama create my-model -f Modelfile فيصبح لديك نموذج باسمك يحمل موجّه النظام والمعاملات معاً — بما فيها num_ctx، وهو ما يلتف على مشكلة مسار OpenAI السابقة. المقابل في LM Studio هو Presets: ملفات JSON مسماة تجمع موجّه النظام ومعاملات الاستدلال وتُشارك كملفات بين الأجهزة والزملاء، لكنها لا تشمل معاملات التحميل كطول السياق، فذاك يبقى في إعدادات تحميل النموذج.

سطر واحد يفصل بينهما في الكود

كلاهما يقدّم خادماً متوافقاً مع OpenAI API عبر المسار /v1: Ollama على المنفذ 11434 وLM Studio على 1234. بمكتبة openai في بايثون يصبح التبديل بينهما تغيير سطر واحد:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

للتحول إلى LM Studio يكفي جعل base_url يشير إلى http://localhost:1234/v1؛ فمفتاح ollama شكلي ومُتجاهَل، وLM Studio لا يطلب مفتاحاً أصلاً. وهذا التوافق يفتح الباب لكل النظام البيئي: إضافة Continue في VS Code تدعم الاثنين لمساعد برمجة محلي بالكامل، وOpen WebUI يتصل بـ Ollama مباشرة أو بـ LM Studio كمزوّد متوافق. وإن كنت تبني وكلاء يستهلكون هذه الخوادم، فدليلنا عن البرمجة بوكلاء الذكاء الاصطناعي: دليل الأدوات والمخاطر يغطي الطرف الآخر من المعادلة.

المحور	Ollama	LM Studio
الترخيص	النواة مفتوحة برخصة MIT	مغلق، مجاني شخصياً وتجارياً
الخادم	منفذ 11434، متوافق مع OpenAI عبر /v1	منفذ 1234، متوافق مع OpenAI عبر /v1
إدارة الذاكرة	تفريغ بعد 5 دقائق، keep_alive	تحميل عند الطلب، مهلة 60 دقيقة وإخلاء تلقائي
نافذة السياق	قصّ صامت، اضبطها يدوياً	معروضة صراحة عند التحميل
العتاد والمنصات	ويندوز وماك ولينكس؛ CUDA وROCm وMetal وVulkan	لا يدعم Intel Mac؛ يضيف MLX على Apple Silicon
المصادقة	لا توجد، احمِه بوكيل عكسي	رموز Bearer اختيارية، معطّلة افتراضياً

175 ألف خادم مكشوف: درس الأمن قبل فتح المنفذ

كلا الخادمين يستمع افتراضياً على 127.0.0.1 فقط، وهنا الأمان. لكن Ollama بلا أي مصادقة مدمجة، وضبط OLLAMA_HOST=0.0.0.0 — وهو أول نصيحة تجدها في المنتديات حين تريد الوصول من جهاز آخر — يكشف الخادم كاملاً لكل الشبكة. تقرير SentinelOne وCensys في يناير 2026 رصد نحو 175,000 خادم Ollama مكشوفاً على الإنترنت في 130 دولة، ونحو نصفها يدعم استدعاء الأدوات، ما يرفع الخطر من مجرد توليد نص على حسابك إلى تنفيذ عمليات فعلية. وثغرة Probllama التاريخية (CVE-2024-37032)، وهي اجتياز مسار في /api/pull كان يقود لتنفيذ كود عن بُعد وأُصلح خلال أيام في 2024، تلخّص الدرس: أي كشف خارجي يجب أن يمرّ عبر وكيل عكسي بمصادقة، لا عبر فتح المنفذ مباشرة. LM Studio يتقدّم خطوة هنا بإضافة رموز API اختيارية من إعدادات الخادم، لكنها معطّلة افتراضياً أيضاً، فالمسؤولية عليك في الحالتين.

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

ما استجدّ ويغيّر الحسابات القديمة

المستجدات الأخيرة تكسر ما تبقى من الصورة النمطية. LM Studio لم يعد «تطبيق سطح مكتب» فحسب: أضاف وضع خدمة يعمل عند إقلاع النظام، وأطلق llmster، نواة بلا واجهة لخوادم لينكس تُشغَّل بالأمر lms daemon up — أي أنه بدأ يزاحم Ollama في عقر داره. وفي المقابل، أضاف Ollama نماذج سحابية بلاحقة -cloud في وسم النموذج تتطلب تسجيل دخول، أي أنه لم يعد «محلياً صرفاً» بالكامل، وإن بقي الاستخدام المحلي الكامل متاحاً بلا حساب ولا اتصال. من يقارن اليوم بانطباعات 2024 يقارن أداتين لم تعودا موجودتين.

سؤال واحد يحسم الاختيار

اسأل نفسك: هل ستستخدم النموذج من تطبيق واحد على جهازك، أم ستجعله يخدم أدوات وسكربتات وخدمات أخرى؟ إن كانت الأولى فابدأ بـ LM Studio؛ واجهته تختصر عليك منحنى التعلم، وعرضه الصريح لطول السياق يجنّبك أغرب مشاكل التشغيل المحلي، وMLX يمنحك أفضل أداء على Apple Silicon. وإن كانت الثانية فـ Ollama هو المعيار الفعلي الذي تفترضه معظم الأدوات، برخصة مفتوحة ونشر سلس في الحاويات والخوادم — بشرط أن تضبط num_ctx صراحة ولا تفتح المنفذ للشبكة أبداً بلا حماية. ولا تعارض في الجمع: كثيرون يستكشفون النماذج ويقيّمونها في LM Studio ثم يشغّلون ما اختاروه عبر Ollama للأتمتة. وإن وجدت أن التشغيل المحلي كله لا يناسب حجم عملك بعد، فستجد البدائل السحابية مرتّبة بحسب طريقة عملك في أفضل أدوات البرمجة بالذكاء الاصطناعي 2026.