هل تحتاج إلى VPS مزوّد بـGPU أم يكفي CPU؟

هل تحتاج إلى VPS مزوّد بـGPU، أم يكفي CPU؟

يغيّر VPS المزوّد بـGPU أمرين عند تشغيل نموذج بنفسك: سرعة خروج التوكنات، وحجم النموذج الذي يمكن أن تتسع له الذاكرة أصلاً. ولا يغيّر شيئاً آخر. إذا كان عبء العمل لديك يتضمن نموذج محادثة مكمّماً من 7B إلى 27B يجيب شخصاً واحداً في كل مرة، أو مهمة embeddings منخفضة الحجم، أو نسخاً صوتياً باستخدام Whisper small، فإن VPS عادياً يعمل بـCPU ويمتلك ذاكرة RAM كافية ينجز المهمة بالفعل. ابدأ باستخدام CPU، وقِس الرقم الذي يسبب لك المشكلة، ثم انتقل إلى مستوى أعلى.

السبب هو عرض نطاق الذاكرة. عندما يولّد نموذج لغوي توكناً واحداً، فإنه يقرأ من الذاكرة كل الأوزان التي يحتاج إليها. يبلغ حجم نموذج 8B مكمّم إلى 4 bits نحو 4.9 GB على القرص، ويكون حجمه في الذاكرة قريباً من ذلك، لذا يعني إنتاج توكن واحد نقل نحو 4.9 GB. اقسم عرض نطاق ذاكرة الجهاز على هذا الرقم، تحصل على الحد الأقصى النظري لعدد التوكنات في الثانية. تفسّر هذه القسمة الواحدة تقريباً كل اختبار أداء ستقرأه.

ما الذي توفره GPU فعلياً

عرض النطاق الترددي. تنقل ذاكرة DDR5 في خادم حديث عشرات الجيجابايتات في الثانية. أما ذاكرة GPU (VRAM، أو video RAM) فتنقل مئات الجيجابايتات، وقد تتجاوز ألف جيجابايت في الثانية. وتحدد هذه النسبة مقدار تسارع الأداء، وهي كبيرة.

السعة مع السرعة. يستطيع خادم CPU مزود بذاكرة RAM سعتها 64 GB تحميل نموذج 70B بدقة 4 bits. لكنه سيعمل بسرعة أقرب إلى سرعة القراءة منها إلى سرعة المحادثة. ولا تفيد GPU في هذه الحالة إلا إذا كان النموذج يتسع في VRAM، لأن مسار التنفيذ البطيء يستعيد التحكم فور نقل الطبقات إلى RAM النظام.

إنتاجية الدفعات. هذا هو الجانب الذي يستخف به كثيرون. عند توليد GPU النص لمستخدم واحد، يبقى معظم قدرتها الحوسبية خاملاً لأنها تنتظر الذاكرة. عند معالجة 20 طلباً في الوقت نفسه، تخدم قراءة الأوزان نفسها الطلبات العشرين جميعاً. ترتفع إنتاجية الرموز الإجمالية عدة أضعاف، بينما ينخفض الأداء لكل مستخدم انخفاضاً طفيفاً فقط. تدعم محركات الاستدلال على CPU، مثل llama.cpp، معالجة الدفعات أيضاً، وتختلف المكاسب حسب العتاد وعبء العمل. إذا كنت تبني API يستدعيه عدد كبير من العملاء، فمعالجة الدفعات هي سبب اختيار GPU، أكثر من كونها سرعة مسار واحد خاماً.

معالجة المطالبة. تعتمد قراءة مطالبة طويلة على قدرة المعالجة، لا على الذاكرة، وهنا تحقق GPU أكبر تفوق لها. يستغرق سياق من 30,000 token نحو دقيقة على CPU، لكنه يستغرق بضع ثوانٍ على GPU. وتظهر أهمية ذلك باستمرار في إعدادات الاسترجاع التي تضع المستندات داخل كل طلب.

الأرقام التقريبية وكيفية قراءتها

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

للمقارنة، يبلغ متوسط القراءة الصامتة لدى البالغين باللغة الإنجليزية نحو 4.0 إلى 4.3 كلمات في الثانية: 238 كلمة في الدقيقة للمواد غير الأدبية و260 كلمة للروايات. ويبدو أي معدل يبلغ 15 token في الثانية أو أكثر شبيهاً بسرعة الكتابة المعتادة لقارئ واحد. لذلك تكون إعدادات كثيرة تعمل على CPU فقط كافية عملياً دون ضجيج.

