بدء استخدام vLLM بسرعة: تقديم نماذج LLM高性能

استنتاج نموذج LLM السريع باستخدام واجهة برمجة التطبيقات الخاصة بـ OpenAI

Page content

vLLM هو محرك استنتاج وتقديم ذا كفاءة عالية في الذاكرة لمحركات النماذج الكبيرة (LLMs) تم تطويره من قبل مختبر سكاي كومبيتينغ في جامعة كاليفورنيا بيركلي.

مع خوارزمية PagedAttention الثورية، يحقق vLLM أداءً أعلى بنسبة 14-24 مقارنةً بالطرق التقليدية لتقديم الخدمة، مما يجعله الخيار المثالي لتطبيقات النماذج الكبيرة في الإنتاج.

شعار vllm

ما هو vLLM؟

vLLM (النموذج الافتراضي) هو مكتبة مفتوحة المصدر لاستنتاج النماذج الكبيرة وتقديمها، وقد أصبحت معيارًا صناعيًا سريعًا لتطبيقات الإنتاج. تم إصدارها في عام 2023، وقدمت PagedAttention، وهي تقنية مبتكرة لإدارة الذاكرة تحسّن بشكل كبير كفاءة تقديم الخدمة.

الميزات الرئيسية

الأداء العالي في الاستيعاب: يوفر vLLM أداءً أعلى بنسبة 14-24 مقارنةً بـ HuggingFace Transformers مع نفس الأجهزة. يأتي هذا الزيادة الكبيرة في الأداء من خلال التجميع المستمر، والكيرنيل المحسّن CUDA، والخوارزمية PagedAttention التي تلغي تجزئة الذاكرة.

التوافق مع واجهة OpenAI: يحتوي vLLM على خادم واجهة برمجة تطبيقات مدمج تمامًا متوافق مع تنسيق OpenAI. هذا يسمح بتحوّل سلس من OpenAI إلى البنية التحتية المضيفة دون تغيير كود التطبيق. ما عليك سوى توجيه عميل واجهة برمجة تطبيقاتك إلى نقطة النهاية الخاصة بـ vLLM، ويعمل بشكل شفاف.

خوارزمية PagedAttention: الابتكار الأساسي وراء أداء vLLM هو PagedAttention، التي تطبّق مفهوم تجزئة الذاكرة الافتراضية على آليات الانتباه. بدلًا من تخصيص كتل تذكيرية متصلة لـ KV كاش (الذي يؤدي إلى تجزئة)، يقسم PagedAttention الذاكرة إلى كتل ثابتة يمكن تخصيصها حسب الحاجة. هذا يقلل هدر الذاكرة بنسبة تصل إلى 4 مرات ويعمّل على تمكين أحجام دُفعات أكبر بكثير.

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

الدعم متعدد وحدات معالجة الرسومات: يدعم vLLM التوازي المتجهي والأنبوب المتجهي لتقسيم النماذج الكبيرة عبر وحدات معالجة الرسومات متعددة. يمكنه تقديم نماذج لا تتناسب مع ذاكرة وحدة معالجة الرسومات الواحدة، مع دعم تكوينات من 2 إلى 8+ وحدات معالجة الرسومات.

الدعم الواسع للنماذج: متوافق مع معماريات النماذج الشائعة بما في ذلك LLaMA، Mistral، Mixtral، Qwen، Phi، Gemma، وغيرها الكثير. يدعم النماذج المدربة على الأوامر والنماذج الأساسية من HuggingFace Hub.

متى تستخدم vLLM

تتفوق vLLM في سيناريوهات محددة حيث تبرز قوتها:

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

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

تحسين التكلفة: عندما تكون تكلفة وحدات معالجة الرسومات مسألة، فإن أداء vLLM الأفضل يعني أنه يمكنك تقديم نفس حجم المرور مع عدد أقل من وحدات معالجة الرسومات، مما يقلل التكلفة البنية التحتية مباشرة. الكفاءة المضاعفة 4 مرات من PagedAttention تسمح أيضًا باستخدام وحدات معالجة الرسومات الأصغر والأرخص.

النشر في Kubernetes: تصميم vLLM بدون حالة وبنية معمارية ملائمة للحاويات يجعله مثاليًا لعناقيد Kubernetes. أداءه المستقر تحت الضغط وإدارة الموارد البسيطة تتكامل جيدًا مع البنية التحتية السحابية.

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

كيفية تثبيت vLLM

المتطلبات المسبقة

قبل تثبيت vLLM، تأكد من أن نظامك يلبي هذه المتطلبات:

  • وحدة معالجة الرسومات: وحدة معالجة الرسومات NVIDIA مع قدرة حسابية 7.0+ (V100، T4، A10، A100، H100، RTX 20/30/40 series)
  • CUDA: الإصدار 11.8 أو أعلى
  • Python: 3.8 إلى 3.11
  • VRAM: الحد الأدنى 16GB للنماذج 7B، 24GB+ للنماذج 13B، 40GB+ للنماذج الأكبر
  • السائق: سائق NVIDIA 450.80.02 أو أحدث

