إعداد خادم الاستدلال: vLLM، llama.cpp، SGLang

وصلت الأجهزة، ويعمل برنامج التشغيل، nvidia-smi يعرض كل بطاقة. الآن، السؤال هو: ما الذي يُقدّم الرموز فعليًا؟ الإجابة هي واحدة من أربع أو خمس مجموعات تقديم مفتوحة، والاختيار الخاطئ سيكلفك ضعف الإنتاجية، وثلاثة أضعاف زمن الاستجابة، أو ثلاثة أيام من تصحيح الأخطاء. تُقدّم هذه المقالة خيارًا موضوعيًا بينها، وتشرح بالتفصيل الإعداد للخيار الذي ينبغي على معظم عملاء كينتينو اختياره أولًا: vLLM في Docker، مع الصورة المُعتمدة من NGC، على نقطة نهاية متوافقة مع OpenAI.

الجمهور: شخص قرأ L02، يمكن تشغيله docker run --gpus all nvidia-smiوالآن يحتاج إلى الطبقة التالية.

مصفوفة القرار

خمس مجموعات تستحق النظر فيها في مايو 2026. أما الباقي فهو إما غلاف حول إحدى هذه المجموعات أو مشروع بحثي.

باختصار، إذا كنت غير متأكد، شغّل vLLM في حاوية NGC. إذا كان عبء العمل لديك كثيفًا بالمخرجات المنظمة أو مطالبات النظام المشتركة، فشغّل SGLang. إذا كنت تستخدم Jetson أو جهاز تطوير 4090 واحدًا، فشغّل llama.cpp. أما ما عدا ذلك فهو حالات استثنائية.

يُعدّ vLLM هو الوضع الافتراضي، وهذا هو السبب.

يُعدّ vLLM (الإصدار 0.20+ اعتبارًا من مايو 2026) أكثر حزم الخدمة المفتوحة انتشارًا لأنظمة إدارة التعلم (LLMs) وأنظمة إدارة التعلم الافتراضية (VLMs) الخاصة بالمحولات. ثلاثة عوامل تمنحه هذه الميزة:

1. الخلط المستمر تنضم الطلبات الواردة إلى مجموعة الطلبات الجارية في عملية المعالجة التالية. يرتفع استخدام وحدة معالجة الرسومات على نقطة نهاية ذات حركة مرور مختلطة من 40% إلى أكثر من 85% مقارنةً باستنتاج HuggingFace البسيط المجمع.
2. PagedAttention بالإضافة إلى التخزين المؤقت للبادئة تُدار ذاكرة التخزين المؤقت للقيم والمفاتيح (KV) في كتل ثابتة الحجم، مثل صفحات الذاكرة الافتراضية لنظام التشغيل. يتشارك طلبان يشتركان في موجه النظام كتل KV الخاصة بهذا البادئة. بالنسبة لسير عمل الوكيل الذي يستخدم موجهات نظام مشتركة بحجم 2 كيلوبايت، تتراوح نسبة نجاح ذاكرة التخزين المؤقت للبادئة بين 80 و95%.
3. بلاكويل - أول حبوب — FlashAttention 3، FP8 attention، MXFP4 weight-only quant، ومسار matmul القائم على CUTLASS يستهدف sm_120 (5090، RTX Pro 6000 Blackwell) و sm_100 (B200) بشكل أصلي.

يُعد CUDA 13 هو الإصدار الافتراضي لملفات PyPI v0.20+، و vllm/vllm-openai:latest صورة. لا تزال عجلات CUDA 12.8 تُشحن كبديل لـ sm_120.

تثبيت vLLM: pip مقابل Docker

هناك مساران للتثبيت. اختر Docker إلا إذا كان لديك سبب محدد لعدم القيام بذلك.

المسار أ - استخدام pip في بيئة افتراضية (للتطوير فقط)

python3.12 -m venv ~/venvs/vllm && source ~/venvs/vllm/bin/activate
pip install --upgrade pip && pip install vllm   # CUDA 13.0 wheels by default