حساب VRAM قبل الشراء

حجم ملف النموذج هو الحد الأدنى، وليس المتطلب الكامل. احسب الأوزان، وأضف إليها KV cache (ذاكرة التخزين المؤقت للمفتاح والقيمة، وهي الذاكرة التي تحتفظ بها آلية attention لكل توكن)، ثم أضف نحو 1 GB من النفقات الإضافية.

احسب حجم الذاكرة المؤقتة بدلاً من إضافة نسبة ثابتة، لأن تكميم الأوزان لا يكمّم الذاكرة المؤقتة. لكل توكن، يخزّن نموذج يستخدم full attention مفتاحاً وقيمة لكل طبقة ولكل KV head، بمقدار 2 bytes لكل رقم في FP16، وهو نوع الذاكرة المؤقتة الافتراضي في Ollama. توضح بيانات النموذج الوصفية في Ollama، التي جرى التحقق منها في 2026-10-27، أن Llama 3.1 8B يضم 32 طبقة و8 KV heads بأبعاد 128، ما يعادل 128 KiB لكل توكن: نحو 1.07 GB عند سياق 8k و2.15 GB عند 16k. لذلك يحتاج نموذج 8B بحجم 4.9 GB إلى نحو 7 GB من VRAM عند 8k، ونحو 8 GB عند 16k. يبلغ حجم نموذج 27B عند 4 bits نحو 17 GB (Gemma 3 27B في مكتبة Ollama). وتذكر البيانات الوصفية لـGemma 3 نافذة منزلقة من 1,024 توكناً، ما يمنع جزءاً كبيراً من الذاكرة المؤقتة من النمو، لذا خطط لتوفير 20 GB أو أكثر. يبلغ حجم نموذج 70B عند 4 bits نحو 43 GB (Llama 3.3 70B). ومع وجود 80 طبقة، تضيف الذاكرة المؤقتة FP16 نحو 2.7 GB عند 8k و5.4 GB عند 16k، لذا يحتاج النموذج إلى بطاقة بسعة 48 GB مع هامش ضئيل، أو إلى بطاقتين أصغر. وتظل هذه الحسابات صالحة عند أحجام أكبر بكثير، وتوضح حسابات VRAM لنموذج حجمه 2.8 تريليون معامل مثل Kimi K3 متى يتوقف اختيار البطاقة عن كونه السؤال الأساسي أصلاً.

تظهر أهمية ذلك أكثر مع السياقات الطويلة. في النماذج التي تستخدم full attention مثل Llama 3.1، تنمو KV cache خطياً مع طول السياق، وقد يتجاوز حجمها حجم الأوزان نفسها عند 128k توكناً. وتختلف النماذج التي تستخدم sliding-window أو chunked attention: تذكر وثائق Hugging Face الخاصة بـTransformers أن Mistral وGemma 2 وLlama 4 أمثلة تتوقف فيها الذاكرة المؤقتة الخاصة بهذه الطبقات عن النمو عندما تصل إلى حجم النافذة أو المقطع، لذلك تنمو أحجامها الإجمالية بوتيرة أبطأ. إذا كنت تخطط لاستخدام سياقات طويلة، فاحسب السعة المطلوبة للذاكرة المؤقتة أولاً، وتحقق مما يتيحه محركك من تكميم لها. في Ollama، تستخدم OLLAMA_KV_CACHE_TYPE=q8_0 نحو نصف الذاكرة التي يستخدمها f16 الافتراضي، ولا ينطبق تكميم الذاكرة المؤقتة إلا عند تفعيل Flash Attention. حدّد طول السياق صراحةً أيضاً. يختار Ollama القيمة الافتراضية وفق VRAM: 4k عند أقل من 24 GiB، و32k من 24 إلى 48 GiB، و256k عند 48 GiB أو أكثر. وعند تشغيل نموذج 70B على بطاقة بسعة 48 GB، تتطلب هذه القيمة الافتراضية ذاكرة مؤقتة أكبر بكثير من سعة البطاقة.

تحقّق مما هو موجود فعلياً على الجهاز

في مثيل GPU، تأكد أولاً من أن برنامج التشغيل يتعرّف على البطاقة.

nvidia-smi