التثبيت عبر pip

أبسط طريقة للتثبيت هي استخدام pip. يعمل هذا على الأنظمة التي تحتوي على CUDA 11.8 أو أحدث:

# إنشاء بيئة افتراضية (مُنصح)
python3 -m venv vllm-env
source vllm-env/bin/activate

# تثبيت vLLM
pip install vllm

# التحقق من التثبيت
python -c "import vllm; print(vllm.__version__)"

لأنظمة تحتوي على إصدارات CUDA مختلفة، تثبيت العجلة المناسبة:

# لـ CUDA 12.1
pip install vllm==0.4.2+cu121 -f https://github.com/vllm-project/vllm/releases

# لـ CUDA 11.8
pip install vllm==0.4.2+cu118 -f https://github.com/vllm-project/vllm/releases

التثبيت عبر Docker

يوفر Docker أسلوب النشر الأكثر موثوقية، خاصةً للإنتاج:

# سحب صورة vLLM الرسمية
docker pull vllm/vllm-openai:latest

# تشغيل vLLM مع دعم وحدات معالجة الرسومات
docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model mistralai/Mistral-7B-Instruct-v0.2

العلم --ipc=host مهم للإعدادات متعددة وحدات معالجة الرسومات لأنه يسمح بالاتصال بين العمليات بشكل صحيح.

التجميع من المصدر

للحصول على أحدث الميزات أو التعديلات الخاصة، قم بتجميعها من المصدر:

git clone https://github.com/vllm-project/vllm.git
cd vllm
pip install -e .

دليل البدء السريع لـ vLLM

تشغيل النموذج الأول

ابدأ vLLM مع نموذج باستخدام واجهة سطر الأوامر:

# تحميل وتقديم Mistral-7B مع واجهة برمجة تطبيقات متوافقة مع OpenAI
python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000

سيقوم vLLM تلقائيًا بتنزيل النموذج من HuggingFace Hub (إذا لم يكن مخزنًا) ويبدأ الخادم. سترى إخراجًا يشير إلى جاهزية الخادم:

INFO:     بدأ عملية الخادم [12345]
INFO:     ينتظر بدء تطبيق.
INFO:     اكتمال بدء التطبيق.
INFO:     Uvicorn يعمل على http://0.0.0.0:8000

إجراء طلبات API

بمجرد تشغيل الخادم، يمكنك إجراء الطلبات باستخدام عميل OpenAI Python أو curl:

باستخدام curl:

curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "mistralai/Mistral-7B-Instruct-v0.2",
        "prompt": "اذكر ما هو vLLM في جملة واحدة:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

باستخدام عميل OpenAI Python:

from openai import OpenAI

# أعد توجيهك إلى خادم vLLM
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"  # لا يتطلب vLLM المصادقة بشكل افتراضي
)

response = client.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    prompt="اذكر ما هو vLLM في جملة واحدة:",
    max_tokens=100,
    temperature=0.7
)

print(response.choices[0].text)

واجهة برمجة تطبيقات إكمال المحادثة:

response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[
        {"role": "system", "content": "أنت مساعد مفيد."},
        {"role": "user", "content": "ما هو PagedAttention؟"}
    ],
    max_tokens=200
)

print(response.choices[0].message.content)

التكوين المتقدم

يقدم vLLM العديد من المعلمات لتحسين الأداء:

python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000 \
    --gpu-memory-utilization 0.95 \  # استخدام 95% من ذاكرة وحدة معالجة الرسومات
    --max-model-len 8192 \            # أقصى طول تسلسل
    --tensor-parallel-size 2 \        # استخدام 2 وحدة معالجة رسمية مع توازي متجهي
    --dtype float16 \                 # استخدام دقة FP16
    --max-num-seqs 256                # أقصى حجم دفعة

شرح المعلمات الرئيسية:

  • --gpu-memory-utilization: كمية ذاكرة وحدة معالجة الرسومات التي يجب استخدامها (0.90 = 90%). القيم الأعلى تسمح بدفعات أكبر ولكن تترك هامشًا أقل لانفجارات الذاكرة.
  • --max-model-len: أقصى طول سياق. تقليله يوفر ذاكرة لدفعات أكبر.
  • --tensor-parallel-size: عدد وحدات معالجة الرسومات التي يجب تقسيم النموذج عليها.
  • --dtype: نوع البيانات لوزن (float16، bfloat16، أو float32). FP16 عادةً هو الأفضل.
  • --max-num-seqs: أقصى عدد من التسلسلات التي يجب معالجتها في دفعة.

مقارنة vLLM مع Ollama

