انتقل إلى المحتوى الرئيسي

الواجهات الخلفية للاستدلال: vLLM وOllama — الدليل الكامل

ما هي الواجهة الخلفية للاستدلال؟​

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

vLLM: الواجهة الخلفية للإنتاج​

vLLM هو الإعداد الافتراضي للإنتاج في AuroraSOC. نشأت في جامعة كاليفورنيا في بيركلي وتستخدم الآن على نطاق واسع للنماذج واسعة النطاق التي تخدم في بيئات الإنتاج.

لماذا vLLM هو الإعداد الافتراضي​

AuroraSOC هو نظام متزامن متعدد الوكلاء. أثناء الاستجابة للحوادث، يمكن للمنسق والوكلاء المتخصصين إصدار طلبات الاستدلال في نفس الوقت تقريبًا. تم تصميم vLLM لهذا النمط.

التجميع المستمر بلغة واضحة​

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

يستخدم vLLM التجميع المستمر: عند وصول الطلبات، يقوم بتجميع العمل ديناميكيًا في تمريرات GPU فعالة بدلاً من تشغيل كل طلب على حدة.

تشبيه المطعم:

  • قائمة الانتظار التقليدية: يقوم المطبخ بطهي طاولة واحدة في كل مرة.
  • التجميع المستمر: يقوم المطبخ بتنسيق جميع الطاولات النشطة ويحافظ على استخدام كل موقد.

والنتيجة هي إنتاجية أعلى وزمن وصول أقل تحت الحمل المتزامن.

PagedAttention وكفاءة ذاكرة التخزين المؤقت KV​

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

يقوم PagedAttention الخاص بـ vLLM بتخصيص هذه الذاكرة بشكل أكثر ديناميكية، بحيث يمكنك احتواء المزيد من المحادثات المتزامنة في نفس ميزانية ذاكرة وحدة معالجة الرسومات.

واجهة برمجة التطبيقات المتوافقة مع OpenAI​

يوفر vLLM واجهة متوافقة مع OpenAI. من الناحية العملية، يمكن عادةً إعادة استخدام التعليمات البرمجية التي تستهدف واجهات برمجة تطبيقات الدردشة على نمط OpenAI عن طريق تغيير عنوان URL الأساسي واسم النموذج فقط. يعد هذا التوافق سببًا رئيسيًا وراء إمكانية ترحيل AuroraSOC إلى الوضع الافتراضي vLLM مع الحد الأدنى من التغييرات على مستوى التطبيق.

متطلبات GPU​

GPUVRAMمناسبة ل
ار تي اكس 309024 جيجابايتالنموذج المتخصص (8 ب)
آر تي إكس 409024 جيجابايتالنموذج المتخصص (8 ب)
A10G24 جيجابايتالنموذج المتخصص (8 ب)
A100 (40 جرام)40 جيجابايتمنسق أو كليهما
A100 (80 جرام)80 جيجابايتكلا النموذجين، موتر متوازي

أولاما: البديل المطور​

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

لماذا لا يعتبر Olma هو الإنتاج الافتراضي​

يُعد Ollama ممتازًا للتطوير المحلي واختبار الوكيل الفردي، ولكنه غير مُحسّن لتوزيع SOC عالي التزامن.

مثال على الرياضيات في قائمة الانتظار:

  • إذا استغرق استدعاء وكيل واحد حوالي 3 ثوانٍ على وحدة المعالجة المركزية
  • ويتم وضع 16 وكيلًا متخصصًا في قائمة الانتظار بشكل فعال
  • قد ينتظر الوكيل الأخير حوالي 42 ثانية قبل أن يبدأ عمله

عادةً ما يكون هذا التأخير غير مقبول للاستجابة النشطة للحوادث.

جدول القرار الخلفي​

الموقفالخلفية الموصى بها
نشر الإنتاجvLLM
اختبار الحمل متعدد العواملvLLM
كمبيوتر محمول للمطور (بدون GPU)أولاما
اختبار الدخان CI/CDأولاما
تصحيح أخطاء الوكيل المفردأولاما

