توصيات لتحسين الأداء وإدارة الذاكرة لبرنامج أولاما

  • تتمثل الأولوية في ضمان أن النماذج المستخدمة بشكل تفاعلي تتناسب بنسبة 100٪ مع ذاكرة الوصول العشوائي للفيديو لتجنب انخفاضات الأداء الكبيرة.
  • يؤثر كل من التحديد الكمي وطول السياق واختيار النموذج على كل من الجودة واستهلاك الذاكرة.
  • يعمل Ollama على تبسيط إدارة النماذج والموارد مقارنةً بـ llama.cpp، على حساب تحكم أقل دقة.
  • يُتيح إعداد الأجهزة المتوازن من حيث ذاكرة الوصول العشوائي للفيديو (VRAM) وذاكرة الوصول العشوائي (RAM) ووحدة المعالجة المركزية (CPU) والقرص الصلب إمكانية تقديم عرض SaaS خاص وسلس لأنظمة إدارة التعلم (LLMs).
Lorena Figueredo

15 دقيقة

توصيات لتحسين الأداء وإدارة الذاكرة لبرنامج أولاما

إذا كنت تفكر في إنشاء خدمة ماجستير القانون الخاصة مع أولاماسواء كان الأمر يتعلق بمزود خدمة الإنترنت الريفي الخاص بك، أو مركز بيانات صغير، أو جهاز كمبيوتر قوي في المنزل، فإن السؤال الكبير يبقى هو نفسه دائمًا: كيف تحصل على أقصى استفادة من أدائك دون إهدار المال على أجهزة لا تستخدمها؟