كلا vLLM و Ollama من البدائل الشائعة لاستضافة النماذج الكبيرة محليًا، لكنهما يستهدفان حالات استخدام مختلفة. فهم متى يجب استخدام كل أداة يمكن أن يؤثر بشكل كبير على نجاح مشروعك.

الأداء والاستيعاب

vLLM مصمم لتقديم أقصى استيعاب في السيناريوهات متعددة المستخدمين. خوارزمية PagedAttention والتجميع المستمر تسمح بتقديم مئات الطلبات المتزامنة بكفاءة. تظهر المقارنات أن vLLM تحقق استيعابًا أعلى بنسبة 14-24 مقارنةً بالimplementations القياسية و2-4 مقارنةً بـ Ollama تحت الاستيعاب العالي.

Ollama تُحسّن للاستخدام التفاعلي الفردي مع التركيز على تقليل التأخير لكل طلب. على الرغم من أنها لا تطابق أداء vLLM في الاستيعاب متعدد المستخدمين، إلا أنها توفر أداءً ممتازًا للاستخدامات التطويرية والشخصية مع أوقات بدء أسرع وانخفاض استهلاك الموارد أثناء الراحة.

سهولة الاستخدام

Ollama تتفوق بشكل قاطع على البساطة. تثبيت واحد فقط (curl | sh)، وتشغيل النماذج بسيط مثل ollama run llama2. تحتوي على مكتبة نماذج مع إصدارات مُكمّمة محسّنة لملاءمة متنوعة من مخططات الأجهزة. تجربة المستخدم تشبه Docker – اسحب، ابدأ، وانطلق.

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

واجهة API والتكامل

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

Ollama توفر واجهة API أبسط وكتابات مخصصة لـ Python/JavaScript. على الرغم من أنها وظيفية، إلا أنها ليست متوافقة مع OpenAI، مما يتطلب تغييرات في الكود عند دمجها مع تطبيقات تتوقع تنسيق OpenAI. ومع ذلك، تُقدّم مشاريع مجتمعية مثل Ollama-OpenAI adapters هذا الفجوة.

إدارة الذاكرة

خوارزمية PagedAttention لـ vLLM توفر كفاءة أفضل في إدارة الذاكرة لطلبات متزامنة. يمكنها تقديم 2-4 مرات أكثر مستخدمًا متزامنًا مع نفس VRAM مقارنةً بـ implementations بسيطة. هذا يُترجم مباشرة إلى توفير تكاليف في الإنتاج.

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

الدعم متعدد وحدات معالجة الرسومات

vLLM تتفوق مع التوازي المتجهي الأصلي والأنبوب المتجهي، وتوزيع النماذج بكفاءة عبر 2-8+ وحدات معالجة رسمية. هذا ضروري لتقديم نماذج كبيرة مثل LLMs بـ 70B معلمة لا تتناسب مع وحدة معالجة رسمية واحدة.

Ollama لديها دعم محدود متعدد وحدات معالجة الرسومات، تعمل بشكل أفضل مع وحدة معالجة رسمية واحدة. هذا يجعلها أقل مناسبة للنماذج الكبيرة التي تتطلب توزيع الاستنتاج.

توصيات استخدام

اختر vLLM عندما:

  • تقديم واجهة برمجة تطبيقات إنتاجية لمستخدمين متزامنين عديد
  • تحسين التكلفة لكل طلب في النشر السحابي
  • العمل في عناقيد Kubernetes أو منصات ترتيب الحاويات
  • تحتاج إلى توافق واجهة OpenAI للتطبيقات الحالية
  • تقديم نماذج كبيرة تتطلب دعمًا متعدد وحدات معالجة الرسومات
  • الأداء والاستيعاب مطلوبان بشكل حرج

اختر Ollama عندما:

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

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

مقارنة vLLM مع Docker Model Runner

أصدر Docker مؤخرًا Model Runner (سابقًا GenAI Stack) كحل رسمي لنشر النماذج المحلية. كيف تختلف عن vLLM؟

فلسفة العمارة

Docker Model Runner يهدف إلى أن يكون “Docker للذكاء الاصطناعي” - طريقة بسيطة ومُعيّنة لتشغيل النماذج المحلية بنفس سهولة تشغيل الحاويات. يُبسط التعقيد ويقدم واجهة متسقة عبر النماذج المختلفة والمهام.

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

الإعداد والبدء

Docker Model Runner تثبيت Docker Users سهل:

docker model pull llama3:8b
docker model run llama3:8b

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

vLLM تتطلب إعدادًا أوليًا أكثر (Python، CUDA، التبعيات) أو استخدام صور Docker المُعدة مسبقًا:

docker pull vllm/vllm-openai:latest
docker run --runtime nvidia --gpus all vllm/vllm-openai:latest --model <model-name>

خصائص الأداء

