vLLM أم Ollama أم llama.cpp؟ اختر خادم الاستدلال في المقرّ وفق التزامن، لا وفق الضجيج
تختار معظم الشركات الصغيرة والمتوسطة في الإمارات خادم LLM في المقرّ بناءً على عرض توضيحي بمستخدم واحد، ثم تصطدم بجدار حين يستعلمه ثلاثة موظفين في الوقت نفسه. عند طلب واحد تكون الفجوة بين Ollama وvLLM غير مرئية. وعند عشرة طلبات تصبح كارثية. وإليك الرقم الوحيد الذي يجب أن يقود القرار بأكمله: احسب عدد مستخدميك المتزامنين في ساعة الذروة. أقل من خمسة، وOllama يفي بالغرض. أكثر من خمسة، وأنت بحاجة إلى vLLM، ولا قدر من الضبط يردم تلك الفجوة. يربط هذا الدليل كل خادم بحمل التزامن الفعلي في عيادات الإمارات ومكاتب المحاماة وشركات الوساطة العقارية، اعتماداً على إنتاجية مقيسة، لا على ادعاءات المورّدين.
فجوة التزامن التي تباغت الجميع
شغّل عرضاً توضيحياً بمستخدم واحد وسيفوز Ollama فعلاً. فهو ينتج نحو 45 رمزاً في الثانية مقابل 38 لـvLLM على نموذج Llama 3.1 8B. ذلك الرقم بطلب واحد هو ما تراه الفرق، وهو السبب في أنها تظل تلجأ إلى Ollama في بيئة الإنتاج.
تبدأ المتاعب لحظة ظهور مستخدم ثانٍ وثالث. يعالج Ollama الطلبات تسلسلياً بشكل افتراضي، فينتظر كل طلب خلف سابقه، ويتفاقم الأثر بسرعة مع تصاعد الحمل. عند 8 طلبات متزامنة، ينتج vLLM 187 رمزاً في الثانية مقابل 82 لـOllama، أي فجوة بمقدار 2.3 ضعف. وعند 10 مستخدمين متزامنين يصبح الرقم 485 مقابل 148. وادفع الحمل إلى 50 مستخدماً متزامناً على GPU واحد، فيبلغ vLLM نحو 920 رمزاً في الثانية بينما يستقر Ollama قرب 155. وتضع اختبارات الأداء المستقلة لعام 2026 الفجوة عند اتساع يصل إلى 16 ضعفاً حتى 29 ضعفاً عند التزامن العالي جداً، فإن جانبت الأرقامُ هنا الصوابَ فهي إلى التحفّظ أقرب.
تقع نقطة التقاطع عند نحو 5 مستخدمين متزامنين. فالعيادة التي تشغّل نظام استقبال واحداً إلى جانب مساعد واحد للملاحظات السريرية تبقى دون ذلك الخط، وسيصمد Ollama. أما مكتب محاماة من 20 شخصاً يطرق فيه المساعدون القانونيون والشركاء مساعدَ المستندات طوال اليوم فلا يبقى دونه، وهناك يصبح vLLM متطلباً وظيفياً لا ترقيةً يمكنك تأجيلها. لا شيء من هذا تقديري. إنها الطريقة التي تتعامل بها بنية كل خادم مع حساب الانتباه المتزامن، مقيسةً على أجهزة حقيقية.
لماذا تتباعد الأرقام: PagedAttention مقابل طابور FIFO
تفسّر البنية الفجوةَ بأكملها. ينفّذ vLLM آلية PagedAttention التي تقسّم ذاكرة KV المؤقتة — وهي الذاكرة التي تحفظ حالة الانتباه لكل رمز — إلى كتل ثابتة الحجم وغير متجاورة، وهي فكرة مستعارة مباشرةً من ترقيم الذاكرة الافتراضية في أنظمة التشغيل. ذلك القرار التصميمي الواحد يقضي على تجزئة ذاكرة KV المؤقتة، ويستعيد ما يصل إلى 55% من ذاكرة VRAM التي تهدرها التطبيقات البسيطة على الحشو والتخصيص المفرط، ويجعل التجميع المستمر أمراً بسيطاً.
يعمل التجميع المستمر افتراضياً، فيشتغل vLLM على رموز من عدة طلبات في التمريرة الأمامية ذاتها بدلاً من استنزاف طلب واحد قبل أن يلمس التالي. عندئذ تكلّفك إضافة المستخدمين المتزامنين من 10 إلى 20 بالمئة من الإنتاجية حتى الحمل المتوسط، بدلاً من أن تُسقطها من حافة هاوية.
يعمل Ollama بالعكس. فهو يُغلّف llama.cpp داخلياً ويصفّ الطلبات بشكل افتراضي في طابور FIFO، مع قيام OLLAMA_NUM_PARALLEL باختيار 1 أو 4 تلقائياً بحسب الذاكرة المتاحة، وقيام OLLAMA_MAX_QUEUE باحتجاز الباقي عند قيمة افتراضية تبلغ 512. اضبط OLLAMA_NUM_PARALLEL=4 صراحةً فترتفع الإنتاجية ثلاثة إلى أربعة أضعاف، لكن زمن الاستجابة لكل طلب يرتفع من 20 إلى 40 بالمئة، ومع ذلك لا تقترب من كفاءة vLLM في التزامن. والمشكلة الأسوأ هي إخلاء النماذج: في ظل حركة نماذج مختلطة، يُفرّغ Ollama النماذج ويعيد تحميلها، فيقفز زمن الاستجابة عدة ثوانٍ. تخيّل نظام ذكاء اصطناعي صوتي في عيادة بدبي يتجمّد ثلاث ثوانٍ في منتصف الجملة والطبيب مع مريضه. وحده هذا يُخرج Ollama من الحسبان في أي نشر إنتاجي متعدد النماذج.
الخادم الذي أغفله الحكم الأصلي: SGLang لـRAG والصوت والوكلاء
كُتبت قاعدة «vLLM فوق خمسة مستخدمين، وانتهى» للحركة العامة. والأنظمة التي تبنيها هذه الشركة فعلاً ليست عامة. فمسار RAG، ووكيل صوتي، وروبوت حجز عبر WhatsApp، جميعها يرسل الكتلة النصية الكبيرة ذاتها في صدر كل طلب على حدة: موجّه النظام، وتعريفات الأدوات والدوال، وكثيراً نافذة السياق المسترجَعة ذاتها. تلك الكتلة الأمامية المتكررة هي البادئة، وعلى الحركة كثيفة البادئات يتفوّق خادم واحد على vLLM. ذلك الخادم هو SGLang.
ميزة SGLang هي RadixAttention. فهو يخزّن ذاكرة KV المؤقتة في شجرة جذرية ويعيد استخدام أي بادئة مشتركة عبر الطلبات المتزامنة، فيحسب تلك الكتلة مرة واحدة بدلاً من إعادة حسابها لكل مُستدعٍ. وعلى الأحمال كثيفة البادئات يكون العائد حاداً: ما يصل إلى 5 أضعاف في قياس LMSYS الأصلي، و6.4 أضعاف في نتيجة التخزين المؤقت للبادئات بـRadixAttention لاحقاً، مع إنتاجية إجمالية أعلى بنحو 29% من vLLM على H100 مماثل يشغّل Llama 3.1 8B، أي نحو 16,200 رمزاً في الثانية مقابل 12,500. ويبلغ متوسط زمن أول رمز 79ms مقابل 103ms، أي خفض بنسبة 23%، مع زمن بيني بين الرموز قدره 6.0ms مقابل 7.1ms. واقرأ التحذير بوضوح: تظهر تلك الفجوة على الحركة كثيفة البادئات لا على كل حمل، وعلى الطلبات المسطّحة ذات الطلقة الواحدة يتقارب الاثنان.
ثمة تصويب جدير بالذكر لأن الخطأ فيه يتكرر باستمرار. ميزة SGLang ليست أن vLLM يفتقر إلى إعادة استخدام البادئة. فمنذ محرك V1، يفعّل vLLM التخزين المؤقت التلقائي للبادئات افتراضياً، وتطبيق V1 يسبّب خسارة في الإنتاجية دون 1% حتى عند معدل إصابة للتخزين المؤقت قدره 0%، وهو بالضبط سبب تفعيله. ويحصل vLLM كذلك على إعادة استخدام البادئة عبر الطلبات جاهزةً دون عناء. أما عوامل التمايز الحقيقية لـSGLang فهي استراتيجية الإخلاء بالشجرة الجذرية، وميزاته في التوليد المنظّم والوكلاء، وفارق الإنتاجية المقيس على البادئات المشتركة الثقيلة.
لذا فالقاعدة العملية تنقيح لا انقلاب. يبقى vLLM الخيار الافتراضي الواسع: أوسع تغطية للنماذج والأجهزة، وأقوى توثيق، ودون خطوة تصريف. والجأ إلى SGLang حين تكون حركتك محادثةً متعددة الأدوار، أو RAG، أو حركةً وكيلية بموجّه نظام مشترك ثقيل، وهي بالضبط هيئة روبوت الفرز عبر WhatsApp في عيادة إماراتية أو وكيل تحليل العقود في مكتب محاماة. وخادمان يمكنك تخطّيهما: يقبع TGI من HuggingFace في وضع الصيانة في 2026، وHuggingFace نفسها تشير إلى vLLM وSGLang، فهو ليس خياراً لبناء جديد. وTensorRT-LLM هو خيار عصر كل رمز أخير الذي يكلّف أسبوعاً إلى أسبوعين من الإعداد ويقيّدك بـNVIDIA، ولا يستحق العناء إلا حين تعصر ميزانية GPU ثابتة لكل ما فيها.
المقياس الذي يحسم نشراً صوتياً ليس عدد الرموز في الثانية
إجمالي الرموز في الثانية معيار خاطئ لوكيل صوتي. فما يحسم إن كان خط الهاتف يبدو بشرياً هو زمن أول رمز: كم يجلس المتصل في صمت قبل أن ترتد إليه الكلمة الأولى. تضع اختبارات Twilio في أواخر 2025 هدف زمن أول رمز لـLLM عند 375ms بحد أعلى قدره 750ms، ضمن ميزانية كاملة لفجوة الدور التحادثي تبلغ نحو 885ms (بحد أعلى 1,100ms). أخطئ ذلك يسمع المتصل صمتاً ميتاً، ثم يبدأ بالكلام فوق الوكيل.
نادراً ما تكون الإنتاجية المستدامة هي القيد بمجرد نزول أول رمز. فالإنسان يقرأ بنحو 4 إلى 5 رموز في الثانية، والنموذج الذي يبثّ بسرعة 50 إلى 100 رمز في الثانية يكون بالفعل أسرع مما يستطيع أحد متابعته بارتياح؛ ونحو 10 رموز في الثانية هي الحد الأدنى لمجاراته. ويبدأ توليف الكلام لحظة وصول أول الرموز. الرقم الملزِم هو زمن أول رمز، لا المعدل الإجمالي.
وهنا بالضبط يكون طابور FIFO في Ollama مُسقِطاً للمحادثة الفورية. فزمن أول رمز للمتصل المتزامن الثاني يصبح الزمن اللازم لإنهاء المتصل الأول — زمن استجابة غير مرئي في عرض بمستخدم واحد وقاتل على خط حي. ويُبقي vLLM زمن أول رمز مسطّحاً تقريباً مع إضافة المتصلين، لأن التجميع المستمر والتعبئة المسبقة المجزّأة (مفعّلة دوماً في محرك V1) يجدولان تمريرة التعبئة المسبقة الأولى لطلب جديد دون استنزاف الطابور. أما الجدولة الواعية بالتخزين المؤقت في SGLang فتُبقي المعدل لكل طلب أكثر ثباتاً عند التزامن العالي. ضعه في سياق الإمارات. خط استقبال عيادة أو روبوت حجز عبر WhatsApp يتعامل مع ثلاث محادثات متزامنة قد تجاوز بالفعل النقطة التي يصبح عندها زمن الاستجابة لكل طلب في Ollama مقبولاً للصوت، حتى وإن بدا إجمالي رموزه في الثانية لا يزال جيداً على لوحة المعلومات.
النموذج نفسه بكمّنة مختلفة: ما الذي يتغيّر حين تنتقل إلى vLLM
يظل المقال يستشهد بـQ4_K_M دون أن يقول ما الذي يشغّله صندوق vLLM فعلاً، وذلك مهم. فالانتقال من Ollama إلى vLLM يغيّر الكمّنة، والمشتري بحاجة لأن يعرف إن كانت الجودة تنجو من النقلة. إن Q4_K_M كمّنة GGUF، وهي الصيغة الأصلية لـOllama وllama.cpp، وهي ممتازة للعمل بمستخدم واحد على CPU أو بتفريغ إلى GPU.
أما خدمة الإنتاج في vLLM فتستخدم شيئاً آخر: AWQ بمستوى INT4، أو FP8. وAWQ عبر Marlin هو الخيار الافتراضي لعام 2026 لخدمة GPU، ونقطة التوازن المُوصى بها بين الجودة والإنتاجية، ويُوصى بـFP8 لمعظم السيناريوهات لأن كلفته في الجودة تقترب من الصفر. وعلى بنية vLLM حالية، يقدّم FP8 W8A8 إنتاجية أعلى بنحو 15% إلى 27% من BF16 بينما يبقى MMLU ثابتاً ويتحرك GSM8K في حدود 0.15 إلى 0.83 نقطة. وفي مقارنة MMLU-Pro سجّل FP8 نسبة 69.64% مقابل 70.24% لـBF16، أي فجوة قدرها 0.6 نقطة. النقلة إلى vLLM مكسب في الإنتاجية لا اقتطاع في الجودة. وتغيير الكمّنة تحويل لمرة واحدة إلى AWQ أو FP8، لا تنزيل في المستوى.
لا تشغّل GGUF على vLLM متوقعاً أرقامه الحقيقية. يستطيع vLLM تقنياً تحميل GGUF، لكن توثيقه نفسه يصف ذلك المسار بأنه «تجريبي للغاية وغير محسّن بما يكفي» ويوجّهك إلى llama.cpp بدلاً منه؛ وعملياً تعمل GGUF على vLLM بنحو 93 رمزاً في الثانية مع زمن أول رمز قرب 958ms، أي بعيداً عن نطاق AWQ أو FP8.
ثمة استثناء حقيقي يُبقي llama.cpp في الصورة. فعلى صندوق ضيّق الـVRAM، لنقل نموذج 32B بالكاد يتّسع داخل 24GB، قد تترك GGUF Q4 على llama.cpp أو Ollama مساحة أكبر من FP8 على vLLM، لأن الأوزان رباعية البتات أصغر ببساطة. وحين تكون البطاقة هي القيد المُلزِم، فتلك المساحة سبب حقيقي للبقاء على GGUF بدلاً من مطاردة إنتاجية vLLM.
متطلبات الأجهزة وموضع llama.cpp
يحتاج vLLM إلى أجهزة NVIDIA: تعريف بإصدار 525 أو أعلى، وCUDA 12.1 كحد أدنى، وقدرة حوسبة GPU بمستوى 7.0 أو أعلى. وهذا يشمل V100 وما تلاه، بما في ذلك سلاسل RTX 20 و30 و40، وA10G وA100 وH100. تتناسب ذاكرة VRAM مع حجم النموذج. بطاقة بسعة 8GB تشغّل نموذجاً بحجم 7B إلى 8B بكمّنة Q4_K_M؛ و16 إلى 24GB تتعامل مع نماذج 14B إلى 32B؛ وتتطلب نماذج 70B من 48 إلى 96GB. خصّص 500MB إلى 2GB إضافية من ذاكرة VRAM لنفقات إطار العمل قبل أن يُحمَّل النموذج أصلاً، فمن السهل التقصير في حجم GPU بنسيان ذلك.
تصف تلك النطاقات مستخدماً واحداً. وعند التزامن ينقلب الحساب. فذاكرة KV المؤقتة، لا أوزان النموذج، هي ما يهيمن على VRAM، وهذا هو خطأ تحديد الحجم الذي يوقع أكثر الفرق. يحتاج نموذج Llama 3.1 70B عند سياق 32k نحو 10 إلى 11GB من ذاكرة KV المؤقتة بصيغة FP16 لكل تسلسل نشط (نحو 5GB بـFP8). ضع عليه 10 مستخدمين متزامنين فأنت أمام ما يقارب 100 إلى 112GB من ذاكرة KV المؤقتة بصيغة FP16، ونحو 56GB بـFP8، تجلس فوق الأوزان. لا بطاقة واحدة تحمل ذلك. ويعمل نشر 70B متعدد المستخدمين الحقيقي بتوازي موترات متعدد الـGPU عبر --tensor-parallel-size، وعلى تلك الراية أن تكون أُسّاً للعدد 2 يقسم عدد رؤوس انتباه النموذج بالتساوي، فتنجح 1 و2 و4 و8 بينما تفشل عادةً القيم الفردية كـ3 أو 5 أو 6. خط «48 إلى 96GB» يحدّد حجم مستخدم واحد. أما غرفة مليئة بهم على نموذج 70B فبناء بموترين أو أربعة أو ثمانية GPU.
إن كان موقعك في الإمارات خالياً من أي GPU من NVIDIA، فإن llama.cpp هو الجواب. تخيّل مكتباً فرعياً على محطة عمل بـGPU مدمج، أو جهازاً طرفياً في عيادة نائية. على GPU من NVIDIA ينتج نحو 122 إلى 128 رمزاً في الثانية على Llama 3 8B بكمّنة Q4_K_M. وعلى Apple M4 Max عبر Metal يدبّر نحو 75. وعلى CPU خالص بدعم AVX-512 أو ARM NEON يهبط إلى 10 إلى 15 رمزاً في الثانية، مقبول لشخص واحد يلخّص مستنداً، عديم الجدوى لأي عمل بالزمن الحقيقي.
قوة llama.cpp هي الانتشار لا التزامن. فهو يعمل على CUDA وROCm وIntel SYCL وApple Metal وVulkan. استخدمه للنشر الطرفي على CPU فقط ولأجهزة المطوّرين. ولا تضعه أمام غرفة مليئة بالموظفين يتشاركون نظاماً واحداً.
مصفوفة القرار وواقع الامتثال في الإمارات
يتلخّص الأمر الآن في أربع حالات، لا ثلاث. التطوير والعروض التوضيحية واختبار المستخدم الواحد تذهب إلى Ollama: الإعداد دون عشر دقائق، ونماذج GGUF المكمّنة تُحمَّل بأمر واحد، والإنتاجية التسلسلية كافية وافرة. ويجتاز Ollama بصدق عتبةً ثانية أضيق أيضاً. فأداة داخلية صغيرة متقطّعة بمجموعة نماذج ثابتة ودون إخلاء، حيث يكون OLLAMA_NUM_PARALLEL مع OLLAMA_MAX_QUEUE محدود السقف جيداً بما يكفي حقاً، تجعل الدفع مقابل عمليات vLLM اقتصاداً زائفاً. واعرف أنماط فشله قبل أن تتّكئ عليه. فالطابور الممتلئ يعيد رمز 503، والسقف الافتراضي للنماذج المحمّلة هو 3 لكل GPU، وإعادة تحميل نموذج بارد تكلّف 10 إلى 60 ثانية. وأي نشر إنتاجي يخدم ثلاثة مستخدمين متزامنين أو أكثر يذهب إلى vLLM، وهذا حال معظم العملاء الذين نراهم: عيادة بخمسة أطباء تشغّل جلسات منفصلة للاستقبال وللتوثيق السريري، ومكتب محاماة يستعلم فيه مساعدان قانونيان وشريك نظامَ تحليل العقود في آنٍ واحد، وشركة وساطة عقارية يسحب فيها الوكلاء ملخصات العقارات أثناء اجتماعات العملاء. أما الإنتاج كثيف البادئات — حركة RAG أو صوت أو حركة وكيلية بموجّه نظام مشترك ثقيل — فيذهب إلى SGLang من أجل ميزة الإنتاجية وزمن أول رمز. وأما المواقع الطرفية بـCPU فقط أو بأجهزة مختلطة فتذهب إلى llama.cpp، إما كنقطة نهاية بمستخدم واحد أو مدمجةً في مسار مع معالجة مسبقة لتخفيف الحمل.
تلك الفجوة التشغيلية نصف القرار، وعادةً ما تبقى دون ذكر. فـOllama ثنائي موقَّع وحيد دون مقاييس مدمجة ودون توسّع أفقي. أما vLLM في الإنتاج فيعني Docker أو Kubernetes، وترقيع تبعيات CUDA وPython، ومصادقة HuggingFace، وضبط ذاكرة GPU، وفي المقابل يشحن نقطة نهاية Prometheus عند /metrics ويتوسّع أفقياً. أنت تشتري القابلية للمراقبة والتزامن بعبء تشغيلي. سعّر كلا الجانبين قبل أن تلتزم.
يشحذ تنظيم الإمارات كل هذا. يغطّي قانون حماية البيانات الشخصية الاتحادي، Federal Decree-Law No. 45 of 2021، كل معالجة للبيانات الشخصية العائدة للمقيمين في الإمارات، فسجلات المرضى وملفات القضايا وبيانات معاملات العملاء التي تمرّ عبر خادم استدلال LLM داخلة في النطاق. وكن دقيقاً بشأن أنيابه الراهنة. فحتى عام 2026 لم تصدر بعد اللوائح التنفيذية الاتحادية للقانون ولم يكتمل تشغيل مكتب بيانات الإمارات بعد، لذا يبقى الإنفاذ محدوداً وذاتي التوجيه إلى حد كبير. الالتزامات مُلزِمة؛ وآلية الإنفاذ التفصيلية في منتصف التحوّل. تلك هي الحالة الصادقة، وهي بالضبط سبب كون الاستضافة في المقرّ هي الوضع المتحفّظ: فهو يصمد بصرف النظر عن كيفية استقرار اللوائح.
بالنسبة للكيانات المسجّلة في DIFC تكون الصورة أكثر واقعية. فقد سُنّت DIFC Regulation 10 المتعلقة بالمعالجة عبر الأنظمة المستقلة وشبه المستقلة في أواخر 2023، وهي قابلة للإنفاذ الآن، مع بدء الإنفاذ الكامل في 2026. وهي تشترط إشعارات شفافية عند أول استخدام لنظام ذكاء اصطناعي، وسجلاً لحالات استخدام النظام وأنشطة المعالجة، وتقييمات للمخاطر والأثر ومحفّزات تدخّل بشري للمعالجة عالية المخاطر، وشهادةً للنظام، وكذلك — للمعالجة عالية المخاطر من قِبل الناشرين والمشغّلين — تعيين Autonomous Systems Officer، وهو مسؤول بمكانة وكفاءات شبيهة بـData Protection Officer. وقد ارتفعت كلفة الإخفاق في حماية البيانات داخل DIFC في تعديلات 8 July 2025 على قانون حماية البيانات في DIFC. فإخفاق DPIA يحمل الآن غرامة إدارية تصل إلى USD 50,000، والإفصاح غير المشروع لسلطة عامة يصل إلى USD 50,000، وإخفاق التقييم السنوي لـDPO يصل إلى USD 25,000، ضمن نطاق Schedule 2 يمتد تقريباً من USD 10,000 إلى 100,000. شغّل خادم استدلال لعيادة أو مكتب محاماة أو شركة وساطة على بيانات شخصية، وعندئذ يكون DPIA جزءاً من النشر لا فكرةً لاحقة.
تشغيل خادم الاستدلال في المقرّ داخل الإمارات يُزيل أسئلة النقل عبر الحدود كلياً ويمنحك وضعاً نظيفاً لأي تدقيق. وبالنسبة لعيادة فهو يتقاطع مباشرةً مع إقامة البيانات الصحية: سجلات المرضى المتدفّقة عبر LLM ينبغي ألّا تغادر الولاية القضائية، وبورصات الصحة الوطنية الثلاث (NABIDH في دبي، وMalaffi في أبوظبي، وRiayati اتحادياً، وهي الآن متكاملة بعمق على مستوى الدولة) سبب لأن يعيش خادم الاستدلال على أجهزة محلية بدلاً من نقطة نهاية سحابية مُدارة بلا منطقة إماراتية. أما شركة وساطة أو إدارة صندوق تعمل في ADGM فتواجه التزاماً موازياً ضمن نظام حماية البيانات الخاص بها لا التزاماً مطابقاً، وهو ما يعزّز النقطة فحسب: حيث يعمل خادم الاستدلال فعلياً قرارُ امتثال لا قرارُ أداء فحسب. لذا فاختيار الخادم يحمل ما يتجاوز الأداء. إنه يقرّر ما إذا كان النشر سيجتاز مراجعة DPIA من الأساس.
هل لديك أسئلة حول إعدادك؟
نساعد الشركات الإماراتية الصغيرة والمتوسطة على بناء أنظمة ذكاء اصطناعي متوافقة ومحلية وفعّالة فعلاً. محادثة أولى مجانية.