مقارنة Ollama وvLLM: من التشغيل المحلي إلى الخادم المشترك
مقارنة Ollama وvLLM لاختيار محرك تشغيل النماذج حسب عدد الطلبات وذاكرة GPU وحجم النموذج، مع توضيح التثبيت والتكميم وتوافق API وتكاليف الانتقال والتشغيل.
نُشر في

تبدأ مقارنة Ollama وvLLM بسؤال بسيط: هل يقضي جهازك معظم وقته في انتظار المستخدمين، أم يقضي المستخدمون وقتهم في انتظاره؟ ابدأ بـ Ollama إذا كنت تستخدم جهازا واحدا ويصل إليه عدد قليل من المستخدمين بين حين وآخر. واختر vLLM عندما تتداخل الطلبات، وتصبح قدرة الخدمة على إنجازها وزمن الاستجابة هما التحدي. رسوم البرنامج عند الاستضافة الذاتية هي $0 لكليهما؛ وما يختلف فعليا هو تكلفة العتاد والجهد التشغيلي.
مقارنة Ollama وvLLM: أيهما تختار؟
احتفظ بـ Ollama للحاسوب المحمول أو المساعد الخاص أو الخدمة الداخلية الصغيرة التي تستجيب بالفعل بالسرعة المطلوبة. واختر vLLM لخدمة مشتركة تعمل على GPU وتتلقى طلبات متداخلة باستمرار، أو عندما تحتاج إلى تحكم صريح في الاستدلال الموزع. مجرد نقل الخدمة إلى جهاز يحمل اسم خادم لا يبرر تغيير المحرك.
يجمع Ollama تنزيل النماذج وإعدادها وإتاحتها عبر خادم في مسار عمل بسيط. أما vLLM فهو محرك استدلال صمم لجدولة طلبات كثيرة وإدارة ذاكرة العمل التي تحتاجها. ولا يمثل أي منهما النموذج نفسه: نقل التطبيق بينهما يغير طريقة تشغيل نموذجه.
يتوقف الاختيار على أربعة أمور: ذروة الطلبات المتزامنة، وذاكرة GPU المتاحة، وملفات النموذج المحددة التي ستشغلها، وزمن الاستجابة الذي تلتزم به أمام المستخدمين. عدد المستخدمين المسجلين لا يعبر عن ذلك بدقة. فقد يولد فريق برمجة صغير يستخدم وكلاء برمجيين طلبات متداخلة أكثر من مجموعة أكبر بكثير تطرح أسئلة متفرقة.
جرى التحقق من تكلفة البرنامج والوثائق في 12 أكتوبر 2026. تستند هذه المقارنة إلى الوثائق وتحليل تكلفة مفصل بالحسابات؛ ولم نجر اختبار أداء للاستدلال من أجل هذا المقال. تتضمن صفحة أسعار Ollama الحالية استخداما محليا مجانيا، ويتيح ترخيص مشروع vLLM استخدامه من دون رسوم للبرنامج. أسعار Ollama، ترخيص vLLM.
تستند صفوف الميزات إلى وثائق التزامن الرسمية في Ollama، ونظرة عامة على ميزات vLLM، ودليل التوسع في vLLM. أما تحديد الأنسب فهو تقدير تحريري لهذه القدرات الموثقة، وليس ترتيبا مبنيا على قياسات السرعة.
حدد اختيارك وفق المستخدمين ووحدات GPU وحجم النموذج
استخدم الحالات التالية لتحديد الخيار الذي تبدأ بتقييمه، لا بوصفها ضمانا للسعة. المقصود بـ«المستخدمين» هنا أشخاص أو وكلاء يولدون أعمالا متداخلة؛ والنطاقات أمثلة للتخطيط. يضم نموذج 8B نحو ثمانية مليارات معلمة، وهي القيم الرقمية المخزنة التي تحدد النموذج.
لا يكفي حجم النموذج وحده لاتخاذ قرار شراء GPU. الحد الأدنى النظري لذاكرة الأوزان وحدها في نموذج كثيف بحجم 8B وبدقة 4 بت لكل وزن هو 4 GB؛ أما نموذج 70B فحده الأدنى 35 GB. تحسب هذه القيمة بضرب عدد المعلمات × عدد البتات ÷ 8، باستخدام البايتات بالنظام العشري. وتضاف إليها بيانات التكميم الوصفية، والموترات ذات الدقة الأعلى، وبيئة التشغيل، وذاكرة المحادثات. ولا يمثل أي من الرقمين توصية بحجم VRAM المطلوب.
لهذا لا يكفي أن تقول «تم تحميل النموذج» للحكم على صلاحية النظام. فقد تتسع ذاكرة الجهاز للأوزان، ولا يبقى فيها ما يكفي للمحادثات المفتوحة لدى المستخدمين. اختر أولا نسخة النموذج بالاستعانة بـدليل نماذج البرمجة المحلية، ثم حدد الموارد اللازمة لحمل الخدمة.
التثبيت والعتاد: Ollama أسهل للبدء على جهازك الأول
يتفوق Ollama عندما تكون المهمة العاجلة تشغيل نموذج مفيد على العتاد الذي تملكه بالفعل. فتطبيقاته المكتبية ومسار العمل عبر سطر الأوامر يقللان قرارات الإعداد التي تحتاج إلى اتخاذها. على Linux، طريقة التثبيت الواردة في الوثائق هي:
curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.2استخدم ollama serve إذا لم يكن الخادم يعمل بالفعل. ويوضح دليل Linux أيضا طريقة تشغيله كخدمة عند بدء النظام؛ فخدمة دائمة أنسب من إبقاء نافذة الطرفية مفتوحة لتلقي طلبات الآخرين.
يدعم Ollama التسريع بوحدات GPU من Apple عبر Metal، وبعض عتاد AMD عبر ROCm، ووحدات GPU من NVIDIA، وأجهزة إضافية على Windows/Linux عبر Vulkan. وتحدد صفحته الخاصة بـ NVIDIA حاليا قدرة حوسبة 5.0 أو أعلى، مع متطلبات للتعريفات تختلف للبطاقات الأقدم. تحقق من البطاقة ونظام التشغيل تحديدا في قائمة العتاد الذي يدعمه Ollama.
يتفوق vLLM عندما يكون التثبيت بداية لبيئة خدمة تتولى إدارتها وتشغيلها. يستخدم دليل البدء السريع الحالي لـ NVIDIA بيئة Python معزولة. بعد تثبيت uv وتوفير تعريف متوافق لوحدة GPU، يكون تسلسل التثبيت الموثق كما يلي:
uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=autoهذه أوامر إعداد مأخوذة من الوثائق، ولم ننفذها ضمن هذه المقارنة. أما تثبيتات AMD وIntel فلها تعليمات مختلفة لمحرك التنفيذ. دليل البدء السريع لـ vLLM.
يشترط مسار تثبيت vLLM على NVIDIA نظام Linux وقدرة حوسبة 7.5 أو أعلى. ولا يدعم هذا المسار التشغيل المباشر على Windows؛ إذ توجه الوثائق مستخدمي Windows إلى WSL. وليست NVIDIA خيار العتاد الوحيد: ففهرس التثبيت يشمل أيضا AMD ROCm وIntel XPU ومسارات CPU، وكذلك Apple Silicon عبر إضافة vLLM-Metal التي يتولى المجتمع صيانتها. متطلبات GPU، فهرس التثبيت.
يعتمد مسار Apple على MLX ونماذج محسنة له. لذلك ينبغي تقييمه بوصفه محرك تنفيذ مستقلا، دون افتراض أنه يتصرف كخادم CUDA. وإذا كان Mac محور عملك، يظل Ollama نقطة البداية الأبسط التي نوصي بها. أما إذا كان القرار يتعلق أساسا ببيئة العمل المكتبية، فراجع مقارنة Ollama وLM Studio المنفصلة.
أداء vLLM مقابل Ollama: التزامن هو العامل الحاسم
يمثل vLLM الخيار المبدئي الأقوى عند استمرار الطلبات المتزامنة، لأن ميزات الجدولة الموثقة فيه تعالج هذا النوع من الأحمال مباشرة. معدل الإنجاز هو إجمالي العمل المكتمل خلال فترة زمنية، وهو يختلف عن سرعة ظهور إجابة لطلب منفرد.
تشمل ميزات vLLM التجميع المستمر، الذي يضم أعمالا جديدة مع تقدم الطلبات الجارية، وPagedAttention لإدارة ذاكرة المفاتيح والقيم المستخدمة أثناء توليد النص. وتعرف هذه الذاكرة عادة باسم KV cache؛ وهي ذاكرة عمل النموذج لوحدات النص، أو التوكنات، في المحادثة. نظرة عامة على ميزات vLLM.
تجزئة المعالجة الأولية للموجه، المعروفة بـ chunked prefill، تقسم قراءة الموجه الطويل إلى أجزاء أصغر، يمكن جدولتها بالتوازي مع استمرار توليد الإجابات. أما التخزين المؤقت للبادئات فيعيد استخدام المعالجة السابقة عندما تتطابق بدايات الموجهات، كما في موجه نظام يتكرر. وهو يختصر معالجة الموجه، لكنه لا يلغي العمل اللازم لتوليد توكنات الإجابة الجديدة. الجدولة والضبط، حدود التخزين المؤقت للبادئات.
Ollama يدعم الطلبات المتوازية بالفعل
توثق Ollama دعم الطلبات المتوازية لكل نموذج وتحميل عدة نماذج في الوقت نفسه، ضمن حدود الذاكرة. يتحكم OLLAMA_NUM_PARALLEL في الأولى، وOLLAMA_MAX_LOADED_MODELS في الثانية. ويضع OLLAMA_MAX_QUEUE حدا للعمل المنتظر، وقد يعيد الخادم المثقل بالطلبات الرمز HTTP 503. وتسرد الأسئلة الشائعة الحالية قيمة افتراضية للطلبات المتوازية قدرها 1. إعدادات التزامن في Ollama.
قد تكفي زيادة عدد الطلبات المتداخلة المسموح بها لمساعد دعم صغير. لكن إطالة قائمة الانتظار لا تضيف قدرة حوسبية؛ وقد تعني فقط أن العملاء سينتظرون أطول قبل وصول أول توكن. اضبط النظام لتحقيق زمن الاستجابة المطلوب، لا للوصول إلى أطول قائمة انتظار يقبلها الخادم.
قد يستهلك السياق الذاكرة التي خصصتها لاستيعاب المستخدمين
حدد طول السياق صراحة قبل مقارنة المحركين. تصف صفحة السياق المخصصة في Ollama قيما افتراضية تعتمد على الذاكرة، بينما لا تزال صفحة الأسئلة الشائعة تذكر قيمة افتراضية ثابتة. وهذا التعارض في الوثائق سبب إضافي لفحص الإعدادات الفعلية، بدلا من افتراض تطابقها بين الحاسوب المحمول والخادم. يعرض ollama ps السياق المحمل وتوزيع التشغيل بين CPU وGPU. إرشادات السياق في Ollama.
في إعداد توضيحي، تحجز أربع محادثات متوازية، طول كل منها 8,192 توكنا، سعة إجمالية تبلغ 32,768 توكن سياق. وبالمقارنة مع محادثة واحدة بطول 4,096، فهذه ثمانية أمثال السعة الإجمالية للسياق، وليست ثمانية أمثال إجمالي RAM للعملية. أوزان النموذج وتخصيصات الذاكرة الأخرى لا تتوسع بالطريقة نفسها. وتشرح وثائق التزامن في Ollama هذا الأثر المضاعف للسياق.