vLLM تقدم أداءً أفضل في السيناريوهات متعددة المستخدمين بسبب PagedAttention والتجميع المستمر. لخدمات واجهة برمجة التطبيقات الإنتاجية التي تتعامل مع مئات الطلبات في الثانية، تقدم تحسينات vLLM 2-5 مرات أفضل من الأساليب العامة.

Docker Model Runner تركز على سهولة الاستخدام أكثر من الأداء الأقصى. إنها مناسبة للتطوير المحلي، الاختبار، والمهام المعتدلة، لكنها لا تُنفّذ التحسينات المتقدمة التي تجعل vLLM تتفوق عند التوسع.

دعم النماذج

Docker Model Runner تقدم مكتبة نماذج مُعدة مسبقًا مع الوصول إلى نماذج شائعة في خط واحد. تدعم عدة مهام (ليس فقط النماذج الكبيرة) بما في ذلك Stable Diffusion، Whisper، ونماذج الذكاء الاصطناعي الأخرى، مما يجعلها أكثر تنوعًا لمهام الذكاء الاصطناعي المختلفة.

vLLM تخصص في استنتاج النماذج الكبيرة مع دعم عميق للنماذج اللغوية القائمة على Transformer. تدعم أي نموذج LLM متوافق مع HuggingFace، لكنها لا تمتد إلى أنواع أخرى من النماذج الذكاء الاصطناعي مثل إنشاء الصور أو التعرف على الصوت.

النشر في الإنتاج

vLLM تم اختبارها في الإنتاج في شركات مثل Anthropic، Replicate، وغيرها الكثير التي تقدم ملايين الرموز يوميًا. خصائص الأداء وثباتها تحت الضغط الشديد يجعلها المعيار المعتاد لتقديم النماذج الكبيرة في الإنتاج.

Docker Model Runner جديدة وموضعها أكثر للتطوير والاختبار المحلي. على الرغم من أنها يمكن أن تقدم حركة المرور الإنتاجية، إلا أنها تفتقر إلى السجل المثبت والأداء المحسّن الذي تتطلبه النشرات الإنتاجية.

نظام التكامل

vLLM تتكامل مع أدوات البنية التحتية الإنتاجية: مُشغل Kubernetes، متر Prometheous، Ray لتقديم الخدمة الموزعة، وتكامل واسع مع واجهة OpenAI لتطبيقات موجودة.

Docker Model Runner تتكامل بشكل طبيعي مع نظام Docker و Docker Desktop. بالنسبة للفرق التي استثمرت في نظام Docker، هذه التكامل توفر تجربة متماسكة ولكن أقل ميزات خدمة النماذج الكبيرة.

متى تستخدم كل منهما

استخدم vLLM لـ:

  • خدمات واجهة برمجة التطبيقات النماذج الكبيرة في الإنتاج
  • الاستيعاب العالي والنشر متعدد المستخدمين
  • النشر السحابي المكلف بتقنيات كفاءة أقصى
  • عناقيد Kubernetes وبنية تحتية سحابية
  • عندما تحتاج إلى كفاءة قابلة للتوسع والأداء

استخدم Docker Model Runner لـ:

  • التطوير المحلي والاختبار
  • تشغيل أنواع مختلفة من نماذج الذكاء الاصطناعي (ليس فقط النماذج الكبيرة)
  • الفرق التي استثمرت بشكل كبير في نظام Docker
  • التجريب السريع دون إعداد البنية التحتية
  • الأغراض التعليمية

النهج الهجين: تستخدم العديد من الفرق Docker Model Runner محليًا للراحة، ثم تنشر مع vLLM في الإنتاج للأداء. يمكن استخدام صور Docker Model Runner أيضًا لتشغيل حاويات vLLM، مما يجمع بين كلا النهجين.

أفضل الممارسات للنشر في الإنتاج

النشر عبر Docker

أنشئ تكوين Docker Compose قابل للإنتاج:

version: '3.8'

services:
  vllm:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    environment:
      - CUDA_VISIBLE_DEVICES=0,1
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
      - ./logs:/logs
    ports:
      - "8000:8000"
    command: >
      --model mistralai/Mistral-7B-Instruct-v0.2
      --tensor-parallel-size 2
      --gpu-memory-utilization 0.90
      --max-num-seqs 256
      --max-model-len 8192      
    restart: unless-stopped
    shm_size: '16gb'
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 2
              capabilities: [gpu]

النشر عبر Kubernetes

نشر vLLM على Kubernetes للاستيعاب الإنتاجي:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
          - --model
          - mistralai/Mistral-7B-Instruct-v0.2
          - --tensor-parallel-size
          - "2"
          - --gpu-memory-utilization
          - "0.90"
        resources:
          limits:
            nvidia.com/gpu: 2
        ports:
        - containerPort: 8000
        volumeMounts:
        - name: cache
          mountPath: /root/.cache/huggingface
      volumes:
      - name: cache
        hostPath:
          path: /mnt/huggingface-cache
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  selector:
    app: vllm
  ports:
  - port: 80
    targetPort: 8000
  type: LoadBalancer