في عالم نماذج اللغة الكبيرة، ذاكرة الوصول العشوائي للفيديو (VRAM)، وذاكرة الوصول العشوائي (RAM)، ووحدة المعالجة المركزية (CPU)، ووحدة معالجة الرسومات (GPU هذه ليست مجرد مصطلحات تقنية، بل هي العناصر التي ستحدد مدى كفاءة نظام الحوسبة العنقودية لديك. علاوة على ذلك، يدير كل من Ollama و llama.cpp الذاكرة وتخصيص وحدة المعالجة المركزية/وحدة معالجة الرسومات بشكل مختلف، وفهم هذا الأمر أساسي لتحديد ما إذا كان استخدام عقدة كبيرة مزودة بوحدات معالجة رسومات متعددة أو عدة أجهزة أصغر حجماً (جهاز لكل عميل) أكثر فعالية من حيث التكلفة.

تجميع وحدات معالجة الرسومات في مجموعة أو تخصيصها بنسبة 1:1: ما هو الأفضل لشركة أولاما؟

عند التفكير في استخدام خدمة SaaS خاصة مع Ollama، فإن المعضلة الأولى هي ما إذا كان ينبغي إنشاء مجموعة وحدات معالجة الرسومات المركزية أو تخصيص جهاز (أو وحدة معالجة رسومية) لكل عميل. وهنا يبرز دور كيفية استخدام Ollama و llama.cpp للموارد:

  • عقدة "وحشية" مزودة بوحدات معالجة رسومية متعددة: مثالي إذا كنت تريد قوائم انتظار الطلبات المشتركة، للاستفادة الكاملة من وحدة معالجة الرسومات مع العديد من المستخدمين المتزامنين، ولتوحيد الإدارة والصيانة.
  • آلة واحدة لكل عميل: مزيد من العزلة، وتقليل متاعب تعدد المستأجرين، واستهلاك موارد يمكن التنبؤ به، ومناسب للغاية للعملاء الذين يدفعون ثمن "أجهزتهم".

أولاماما تركز حاليًا بشكل أكبر على الاستفادة من وحدة معالجة رسومات محلية واحدة أو أكثر لكل مثيل بدلاً من إدارة مجموعة موزعة من نوع Kubernetes مع موازنة دقيقة للأحمال بين الأجهزة. بالنسبة لمزود خدمة إنترنت صغير يرغب في خدمة "المستخدمين المتقدمين":

  • إذا كان الهدف هو سهولة التشغيلعادةً ما يكون الخيار الأكثر منطقية هو استخدام عدد قليل من الأجهزة ذات الحجم المناسب (16-24 جيجابايت من ذاكرة الوصول العشوائي للفيديو لكل منها) مع Ollama لكل عقدة وتوزيع العميل لكل خادم.
  • إذا كنت ترغب في لعب دور "مُوسِّع نطاق مصغر"، يمكنك أن تقترح خادم كبير مزود بوحدات معالجة رسومية متعددة ووكيل (أو عدة نسخ من Ollama/llama.cpp) لكل عميل، ولكن تعقيد الجدولة والعزل يزداد بشكل كبير.

العامل الحاسم ليس فقط البنية الطوبولوجية، بل ما هي النماذج التي ستخدمها، وفي أي سياق، وكم عدد الجلسات المتزامنة؟هذا يحدد بشكل مباشر مقدار ذاكرة الوصول العشوائي للفيديو (VRAM) التي تحتاجها لكل مستخدم.

كيف تدير أولاما الذاكرة، وذاكرة الوصول العشوائي للفيديو، ومشاركة وحدة المعالجة المركزية/وحدة معالجة الرسومات

يعتمد أولاما داخليًا على ملف llama.cpp وخلفيات أخرىلكنها تضيف طبقة من التنظيم تُسهّل حياتك بشكل كبير. وفيما يتعلق بالذاكرة والأداء، هناك عدة نقاط رئيسية:

رسم الخرائط النموذجية وتحميل الذاكرة

llama.cpp الولايات المتحدة الأمريكية mmap لربط ملف GGUF الخاص بالنموذج بمساحة العناوين. وهذا يسمح بـ يحدد نظام التشغيل الأجزاء الموجودة فعليًا في ذاكرة الوصول العشوائي (RAM). في كل لحظة، مما يقلل من وقت التحميل الأولي مقارنة بتحميل الملف بأكمله في الذاكرة دفعة واحدة.

أما أولاما، فهي مسؤولة عن:

  • تحميل وتنزيل النماذج من ذاكرة الوصول العشوائي للفيديو/ذاكرة الوصول العشوائي وفقًا للنشاط، مع مراعاة وقت أولاما_ابقوا_على_الحياة.
  • مشاركة النماذج بين جلسات نفس المثيل لـ تجنب عمليات إعادة الشحن غير الضرورية.
  • أظهر نفسك مع ollama ps استخدام الذاكرة، القسمة CPU / GPU وإذا كان هناك تفريغ للطبقات إلى المعالج.

عملياً، عندما ترى نموذجاً يحتوي على، على سبيل المثال، 18%/82% وحدة المعالجة المركزية/وحدة معالجة الرسوماتهذا يعني أن جزءًا من الطبقات لم يتناسب مع ذاكرة الوصول العشوائي للفيديو (VRAM) ويتم تنفيذه في ذاكرة الوصول العشوائي للنظام عبر وحدة المعالجة المركزية (CPU)، مع التأثير الناتج على السرعة، كما توضح العديد من الأمثلة. تحليل زمن الاستجابة في الشبكات المحلية.

ماذا يحدث إذا لم يتسع النموذج في ذاكرة الوصول العشوائي للفيديو (VRAM)؟

إليك أحد أهم الأسئلة: إذا تم تخزين نموذج بالكامل في ذاكرة الوصول العشوائي للفيديو (VRAM)، فستحصل على العائد المتوقع بنسبة 100%لكن عندما يتجاوز حجم النموذج سعة ذاكرة الفيديو المتاحة، يقوم برنامج Ollama بتوزيع الطبقات بين وحدة معالجة الرسومات ووحدة المعالجة المركزية. هل يتراجع الأداء بشكل متناسب مع عدد الطبقات التي يتم نقلها إلى ذاكرة الوصول العشوائي، أم أنه يقيدك تمامًا بسرعة ذاكرة الوصول العشوائي وناقل البيانات؟

بيانات عملية مع RTX 4080 16 جيجا بايت إنهم مدمرون:

  • نماذج 100% GPU: في حدود 60 إلى 140 رمزًا في الثانية (على سبيل المثال، gpt-oss:20b مع استخدام 14 جيجابايت يصل إلى ~140 رمزًا في الثانية).
  • 70-80% من وحدات معالجة الرسومات (الباقي في وحدة المعالجة المركزية): ينخفض ​​إلى ~19-50 توكو/ثانية.
  • نماذج تحتوي على حوالي 20% من وحدة معالجة الرسومات (في الغالب على وحدة المعالجة المركزية): تبقى عند ~12 tok/s (حالة gpt-oss: 120b، 66 جيجابايت من ذاكرة الوصول العشوائي + ذاكرة الوصول العشوائي للفيديو المستخدمة).

بمعنى آخر، الأمر لا يتعلق ببساطة بـ "أخسر 30% من الأداء لأن 30% منه يعتمد على وحدة المعالجة المركزية"، بل يؤدي زمن انتقال البيانات بين ذاكرة الوصول العشوائي (RAM) وذاكرة الوصول العشوائي للفيديو (VRAM) وتنفيذ الطبقات على وحدة المعالجة المركزية (CPU) إلى مضاعفة عنق الزجاجةيمكن أن يكون إعداد 20B الذي يعتمد كليًا على وحدة معالجة الرسومات أسرع بمقدار 10-11 مرة من إعداد 120B الذي يعتمد في الغالب على وحدة المعالجة المركزية.

إذن، بالنسبة لمجموعتك: الهدف الأول هو ملاءمة نماذج الاستخدام التفاعلي الحاسمة بالكامل في ذاكرة الوصول العشوائي للفيديو (VRAM).أي شيء لا يتناسب مع ذلك يُفضل تخصيصه للمهام الدفعية أو الليلية أو ذات الأولوية المنخفضة.

نماذج MoE (مزيج من الخبراء) وتفريغ وحدة المعالجة المركزية

نماذج النوع خليط من الخبراء (مثل GLM 4.7 Flash أو بعض إصدارات Qwen و DeepSeek) تحتوي على العديد من المعلمات الإجمالية، ولكنها لا تُفعّل سوى جزء من الخبراء لكل رمز مميز. وهذا، نظريًا، يمكن أن يساعد في السيناريوهات ذات ذاكرة الوصول العشوائي للفيديو المحدودة لأن لا تُستخدم جميع أجزاء النموذج في نفس الوقت..

عملياً، مع أولاما:

  • هامش ربح قدره 30 مليار - أ3 مليار (30 مليار إجمالي، 3 مليارات فعّالة) كـ glm-4.7-flash يتحرك بسرعة تتراوح بين 30 و35 توكو/ثانية مع تخفيف جزئي للحمل على وحدة المعالجة المركزية، وهو أمر محترم للغاية بالنسبة لحجمه.
  • لا تعوض ميزة MoE إذا استمر النموذج في تجاوز VRAM ويجبر العديد من الطبقات على الانتقال عبر الناقل.
  • لا يفهم أولاما نموذج MoE كشيء مميز على مستوى المجدول؛ فهو ببساطة يرى طبقات وذاكرة. تكمن روعة MoE في بنية النموذج، وليس في أولاما.

الاستنتاج العملي: تساعد وزارة التعليم، لكنها لا تصنع المعجزات.إذا تجاوزتَ حدّ ذاكرة الوصول العشوائي للفيديو (VRAM) بشكلٍ كبير، فستستمر في تحمّل تكاليف استخدام ذاكرة الوصول العشوائي (RAM) ووحدة المعالجة المركزية (CPU). من الأفضل استخدام تقنية MoE لتجاوز الحدود قليلاً، وليس لتبرير العمل دائمًا خارج نطاق ذاكرة الوصول العشوائي للفيديو.

مقارنة بين Llama.cpp و Ollama لتحقيق أقصى استفادة من جهازك

تبدأ العديد من المناقشات بالسؤال المعتاد: "لماذا نستخدم Ollama وليس llama.cpp مباشرة؟" من حيث الأداء وإدارة الذاكرة، يجدر التمييز بوضوح بين أدوار كل منهما.

llama.cpp: غرفة عمليات الموتر

llama.cpp هو محرك C++ عالي الأداءيهدف هذا النظام إلى استخلاص أقصى أداء ممكن من وحدة المعالجة المركزية ووحدة معالجة الرسومات، مع التركيز بشكل خاص على وحدات المعالجة المركزية x86 المزودة بتقنية AVX، ومعالجات Apple Silicon، ووحدات معالجة الرسومات NVIDIA/AMD. وهو مصمم خصيصًا لمن يرغبون في:

  • يعدل التكميم بالتفصيل (Q4_K_M، Q5_0، Q8_0، Q2_K…).
  • للتحكم عدد الطبقات في وحدة معالجة الرسومات مع --n-gpu-layers.
  • مقبض السياق، الدفعة، وعدد الخيوط، وقواعد GBNF، وغيرها من المعلمات الدقيقة.

مستوى منخفض، نعم، لكنه قوي للغاية. من حيث الذاكرة:

  • استخدم mmap لتحميل النموذج والسماح للنواة بتحديد ما يتم الاحتفاظ به في ذاكرة الوصول العشوائي (RAM).
  • يتيح لك ذلك اختيار الطبقات التي يتم تمريرها إلى وحدة معالجة الرسومات بدقة -ngl، وضبط استهلاك ذاكرة الوصول العشوائي للفيديو (VRAM) بدقة تصل إلى المليمتر.
  • INTEGRA K-Quants لتقليل الحجم بأقل تأثير ممكن على الجودة.

باختصار: ملف llama.cpp مثالي إذا كنت تريد قم ببناء خدمتك فائقة التحسين حيث يمكنك التحكم في كل معلمة ولا تمانع في التعامل مع خيارات سطر الأوامر والتكوين المتقدم.

أولاما: منسق الواجهة الخلفية

تم تطوير Ollama بلغة Go وتعتمد على llama.cpp (ومحركات أخرى مثل vLLM في بعض الحالات) كخادم خلفي لها. هدفها هو تزويدك بـ تجربة من نوع "Docker للعارضات":

  • واجهة سطر أوامر بسيطة: ollama pull, ollama run, ollama list, ollama ps.
  • REST API en 127.0.0.1:11434 بشكل افتراضي، يكون جاهزًا للاتصال بواجهات المستخدم الرسومية مثل Open WebUI أو تطبيقاتك الخاصة.
  • إدارة النماذج: قم بتنزيل نماذجك الخاصة من سجل النظام، أو تحديثها، أو تخزينها محليًا، أو نسخها ودفعها إلى النظام.
  • الكشف التلقائي عن الأجهزةيقوم بتحليل وحدة معالجة الرسومات (GPU) وذاكرة الوصول العشوائي (RAM) والسياق لضبط طبقات وحدة معالجة الرسومات/وحدة المعالجة المركزية (CPU) دون الحاجة إلى لمسها. --n-gpu-layers.

الفرق الحقيقي هو مستوى التجريدملف llama.cpp هو المحرك الأساسي، أما Ollama فهي السيارة الكاملة الجاهزة للقيادة. في مقابل تحكم أقل دقة، ستحصل على:

  • ابدأ تشغيل النماذج بأمر واحد.
  • قوائم الانتظار للطلبات والتنزيل التلقائي بعد فترة الخمول (أولاما_ابقوا_على_الحياة).
  • التكامل المباشر مع واجهات المستخدم الرسومية والأطر البرمجية.

للمستخدم النهائي أو لتقديم خدمة عامة لعملاء مزودي خدمة الإنترنت، أولاما هو الخيار الواضح عادةًبالنسبة للطرازات XXL الضيقة جدًا أو لتحقيق أقصى استفادة من وحدة معالجة الرسومات المحددة، يمكن أن يكون لملف llama.cpp ميزة طفيفة إذا كنت تعرف كيفية ضبطه جيدًا.

توصيات الأجهزة: ذاكرة الوصول العشوائي للفيديو (VRAM)، وذاكرة الوصول العشوائي (RAM)، ووحدة المعالجة المركزية (CPU)، والقرص الصلب لجهاز أولاما

توصيات لتحسين الأداء وإدارة الذاكرة لبرنامج أولاما

لتحديد حجم مجموعتك الحاسوبية، لا يكفي النظر إلى وحدة معالجة الرسومات فقط. التوازن بين ذاكرة الوصول العشوائي للفيديو، وذاكرة الوصول العشوائي، ووحدة المعالجة المركزية، والقرص، والسياق لديه قوة أكبر مما يبدو.

ذاكرة الوصول العشوائي للفيديو (VRAM): المورد الحرج

تُعدّ ذاكرة الوصول العشوائي للفيديو (VRAM) هي العائق الرئيسي. للاسترشاد فقط:

  • 8 GB VRAM: كافية للنماذج الكمية الصغيرة/المتوسطة (7 مليارات، وبعض 13 مليار في Q4_K_M مع سياق متواضع).
  • 16 GB VRAM: النقطة المثلى الحالية للاستخدام الجاد: 14B، 20B، 24B في Q4_K_M بالكامل على وحدة معالجة الرسومات مع ~16-32K سياق.
  • 24 جيجا او اكثر: ضروري إذا كنت تريد 30B-35B مع سياق GPU واسع أو للتعامل مع جلسات متزامنة متعددة من النماذج متوسطة الحجم دون البدء في تفريغ الطبقات.

بعض القيم العملية على بطاقة RTX 4080 بسعة 16 جيجابايت مع سياق ~19K وتكميم Q4_K_M:

  • gpt-oss:20b (20B): ~14 جيجابايت، 100% وحدة معالجة الرسومات، ~140 توك/ثانية.
  • qwen3:14b: ~12 جيجا بايت، 100% وحدة معالجة الرسومات، ~62 توك/ثانية.
  • ميسترال-3:14ب: ~13 جيجا بايت، 100% وحدة معالجة الرسومات، ~70 توك/ثانية.

أي نموذج يتجاوز هذه الحدود ينتهي به الأمر إلى دمج وحدة المعالجة المركزية ووحدة معالجة الرسومات. في مشروعك، إذا كنت ترغب في توفير سياق كبير، مثل 80-100 ألف، لعدة مستخدمين، كل قفزة في السياق تزيد أيضًا من الاستهلاك الفعلي لذاكرة الوصول العشوائي للفيديو (VRAM).لأن ذاكرة التخزين المؤقت KV تنمو.

ذاكرة الوصول العشوائي ووحدات المعالجة المركزية: أهم مما تبدو عليه

عندما يقوم نظام أولاما بتفريغ طبقات المعالجة إلى وحدة المعالجة المركزية، فإنك يصبح المعالج جزءًا من محرك الاستدلالفي الاختبارات التي أجريت باستخدام معالج i7-14700 (8P+12E) وذاكرة وصول عشوائي DDR5-6000 سعة 64 جيجابايت:

  • لا تزال النماذج التي تحتوي على طبقات وحدة المعالجة المركزية بنسبة 20-30% قابلة للاستخدام (~30-50 tok/s).
  • عندما ترتفع نسبة استخدام وحدة المعالجة المركزية إلى أكثر من 50%، تبدأ تجربة الدردشة في الشعور بالبطء، خاصة إذا كان السياق كبيرًا.

توصيات منطقية لعقدة الخدمة:

  • الحد الأدنى لذاكرة الوصول العشوائي (RAM) 16 جيجابايتمخصص فقط للعب باستخدام الضوء 7B و 13B.
  • يُوصى باستخدام ذاكرة وصول عشوائي (RAM) بسعة 32-64 جيجابايت: للاستخدام الجاد متعدد المستخدمين مع نماذج 14-24B وسياق واسع.
  • وحدة معالجة مركزية بثمانية أنوية على الأقل (أو مزيج P+E الحديث) لتخفيف تفريغ الطبقة دون انهيار العقدة، والنظر أيضًا في كيفية قم بتكوين ملفات تعريف الأداء في أنظمة ويندوز إن أمكن.

الألبوم: الفيل الصامت

ملفات النموذج كبيرة للغاية. يساعد التكميم، ولكن مع ذلك:

  • نماذج كمية صغيرة: ~2 جيجابايت.
  • نماذج الوسيط الكمي: 5-20 جيجابايت.
  • نماذج كبيرة: بسهولة 40-200 جيجابايت أو أكثر؛ هناك نقاط تفتيش تتجاوز 1 تيرابايت.

كقاعدة عامة سريعة، احجز دائمًا هامش لا يقل عن ضعفين إلى ثلاثة أضعاف حجم كل نموذج بين الملف الأساسي، والمتغيرات، وذاكرة التخزين المؤقت، والسجلات، ويقيّم خيارات التخزين المحلي مقابل السحابة الهجينةواستخدم NVMe SSD: أوقات تحميل mmap والترقيم تستفيد بشكل كبير من هذا.

التحديد الكمي والسياق واختيار النموذج: التأثير المباشر على الأداء

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

حجر رشيد التكميم

باختصار، يمكنك التفكير في هذه الاختلافات:

  • FP16نموذج ذو جودة عالية جدًا وحجم ضخم، يكاد يخلو من الضغط. يتطلب ذاكرة وصول عشوائي كبيرة (VRAM/RAM).
  • س 8_0ضغط لطيف، جودة مطابقة تقريبًا لـ FP16، ولكن لا يزال حجمًا كبيرًا.
  • س4_ك_مالمعيار "المتوازن" للاستخدام المحلي. قلل الحجم إلى النصف مع خسارة متوسطة في الدقة لا تتجاوز 1-2%. وهو الخيار الموصى به لمعظم عمليات النشر.
  • س2_ك: ضغط شديد، حجم صغير للغاية، لكن النموذج يصبح أقل موثوقية بشكل واضح، مع المزيد من الهلوسات.

عملياً، بالنسبة لخدمة SaaS محلية ذات عملاء متعددين، اختر طرازات Q4_K_M يُقدّم هذا الجهاز أفضل نسبة بين الجودة والأداء واستهلاك ذاكرة الفيديو. يُعدّ Q8_0 خيارًا مناسبًا إذا كنت تمتلك ذاكرة فيديو كبيرة وترغب في تحسين جودة الأداء قليلًا من جهاز صغير أو متوسط ​​الحجم.

طول السياق (num_ctx) وتكلفته الخفية

معامل num_ctx يُحدد ملف Ollama/llama.cpp عدد الرموز التي يمكن للنموذج "رؤيتها" في وقت واحد: النظام، وسجل المحادثات، والموجه الحالي، والاستجابة. على المستوى المفاهيمي:

  • النوافذ الصغيرة (2K-4K): ذاكرة أقل، سرعة أكبر، لكنك تفقد السياق في المحادثات الطويلة أو المستندات الكبيرة.
  • نوافذ متوسطة (8K-32K): نقطة وسطية معقولة لمعظم الاستخدامات الاحترافية.
  • النوافذ العملاقة (64K-128K+): مذهلة على الورق، لكنها تستهلك الكثير من ذاكرة الوصول العشوائي للفيديو وتؤدي إلى تدهور الأداء إذا كانت الأجهزة بالفعل عند حدودها القصوى.

علاوة على ذلك، إذا أجبرت عدد السياقات (num_ctx) أعلى من السياق الذي تم تدريب النموذج عليهقد تواجه سلوكًا غير معتاد وانخفاضًا في الجودة. لا يكفي مجرد زيادة القيمة في الإعدادات؛ فهناك حدٌّ معماري.

في حالتك، فإن التصرف المنطقي هو:

  • Ofrecer خطط "عادية" بسياق 8K-16Kوالتي تتناسب بشكل جيد مع ذاكرة الوصول العشوائي للفيديو (VRAM).
  • كتاب 64 ألف - 100 ألف سياق مخصص فقط للأجهزة أو وحدات معالجة الرسومات المتميزة، ويقبل انخفاض عدد الرموز المميزة في الثانية.

أفضل الممارسات لتحسين الأداء وإدارة الذاكرة باستخدام أولاما

إلى جانب الأجهزة، هناك العديد من قرارات التكوين والهندسة المعمارية التي يمكن أن تحدث فرقًا كبيرًا في ضمان تشغيل مجموعتك بسلاسة.

تأكد من أن النماذج الحيوية تعمل بنسبة 100% على وحدة معالجة الرسومات (GPU).

قبل تسليم نموذج للعميل، يُنصح باختباره والتحقق منه مع ollama ps ال يشير حقل المعالج إلى استخدام وحدة معالجة الرسومات بنسبة 100% أثناء الاستخدام. إذا رأيت تقسيمات بنسبة 60/40 بين وحدة المعالجة المركزية ووحدة معالجة الرسومات أو أسوأ من ذلك، فانقر على:

  • انتقل إلى تكميم أكثر عدوانية (على سبيل المثال، من Q8_0 إلى Q4_K_M).
  • استخدم نموذج أصغر (على سبيل المثال، 20B بدلاً من 35B).
  • الحد num_ctx إذا كان بإمكان العميل أن يتعايش مع سياق أصغر نوعاً ما.

يُفضّل استخدام خادم 20B مضبوط جيداً بسرعة 140 توكو/ثانية على خادم 120B بطيء بسرعة 12 توكو/ثانية في المحادثات التفاعلية. يُقدّر المستخدمون الخيار الأخير أكثر بكثير. مرونة التجربة أن التحسن الافتراضي في الجودة سيكون من الصعب إدراكه.

اضبط OLLAMA_KEEP_ALIVE واستراتيجية النموذج المحمّل

معامل أولاما_ابقوا_على_الحياة يُحدد هذا الخيار المدة التي يحتفظ فيها نظام أولاما بالنموذج في الذاكرة بعد آخر طلب. القيم الممكنة:

  • 0يتم التنزيل فور اكتمال الاستجابة. هذا يوفر الذاكرة، ولكنه يؤدي إلى أوقات تحميل أطول.
  • X متر (مثال: 5 دقائق، 15 دقيقة): يوازن بين ذاكرة الوصول العشوائي/ذاكرة الفيديو وسرعة الاستجابة. مثالي للخدمات التي تشهد ارتفاعات مفاجئة في الاستخدام.
  • -1يبقى النموذج مُحمّلاً أثناء تشغيل الخدمة. مفيد للغاية لنماذج SaaS الرئيسية الخاصة بك.

في سيناريو متعدد المستخدمين، عادةً ما يكون من الجيد الحفاظ على يتم تحميل نموذج أو نموذجين أساسيين دائمًا (على سبيل المثال، برنامج عام 14B وبرنامج متخصص) وتنزيل الباقي بعد بضع دقائق من عدم النشاط.

التحكم في متغيرات البيئة ومسارات النموذج

تتيح لك Ollama تعديل سلوكها باستخدام متغيرات بيئية متنوعة تؤثر على كيفية إدارة الموارد والوصول إليها:

  • نماذج الفرنالمسار الذي تُخزَّن فيه النماذج. مفيد لإرسالها إلى قرص صلب/SSD مخصص ذي سعة تخزينية أعلى.
  • أولاما_هوستواجهة برمجة التطبيقات (API) والمنفذ (الافتراضي 127.0.0.1:11434). إذا قمتَ بعرضها على الشبكة المحلية، فقم بتقييد الوصول إليها باستخدام جدار الحماية.
  • أولاما_الأصول: CORS لواجهات المستخدم الرسومية الخارجية على الويب (Open WebUI، واللوحات المخصصة، وما إلى ذلك).
  • OLLAMA_DEBUG: وضع التصحيح لعرض سجلات مفصلة لتحميل النموذج، واكتشاف وحدة معالجة الرسومات، وأخطاء CUDA/ROCm، وما إلى ذلك.

في نظام لينكس، يتم عادةً ضبط هذه المعلمات باستخدام سيستم دي (مع systemctl edit ollama.service)، بينما في نظامي التشغيل ويندوز وماك أو إس يتم تعيينها كمتغيرات بيئة النظام أو المستخدم.

المراقبة والسجلات

في نظام المجموعة، تحتاج إلى فهم واضح لما يحدث على كل عقدة. وللقيام بذلك:

  • على نظام لينكس، استخدم journalctl -u ollama لمراقبة سجلات الخدمة. مع -f يمكنك رؤيتها في الوقت الفعلي.
  • تكمل مع nvidia-smi أو ما يعادلها في AMD لعرض ذاكرة الوصول العشوائي للفيديو (VRAM) وحمل وحدة معالجة الرسومات (GPU) واستهلاك الطاقة.
  • قم بدمج المقاييس (الرموز المميزة/ثانية، قوائم الانتظار، الأخطاء) في مجموعة أدوات المراقبة الخاصة بك إذا كنت جادًا بشأن SaaS.

إن اكتشاف أن النموذج يعمل بشكل أساسي على وحدة المعالجة المركزية، أو أن قوائم الانتظار عالقة، في وقت مبكر، يوفر عليك الكثير من المشاكل مع العملاء؛ وأدوات لـ اكتشف عنوان IP على شبكتك المحلية بإمكانهم المساعدة في جرد العقد.

اختيار النماذج وحالات الاستخدام النموذجية في أولاما

مع كل ما سبق، فإن الركن الآخر للأداء هو اختر النموذج المناسب لكل مهمةليس فقط "للانطلاق بأقصى سرعة" ولكن أيضًا للتحكم في الاستهلاك وزمن الاستجابة.

قوالب للدردشة العامة والمساعدين

للمحادثات، والدعم، وكتابة البريد الإلكتروني، والملخصات، والمهام العامة، قوالب مثل:

  • كوين 3 14 بتتبع ممتاز للتعليمات وسرعة جيدة عند استخدام وحدة معالجة الرسومات بنسبة 100%.
  • ميسترال 3 14بمتوازنة للغاية من حيث جودة اللغة والأداء.
  • جيما ولاما 3.x في تكوينات 7-14B: خيارات عامة جيدة للمستخدمين الأقل تطلبًا أو للأجهزة الأساسية.

مع هذه العائلات في سياق Q4_K_M و 8K-16K، لديك أساس متين للغالبية العظمى من المستخدمين المحترفين دون تشبع ذاكرة الوصول العشوائي للفيديو (VRAM).

نماذج للبرمجة والتطوير

بالنسبة لمهام توليد التعليمات البرمجية ومراجعتها وتطويرها، يُنصح باختيار نماذج محددة:

  • qwen3-coder:30b: قوي في البرمجة والأدوات، على الرغم من أن جزءًا من النموذج ينتهي به المطاف في وحدة المعالجة المركزية مع ذاكرة وصول عشوائي للفيديو بسعة 16 جيجابايت.
  • مبرمج DeepSeek، CodeLlama وهناك متغيرات أخرى للرموز لأحجام أصغر، إذا كنت تريد المزيد من الخفة.

إذا كنت ستقدم "خططًا للمطورين"، ففكر في عقدة مع أكثر من 16 جيجابايت من ذاكرة الوصول العشوائي للفيديو لاستيعاب هذه النماذج دون التسبب في تحميل كبير جدًا على وحدة المعالجة المركزية.

النماذج متعددة الوسائط والرؤية

بالنسبة للمهام التي تجمع بين النصوص والصور (تحليل لقطات الشاشة، والمستندات الممسوحة ضوئيًا، وما إلى ذلك)، النماذج المصنفة الرؤية (لافا، مون دريم، باكلافا، كوين-فل...) هي التي يجب عليك تجميعها. هنا:

  • يزداد استهلاك ذاكرة الوصول العشوائي للفيديو (VRAM) وعادة ما تكون سرعة الرمز المميز أقل.
  • من المستحسن حصرها في مهام محددة وعدم خلطها بمحادثات مكثفة تضم العديد من المستخدمين.

إذا كان لديك مجموعة وحدات معالجة رسومات مختلطة (على سبيل المثال 5070 + 5060 + 4060، بإجمالي 48 جيجابايت من ذاكرة الوصول العشوائي للفيديو)، فقد يكون من المثير للاهتمام تخصيص إحدى البطاقات لنماذج الرؤية وأخرى للنصوص فقط، لتجنب تحميل جهاز واحد بكل شيء.

أنواع التثبيت والنشر والتنفيذ (أصلي، دوكر، حاويات)

على المستوى التشغيلي، يمكن تثبيت Ollama بعدة طرق: بشكل أصلي على أنظمة Windows أو macOS أو Linux، أو في حاويات (Podman، Docker ...).

على سبيل المثال، في نظام لينكس، يمكنك نشر ملف llama.cpp في حاوية مُحسَّنة لوحدة معالجة الرسومات (GPU):


Description=llama
After=network-online.target


Image=ghcr.io/ggml-org/llama.cpp:server-cuda
ContainerName=llama
PublishPort=8000:8000
AddDevice=nvidia.com/gpu=all
Environment=NVIDIA_DRIVER_CAPABILITIES=all
Environment=NVIDIA_VISIBLE_DEVICES=all

Exec=--host 0.0.0.0 \
     --port ${PORT} \
     -m ${MODEL_PATH} \
     -ngl ${NGL} \
     -c ${CONTEXT_SIZE} \
     --flash-attn on \
     --batch-size ${BATCH}

Volume=/data/models:/models:Z
Network=llama.network


Restart=always
Environment=PORT=8000
Environment=MODEL_PATH=/models/gemma-4-E4B-it-Q8_0.gguf
Environment=NGL=99
Environment=CONTEXT_SIZE=128000
Environment=BATCH=512


WantedBy=default.target

يتيح لك هذا النوع من النشر افصل Ollama و llama.cpp والأدوات الأخرى في الحاويات، تحكم في الإصدارات واعزل الموارد حسب الخدمة (وإذا أردت، حسب العميل).

لإدارة نماذج Hugging Face في GGUF أو Safetensors، يمكنك استخدام أدوات مثل برنامج تنزيل Rust-HF ثم استوردها إلى أولاما باستخدام ملفات النماذجحيث تقوم بتحديد FROM وTEMPLATE والمعلمات الافتراضية ونظام المطالبة، بالإضافة إلى الصيانة المزامنة والنسخ الاحتياطية المحلية من القطع الأثرية إذا كنت تعمل مع عقد متعددة.

بمجرد تجميع الأجزاء، فإن الباقي يتعلق بقرارات الحوكمة: ما هي النماذج التي تقدمها لأي عملاء، وما هي حدود السياق، وما هي السياسة المتبعة للتحديثات والقياسات الكمية حتى لا تكسر التوافق أو الأداء المتوقع.

إذا كنت متأكدًا من أن الأولوية هي أن تتناسب النماذج تمامًا مع ذاكرة الوصول العشوائي للفيديو (VRAM)، وأن يظل التكميم عند مستوى معقول (Q4_K_M)، وألا يتجاوز السياق ما يمكن أن يتحمله جهازك، فإن إعداد خدمة البرمجيات كخدمة (SaaS) الخاصة بشركة أولاما على مجموعة متوسطة الحجم لم يعد الأمر مجرد خيال علمي، بل أصبح استثمارًا معقولًا: فأنت تدفع مقابل وحدات معالجة الرسومات حيث تساهم بالفعل، وتهتم بذاكرة الوصول العشوائي لدعم عمليات التنزيل العرضية، وتستخدم أدوات التنسيق (Ollama، llama.cpp، الحاويات، Open WebUI) لمنح عملائك تجربة "ChatGPT خاص" ولكن بقواعدك الخاصة ودون الاعتماد على السحابة.

التدقيق السنوي لجهاز الكمبيوتر المنزلي
المادة ذات الصلة:
لوحة بيانات القياس عن بُعد للحاسوب المحلي بدون استخدام السحابة: دليل شامل