النقاط الرئيسية
- يُعد vLLM وHugging Face TGI خادمي الاستدلال مفتوحي المصدر (Apache 2.0) المهيمنين لخدمة متعددة المستأجرين عالية الإنتاجية؛ ويدعم كلاهما التجميع المستمر والتوازي الموتري متعدد وحدات المعالجة الرسومية.
- NVIDIA NIM هو خدمة مصغّرة مدفوعة ومبنية مسبقاً (اشتراك NVIDIA AI Enterprise) تغلّف TensorRT-LLM لتحقيق أعلى إنتاجية على أجهزة NVIDIA، مع دعم مدعوم باتفاقية مستوى خدمة من المورد.
- Ollama غير مصمم لخدمة المؤسسات متعددة المستأجرين -- فهو بيئة تشغيل موجهة لعقدة واحدة ومستخدم واحد؛ استخدمه لأجهزة المطورين المحمولة والنماذج الأولية الطرفية أو القسمية، لا لحركة واجهة برمجة تطبيقات الإنتاج.
- تختلف نضج نشر Kubernetes: يوفر vLLM وTGI مخططات Helm مجتمعية/رسمية، ولدى NIM مشغّله الخاص من NVIDIA، بينما لا يملك Ollama سوى مخططات مجتمعية دون آليات توسّع تلقائي أصيلة.
- الترخيص يحدد التكلفة الإجمالية: vLLM وTGI مجانيان ومفتوحا المصدر؛ يضيف NIM تكلفة اشتراك لكل وحدة معالجة رسومات فوق تكلفة الوحدة نفسها، مقابل الدعم والتحسين الجاهز.
- تختلف قابلية الملاحظة بشكل حاد: يعرض vLLM وTGI مقاييس Prometheus جاهزة؛ يتكامل NIM مع حزمة مراقبة DCGM/Base Command الخاصة بـ NVIDIA؛ لدى Ollama قياس عن بُعد مدمج محدود جداً.
- استخدم vLLM لأفضل إنتاجية مقابل التكلفة مفتوحة المصدر، وTGI إذا كنت داخل نظام Hugging Face بالفعل، وNIM إذا احتجت دعماً من المورد وتستطيع الدفع مقابله، واحتفظ بـ Ollama للنماذج الأولية فقط.
📍 في جملة واحدة
بالنسبة لخدمة نماذج اللغة الكبيرة المؤسسية متعددة وحدات المعالجة الرسومية، يُعد vLLM وHugging Face TGI الخيارين مفتوحي المصدر الجاهزين للإنتاج، وNVIDIA NIM هو البديل المدفوع الجاهز للاستخدام، وOllama مصمم لمستخدم واحد لا لتعدد المستأجرين.
💬 بعبارات بسيطة
تشغيل نموذج ذكاء اصطناعي واحد على جهازك المحمول مشكلة مختلفة عن خدمة مئات الموظفين أو العملاء من مجموعة وحدات معالجة رسومات مشتركة. vLLM وTGI برمجيات مجانية مصممة للمشكلة الثانية. يقوم NVIDIA NIM بالمهمة نفسها كمنتج مدفوع وجاهز مسبقاً بدعم من NVIDIA خلفه. أما Ollama، الأداة التي يستخدمها معظم الناس لتجربة نموذج محلياً، فلم يُصمَّم لهذا العدد من المستخدمين المتزامنين.
ما هو خادم استدلال نماذج اللغة الكبيرة للمؤسسات؟
خادم استدلال نماذج اللغة الكبيرة للمؤسسات هو طبقة البرمجيات التي تقبل طلبات متزامنة من مستخدمين أو تطبيقات كثيرة وتوجّهها بكفاءة عبر مجموعة وحدات معالجة رسومات مشتركة. يختلف هذا عن بيئة التشغيل لمستخدم واحد، التي تحمّل نموذجاً واحداً لعملية واحدة على جهاز واحد.
ثلاثة أمور تفصل برمجيات الخدمة على مستوى المؤسسات عن أداة الجهاز المحمول: التجميع المستمر (تعبئة عدة طلبات جارية في المرور نفسه على وحدة المعالجة الرسومية)، التوازي متعدد وحدات المعالجة الرسومية (تقسيم نموذج واحد عبر عدة وحدات معالجة رسومات أو عقد)، وسطح واجهة برمجة تطبيقات جاهز للإنتاج (فحوصات الصحة، المقاييس، آليات التوسّع التلقائي) يمكن لفريق المنصة تشغيله داخل Kubernetes.
بُني كل من vLLM وHugging Face TGI وNVIDIA NIM حول هذه المتطلبات الثلاثة منذ البداية. أما Ollama، المبني على llama.cpp، فقد صُمم من أجل قابلية النقل والبساطة على جهاز واحد -- وهو هدف مختلف ومشروع، لكنه ليس الهدف نفسه. راجع مقارنتنا لمحركات المستخدم الواحد إذا كان السؤال الذي تطرحه فعلياً هو "ما الأسهل تثبيتاً على جهازي" -- يغطي هذا الدليل الطرف الآخر من هذا القرار.
مقارنة الميزات: vLLM مقابل TGI مقابل NVIDIA NIM مقابل Ollama
| القدرة | vLLM | TGI | NVIDIA NIM | Ollama |
|---|---|---|---|---|
| الترخيص | Apache 2.0 / مجاني | Apache 2.0 / مجاني | NVIDIA AI Enterprise / مدفوع | MIT / مجاني |
| الغرض التصميمي | خدمة GPU عالية الإنتاجية | خدمة إنتاج أصيلة لـ HF | حزمة مؤسسية جاهزة من NVIDIA | مستخدم واحد، لا تعدد مستأجرين |
| متعدد GPU | توازي موتري + خطوط أنابيب | توازي موتري | توازي موتري (TensorRT-LLM) | عقدة واحدة فقط |
| تجميع مستمر | نعم (PagedAttention) | نعم (موجّه Rust) | نعم (محرك Triton) | محدود / تجريبي |
| التكميم | GPTQ / AWQ / FP8 / INT4 | GPTQ / AWQ / bitsandbytes | FP8 / INT4 (TensorRT-LLM) | GGUF Q4-Q8 |
| نشر Kubernetes | مخطط Helm / KServe | مخطط Helm رسمي من HF | NIM Operator (رسمي) | مخططات مجتمعية فقط |
| نموذج الدعم | مجتمعي / GitHub | مجتمعي + عقود HF | دعم NVIDIA باتفاقية مستوى خدمة | مجتمعي فقط |
| قابلية الملاحظة | مقاييس Prometheus مدمجة | Prometheus + تتبع OTel | NVIDIA DCGM + Prometheus | محدودة جداً / لا شيء مدمج |
فهم vLLM: رائد الإنتاجية مفتوح المصدر
vLLM خادم استدلال مفتوح المصدر (Apache 2.0) مصمم خصيصاً للخدمة عالية الإنتاجية متعددة وحدات المعالجة الرسومية. نشأ من مختبر Sky Computing في جامعة كاليفورنيا بيركلي، وهو أحد أكثر محركات المصدر المفتوح انتشاراً لواجهات برمجة تطبيقات نماذج اللغة الكبيرة في الإنتاج.
- PagedAttention: يدير ذاكرة التخزين المؤقت KV في كتل ذات حجم ثابت بدلاً من تخصيص متجاور لكل طلب، ما يرفع استخدام ذاكرة وحدة المعالجة الرسومية القابل للتحقيق ويتيح لمزيد من الطلبات المتزامنة مشاركة وحدة معالجة رسومية واحدة.
- التجميع المستمر: تنضم الطلبات الجديدة إلى دفعة قيد التشغيل بدلاً من انتظار انتهاء الدفعة الحالية، ما يحافظ على استخدام مرتفع لوحدة المعالجة الرسومية تحت حركة متغيرة.
- متعدد وحدات المعالجة الرسومية والعقد: يقسّم التوازي الموتري طبقات نموذج واحد عبر وحدات المعالجة الرسومية في عقدة واحدة؛ ويقسّم توازي خطوط الأنابيب عبر العقد للنماذج الأكبر من ذاكرة VRAM المجمّعة لعقدة واحدة.
- التكميم: تقلل صيغ GPTQ وAWQ وFP8 وINT4 من استهلاك VRAM لكل نسخة، ما يزيد عدد نسخ النموذج المتزامنة التي يمكن لأسطول ثابت من وحدات المعالجة الرسومية استضافتها.
- واجهة برمجة تطبيقات متوافقة مع OpenAI: يوفّر
vllm serve <model>بديلاً مباشراً لواجهة OpenAI Chat Completions، ما يقلل من عمل التكامل في جانب التطبيق. - يوفّر vLLM مخطط Helm رسمياً ويتكامل مع KServe لخدمة النماذج الأصيلة في Kubernetes، مع توسّع تلقائي مدفوع بعمق طابور الطلبات أو استخدام وحدة المعالجة الرسومية.
# خدمة نموذج بتوازي موتري عبر 4 وحدات معالجة رسومات
pip install vllm
vllm serve meta-llama/Llama-3.3-70B-Instruct \
--tensor-parallel-size 4 \
--gpu-memory-utilization 0.9 \
--host 0.0.0.0 --port 8000فهم Hugging Face TGI: الخيار الأصيل لـ Hugging Face
Hugging Face Text Generation Inference (TGI) خادم استدلال مفتوح المصدر (Apache 2.0) بنته Hugging Face لنشر إنتاج النماذج المستضافة على Hugging Face Hub. يشغّل منتج Inference Endpoints الخاص بـ Hugging Face نفسها، فهو يخدم بالفعل حركة على نطاق مؤسسي في الإنتاج.
- موجّه طلبات مبني بلغة Rust: يدير الطوابير والتجميع المستمر بعبء أقل لكل طلب مقارنة بموجّه مبني بالكامل بلغة بايثون.
- Flash Attention وPaged Attention: تبنّى TGI نفس تقنيات كفاءة الذاكرة التي يستخدمها vLLM، ما أغلق معظم فجوة الإنتاجية بينهما على أجهزة مماثلة.
- التوازي الموتري: يقسّم نموذجاً عبر عدة وحدات معالجة رسومات في عقدة واحدة؛ الخدمة متعددة العقد مدعومة لكن بأدوات أصيلة أقل مقارنة بـ vLLM.
- التكميم: صيغ bitsandbytes وGPTQ وAWQ وEETQ.
- تكامل أصيل مع Hugging Face Hub: لا يتطلب جلب نموذج ومحلّل الرموز الخاص به وأوزان safetensors أي خطوة تحويل يدوية إذا كان النموذج مستضافاً بالفعل على الـ Hub.
- ملاحظة ترخيص: وُزّع TGI لفترة وجيزة تحت ترخيص أكثر تقييداً كتبته Hugging Face نفسها (HFOILv2) في 2023-2024 قبل العودة إلى Apache 2.0 -- تحقق من إصدار الترخيص المثبّت في بيان النشر لديك، إذ قد تظل صورة قديمة مخزنة مؤقتاً تحمل العلامة المقيّدة.
فهم NVIDIA NIM: الخيار المدعوم من المورد
NVIDIA NIM (خدمات الاستدلال المصغّرة من NVIDIA) هو حاوية مدفوعة ومبنية مسبقاً تغلّف محرك الاستدلال TensorRT-LLM من NVIDIA خلف واجهة برمجة تطبيقات موحّدة، وتُباع كجزء من اشتراك NVIDIA AI Enterprise. تستبدل الإعداد اليدوي لـ vLLM وTGI بنشر مدعوم ومحسَّن مسبقاً.
- حاويات محسَّنة بـ TensorRT-LLM: تقوم NVIDIA بتجميع وضبط نواة الاستدلال مسبقاً لكل نموذج وكل جيل من وحدات المعالجة الرسومية (H100، A100، L40S)، ما يحقق عادةً أعلى إنتاجية لكل وحدة معالجة رسومية من بين الخيارات الأربعة على أجهزة NVIDIA تحديداً.
- دعم واتفاقية مستوى خدمة مدعومان من NVIDIA: العامل المميّز مقارنة بالخيارات مفتوحة المصدر -- مسار تذاكر دعم والتزامات توفّر يمكن لفريق المنصة إدراجها في عقد مع المورد.
- NIM Operator لـ Kubernetes: مشغّل NVIDIA الخاص المبني على Helm لنشر وتوسيع وإدارة حاويات NIM في مجموعة، بما في ذلك التكامل مع حزمة مراقبة NVIDIA نفسها (DCGM Exporter، Base Command).
- كتالوج النماذج: تحافظ NVIDIA على مجموعة منتقاة من النماذج مفتوحة الأوزان المعبّأة مسبقاً كحاويات NIM جاهزة للاستخدام، مع مسار لتعبئة نماذج مخصصة مضبوطة دقيقاً.
- المقايضة هي الارتباط بالمورد وتكلفة الترخيص: يعمل NIM بكفاءة فقط على وحدات معالجة رسومات NVIDIA، ويُحتسب الاشتراك لكل وحدة معالجة رسومية سنوياً فوق تكلفة الجهاز نفسه -- تأكد من الأسعار الحالية مباشرة من NVIDIA AI Enterprise قبل وضع الميزانية، إذ تتغير أسعار اشتراكات البرمجيات المؤسسية دون إشعار عام كبير في كثير من الأحيان.
لماذا Ollama ليس محرك خدمة مؤسسي
Ollama غير مصمم لخدمة استدلال المؤسسات متعددة المستأجرين، وهذا خيار تصميمي، لا عيباً. يغلّف Ollama برنامج llama.cpp بواجهة برمجة تطبيقات REST بسيطة وسحب نموذج بأمر واحد، محسَّن لمطوّر يشغّل نموذجاً واحداً على جهاز واحد.
- التزامن: أضاف Ollama معالجة أساسية للطلبات المتوازية، لكن دون تجميع مستمر أو إدارة ذاكرة على غرار PagedAttention، لذا تتراجع الإنتاجية بشكل أسرع تحت مستخدمين متزامنين كثيرين مقارنة بـ vLLM أو TGI على وحدة المعالجة الرسومية نفسها.
- متعدد وحدات المعالجة الرسومية: يمكن لـ Ollama تقسيم نموذج كبير عبر وحدات معالجة رسومات جهاز واحد، لكن دون خدمة موزّعة أصيلة متوازية موترياً أو متعددة العقد تضاهي vLLM.
- Kubernetes: لا توجد سوى مخططات Helm يديرها المجتمع؛ لا يوجد مشغّل Kubernetes أصيل، ولا تكامل مع أدوات التوسّع التلقائي، ولا عقد دعم من المورد.
- قابلية الملاحظة: مقاييس مدمجة محدودة جداً -- لا نقطة نهاية Prometheus افتراضياً، على عكس vLLM وTGI.
- أين يظل Ollama الأداة الصحيحة داخل مؤسسة: أجهزة المطورين المحمولة، نموذج أولي قسمي بحركة داخلية منخفضة، أو جهاز طرفي معزول يخدم مستخدماً واحداً في كل مرة. بمجرد أن تتطلب الحركة تزامناً متعدد المستأجرين، انتقل إلى vLLM أو TGI أو NIM -- راجع إعدادات نماذج اللغة المحلية متعددة وحدات المعالجة الرسومية للجانب الخاص بالأجهزة من هذا الانتقال.
قرارات البنية: عقدة واحدة مقابل عقد متعددة
القرار الأول في البنية هو عقدة واحدة مقابل عقد متعددة، ويُحسم بناءً على ما إذا كان النموذج يتسع في ذاكرة وحدة المعالجة الرسومية المجمّعة لعقدة واحدة، لا بناءً على حجم الحركة وحده.
- عقدة واحدة، متعدد وحدات معالجة رسومية: استخدم التوازي الموتري (
--tensor-parallel-sizeفي vLLM،--num-shardفي TGI) لتقسيم طبقات نموذج واحد عبر وحدات المعالجة الرسومية في خادم واحد. هذا هو الافتراضي للنماذج التي تتسع في VRAM المجمّعة لعقدة واحدة. - عقد متعددة: أضف توازي خطوط الأنابيب بمجرد أن يتجاوز نموذج ذاكرة وحدة المعالجة الرسومية لعقدة واحدة، أو يتجاوز حجم الطلبات ما يمكن للتوازي الموتري على عقدة واحدة خدمته. يدعم vLLM ذلك عبر Ray؛ ويدعمه NIM عبر قوالب نشر متعددة العقد خاصة به.
- موازنة الحمل: يعمل موازن دوري بسيط بشكل جيد للنسخ متساوية الحجم، لكن التوجيه الواعي بذاكرة التخزين المؤقت KV -- إعادة توجيه طلب متابعة في المحادثة نفسها إلى النسخة التي تحتفظ بالفعل بسياقها المخزَّن مؤقتاً -- يقلل زمن الاستجابة بشكل ملموس في أعباء عمل شبيهة بالمحادثة.
- توجيه النماذج: تشغّل المؤسسات التي تستخدم أكثر من نموذج (مثلاً نموذج برمجة ونموذج محادثة عام) عادةً مجموعات نسخ منفصلة لكل نموذج خلف طبقة توجيه، بدلاً من مجموعة مشتركة -- إذ لا تُقسَّم ذاكرة وحدة المعالجة الرسومية بنظافة كافية بين نماذج مختلفة جداً لتبرير التعقيد.
- التوسّع التلقائي: وسّع بناءً على عمق طابور الطلبات أو استخدام وحدة المعالجة الرسومية، لا على المعالج المركزي (الافتراضي التقليدي لـ HPA في Kubernetes) -- إذ بالكاد يتحرك استخدام المعالج المركزي لجراب استدلال يعمل على وحدة معالجة رسومية بغض النظر عن الحمل. يُعد KEDA مع مقياس Prometheus مخصص النمط الشائع لـ vLLM/TGI؛ ويربط مشغّل NIM ذلك كجزء من المنتج. راجع توسيع نماذج اللغة المحلية للمؤسسات لتخطيط السعة الأوسع وراء هذا القرار.
كيفية نشر حزمة استدلال متعددة وحدات المعالجة الرسومية
يتّبع نشر حزمة استدلال مؤسسية تسلسلاً ثابتاً: تحديد اتفاقية مستوى الخدمة، تحديد حجم الأسطول، اختيار المحرك، ثم ربط النشر والتوجيه وقابلية الملاحظة حوله.
- 1حدد اتفاقية مستوى الخدمة الخاصة بزمن الاستجابة والتزامن قبل اختيار الأجهزة.
- 2حدد حجم أسطول وحدات المعالجة الرسومية بناءً على استهلاك النموذج لذاكرة VRAM وهدف عدد الطلبات المتزامنة، لا بناءً على عدد معاملات النموذج وحده.
- 3اختر محرك الخدمة -- vLLM أو TGI لمرونة مفتوحة المصدر، وNIM لنشر جاهز مدعوم من المورد.
- 4حوّل المحرك إلى حاوية وانشره عبر Helm (أو NIM Operator) في مجموعة Kubernetes الخاصة بك.
- 5اضبط التوازي الموتري داخل عقدة واحدة وتوازي خطوط الأنابيب عبر العقد إذا تطلب النموذج ذلك.
- 6أعدّ موازنة حمل واعية بذاكرة التخزين المؤقت KV أو دورية أمام مجموعة النسخ.
- 7اربط التوسّع التلقائي بعمق طابور الطلبات أو استخدام وحدة المعالجة الرسومية، لا بالمعالج المركزي.
- 8أضف قابلية ملاحظة عبر Prometheus/OpenTelemetry واختبر الحمل عند التزامن المستهدف قبل الإطلاق الفعلي.
مقارنة الترخيص ونموذج الدعم
الترخيص هو البند الذي يغيّر أكثر من غيره التكلفة الإجمالية للملكية بين هذه الخيارات الأربعة. كل من vLLM وHugging Face TGI مرخّصان بموجب Apache 2.0 ومجانيان بأي مقياس -- لا تدفع سوى تكلفة البنية التحتية لوحدات المعالجة الرسومية الأساسية. يضيف NVIDIA NIM اشتراكاً لكل وحدة معالجة رسومية سنوياً فوق تكلفة الوحدة نفسها، مقابل أداء محسَّن بـ TensorRT-LLM وعقد دعم من المورد -- تأكد من الأسعار الحالية لكل وحدة معالجة رسومية مباشرة من NVIDIA، إذ لا تُنشَر أسعار اشتراكات البرمجيات المؤسسية علناً كما هو الحال مع منتج استهلاكي. Ollama مرخّص بموجب MIT ومجاني، مع دعم يقتصر على مجتمعه على GitHub وDiscord -- لا توجد طبقة دعم مؤسسي مدفوعة حتى وقت كتابة هذا المقال.
يهم نموذج الدعم بقدر تكلفة الترخيص بالنسبة لنظام إنتاجي: يأتي دعم vLLM وTGI من قضايا GitHub والقنوات المجتمعية (سريع في المشكلات الشائعة، دون اتفاقية مستوى خدمة)، ويأتي NIM بعقد دعم من NVIDIA والتزامات توفّر، بينما لا يملك Ollama أي مسار دعم يتجاوز القنوات المجتمعية.
نقاط قابلية الملاحظة للخدمة الإنتاجية
**يعرض كل من vLLM وTGI نقطة نهاية /metrics متوافقة مع Prometheus جاهزة، تغطي زمن استجابة الطلبات، عمق الطابور، استخدام ذاكرة التخزين المؤقت KV لوحدة المعالجة الرسومية، وإنتاجية الرموز.** اربط ذلك بحزمة Prometheus/Grafana قائمة للحصول على لوحات تحكم بمستوى الإنتاج دون أدوات قياس مخصصة.
يتكامل NVIDIA NIM مع حزمة مراقبة NVIDIA نفسها -- DCGM Exporter لمقاييس مستوى وحدة المعالجة الرسومية (الاستخدام، الذاكرة، درجة الحرارة، أخطاء ECC) وBase Command Manager للرؤية على مستوى الأسطول -- وهو ملاءمة أقوى إذا كانت بقية البنية التحتية متمركزة حول NVIDIA بالفعل.
لدى Ollama قياس عن بُعد مدمج محدود جداً: لا نقطة نهاية Prometheus افتراضياً، وهو ما يتسق مع تصميمه لمستخدم واحد لكنه فجوة حقيقية إذا حاولت تشغيله كبنية تحتية مشتركة واحتجت رؤية زمن استجابة كل طلب عبر مستخدمين متزامنين كثيرين.
أي خادم استدلال تختار؟
أفضل خيار مفتوح المصدر عموماً: vLLM -- أعلى تبنٍّ من المجتمع، أوسع أدوات لمتعدد وحدات المعالجة الرسومية، وتيرة تطوير نشطة.
أفضل خيار إذا كنت بالفعل على Hugging Face: TGI -- تكامل أصيل مع الـ Hub، تكافؤ مع Inference Endpoints الرسمي.
أفضل خيار إذا احتجت دعماً من المورد: NVIDIA NIM -- مدعوم باتفاقية مستوى خدمة، جاهز للاستخدام، مقابل تكلفة اشتراك.
غير مناسب لحركة إنتاج متعددة المستأجرين: Ollama -- احتفظ به لأجهزة المطورين ونشر الحافة لمستخدم واحد.
- 🧭 فريق منصة يشغّل واجهة برمجة تطبيقات داخلية مشتركة لنماذج اللغة الكبيرة لعدة فرق ← vLLM أو TGI، مستضافين ذاتياً على Kubernetes.
- 🧭 مؤسسة خاضعة للتنظيم تحتاج عقد دعم ومسار تدقيق ← NVIDIA NIM.
- 🧭 فريق موحّد بالفعل على Hugging Face Hub لاستضافة النماذج ← TGI.
- 🧭 مطورون يبنون إثباتاً للمفهوم قبل تجهيز البنية التحتية ← Ollama، ثم الانتقال إلى vLLM/TGI بمجرد أن تصبح الحركة المتزامنة حقيقية.
- ❌ إذا كنت تتوقع أكثر من حفنة من المستخدمين المتزامنين، لا تضع Ollama خلف نقطة نهاية إنتاج مشتركة -- استخدم vLLM أو TGI بدلاً من ذلك.
- ❌ إذا احتجت توسّعاً تلقائياً أصيلاً في Kubernetes بناءً على حمل الطلبات، فلا يملك Ollama ما يعادل التوسّع المدفوع بعمق الطابور عبر KEDA -- استخدم vLLM أو TGI أو NIM.
أخطاء شائعة عند تحديد حجم بنية الاستدلال المؤسسية
- تحديد حجم وحدات المعالجة الرسومية بناءً على عدد المعاملات بدلاً من عدد الطلبات المتزامنة. لا يترك أسطول وحدات معالجة رسومات مصمَّم فقط لتتسع نسخة واحدة من النموذج في VRAM أي هامش للمستخدمين المتزامنين -- حدد الحجم عند ذروة التزامن، ثم تحقق من أن النموذج ما زال يتسع.
- نشر Ollama خلف موازن حمل إنتاج مشترك. يعمل في عرض توضيحي بمستخدمين اثنين؛ لكنه لا يصمد في تصميم مخصص لمئات المستخدمين.
- التوسّع بناءً على استخدام المعالج المركزي. بالكاد تتحرك جرابات الاستدلال العاملة على وحدة معالجة رسومية من حيث استخدام المعالج المركزي بغض النظر عن الحمل -- وسّع بناءً على عمق الطابور أو استخدام وحدة المعالجة الرسومية بدلاً من ذلك.
- تجاهل التحقق من الترخيص في صور TGI القديمة المخزَّنة مؤقتاً. تأكد من أن علامة الصورة المسحوبة تطابق إصدار Apache 2.0، لا نسخة مبنية من حقبة HFOILv2 مخزَّنة مؤقتاً.
- وضع ميزانية لـ NIM دون تأكيد الأسعار الحالية لكل وحدة معالجة رسومية مباشرة من NVIDIA. تتغير أسعار اشتراكات البرمجيات المؤسسية؛ وعرض سعر قديم ليس أساساً صالحاً للميزانية.
المصادر
- توثيق vLLM الرسمي -- الوثائق الرسمية لـ vLLM: PagedAttention، التجميع المستمر، وأدلة النشر متعدد وحدات المعالجة الرسومية/العقد.
- Hugging Face Text Generation Inference (GitHub) -- مستودع TGI الرسمي: البنية، صيغ التكميم المدعومة، وتاريخ الترخيص.
- توثيق NVIDIA NIM الرسمي -- الوثائق الرسمية لـ NIM: النماذج المدعومة، محرك TensorRT-LLM، وNIM Operator الخاص بـ Kubernetes.
- مستودع Ollama على GitHub -- مستودع Ollama الرسمي ومتتبع القضايا، مُشار إليه لسلوك التزامن والنشر.
- NVIDIA AI Enterprise -- صفحة منتج NVIDIA لاشتراك AI Enterprise الذي يُوزَّع NIM ضمنه.
الأسئلة الشائعة
ما الفرق بين vLLM وNVIDIA NIM؟
vLLM خادم استدلال مجاني ومفتوح المصدر (Apache 2.0) تستضيفه وتشغّله بنفسك. NVIDIA NIM حاوية مدفوعة ومبنية مسبقاً من NVIDIA تغلّف محرك TensorRT-LLM، تُباع باشتراك NVIDIA AI Enterprise لكل وحدة معالجة رسومية مع دعم من المورد. يحقق NIM عادةً أعلى إنتاجية لكل وحدة معالجة رسومية على أجهزة NVIDIA لأن NVIDIA تضبط نواة الاستدلال مسبقاً؛ ويمنحك vLLM تحكماً أكبر ودون رسوم ترخيص، مقابل قيامك بذلك الضبط والدعم بنفسك.
هل يمكن استخدام Ollama لخدمة استدلال متعددة المستخدمين على مستوى المؤسسات؟
لا يُنصح به لحركة إنتاج متعددة المستأجرين. لا يملك Ollama تجميعاً مستمراً أو إدارة ذاكرة على غرار PagedAttention، ولا توسّعاً تلقائياً أصيلاً في Kubernetes، لذا يتراجع أداؤه أسرع تحت حمل متزامن مقارنة بـ vLLM أو TGI أو NIM على وحدة المعالجة الرسومية نفسها. يناسب أجهزة المطورين المحمولة، وأجهزة الحافة لمستخدم واحد، أو النماذج الأولية الداخلية منخفضة الحركة.
هل يستحق NVIDIA NIM تكلفة الترخيص مقارنة بـ vLLM أو TGI مفتوحي المصدر؟
يعتمد ذلك على ما إذا كان عقد الدعم من المورد والإنتاجية المحسَّنة مسبقاً يستحقان تكلفة الاشتراك بالنسبة لك، مقابل الاحتفاظ ببنية تحتية مجانية وتشغيلها بنفسك. غالباً ما تبرر المؤسسات الخاضعة للتنظيم التي تحتاج مسار تدقيق واتفاقية مستوى خدمة هذه التكلفة؛ وغالباً ما تحقق الفرق التي تملك خبرة داخلية في بنية تعلم الآلة إنتاجية مماثلة عبر vLLM أو TGI دون تكلفة ترخيص.
كيف توسّع استدلال نماذج اللغة الكبيرة عبر عدة وحدات معالجة رسومات وعقد؟
استخدم التوازي الموتري لتقسيم طبقات نموذج واحد عبر وحدات المعالجة الرسومية داخل عقدة واحدة، وتوازي خطوط الأنابيب لتقسيمها عبر عدة عقد بمجرد أن يتجاوز النموذج ذاكرة وحدة المعالجة الرسومية المجمّعة لعقدة واحدة. يدعم vLLM كليهما أصيلاً (متعدد العقد عبر Ray)؛ ويدعم TGI التوازي الموتري أصيلاً بأدوات أصيلة متعددة العقد أقل؛ ويدعم NIM كليهما عبر قوالب متعددة العقد خاصة بـ NVIDIA.
ما صيغ التكميم التي يدعمها كل خادم استدلال؟
يدعم vLLM صيغ GPTQ وAWQ وFP8 وINT4. يدعم TGI صيغ bitsandbytes وGPTQ وAWQ وEETQ. يستخدم NVIDIA NIM تكميم FP8 وINT4 الخاص بـ TensorRT-LLM، المضبوط لكل جيل من وحدات المعالجة الرسومية. يستخدم Ollama صيغة GGUF بدقة من Q4 إلى Q8، موجّهة نحو توفير الذاكرة على جهاز واحد بدلاً من الإنتاجية متعددة المستخدمين.
كيف تنشر vLLM أو TGI على Kubernetes؟
يوفّر كلاهما صور حاويات قابلة للنشر ومخططات Helm -- ويتكامل vLLM أيضاً مع KServe لخدمة النماذج الأصيلة في Kubernetes، ولدى TGI مخطط Helm رسمي من Hugging Face. اضبط طلبات الموارد بما يتوافق مع تخصيص وحدات المعالجة الرسومية لديك، واضبط التوسّع التلقائي بناءً على عمق الطابور أو استخدام وحدة المعالجة الرسومية بدلاً من المعالج المركزي، وأضف ServiceMonitor خاص بـ Prometheus لقراءة نقطة نهاية المقاييس المدمجة.
ما هو التجميع المستمر ولماذا يهم في الخدمة المؤسسية؟
يتيح التجميع المستمر للطلبات الجديدة الانضمام إلى دفعة وحدة معالجة رسومية قيد التشغيل بالفعل، بدلاً من انتظار انتهاء الدفعة الحالية قبل بدء دفعة جديدة. يحافظ ذلك على استخدام مرتفع لوحدة المعالجة الرسومية تحت أنماط حركة حقيقية غير منتظمة، لذلك فهو معيار في vLLM وTGI ومحرك TensorRT-LLM الخاص بـ NIM، وأحد أكبر الفروق في الإنتاجية مقارنة بأداة لمستخدم واحد مثل Ollama.
أي خادم استدلال يملك أفضل قابلية ملاحظة؟
يعرض كل من vLLM وTGI نقطة نهاية مقاييس متوافقة مع Prometheus جاهزة، تغطي زمن الاستجابة وعمق الطابور واستخدام ذاكرة التخزين المؤقت KV لوحدة المعالجة الرسومية -- ملاءمة مباشرة مع حزمة Prometheus/Grafana قائمة. يتكامل NVIDIA NIM مع DCGM Exporter وBase Command Manager من NVIDIA، وهو ملاءمة أقوى للبنية التحتية المتمركزة حول NVIDIA. لدى Ollama قياس عن بُعد مدمج محدود جداً ولا نقطة نهاية مقاييس افتراضية.
هل تحتاج النماذج المتعددة أساطيل وحدات معالجة رسومية منفصلة، أم يمكنها مشاركة مجموعة واحدة؟
من الناحية العملية، تشغّل المؤسسات التي تستخدم أكثر من نموذج عادةً مجموعات نسخ منفصلة لكل نموذج بدلاً من مشاركة مجموعة واحدة، لأن ذاكرة وحدة المعالجة الرسومية لا تُقسَّم بنظافة كافية بين نماذج بأحجام مختلفة جداً. وجّه الطلبات إلى المجموعة الصحيحة على مستوى التطبيق أو البوابة بدلاً من محاولة وضع عدة نماذج على النسخ نفسها من وحدات المعالجة الرسومية.
كيف يختلف الترخيص بين vLLM وTGI وNVIDIA NIM؟
كل من vLLM وHugging Face TGI مرخّصان بموجب Apache 2.0 ومجانيان بأي مقياس -- لا تدفع سوى تكلفة البنية التحتية لوحدات المعالجة الرسومية الأساسية. يتطلب NVIDIA NIM اشتراك NVIDIA AI Enterprise المدفوع، المحتسب لكل وحدة معالجة رسومية سنوياً، فوق تكلفة أجهزة وحدة المعالجة الرسومية؛ تأكد من الأسعار الحالية مباشرة من NVIDIA بدلاً من الاعتماد على عرض سعر سابق. Ollama مرخّص بموجب MIT ومجاني، بدعم مجتمعي فقط.