المراقبة والشفافية

يُصدر vLLM متر Prometheus للاستعانة به:

import requests

# الحصول على المتر
metrics = requests.get("http://localhost:8000/metrics").text
print(metrics)

المترات الرئيسية التي يجب مراقبتها:

  • vllm:num_requests_running - الطلبات النشطة
  • vllm:gpu_cache_usage_perc - استخدام ذاكرة كاش GPU
  • vllm:time_to_first_token - متر التأخير
  • vllm:time_per_output_token - سرعة الإنتاج

تحسين الأداء

تحسين استخدام ذاكرة وحدة معالجة الرسومات: ابدأ بـ --gpu-memory-utilization 0.90 وقم بتعديلها بناءً على السلوك الملاحظ. القيم الأعلى تسمح بدفعات أكبر لكنها تزيد من خطر أخطاء OOM أثناء ذروة الحركة المرورية.

تخصيص أقصى طول تسلسل: إذا لم يكن استخدامك يتطلب طول سياق كامل، قلل من --max-model-len. هذا يحرر الذاكرة لدفعات أكبر. على سبيل المثال، إذا كنت بحاجة فقط إلى 4K من السياق، ضع --max-model-len 4096 بدلًا من استخدام أقصى قيمة النموذج (غالبًا 8K-32K).

اختر كميات مناسبة: للنماذج التي تدعم ذلك، استخدم إصدارات مُكمّمة (8-bit، 4-bit) لتقليل الذاكرة وزيادة الاستيعاب:

--quantization awq  # لنموذج AWQ مُكمّم
--quantization gptq # لنموذج GPTQ مُكمّم

تفعيل تخزين المقدمة: للتطبيقات ذات المطالبات المتكررة (مثل روبوتات المحادثة مع رسائل النظام)، قم بتفعيل تخزين المقدمة:

--enable-prefix-caching

هذا يخزن قيم KV للمقدمة الشائعة، مما يقلل الحساب للمطالبات التي تشارك نفس مقدمة المطالبة.

استكشاف المشكلات الشائعة

أخطاء نقص الذاكرة

الأعراض: يتعطل الخادم مع أخطاء نقص الذاكرة في CUDA.

الحلول:

  • خفض --gpu-memory-utilization إلى 0.85 أو 0.80
  • خفض --max-model-len إذا كان استخدامك يسمح بذلك
  • خفض --max-num-seqs لتقليل حجم الدفعة
  • استخدام إصدار مُكمّم من النموذج
  • تفعيل التوازي المتجهي لتوزيعه عبر وحدات معالجة رسمية أكثر

الاستيعاب المنخفض

الأعراض: الخادم يتعامل مع عدد أقل من الطلبات من المتوقع.

الحلول:

  • زيادة --max-num-seqs لسماح دفعات أكبر
  • رفع --gpu-memory-utilization إذا كان لديك هامش
  • تحقق من أن CPU لم تكن محورًا مع htop – قد تنظر في CPUs أسرع
  • تحقق من استخدام وحدة معالجة الرسومات مع nvidia-smi – يجب أن يكون 95%+
  • تفعيل FP16 إذا كنت تستخدم FP32: --dtype float16

تأخير أول رمز

الأعراض: تأخير عالي قبل بدء الإنتاج.

الحلول:

  • استخدام نماذج أصغر للتطبيقات التي تعتمد على التأخير
  • تفعيل تخزين المقدمة للمطالبات المتكررة
  • خفض --max-num-seqs لتركيز التأخير على الأداء
  • تفكير في التحليل التنبؤي لدعم النماذج
  • تحسين تكوين التوازي المتجهي

فشل تحميل النموذج

الأعراض: لا يمكن للخادم البدء، لا يمكن تحميل النموذج.

الحلول:

  • تأكد من أن اسم النموذج يتطابق تمامًا مع تنسيق HuggingFace
  • تحقق من اتصال الشبكة مع HuggingFace Hub
  • تأكد من وجود مساحة كافية في ~/.cache/huggingface
  • لنموذج مغلق، ضع متغير البيئة HF_TOKEN
  • جرّب التنزيل يدويًا مع huggingface-cli download <model>

الميزات المتقدمة

التحليل التنبؤي

تدعم vLLM التحليل التنبؤي، حيث يقترح نموذج أصغر تسلسلات تُتحقق من خلال نموذج كبير. يمكن هذا تسريع الإنتاج بنسبة 1.5-2 مرات:

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-70b-chat-hf \
    --speculative-model meta-llama/Llama-2-7b-chat-hf \
    --num-speculative-tokens 5

محولات LoRA