يجب أن يظهر جدول يتضمن اسم GPU، وإصدار برنامج التشغيل، والذاكرة المستخدمة من إجمالي الذاكرة. تعني NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver أن NVIDIA-SMI لا يستطيع الوصول إلى برنامج التشغيل. تحقق من تثبيت برنامج التشغيل وتحميل وحدة kernel الخاصة به. في صورة Ubuntu القياسية، يكون الحل عادةً sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install، ثم إعادة التشغيل حتى تُحمّل الوحدة الجديدة. بالنسبة إلى أجهزة الحوسبة، توصي وثائق Ubuntu للخوادم باستخدام sudo ubuntu-drivers install --gpgpu، لأنه يختار فرع برنامج التشغيل المخصص للخوادم.

بالنسبة إلى الحاويات، لا يكفي تثبيت برنامج التشغيل وحده. يحتاج Docker إلى NVIDIA Container Toolkit لتمرير الجهاز إلى الحاوية.

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

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

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

يجب أن يظهر الجدول نفسه. يشير سطر docker: Error response from daemon: could not select device driver، الذي يذكر قدرة GPU لا يستطيع الجهاز توفيرها، إلى أن Docker لم يتمكن من العثور على برنامج تشغيل جهاز يطابق الطلب. تحقق من تثبيت مجموعة الأدوات، ثم أعد تنفيذ سطر nvidia-ctk وإعادة التشغيل. في Compose، يقابل ذلك إدخال deploy.resources.reservations.devices تكون قيمة driver فيه هي nvidia، وتحتوي قائمة capabilities الخاصة به على gpu. ويمكن إدراجه ضمن تعريفات الخدمات العادية الموضحة في Docker Compose على VPS.

قِس قبل الترقية

شغّل النموذج الذي تنوي استخدامه فعلياً على خادم CPU المتاح لديك، وسجّل النتائج. عند استضافة LLM ذاتياً عبر Ollama على VPS، يكفي استخدام هذا الخيار:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

تنتهي المخرجات ببيانات التوقيت. تمثل eval rate سرعة التوليد بعدد الرموز في الثانية. وتمثل prompt eval rate سرعة قراءة الجهاز للمدخلات. يوضح الرقمان نوع الترقية المفيدة: انخفاض eval rate يعني وجود مشكلة في عرض نطاق الذاكرة، بينما يعني انخفاض prompt eval rate مع المدخلات الطويلة وجود مشكلة في القدرة الحاسوبية.

على جهاز يحتوي على GPU، تحقق من تحميل النموذج عليه فعلاً:

ollama ps

يعرض العمود PROCESSOR القيمة 100% GPU عندما يتسع النموذج بالكامل، أو يعرض قيمة مثل 43%/57% CPU/GPU عندما لا يتسع. يكون التوزيع الجزئي عادةً أسوأ مما تتوقع، لأن كل رمز يظل منتظراً للجزء الأبطأ.

سؤال التكلفة

تُحاسَب مثيلات GPU على وقت الحوسبة المُخصَّص، لا على عدد الرموز، وتحدّد الجهة الموفّرة الأسعار ورسوم المثيلات المتوقفة. يستهلك GPU يعمل دائماً لخدمة عدد قليل من الطلبات يومياً معظم الوقت المدفوع وهو خامل. ويعتمد الوصول إلى نقطة التعادل على معدل الاستخدام: يكون GPU المشغول منخفض التكلفة لكل رمز، أما GPU الخامل فهو هدر محض.

تنجح ثلاث استراتيجيات عملية. شغّل الأعمال المستمرة منخفضة الحجم على VPS يعمل بوحدة CPU. أرسل الطلبات الصعبة العرضية إلى API مستضاف وادفع لكل رمز. استأجر GPU بالساعة للمهام الدفعية، أو الضبط الدقيق، أو تنفيذ مهام embedding كبيرة، ثم احذفه. من الطبيعي الجمع بين هذه الخيارات، وينطبق هنا أيضاً نهج ضبط تكلفة وكيل AI على VPS يعمل دائماً، مع اختلاف أن الوقت الخامل هو موضع التسرب بدلاً من عدد الرموز.

ما الذي يظل يعمل جيداً من دون GPU

توليد Embeddings بمعدل منخفض. يعالج نموذج Embeddings صغير مئات المستندات القصيرة في الدقيقة باستخدام عدد قليل من أنوية CPU، كما أن الفهرس الذي تنشئه مرة واحدة لا يحتاج إلى سرعة عالية.