vllm serve meta-llama/Llama-3.3-70B-Instruct-FP8 --tensor-parallel-size 4 --port 8000

يعمل Pip بكفاءة وسرعة أكبر عند التعامل مع علامات المحرك. كما أنه يربط مُفسِّر بايثون، وبيئة تشغيل CUDA، وتوافق برامج التشغيل مع إعدادات مضيف واحد. استخدمه في بيئة التطوير، وليس في بيئة الإنتاج.

المسار ب — Docker مع الصورة الأصلية (الإعداد الافتراضي للإنتاج)

docker run --gpus all --runtime nvidia \
  --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3.3-70B-Instruct-FP8 \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.92 \
  --max-model-len 8192 \
  --enable-prefix-caching

ملاحظات تضرّ من يتجاهلها:

• --ipc=host هذا مطلوب لوحدات معالجة الرسومات المتعددة. تتواصل وحدات vLLM العاملة عبر الذاكرة المشتركة؛ مساحة اسم Docker IPC الافتراضية هي 64 ميجابايت ولا يمكنها استيعاب مخازن NCCL المؤقتة.
• قم بتثبيت ذاكرة التخزين المؤقت لـ HuggingFace. وإلا، فسيتم تنفيذ كل شيء. docker run يعيد تنزيل 75 جيجابايت من الأوزان.
• قم بتثبيت علامة للإنتاج: vllm/vllm-openai:v0.20.2 لست :latest.

شركة NGC nvcr.io/nvidia/vllm:25.09-py3 يأتي هذا الإصدار مزودًا بـ CUDA 13.0، ونسخة مُختبرة من vLLM، وNCCL، وشهادة ضمان الجودة من NVIDIA. حجمه أكبر (حوالي 12 جيجابايت)، ويتأخر عن الإصدار الأصلي بشهر أو شهرين. استخدمه إذا كنت تُشغّل أيضًا TensorRT-LLM أو Triton على نفس الجهاز وترغب في استخدام حزمة CUDA/NCCL واحدة لجميعها. وإلا، فإن صورة Docker Hub أصغر حجمًا وأحدث، وتُعادلها.

الأعلام التي تهم فعلاً

يُتيح vLLM ما يقارب مئتي خيار في واجهة سطر الأوامر. معظمها ظرفي. أما الخيارات التي ستستخدمها في كل مرة فهي:

--gpu-memory-utilization هذه هي العلامة الأكثر ضبطًا. يستخدمها vLLM لتحديد مقدار ذاكرة الوصول العشوائي للفيديو (VRAM) التي يجب تخصيصها مسبقًا بعد تحميل الأوزان؛ ويصبح المتبقي منها مخزنًا مؤقتًا لـ KV. انخفاض القيمة إلى حد كبير يؤدي إلى مقاطعة KV مبكرة تحت الضغط. ارتفاع القيمة إلى حد كبير يؤدي إلى نفاد الذاكرة عند أول طلب سياق طويل. 0.92 هي نقطة بداية معقولة لصندوق استدلال مخصص. خفّض القيمة إلى 0.85 إذا كنت تشارك وحدة معالجة الرسومات (GPU).

ثلاثة أوامر إطلاق محددة

هذه هي الإعدادات التي يستخدمها عملاء كينتينو فعليًا. جميعها تفترض استخدام CUDA 13.0، وبرنامج التشغيل 570+، وصورة Docker، و --ipc=host.

Qwen 2.5 72B Instruct INT4 (AWQ) على 4× RTX Pro 6000 Blackwell

docker run --gpus all --runtime nvidia --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
  vllm/vllm-openai:v0.20.2 \
  --model Qwen/Qwen2.5-72B-Instruct-AWQ \
  --quantization awq \
  --tensor-parallel-size 4 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.92 \
  --enable-prefix-caching \
  --max-num-seqs 64 \
  --port 8000