تقديم عدة محولات LoRA فوق نموذج أساسي دون تحميل عدة نماذج كاملة:

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-7b-hf \
    --enable-lora \
    --lora-modules sql-lora=./path/to/sql-adapter \
                   code-lora=./path/to/code-adapter

ثم تحديد المحول الذي يجب استخدامه لكل طلب:

response = client.completions.create(
    model="sql-lora",  # استخدام محول SQL
    prompt="حول هذا إلى SQL: أظهر لي جميع المستخدمين الذين تم إنشاؤهم هذا الشهر"
)

تقديم متعدد LoRA

يسمح vLLM بتقديم متعدد LoRA بتشغيل مئات المحولات المدربة مع هامش صغير من ذاكرة. هذا مثالي لتقديم نماذج مخصصة لمستخدمين أو مهام محددة:

# طلب مع محول LoRA محدد
response = client.chat.completions.create(
    model="meta-llama/Llama-2-7b-hf",
    messages=[{"role": "user", "content": "اكتب استعلام SQL"}],
    extra_body={"lora_name": "sql-lora"}
)

تخزين المقدمة

تفعيل تخزين المقدمة تلقائيًا لتجنب إعادة حساب كاش KV للمقدمة المتكررة:

--enable-prefix-caching

هذا فعّال بشكل خاص لـ:

  • روبوتات المحادثة ذات رسائل النظام الثابتة
  • تطبيقات RAG ذات قوالب سياق ثابتة
  • مطالبات التعلم القصير المتكررة عبر الطلبات

يمكن تخزين المقدمة تقليل وقت أول رمز بنسبة 50-80% للطلبات التي تشارك مقدمة المطالبة.

أمثلة التكامل

تكامل LangChain

from langchain.llms import VLLMOpenAI

llm = VLLMOpenAI(
    openai_api_key="EMPTY",
    openai_api_base="http://localhost:8000/v1",
    model_name="mistralai/Mistral-7B-Instruct-v0.2",
    max_tokens=512,
    temperature=0.7,
)

response = llm("اذكر PagedAttention ببساطة")
print(response)

تكامل LlamaIndex

from llama_index.llms import VLLMServer

llm = VLLMServer(
    api_url="http://localhost:8000/v1",
    model="mistralai/Mistral-7B-Instruct-v0.2",
    temperature=0.7,
    max_tokens=512
)

response = llm.complete("ما هو vLLM؟")
print(response)

تطبيق FastAPI

from fastapi import FastAPI
from openai import AsyncOpenAI

app = FastAPI()
client = AsyncOpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"
)

@app.post("/generate")
async def generate(prompt: str):
    response = await client.completions.create(
        model="mistralai/Mistral-7B-Instruct-v0.2",
        prompt=prompt,
        max_tokens=200
    )
    return {"result": response.choices[0].text}

مقارنات الأداء

بيانات الأداء الفعلية تساعد في توضيح مزايا vLLM:

مقارنة الاستيعاب (Mistral-7B على وحدة معالجة الرسومات A100):

  • vLLM: ~3,500 رموز/ثانية مع 64 مستخدمًا متزامنًا
  • HuggingFace Transformers: ~250 رموز/ثانية مع نفس التزامن
  • Ollama: ~1,200 رموز/ثانية مع نفس التزامن
  • النتيجة: vLLM توفر تحسنًا بنسبة 14 مقارنةً بالimplementations الأساسية

كفاءة الذاكرة (LLaMA-2-13B):

  • Implementation الأساسية: 24GB VRAM، 32 تسلسل متزامن
  • vLLM مع PagedAttention: 24GB VRAM، 128 تسلسل متزامن
  • النتيجة: 4 مرات أكثر طلبًا متزامنًا مع نفس الذاكرة

التأخير تحت الحمل (Mixtral-8x7B على 2xA100):

  • vLLM: P50 التأخير 180ms، P99 التأخير 420ms عند 100 طلب/ثانية
  • تقديم الخدمة الأساسية: P50 التأخير 650ms، P99 التأخير 3,200ms عند 100 طلب/ثانية
  • النتيجة: vLLM تحافظ على تأخير ثابت تحت الحمل العالي

توضح هذه المقارنات لماذا أصبحت vLLM المعيار المعتاد لتقديم النماذج الكبيرة في الإنتاج حيث يهم الأداء.

تحليل التكاليف

فهم التكاليف المرتبطة باختيار vLLM:

السيناريو: تقديم 1 مليون طلب/يوم

مع تقديم الخدمة الأساسية:

  • المطلوب: 8x وحدة معالجة الرسومات A100 (80GB)
  • تكلفة AWS: ~$32/ساعة × 24 × 30 = $23,040/شهر
  • تكلفة لكل مليون رموز: ~$0.75

