معظم النقاش حول LLMs المحلية في 2026 يدور حول تشغيلها لأغراض chat — بديل خصوصية لمساعدات السحابة. حالة استخدام جيّدة. ليست التي شكّلت هندستي في السنة الماضية. مجموعة LLM المحلية الخاصة بي — Ollama + llama.cpp + vLLM + Open WebUI
- بضعة أجزاء داعمة — مُوصَلة بـpipeline هندستي الفعلية، بجانب Postgres وRedis، تُنجز عملاً حقيقياً على مهام حقيقية كانت ستكلّف رصيد API أو لا تكلّف شيئاً لكن تُشحَن بجودة أدنى.
شكل المجموعة
المعمارية أقل غرابة مما تبدو:
- Ollama هو المحرّك اليومي. يعمل على GPU الخاصة بـhomelab، يكشف API متوافق مع OpenAI، ويخدم كل استدلال موجَّه محلياً أجريه أثناء البرمجة والكتابة النصية. تُسحَب النماذج عند الطلب؛ حفنة تبقى ساخنة. الواجهة بسيطة لدرجة أن معظم تكاملات أدواتي تتعامل معها كـ”endpoint OpenAI آخر، بـbase URL مختلف.”
- llama.cpp هو بديل فئة المعالج. حين أكون على laptop بلا وصول GPU، أو حين أريد تشغيل نموذج صغير لمهمة نصّية حيث latency مقبولة، يُشغّله llama.cpp. التداخل مع Ollama عمدي — llama.cpp ذو مستوى أدنى، وأستخدمه حين أريد تحكّماً دقيقاً في التحجيم (quantisation)، طول السياق، أو معاملات أخذ العينات.
- vLLM هو طبقة الخدمة لأي شيء يريد إنتاجية حقيقية. مهام الاستدلال الدفعي، تشغيلات التقييم، توليد بيانات اصطناعية للاختبارات — يُنجزها vLLM بجزء من وقت الحائط الذي يأخذه Ollama، لأن هذا ما حُسِّن من أجله.
- Open WebUI هو السطح البشري. حين أريد الدردشة مع نموذج محلي، مقارنة مخرجات جنباً إلى جنب، أو إجراء محادثة متعدّدة الأدوار غير رسمية جداً للنصوص البرمجية، هناك أذهب.
- LM Studio وJan يملأان فجوات مماثلة أحياناً؛ أُبقيهما مثبّتَين لكن أستخدمهما أقل من ما سبق.
كل شيء يجلس على جهاز homelab بـGPU تكلّف أقل من شهر من إنفاق API. الاقتصاديات تتقاطع بسرعة حين تُشغّل حجم استدلال حقيقياً.
ما أستخدمه فعلاً من أجله
المهام التي كسبت موضعاً دائماً في المجموعة المحلية، بترتيب تقريبي لمدى تكرارها:
1. مراجعة ما قبل الـcommit
قبل أي commit جوهري، يُشغّل نموذج محلي مراجعة منظّمة: “اقرأ الـdiff، اذكر أي شيء يبدو غريباً، صنّف حسب الخطورة.” الهدف ليس استبدال المراجعة — إنه مسك الأشياء الواضحة قبل فتح الـPR، كي لا تُنفق مراجعة الإنسان على أخطاء أسلوبية أو معالجة أخطاء مفقودة. تشغيل هذا محلياً مجّاني؛ تشغيله على API سحابي لكل commit سيكون مكلفاً وأبطأ.
2. بيانات اصطناعية للاختبارات
كثيراً ما تحتاج اختبارات الوحدات حمولات مخترَعة: سجلات مستخدمين، كتالوجات منتجات، سطور سجل، أشكال events. نموذج محلي يولّدها برخص، بشكل محدّد مع seed، ودون إرسال بيانات إلى خدمة طرف ثالث. أحتفظ بنصوص seed في شجرة الاختبار بجانب fixtures التي تُنتجها.
3. شرح الكود
حين أستكشف codebase غير مألوف — مشروع OSS لشخص آخر، إطار جديد — يُعطيني نموذج محلي مراجعة أولى لـ”ما الذي يفعله هذا الملف، بلغة بسيطة.” ليست موثوقة؛ إنها خريطة بداية. ثم أقرأ الكود وأُصحّح نموذجي الذهني حيث أخطأ LLM. المزيج أسرع من أيٍّ منهما منفرداً.
4. مسوّدات التوثيق
كتابة README، دليل تشغيل، أو دراسة حالة بعد حادثة تبدأ عادةً بـprompt منظّم وتوليد مسوّدة أولى، ثم تحرير بشري كبير. النموذج المحلي يتجاوز بي مشكلة الصفحة الفارغة في ثوانٍ؛ التحرير هو حيث أكسب التوقيع. هذا المنشور بدأ بهذه الطريقة.
5. تقطير البحث
أُغذّي النموذج مجموعة من الإشارات المرجعية أو الروابط وأطلب تركيباً. التركيب نادراً ما يكون جيّداً بما يكفي للتصرّف بناءً عليه مباشرةً — لكنه كثيراً ما يكون جيّداً بما يكفي لمعرفة أي ثلاثة روابط تستحق القراءة الكاملة. هذه أرخص أداة لإعطاء أولوية البحث عندي على الإطلاق.
ما لا يفعله بشكل جيّد
بعض الفئات حيث النماذج المحلية ما زالت تخسر أمام نماذج سحابة الحدود، والفارق ليس قريباً:
- مهام الاستدلال طويل الأفق. النماذج الحدودية الأكبر أفضل حقاً في الحفاظ على خطّة معقّدة متعدّدة الخطوات. النماذج المحلية +70B يمكنها التقريب؛ النماذج المحلية 30B لا تستطيع فعلاً.
- الكتابة بلغات متعدّدة بصوت متسق. النماذج المحلية تميل إلى تسطيح الصوت عبر الترجمات. نماذج السحابة الرائدة تحفظه بشكل أفضل. (هذا مهمّ جداً للنسخة الثلاثية اللغات من هذا الموقع بالذات.)
- توليد الكود على أطر غير مألوفة. النماذج الحدودية رأت المزيد من ذيل التوزيع الطويل. النماذج المحلية المدرَّبة على لقطات أقدم قد تتعثّر مثلاً على اتفاقيات Astro 6.
الانقسام الصحيح هو: استخدم المجموعة المحلية للمهام عالية الحجم وقصيرة الأفق والحساسة للتكلفة. استخدم API الحدودي للعمق والجِدّة. معظم الفِرق الهندسية في 2026 تُشغّل أحدهما أو الآخر. تشغيل كليهما، بتعمّد، بالانقسام الصحيح، هو الإطلاق الحقيقي.
حساب التكلفة
شهر تقريبي من استخدامي:
- الاستدلال المحلي: آلاف الطلبات. تكلفة الكهرباء: تافهة. استهلاك GPU: مهمّ لكن مُستهلَك على مدى عام أو أكثر.
- API الحدودي السحابي: عشرات إلى مئات الطلبات، معظمها “الصعبة حقاً.” التكلفة: مهمّة لكن محدودة.
بدون المجموعة المحلية، إنفاق السحابة سيكون 10–30× أعلى. معها، إنفاق السحابة على أشياء ذاك الإنفاق يكسب ثمنه بوضوح. هذا نوع النمط ثنائي الطبقة الذي سيبدو واضحاً بأثر رجعي وتتجاهله الآن معظم الفِرق.
الربط بـFulcrum
جزء لا بأس به من استخدامي للمجموعة المحلية يعمل عبر لوحة التحكّم الخاصة بالوكلاء (Fulcrum). تشغيلات الوكلاء التي تحتاج تغذية راجعة سريعة تُوجَّه إلى نماذج محلية؛ تلك التي تحتاج عمقاً تُوجَّه إلى السحابة. سياسة التوجيه في لوحة التحكّم، لا في الأدوات الفردية — مما يعني أن سؤال “أي نموذج؟” يُحَل مرة، بالإعداد، لا إعادة تعلّمه لكل مهمّة.
إن كنتَ تُعدّ مجموعتك المحلية في 2026، الشيء الذي تبني أولاً ليس طبقة الاستدلال — تلك سهلة، Ollama يتولّاها. ابنِ طبقة التوجيه: الشيء الذي يقرّر، لكل مهمّة، أي نموذج يُستدعى. هناك يعيش الانضباط الهندسي. هناك تأتي وفورات التكلفة بعامل 10×. هناك الشيء الذي لم يتحدّث عنه أحد بعد، وهو الشيء الذي سيهمّ أكثر بعد 18 شهراً.