يصطدم vLLM أيضا بحدود الذاكرة. يحذر دليل الضبط فيه من أن نقص مساحة KV قد يؤدي إلى إيقاف بعض الطلبات مؤقتا وإعادة الحساب، مما يضر بزمن الاستجابة. ومن الحلول تقليل عدد تسلسلات التوكنات المتزامنة أو ميزانية التوكنات لكل دفعة؛ وإضافة وحدات GPU حل آخر. فمهما بلغت كفاءة المجدول، لا يمكنه توفير ذاكرة لا يملكها الجهاز.
ما يبرر الانتقال هو العجز عن تحقيق هدف الخدمة تحت حمل يمثل ذروة الاستخدام، بعد ضبط معقول للإعدادات. سجل زمن وصول أول توكن، وزمن اكتمال الإجابة، والطلبات الناجحة، ونمو قائمة الانتظار، والأخطاء. وقارن قيمة مئينية عند الطرف الأبطأ من التوزيع إلى جانب الوسيط، لأن المستخدمين يلاحظون الحالات البطيئة. يوفر vLLM مقاييس لبيئة الإنتاج لدعم هذا العمل.
ثبت إصدار النموذج ودقته وأطوال الموجهات وحدود المخرجات ونمط الطلبات عند المقارنة. فمقارنة نموذج صغير مكمم في Ollama بنسخة نموذج أكبر وبدقة عالية في vLLM تقارن بين إعدادين كاملين للتشغيل، ولا تقيس أثر المحركين وحدهما.
صيغ التكميم: نقل النموذج جزء من عملية الانتقال
يتفوق Ollama عندما تكون لديك حزمة نموذج محلية جاهزة؛ ويتفوق vLLM عند اختيار صيغة تشغيل تناسب عتادا محددا. يخزن التكميم قيم النموذج بدقة أقل لتقليل متطلبات الذاكرة. أما حاوية الملف وطريقة التكميم ومحرك التنفيذ، فلكل منها متطلبات توافق مستقلة.
توثق Ollama استيراد أوزان Safetensors ونماذج GGUF، سواء كانت في ملف واحد أو مقسمة على ملفات. وGGUF صيغة لملفات النماذج شائعة في الاستدلال المحلي؛ ويذكر دليل الاستيراد الحالي في Ollama أن تكميم GGUF يجب أن يسبق الاستيراد، لا أن يجري أثناءه. وفي موضع منفصل، تذكر واجهة إنشاء النماذج nvfp4 مثالا للتكميم عند الاستيراد. وهذا لا يعني أن كل بنية نموذج وكل وحدة GPU تدعمان هذا المسار. دليل الاستيراد في Ollama، واجهة إنشاء النماذج.
تذكر Ollama أيضا f16 وq8_0 وq4_0 لذاكرة KV المؤقتة. وهذه إعدادات لذاكرة التخزين المؤقت، وليست قائمة بصيغ أوزان النماذج يمكن التعامل معها على أنها الشيء نفسه. ويتطلب استخدام ذاكرة مؤقتة مكممة تفعيل Flash Attention. وثائق ذاكرة التخزين المؤقت في Ollama.
يسرد vLLM تكاملات للتكميم تشمل AWQ/GPTQ وFP8 وINT8 وINT4 وMXFP4/MXFP8 وNVFP4 وغيرها. وتختلف مصفوفة الدعم باختلاف التنفيذ والعتاد، لذلك لا تكفي عبارة «يدعم 4 بت» لتوجيه قرار الشراء. تحقق من التوافق بين نسخة النموذج المحددة ونواة التنفيذ. وثائق التكميم في vLLM، نظرة عامة على الصيغ.
يحول مقسم النص، أو tokenizer، النصوص إلى معرفات التوكنات التي يفهمها النموذج. وقد يؤدي تغيير الأوزان أو هذا المقسم أو تنسيق المحادثة أو التكميم إلى تغير الإجابات واستدعاءات الأدوات واستهلاك الذاكرة. خصص وقتا وموارد لاختبارات التحقق من عدم تراجع السلوك، حتى إن بقي اسم عائلة النموذج كما هو.
Mellum2.1 يوضح أهمية الصيغ المتاحة عند الإطلاق
يجسد إعلان JetBrains بتاريخ 8 أكتوبر 2026 عن Mellum2.1 نمط الإصدارات التي تبدأ بالخوادم: ذكر المنشور أن نسخ GGUF المخصصة لـ Ollama وllama.cpp وLM Studio ستأتي قريبا. وتقدم صفحة نموذج الإصدار وصفة لتشغيله عبر vLLM، كما تشمل تكاملاته عند الإطلاق vLLM وSGLang، وهو خادم استدلال آخر. منشور الإطلاق من JetBrains، صفحة الإصدار.
وقد تقلص هذا الفارق منذ الإطلاق بالفعل: يحتوي مستودع GGUF الرسمي لدى JetBrains على ملفات مكممة قابلة للتنزيل، وفق التحقق في 12 أكتوبر. فلا تتعامل مع عبارة «قريبا» في منشور الإطلاق على أنها وصف للتوافر اليوم. والدرس العملي هو فحص الملفات المتاحة حاليا ووصفة تشغيلها قبل تغيير المحرك لمجرد الحصول على نموذج جديد. ملفات GGUF الرسمية.
خوادم متوافقة مع OpenAI: احتفظ بالعميل وافحص سلوك الواجهة
يوثق كلا المشروعين خادما متوافقا مع OpenAI، لكن تطابق بنية الطلب لا يضمن تطابق السلوك. عنوان الأساس المحلي في Ollama هو http://localhost:11434/v1/؛ ويستخدم مثال vLLM العنوان http://localhost:8000/v1. وإذا كان تطبيقك يستخدم واجهة Ollama الأصلية /api/chat، فالانتقال يتطلب تكييف التعامل مع API، وليس مجرد تغيير المنفذ. التوافق في Ollama، وثائق خادم vLLM.
على سبيل المثال، بعد تثبيت vLLM على عتاد متوافق، يشغل الأمر التالي النموذج المستخدم في مثال الخادم الموثق، مع حد صريح للسياق واسم يظهر للتطبيق:
vllm serve NousResearch/Meta-Llama-3-8B-Instruct \
--host 127.0.0.1 \
--port 8000 \
--max-model-len 8192 \
--served-model-name app-modelهذا مثال للإعداد؛ ولا يستخدم نسخة نموذج مطابقة للأمر السابق في Ollama، ولا يمثل توصية بتحديد موارد بيئة الإنتاج. يتيح --served-model-name للعميل الاحتفاظ باسم ثابت للنموذج مع تغير إعداد التشغيل. وسائط محرك vLLM.
راجع قوالب المحادثة، التي تحول أدوار الرسائل إلى صيغة إدخال النموذج، وحدد معلمات أخذ العينات صراحة. يستطيع vLLM تطبيق القيم الافتراضية من ملف generation_config.json في مستودع النموذج؛ ويمنع --generation-config vllm هذا التجاوز للإعدادات. قارن تفسير استدعاءات الأدوات والمخرجات المهيكلة والبث والإلغاء ومعالجة الأخطاء باستخدام الطلبات الفعلية للتطبيق.
اجعل المصادقة جزءا من خطة الانتقال. يتجاهل مثال التوافق المحلي في Ollama قيمة مفتاح API الذي يرسله العميل. ويدعم vLLM مفتاح API، لكن وثائق الأمان فيه تحذر من أن ذلك لا يحمي كل نقاط النهاية. أبق محرك التنفيذ ضمن شبكة خاصة، وطبق المصادقة وTLS وقيود المسارات عند نقطة الدخول إلى الخدمة. حدود حماية مفتاح API في vLLM.
وهناك تكلفة انتقال أخرى إذا كان تطبيقك يبدل النماذج الأساسية كثيرا: تصف الأسئلة الشائعة في vLLM تشغيل مثيلات خادم منفصلة، مع طبقة توجيه للتعامل مع عدة نماذج أساسية. فالاسم البديل في API لا يحمل نموذجا آخر. وقد تكون قدرة Ollama على إدارة عدة نماذج محملة أكثر ملاءمة لأداة داخلية قليلة الاستخدام. قيود تعدد النماذج في vLLM.
مقارنة التكلفة: الحمل نفسه بنفقات تشغيل مختلفة
لا يتفوق أي من المحركين بسعر أقل للتوكن عند الاستضافة الذاتية؛ فلا توجد أصلا فاتورة توكنات للمحرك. خطط Ollama السحابية المدفوعة خدمة مستقلة، وليست شرطا لتقديم النماذج المحلية عبر خادم. يشرح دليل أسعار Ollama هذا الفرق؛ وللاطلاع على العروض السحابية الحالية، استخدم رابط صفحة أسعار الشركة أعلاه.
عندما تملك العتاد، تشمل التكلفة الشهرية الكهرباء والحصة المحسوبة من تكلفة العتاد ووقتك. وعندما تستأجره، ابدأ بساعات تشغيل الجهاز وفق السعر المعروض، ثم أضف التخزين والشبكة والتشغيل. ولا توفر كفاءة الاستدلال الأعلى مالا إلا إذا قللت الموارد التي تخصصها، أو اختصرت مدة التشغيل المدفوعة، أو حققت فائدة للأعمال يمكنك تقدير قيمتها.
مثال ميزانية بأساس موحد للمقارنة
الأرقام التالية افتراضات صريحة لإعداد الميزانية، وليست أسعار موردين أو نتائج اختبارات أداء: وحدة GPU بسعر $1 للساعة، و730 ساعة في الشهر، و100,000 مهمة ناجحة. تتضمن كل مهمة 2,000 توكن في الموجه و1,000 توكن في المخرجات، مع استخدام النموذج والتكميم ومعيار الجودة وزمن الاستجابة المستهدف نفسها في المحركين.
إذا حقق كلاهما المتطلبات على وحدة GPU واحدة مستأجرة باستمرار، فستبلغ تكلفة الحوسبة لكل منهما $730 شهريا، أي $0.0073 لكل مهمة ناجحة ولكل 1,000 توكن مخرجات. عند احتساب السعر على أساس توكنات المخرجات، يبقى عمل معالجة الموجه ثابتا؛ فهذا ليس سعرا مشتركا يمزج المدخلات والمخرجات.
أضف الآن إلى ميزانية تشغيل vLLM ساعتين شهريا بسعر مفترض قدره $100 للساعة، وأربع ساعات للانتقال تدفع مرة واحدة:
- إعداد Ollama المرجعي: $730 بصورة متكررة، قبل التكاليف المشتركة بين الخيارين.
- vLLM على العتاد نفسه: $930 بصورة متكررة، أو $0.0093 لكل 1,000 توكن مخرجات.
- الشهر الأول لـ vLLM شاملا الانتقال: $1,330، أو $0.0133 لكل 1,000 توكن مخرجات.
هذه الساعات مدخلات للحساب تستبدلها بتقديرك، وليست ادعاء بشأن المدة التي يستغرقها الانتقال. ويستبعد المثال من الجانبين أعمال التشغيل المشتركة والتخزين ورسوم الشبكة والضرائب.
متى يصبح الخيار الآخر أقل تكلفة؟
عند سعر الساعة المفترض، يجب أن يوفر vLLM أكثر من 200 ساعة GPU شهريا لتعويض نفقات التشغيل الإضافية المفترضة. ولاسترداد كامل تكلفة الانتقال البالغة $400 في الشهر الأول، يرتفع الحد إلى أكثر من 600 ساعة GPU موفرة.
وفي مثال لخدمة دائمة التشغيل، افترض أن اختبار الحمل الذي أجريته يبين حاجة Ollama إلى نسختين متماثلتين من الخدمة، لكل منهما وحدة GPU، بينما يحتاج vLLM إلى واحدة لتلبية الحمل وزمن الاستجابة نفسيهما. تصبح تكلفة الحوسبة في Ollama هي $1,460؛ وتبقى تكلفة حوسبة vLLM مع نفقات التشغيل الإضافية $930. الوفر المشروط بهذه النتيجة هو $530 شهريا، ويسترد تكلفة الانتقال البالغة $400 في نحو 0.75 شهر.
هذا حساب لنقطة التعادل، وليس ادعاء بأن vLLM يخفض احتياجك إلى وحدات GPU إلى النصف. إذا احتاج كلاهما إلى العتاد نفسه، ولم توجد فائدة أخرى تبرر الانتقال، فلن ترجح مقارنة رسوم البرنامج كفة vLLM. ولا يمكن تبرير حد فاصل عام عند عدد محدد من المستخدمين.
قائمة مختصرة للانتقال من Ollama إلى vLLM
انقل نموذجا وسلوك API جرى التحقق منهما، عبر مسار توجيه يتيح الرجوع. الأوزان التي نزلتها ليست سوى جزء مما يعتمد عليه المستخدمون.
وثق إعداد التشغيل الحالي
احفظ هوية النموذج والتكميم والسياق وموجه النظام ومعلمات أخذ العينات وملف Modelfile الخاص بـ Ollama. واحتفظ بطلبات تمثل الاستخدام الفعلي مع النتائج المتوقعة منها في التطبيق. ضمّن محادثات طويلة واستخدام الأدوات، لا موجهات دردشة قصيرة فقط. مرجع Modelfile.
اختر ملفات النموذج المستهدف ومحرك تشغيل GPU
تحقق من بنية النموذج ومقسم النص ودعم التكميم وهامش الذاكرة المتاح. ثبت إصدار النموذج وبيئة التشغيل. ونزل الأوزان المستهدفة بصورة منفصلة، كي لا يتطلب الرجوع إعادة إنشاء الحزمة القديمة.
طابق سلوك API
اضبط عنوان الأساس واسم النموذج، وأعد تطبيق إعدادات الموجه والقالب، واختبر حقول الطلب التي يستخدمها التطبيق. احتفظ بسجل المحادثة ضمن المسار الذي تتحكم فيه بالفعل داخل التطبيق؛ وافحص أي حالة يديرها الخادم قبل التحويل.
أعد تشغيل طلبات الذروة ثم انتقل تدريجيا
طابق أطوال الموجهات والمخرجات، واختبر الطلبات المتداخلة، وقارن معدلات النجاح وزمن الاستجابة في الحالات الأبطأ. ضع الخدمة خلف نقطة دخول تتحقق من الهوية، ووجه نسبة صغيرة من الطلبات إلى محرك التنفيذ الجديد، وأبق المسار القديم حتى تتحقق معايير القبول.