مع vLLM:

  • المطلوب: 2x وحدة معالجة الرسومات A100 (80GB)
  • تكلفة AWS: ~$8/ساعة × 24 × 30 = $5,760/شهر
  • تكلفة لكل مليون رموز: ~$0.19
  • الوفاء: $17,280/شهر (75% تقليل)

يزداد هذا الميزة التكلفة مع التوسع. تُوفر المؤسسات التي تقدم ملايين الرموز شهريًا مئات الآلاف من الدولارات باستخدام vLLM المحسّن بدلاً من implementions بسيطة.

اعتبارات الأمان

المصادقة

لا تشمل vLLM المصادقة بشكل افتراضي. للإنتاج، قم بتنفيذ المصادقة على مستوى Proxy العكسي:

# تكوين Nginx
location /v1/ {
    auth_request /auth;
    proxy_pass http://vllm-backend:8000;
}

location /auth {
    proxy_pass http://auth-service:8080/verify;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;
}

أو استخدم بوابات API مثل Kong، Traefik، أو AWS API Gateway للاuthentication والحد من المعدلات في مستوى المؤسسة.

العزل الشبكي

قم بتشغيل vLLM في شبكات خاصة، لا تُعرض مباشرةً على الإنترنت:

# مثال لـ NetworkPolicy في Kubernetes
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: vllm-access
spec:
  podSelector:
    matchLabels:
      app: vllm
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api-gateway
    ports:
    - protocol: TCP
      port: 8000

الحد من المعدل

قم بتطبيق الحد من المعدل لمنع الاستغلال:

# مثال باستخدام Redis للحد من المعدل
from fastapi import FastAPI, HTTPException
from fastapi.middleware.cors import CORSMiddleware
import redis
from datetime import datetime, timedelta

app = FastAPI()
redis_client = redis.Redis(host='localhost', port=6379)

@app.middleware("http")
async def rate_limit_middleware(request, call_next):
    client_ip = request.client.host
    key = f"rate_limit:{client_ip}"
    
    requests = redis_client.incr(key)
    if requests == 1:
        redis_client.expire(key, 60)  # نافذة 60 ثانية
    
    if requests > 60:  # 60 طلبًا في الدقيقة
        raise HTTPException(status_code=429, detail="تم تجاوز الحد الأقصى للمعدل")
    
    return await call_next(request)

تحكم الوصول إلى النموذج

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

ALLOWED_MODELS = {
    "user_tier_1": ["mistralai/Mistral-7B-Instruct-v0.2"],
    "user_tier_2": ["mistralai/Mistral-7B-Instruct-v0.2", "meta-llama/Llama-2-13b-chat-hf"],
    "admin": ["*"]  # جميع النماذج
}

def verify_model_access(user_tier: str, model: str) -> bool:
    allowed = ALLOWED_MODELS.get(user_tier, [])
    return "*" in allowed or model in allowed

دليل الهجرة

من OpenAI إلى vLLM

تتم هجرة OpenAI إلى vLLM المضيفة بسهولة بسبب توافق واجهة API:

قبل (OpenAI):

from openai import OpenAI

client = OpenAI(api_key="sk-. ..")
response = client.chat.completions.create(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": "مرحبا"}]
)

بعد (vLLM):

from openai import OpenAI

client = OpenAI(
    base_url="https://your-vllm-server.com/v1",
    api_key="your-internal-key"  # إذا أضفت المصادقة
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "مرحبا"}]
)

التعديلات الوحيدة المطلوبة هي تحديث base_url واسم model. يبقى كل الكود الآخر متطابقًا.

من Ollama إلى vLLM

يستخدم Ollama تنسيق واجهة API مختلف. إليك التحويل:

واجهة Ollama API:

import requests

response = requests.post('http://localhost:11434/api/generate',
    json={
        'model': 'llama2',
        'prompt': 'لماذا السماء زرقاء؟'
    })

مثيل vLLM:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
response = client.completions.create(
    model="meta-llama/Llama-2-7b-chat-hf",
    prompt="لماذا السماء زرقاء؟"
)

عليك تحديث مكالمات API عبر كودك، ولكن مكتبات OpenAI توفر تحسينات أفضل في التعامل مع الأخطاء والميزات.

من HuggingFace Transformers إلى vLLM

الهجرة المباشرة من استخدام Python:

HuggingFace:

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")
tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")

inputs = tokenizer("مرحبا", return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=100)
result = tokenizer.decode(outputs[0])

vLLM:

from vllm import LLM, SamplingParams

llm = LLM(model="mistralai/Mistral-7B-Instruct-v0.2")
sampling_params = SamplingParams(max_tokens=100)

outputs = llm.generate("مرحبا", sampling_params)
result = outputs[0].outputs[0].text

واجهة Python لـ vLLM أبسط بكثير وأسرع للاستنتاج بالدفعة.

مستقبل vLLM

يستمر vLLM في التطوير السريع مع ميزات مثيرة على الطريق:

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