يبلغ حجم البيانات المُخزّنة حوالي 36 جيجابايت عند مستوى INT4، موزعة على 4 بطاقات ذاكرة سعة كل منها 96 جيجابايت. عند معدل نقل البيانات TP=4، تستخدم كل بطاقة ربع قيمة المفتاح (KV) لكل طلب، لذا فإن 32 ألف سياق مع 64 مستخدمًا متزامنًا يقع ضمن الميزانية المحددة. يُتوقع أن يتراوح معدل نقل البيانات بين 40 و60 توك/ثانية لكل طلب عند التزامن المنخفض، وإجمالي يتراوح بين 600 و900 توك/ثانية عند 32 مستخدمًا متزامنًا.

لاما 3.3 70B تعليمات FP8 على 8× RTX 5090

docker run --gpus all --runtime nvidia --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
  vllm/vllm-openai:v0.20.2 \
  --model meta-llama/Llama-3.3-70B-Instruct-FP8 \
  --quantization fp8 \
  --tensor-parallel-size 4 \
  --pipeline-parallel-size 2 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --max-num-seqs 64 \
  --swap-space 4 \
  --port 8000

لاحظ أن TP=4 × PP=2، وليس TP=8. تحتوي بطاقات 5090 على 32 جيجابايت لكل منها؛ تبلغ أوزان FP8 لـ 70 بايت حوالي 75 جيجابايت، أي أقل بكثير من 128 جيجابايت على أربع بطاقات. يتجنب تقسيم خط الأنابيب التضخم الناتج عن عملية الاختزال الكاملة التي قد يتسبب بها TP=8 عبر PCIe (انظر كيه03 , N03). TP=8 على مقياس PCIe أسوأ من TP=4 × PP=2 مع التجميع المستمر عند التزامن فوق 8.

Qwen 2.5 VL 32B على جهازين 5090

docker run --gpus all --runtime nvidia --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:v0.20.2 \
  --model Qwen/Qwen2.5-VL-32B-Instruct-AWQ \
  --quantization awq \
  --tensor-parallel-size 2 \
  --max-model-len 16384 \
  --limit-mm-per-prompt '{"image": 4, "video": 0}' \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --port 8000

معالجين 5090، وذاكرة تخزين داخلية من النوع INT4 بسعة 20 جيجابايت تقريبًا، ومساحة كافية لوحدة تشفير الرؤية + KV. أما نسخة 72B VL فتقوم بما يلي: لست يمكن تركيبها على بطاقتي 5090 حتى في وضع INT4؛ استخدم 4× 5090 أو بطاقة Pro 6000 واحدة لذلك. --limit-mm-per-prompt يحد النظام من عدد الصور لكل طلب - قد يؤدي طلب واحد يحتوي على 20 صورة إلى نفاد ذاكرة مُشفِّر الرؤية على جهاز 5090. نقطة النهاية متوافقة مع OpenAI (POST /v1/chat/completions مع image_url أجزاء).

SGLang — عندما يتفوق جهاز التوجيه الخاص بها على vLLM

تعتمد SGLang على تقنية RadixAttention: إعادة استخدام ذاكرة التخزين المؤقت للبادئات، المُطبقة كشجرة جذرية عبر الطلبات، وليس فقط مطابقة تساوي الكتل. بالنسبة لأحمال العمل التي تتشارك فيها معظم الطلبات مطالبات نظام طويلة، يتفوق معدل نجاح SGLang على ذاكرة التخزين المؤقت للبادئات في vLLM. تُظهر المعايير العامة أن SGLang تصل إلى حوالي 16 ألف tok/ثانية مقابل حوالي 12 ألف tok/ثانية في vLLM على H100 لأحمال العمل ذات البادئات المشتركة، مع وجود فجوات أكبر بكثير في حركة مرور الإخراج المهيكل.

نقاط قوة لغة SGLang:

• JSON منظم باستخدام xGrammar. أسرع وأكثر توافقًا من فك التشفير المقيد في vLLM. وهذا أمر بالغ الأهمية بالنسبة لواجهة برمجة تطبيقات JSON التي تتلقى ملايين الطلبات.
• DeepSeek-V3 وغيرها من برامج MoE الكبيرة. تم إصدار خاصية التوازي الواسع للخبراء وتفكيك التعبئة المسبقة/فك التشفير في وقت سابق؛ ولا تزال متقدمة على نطاق العقد المتعددة.
• سير عمل الوكلاء مع مطالبات النظام المشتركة. نقاط نهاية RAG، والطيارين المساعدين، ومطالبات النظام بحجم 2-4 كيلوبايت المشتركة عبر معظم الطلبات.

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

docker run --gpus all --runtime nvidia --ipc=host \
  -p 30000:30000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  lmsysorg/sglang:latest \
  python3 -m sglang.launch_server \
    --model-path Qwen/Qwen2.5-72B-Instruct-AWQ \
    --quantization awq \
    --tp 4 \
    --port 30000 \
    --host 0.0.0.0

يُوفّر SGLang نقطة نهاية متوافقة مع OpenAI على منفذه الخاص (30000 افتراضيًا). يُمكنك استخدامه مباشرةً مع نفس كود العميل، بالإضافة إلى نقاط نهاية توليد البيانات المهيكلة الأصلية لـ SGLang. نصيحتي الصادقة: جرّب vLLM أولًا. إذا كان معدل نجاح البادئة المشتركة لديك أعلى من 60% تقريبًا، وكنتَ تُولي اهتمامًا لزمن الاستجابة، فأعد الاختبار باستخدام SGLang واختر الأنسب.

llama.cpp — عندما يفوز الصغير والمفرد

llama.cpp عبارة عن برنامج استدلال مكتوب بلغة C++ بدون بيئة تشغيل بايثون، ولا يعتمد على CUDA، ويستخدم تنسيق أوزان GGUF الذي يجمع بيانات تعريف التكميم في الملف. يعمل البرنامج على وحدة المعالجة المركزية، أو وحدة معالجة رسومية واحدة، أو أجهزة Mac من سلسلة M، أو Jetson، أو جزئيًا على كل منها. لا يستخدم البرنامج التوازي الموتري كما في vLLM. نموذج واحد، حلقة استدلال واحدة، وسرعة فائقة.

متى يكون ملف llama.cpp هو الإجابة الصحيحة؟

• جيتسون أورين. لا يدعم vLLM معالجات Jetson بشكل جيد، بينما يدعمها llama.cpp. وهذا هو الحل الأمثل لنموذج مدمج في Unitree G1.
• صندوق تطوير واحد 5090 / 4090. مطور واحد يقوم بالتكرار، بدون تزامن، وأسرع مسار تثبيت.
• توزيع مختلط بين وحدة المعالجة المركزية ووحدة معالجة الرسومات. لا يتوافق محرك الأقراص 70B مع بطاقة 5090 (32 جيجابايت). -ngl 40يتم إرسال 40 طبقة من أصل 80 إلى وحدة معالجة الرسومات، بينما يتم تشغيل الباقي على وحدة المعالجة المركزية بسرعة مقبولة للمستخدم الواحد.
• جهاز مدمج. لا حاجة إلى Docker، ولا مشاكل عدم توافق برامج التشغيل، ولا حاجة إلى Python.

خيارات التكميم في GGUF، مرتبة حسب الحجم مقابل الجودة:

Q4_K_M هو الإعداد الافتراضي الصحيح. استخدم Q5_K_M إذا كان لديك مساحة كافية. استخدم Q8_0 فقط للتأكد من عدم وجود فقدان في الكمية. تُعدّ وحدات i-quants (مثل IQ4_XS) تطورًا واعدًا لعامي 2025/2026، ويستحق التجربة عند محاولة تثبيت 70 مليار على بطاقة ذاكرة واحدة بسعة 32 جيجابايت.

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON && cmake --build build --config Release -j

./build/bin/llama-server \
  --model models/qwen2.5-72b-instruct-q4_k_m.gguf \
  --n-gpu-layers 99 --ctx-size 32768 \
  --host 0.0.0.0 --port 8080 --api-key sk-localdev