لا تنتقل بعد إذا كان Ollama يحقق هدف الخدمة، أو لم يكن للنموذج المطلوب مسار تشغيل متحقق منه في vLLM، أو كان الانتقال سيستبدل ببساطة حزمة تعمل بمحرك تنفيذ لا تعرفه. وقد يكون من المعقول أيضا إبقاء Ollama على الحواسيب المحمولة وتشغيل vLLM على خادم مشترك، بشرط اختبار الاختلافات وعدم افتراض تطابق بيئتي التطوير والإنتاج. ولتوسيع قائمة الخيارات، راجع بدائل Ollama.
خطوتك التالية واضحة: سجل حملا يمثل أكثر أوقات الاستخدام ازدحاما، وحدد زمن الاستجابة المقبول له، ثم أعد تشغيله على الخادم المقترح قبل شراء سعة إضافية.
أسئلة شائعة
متى أستخدم vLLM بدلا من Ollama؟
اختر vLLM عندما تبرر الطلبات المتداخلة المستمرة، أو الحاجة إلى ضبط الدفعات صراحة، أو تشغيل النموذج بصورة موزعة، الجهد التشغيلي المطلوب. واحتفظ بـ Ollama عندما يحقق مسار إدارة النماذج الأبسط فيه زمن الاستجابة الذي يستهدفه التطبيق بالفعل.
أيهما أسرع: Ollama أم vLLM؟
يمثل vLLM نقطة البداية الأقوى لمعدل الإنجاز الإجمالي تحت الحمل. لكن قياس السرعة لتطبيقك يظل مشروطا بمطابقة العتاد والأوزان والدقة والسياق والطلبات. وقد يختلف الإعداد الأفضل لسرعة الاستجابة لطلب منفرد عن الأفضل لإجمالي إنجاز الخادم.
لماذا يعمل Ollama ببطء شديد؟
تحقق مما إذا كانت الطلبات تنتظر، أو كان النموذج قد انتقل جزئيا إلى CPU، أو كان طول السياق أو المخرجات يتجاوز الحمل الذي حددت الموارد على أساسه. افحص إعداد التشغيل الفعلي قبل تغيير المحرك؛ فنقل حمل يفوق السعة لا يلغي احتياجه إلى الذاكرة.
لماذا يستهلك Ollama كل هذه الذاكرة RAM؟
الأوزان ليست سوى جزء من الذاكرة المخصصة. فالسياقات الأطول والمحادثات المتوازية والنماذج الإضافية المحملة تحتاج إلى ذاكرة أيضا. قلل أولا السياق غير الضروري وعدد النماذج المحملة، ثم أعد اختبار مستوى التزامن الذي يحتاجه التطبيق.
استخدم قائمة تدقيق إجراءات العمل بالذكاء الاصطناعي لتحديد أي مسار عمل خاص يستحق خادما مشتركا للنماذج، واشترك في النشرة لمتابعة التغييرات اللاحقة في الأدوات.
- تاريخ النشر
- التصنيف
- Build
- اللغة