استخدم Whisper small وbase لتحويل الكلام إلى نص. ينفّذ Faster-whisper عملية التحويل على CPU بسرعة تقترب من الوقت الفعلي عند استخدام النموذج small، وهذا يكفي لخط أنابيب يعمل طوال الليل.

نماذج المحادثة المكمّمة حتى نحو 27B لمستخدم واحد أو مستخدمين. تكون بطيئة، لكنها مقروءة وقابلة للاستخدام.

أي مهمة يمكن اعتبارها مهمة batch. إذا لم يكن أحد يراقب الشاشة، فسرعة التنفيذ الفعلية تصبح مسألة جدولة، لا متطلباً أساسياً.

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

FAQ

كم مقدار VRAM الذي أحتاج إليه لنموذج 7B أو 8B؟

تحتاج إلى نحو 7 GB لنموذج 8B مكمَّم إلى 4-bit مع سياق 8k، ونحو 8 GB مع سياق 16k، عند استخدام ذاكرة التخزين المؤقت الافتراضية FP16 في Ollama. يبلغ حجم الأوزان نحو 4.9 GB، وتضيف ذاكرة KV المؤقتة نحو 1.07 GB عند 8k أو 2.15 GB عند 16k، بينما يبلغ الحمل الإضافي نحو 1 GB. تستوعب بطاقة بسعة 8 GB النموذج عند 8k، لكنها تعمل بهامش ضيق عند 16k، في حين توفّر بطاقة بسعة 12 GB مساحة مريحة للسياقات الأطول. يؤدي تغيير ذاكرة التخزين المؤقت إلى q8_0 إلى خفض حصتها إلى النصف تقريباً. إذا كنت تخطط لاستخدام سياق 128k، فاحسب سعة ذاكرة التخزين المؤقت بشكل مستقل، لأنها قد تصبح أكبر من الأوزان.

هل يمكنني تشغيل Ollama من دون GPU؟

نعم. ينتقل Ollama تلقائياً إلى استخدام CPU، ولا يحتاج إلا إلى مقدار كافٍ من RAM لاحتواء النموذج. توقّع نحو 5 إلى 12 token في الثانية لنموذج 8B مكمَّم إلى 4-bit، بحسب سرعة الذاكرة. يقترب ذلك من سرعة القراءة لمستخدم واحد. تمثل المطالبات الطويلة المشكلة الفعلية عند استخدام CPU، لأن قراءة سياق يتكون من 30,000 token تتطلب قدرة حسابية كبيرة وتستغرق وقتاً أطول بكثير من توليد الرد.

لماذا تكون سرعة GPU لدي أعلى بقليل من CPU؟

السبب المعتاد هو أن النموذج لم يتسع بالكامل في VRAM، لذلك تعمل بعض الطبقات على CPU، وينتظر كل token الجزء الأبطأ. شغّل ollama ps وتحقق من أن العمود PROCESSOR يقرأ 100% GPU. إذا ظهر تقسيم، فاستخدم تكميمًا أصغر أو نموذجًا أصغر. والسبب الشائع الآخر هو استخدام اختبار أداء قصير يهيمن فيه وقت تحميل النموذج على القياس.

هل يستحق VPS مزوّد بـGPU التكلفة لمستخدم واحد؟

غالباً لا. يبلغ متوسط سرعة القراءة الصامتة للبالغين باللغة الإنجليزية نحو 4.0 إلى 4.3 كلمة في الثانية، ويجب تحويل عدد token في الثانية إلى كلمة في الثانية قبل مقارنة خادم CPU بهذه السرعة. الحالات التي تبرر التكلفة لمستخدم واحد هي المطالبات الطويلة، وتوليد الصور، والضبط الدقيق. ويكون تقديم الخدمة لعدة مستخدمين في الوقت نفسه أقوى مبرر، لأن المعالجة الدفعية تتيح لبطاقة GPU مشاركة قراءات الأوزان بين الطلبات.

هل أستأجر GPU بالساعة أم أشغّله باستمرار؟

استأجره بالساعة عندما يكون العمل متقطعاً، مثل الضبط الدقيق، أو تشغيل تضمين جماعي، أو مهمة نسخ صوتي دفعية. شغّله باستمرار فقط عندما تبقى البطاقة مشغولة، لأن تكلفة GPU المحجوزة تُحتسب بحسب الوقت لا بحسب عدد token الناتجة. يكون المساعد منخفض الاستخدام أرخص على CPU VPS، أو على API مُدار تُدفع تكلفته بحسب عدد token، من تشغيل GPU خاملاً.