-ngl 99 يُخفف هذا النظام عبء العمل عن أكبر عدد ممكن من الطبقات. نقطة النهاية متوافقة مع OpenAI على :8080/v1/chat/completionsبالنسبة لأحمال المستخدمين المتعددين، هذه الأداة غير مناسبة - استخدم vLLM. أما بالنسبة لمستخدم واحد على جهاز 5090 واحد أو Jetson، فهي الأداة المناسبة.

TensorRT-LLM و Triton - الخيار الثقيل

TensorRT-LLM هو مُجمِّع NVIDIA المُحسِّن لاستنتاج LLM. يقوم ببناء نموذج في مُحرك TensorRT مُسبقًا، ويدمج النوى، ويختار أفضل تخطيط لكل وحدة معالجة رسومية. عادةً ما يُحسِّن الإنتاجية بنسبة 10-25% وزمن الاستجابة بنسبة 15-30% مُقارنةً بـ vLLM على نفس الجهاز، وأكثر من ذلك على H100/B200. لكن التكلفة تكمن في خطوة البناء (من دقائق إلى ساعات لكل نموذج + تهيئة وحدة المعالجة الرسومية)، ومُحركات غير قابلة للنقل بين أجيال CUDA/برامج التشغيل/وحدات المعالجة الرسومية، وتعقيد تشغيلي أكبر. docker run.

يُعدّ خادم استدلال ترايتون طبقة خدمة النماذج المتعددة التي تستضيف محركات TensorRT-LLM (بالإضافة إلى PyTorch وONNX وTensorFlow وPython وvLLM كخادم خلفي) على خادم واحد. يتيح لك نمط مستودع النماذج تحميل نماذج LLM A وLLM B ونموذج رؤية ونموذج التعرف التلقائي على الكلام (ASR) ومسار Python خلف عنوان URL واحد مع إمكانية التحكم في الإصدارات وتوجيه A/B ورسوم بيانية للتجميع.

يستحق التكلفة عندما: خدمة نماذج متعددة غير متجانسة على خادم واحد؛ أشهر من الإنتاج المستقر مع اختيار نموذج مستقر؛ استغلال آخر جزء من زمن الاستجابة p99 على وحدات معالجة الرسومات في مركز بيانات Hopper/Blackwell.

لا يستحق الأمر العناء عندما: ما زلت تختار نموذجك (كل تبديل هو بناء محرك جديد)؛ أنت تستخدم وحدات معالجة الرسومات الاستهلاكية/محطات العمل (يتقلص تسريع TRT-LLM مقارنة بـ H100، ويتم شحن نموذج vLLM الأسبوع المقبل قبل ستة أسابيع من TRT-LLM)؛ أنت فريق صغير بدون نطاق ترددي للعمليات.

NVIDIA NIM — المسار المُجهز مسبقًا

تقوم NIM (خدمات الاستدلال المصغرة من NVIDIA) بتجميع "Triton + TensorRT-LLM + تكوين مثالي لهذا النموذج المحدد + ترخيص مؤسسي" في حاوية واحدة. docker pull nvcr.io/nim/meta/llama-3.3-70b-instruct:latestقم بتعيين مفتاح NGC، وقم بتشغيله، وستحصل على نقطة نهاية متوافقة مع OpenAI تم اختبارها دون اختيار الكميات أو ضبط العلامات.

يناسب هذا الخيار الحالات التالية: إذا كنت قد اشتريتَ NVIDIA AI Enterprise (أو إذا كان أحد عملائك بحاجة إليها)؛ إذا كنت ترغب في أسرع وقت للوصول إلى نقطة نهاية موثوقة (ساعات، وليس أيام)؛ إذا كان الطراز الذي تريده متوفرًا في الكتالوج (Llama، Mistral، Mixtral، Gemma، Nemotron، ومجموعة متنامية من الشركاء). بعد مؤتمر GTC 2026، تغطي باقة مجانية ما يصل إلى 16 وحدة معالجة رسومية لأعضاء برنامج المطورين - وهو عدد كافٍ للتقييم على معظم عمليات تثبيت خادم Kentino الفردي؛ تحقق من شروط الترخيص الحالية قبل الاشتراك.