تقديم متعدد العقد: توزيع النماذج الكبيرة جدًا (100B+ معلمات) عبر عدة أجهزة، مما يسمح بتقديم نماذج لا تتناسب مع تكوينات العقدة الواحدة.

تحسين الكمية: دعم تنسيقات جديدة من الكمية مثل GGUF (المستخدم من قبل llama.cpp) وتحسين AWQ/GPTQ للحصول على أداء أفضل مع النماذج المُكمّمة.

تحسينات في التحليل التنبؤي: نماذج مُقدمة أكثر كفاءة واستراتيجيات تحليل تنبؤية متكيفة للحصول على تحسينات سرعة أكبر دون فقدان الدقة.

تحسينات في الانتباه: FlashAttention 3، الانتباه الحلقي لسياقات طويلة جدًا (100K+ رموز)، وآليات انتباه متطورة أخرى.

توسيع دعم النماذج: توسيع الدعم إلى نماذج متعددة الوسائط (نماذج لغوية-بصرية)، نماذج الصوت، وعمليات معمارية مخصصة مع ظهورها.

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

روابط مفيدة

مقالات متعلقة على هذا الموقع

  • استضافة نماذج الذكاء الاصطناعي محليًا: دليل شامل لعام 2025 - Ollama، vLLM، LocalAI، Jan، LM Studio والمزيد - مقارنة شاملة لأكثر من 12 أداة لاستضافة نماذج الذكاء الاصطناعي محليًا، بما في ذلك تحليل تفصيلي لـ vLLM إلى جانب Ollama، LocalAI، Jan، LM Studio وغيرها. تغطي نضج واجهات برمجة التطبيقات، دعم مكالمات الأدوات، توافق GGUF والأداء لمساعدتك في اختيار الحل المناسب.

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

  • Docker Model Runner مقابل Ollama: أيهما تختار؟ - مقارنة مفصلة بين Docker Model Runner وOllama لاستضافة نماذج الذكاء الاصطناعي محليًا، تحليل الأداء، دعم وحدات المعالجة الرسومية، توافق واجهات برمجة التطبيقات، والتطبيقات. تساعد على فهم المنافسة التي ينافسها vLLM.

  • دفتر ملاحظات Docker Model Runner: الأوامر والأمثلة - دفتر ملاحظات عملي لـ Docker Model Runner مع الأوامر والأمثلة لنشر النماذج الذكية. مفيد للمجموعات التي تقارن نهج Docker مع قدرات خدمة LLM المتخصصة لـ vLLM.

مصادر خارجية ومستندات

  • مستودع vLLM على GitHub - المستودع الرسمي لـ vLLM مع الكود المصدر، والمستندات الشاملة، والدليل لتثبيت البرنامج، والنقاشات النشطة في المجتمع. موارد ضرورية للبقاء على اطلاع بأحدث الميزات ومتابعة المشكلات.

  • مستندات vLLM - المستندات الرسمية التي تغطي جميع جوانب vLLM من التثبيت الأساسي إلى التكوين المتقدم. تشمل مراجع واجهات برمجة التطبيقات، دليل تعديل الأداء، وأفضل الممارسات للاستضافة.

  • ورقة بحثية PagedAttention - ورقة بحثية تقدم خوارزمية PagedAttention التي تُستخدم في كفاءة vLLM. قراءة ضرورية لفهم الابتكارات التقنية وراء مزايا الأداء لـ vLLM.

  • مدونة vLLM - مدونة رسمية لـ vLLM تقدم إعلانات الإصدار، اختبارات الأداء، تحليلات تقنية، ودراسات حالة من المجتمع من عمليات الاستخدام.

  • مستودع HuggingFace Models - مستودع شامل للنماذج المفتوحة المصدر التي تعمل مع vLLM. ابحث عن النماذج حسب الحجم، المهام، الترخيص، وخصائص الأداء للعثور على النموذج المناسب لحالتك.

  • مستندات Ray Serve - مستندات إطارات Ray Serve لبناء استضافات موسعة ومتوزعة لـ vLLM. تقدم Ray ميزات متقدمة مثل التوسع التلقائي، خدمة نماذج متعددة، وإدارة الموارد لنظامات الإنتاج.

  • TensorRT-LLM من NVIDIA - TensorRT-LLM من NVIDIA لاستنتاج محسّن على وحدات معالجة الرسومات من NVIDIA. بديل لـ vLLM مع استراتيجيات تحسين مختلفة، مفيد للمقارنة وفهم منظور تحسين الاستنتاج.

  • مراجع واجهات برمجة التطبيقات من OpenAI - مستندات OpenAI API الرسمية التي توافق مع واجهات برمجة التطبيقات لـ vLLM. استخدم هذه المستندات عند بناء تطبيقات تحتاج إلى العمل مع واجهات OpenAI ونقاط النهاية المضيفة محليًا لـ vLLM تبادلًا.