كيفية تبديل الواجهات الخلفية​

  1. افتح .env.
  2. اضبط LLM_BACKEND على vllm أو ollama.
  3. في حالة التبديل إلى Ollama، قم بسحب النماذج:
ollama pull granite4:8b && ollama pull granite4:dense
  1. في docker-compose.yml، قم بالتعليق على depends_on: vllm في خدمات الوكيل عند التشغيل في وضع Ollama.
  2. بدء الخدمات أو تحديثها:
docker compose up -d
  1. التحقق من الواجهة الخلفية النشطة:
curl http://localhost:8000/api/v1/inference/status

التحقق من الخلفية النشطة​

1) نقطة النهاية الصحية vLLM​

curl http://localhost:8000/health

السلوك المتوقع: HTTP 200 مع استجابة صحة vLLM.

2) نقطة نهاية إصدار Olma​

curl http://localhost:11434/api/version

السلوك المتوقع: يحتوي JSON على البيانات التعريفية لإصدار Ollama.

3) نقطة نهاية حالة الاستدلال AuroraSOC​

curl http://localhost:8000/api/v1/inference/status

مثال JSON المتوقع:

{
  "backend": "vllm",
  "base_url": "http://vllm:8000/v1",
  "model": "granite-soc-specialist",
  "orchestrator_model": "granite-soc-specialist",
  "healthy": true
}

استكشاف الأخطاء وإصلاحها​

العرَض: نفاد ذاكرة CUDA في سجلات vLLM​

  • السبب: يتجاوز طول سياق النموذج أو تخطيط الموتر VRAM المتوفرة.
  • الإصلاح: خفض --max-model-len، أو تقليل التزامن، أو زيادة سعة وحدة معالجة الرسومات. إذا كانت وحدات معالجة الرسومات المتعددة متاحة، فاضبط VLLM_TENSOR_PARALLEL لتتناسب مع الأجهزة المتاحة.

العرَض: تخرج حاوية vLLM فورًا عند بدء التشغيل​

  • السبب: فقدان وقت تشغيل/مجموعة أدوات NVIDIA، أو مسار نموذج غير صالح، أو فشل الوصول إلى النموذج المسور.
  • الإصلاح: تحقق من مجموعة أدوات حاوية NVIDIA، وتأكد من أن التحميل ./training/output يحتوي على أدلة النماذج المصدرة، وقم بتعيين HF_TOKEN عند الحاجة.

العرَض: تم رفض الاتصال بإرجاع الوكلاء​

  • السبب: يشير LLM_BACKEND إلى واجهة خلفية لا تعمل أو يشير عنوان URL إلى مضيف خاطئ.
  • الإصلاح: تأكيد صحة الخدمة (/health لـ vLLM، /api/version لـ Ollama) والتحقق من صحة قيم VLLM_BASE_URL/OLLAMA_BASE_URL لبيئة وقت التشغيل.

العرَض: لم يتم العثور على نموذج 404 من vLLM​

  • السبب: VLLM_MODEL لا يتطابق مع --served-model-name في docker-compose.yml.
  • الإصلاح: قم بمحاذاة أسماء النماذج تمامًا، بما في ذلك الواصلة وحالة الأحرف، ثم أعد تشغيل الخدمات المتأثرة.

العرَض: لم يتم العثور على نموذج Ollama خطأ​

  • السبب: لم يتم سحب/استيراد OLLAMA_MODEL أو OLLAMA_ORCHESTRATOR_MODEL الذي تم تكوينه.
  • إصلاح: تشغيل:
ollama pull granite4:8b
ollama pull granite4:dense

ثم أعد تشغيل الخدمات.

العَرض: تم تغيير LLM_BACKEND في .env لكن الوكلاء ما زالوا يستخدمون الواجهة الخلفية القديمة​

  • السبب: يتم تحميل متغيرات البيئة عند بدء الحاوية؛ الحاويات قيد التشغيل تحتفظ بالقيم السابقة.
  • الإصلاح: إعادة إنشاء الحاويات باستخدام docker compose up -d (أو إعادة تشغيل الخدمات المتأثرة بشكل صريح).