لا يناسب في الحالات التالية: عندما لا يكون النموذج موجودًا في الكتالوج (تصل الأوزان المفتوحة بعد أسابيع من التأخير)؛ عندما تريد ضبطه (تخفي NIM معظم المقابض عن طريق التصميم).

الخادم الوكيل العكسي، والمصادقة، وتحديد معدل الطلبات

لا تعرض vLLM مباشرةً على الإنترنت العام. ضع nginx (أو Caddy أو Traefik) كخادم وسيط. إليك مثال بسيط لإعدادات nginx:

upstream vllm_backend {
    server 127.0.0.1:8000;
    keepalive 32;
}

limit_req_zone $binary_remote_addr zone=vllm:10m rate=20r/s;

server {
    listen 443 ssl http2;
    server_name infer.example.com;

    ssl_certificate     /etc/letsencrypt/live/infer.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/infer.example.com/privkey.pem;

    location /v1/ {
        if ($http_authorization != "Bearer sk-yourlongrandomtoken") {
            return 401;
        }
        limit_req zone=vllm burst=40 nodelay;

        proxy_pass http://vllm_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;             # streaming SSE
        proxy_read_timeout 600s;
        chunked_transfer_encoding on;
    }
}

ثلاث نقاط يخطئ فيها الناس:

• proxy_buffering off هذا ضروري لتلقي الاستجابات المتدفقة. وإلا ستتراكم الرموز المميزة في الخادم الوكيل وسيتلقى العميل رسالة لمرة واحدة فقط.
• proxy_read_timeout الإعداد الافتراضي هو 60 ثانية. عمليات التعبئة المسبقة متعددة الأنماط الطويلة بمعدل 4 توكوفيرول/ثانية تتجاوز ذلك. اضبطه على 5-10 دقائق.
• استخدم if الكتلة مطابقة تمامًا. للمصادقة الحقيقية، استخدم Lua أو oauth2-proxy أو بوابة مثل Kong.

مراقبة

مصدران للقياسات، وهدفان لجمع البيانات.

• ماجستير القانون الافتراضي /metrics نقطة النهاية. متوافق مع بروميثيوس، نفس منفذ واجهة برمجة تطبيقات OpenAI (:8000/metricsينشر vllm:num_requests_running, vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:time_to_first_token_seconds, vllm:time_per_output_token_seconds. يُعد استخدام ذاكرة التخزين المؤقت KV هو الذي يلتقط الاستباق قبل أن يتسبب في زيادة زمن الاستجابة.
• مُصدِّر سلع بضائع بضائع مركزية (nvcr.io/nvidia/k8s/dcgm-exporter(المنفذ 9400). يصدر معلومات عن استخدام وحدة معالجة الرسومات، واستخدام الذاكرة، والطاقة، ودرجة الحرارة، وعرض نطاق PCIe، وعدادات تصحيح الأخطاء.

كلاهما في بروميثيوس، وكلاهما في جرافانا. لوحة التحكم الأولى: الطلبات قيد التشغيل، استخدام ذاكرة التخزين المؤقت للمفتاح والقيمة، استخدام وحدة معالجة الرسومات، درجة حرارة وحدة معالجة الرسومات، زمن الاستجابة الكلي لـ P95، زمن الوصول الكلي لـ P95. إذا وصل استخدام ذاكرة التخزين المؤقت للمفتاح والقيمة إلى أقصى حد بينما يزداد عدد الطلبات في الانتظار، فأنت تقوم بالمقاطعة - قم بالإيقاف. --max-num-seqs، رفع --gpu-memory-utilizationأو أضف نسخة طبق الأصل.

مأزق الإحماء النموذجي

يكون الطلب الأول إلى vLLM الذي تم تشغيله حديثًا أبطأ بمقدار 5-30 مرة من حالة الاستقرار. يتم التقاط رسوم CUDA البيانية لكل شكل دفعة، وذاكرة التخزين المؤقت للبادئة فارغة، ويقوم المجدول بالمعايرة. قم بتشغيل طلب صغير /v1/chat/completions يُطلب إجراء هذا الطلب عند بدء التشغيل قبل الانضمام إلى موازن الأحمال؛ فبدونه، يتلقى أول مستخدم حقيقي استجابةً تستغرق 15 ثانية على نموذج يستجيب عادةً في ثانية واحدة. بالنسبة لعمليات النشر التدريجي (الأزرق/الأخضر)، يُنصح بتهيئة النسخة الجديدة قبل حذف النسخة القديمة. يُعدّ تخطي التهيئة السبب الأكثر شيوعًا لظهور رسالة "بدا النشر جيدًا، لكن المستخدمين اشتكوا لمدة عشر دقائق".

نماذج متعددة على خادم واحد

يُعدّ vLLM في الأساس خادمًا أحادي النموذج. ثلاثة خيارات متاحة في حال احتجت إلى نماذج متعددة:

1. حاوية واحدة لكل طراز، ومنافذ مختلفة. يحتوي كل منهما على ذاكرة وصول عشوائي للفيديو خاصة به. يتشارك كل من 70B و7B صندوقًا رباعيًا لوحدات معالجة الرسومات عبر CUDA_VISIBLE_DEVICES التقطيع والمطابقة --gpu-memory-utilization. تخطيط ميزانية الذاكرة هو مهمتك.
2. التحميل عند الطلب. يتم تحميل/تفريغ واجهة المستخدم عند وصول الطلبات. يستغرق التحميل من 30 إلى 120 ثانية لحجم 70 بايت؛ زمن الاستجابة الأولي غير مقبول للاستخدام التفاعلي، ولكنه مناسب للمعالجة الدفعية.
3. مستودع نماذج ترايتون. يتحكم نظام Triton بدورة حياة N نموذجًا في خادم واحد، ويُوجّه الطلبات حسب اسم النموذج. هذا ما ستنتقل إليه عندما يتوقف الخيار 1 عن التوسع.

بالنسبة لمعظم عمليات تثبيت Kentino، يكون الخيار 1 صحيحًا حتى يكون لديك أربعة نماذج أو أكثر، وعند هذه النقطة يكون دفع ضريبة التشغيل الخاصة بـ Triton أمرًا يستحق العناء.

الرأي الصريح

ينبغي أن يبدأ 95% من عملاء كينتينو بـ vllm/vllm-openai في بيئة Docker، خلف خادم nginx، على نموذج واحد، مع استخدام Prometheus وDCGM لاستخراج البيانات، دون النظر إلى أي شيء آخر خلال الأشهر الثلاثة الأولى. يثبت SGLang جدارته في معالجة المخرجات المنظمة أو حركة مرور الوكلاء ذات البادئة المشتركة على نطاق واسع. يثبت llama.cpp جدارته على Jetson أو Mac أو جهاز تطوير مخصص لمستخدم واحد. يثبت Triton وTensorRT-LLM جدارتهما عند توفر أشهر من الإنتاج المستقر مع نماذج متعددة. يثبت NIM جدارته عندما يكون النموذج موجودًا في الكتالوج والترخيص متوفرًا.

تكلفة البدء بتعقيد مفرط حقيقية. لقد رأينا عمليات تثبيت في المختبرات تستغرق ثلاثة أسابيع لتشغيل Triton + TensorRT-LLM على خادم Llama 70B واحد، بينما كان vLLM سيستضيفه في غضون عشرين دقيقة. ابدأ بالبسيط أولاً، ثم أضف التعقيد عندما تتأكد من حاجتك إليه.

---

هذا جزء من ويكي كينتينو، وهي سلسلة مرجعية حول الحوسبة الذكية، والروبوتات، والأنظمة التي تربط بينهما. نرحب بالتعليقات والتصويبات على info@kentino.com.