بقلم هل تحتاج إلى VPS مزوّد بـGPU أم يكفي CPU؟
اكتشف متى تحتاج فعلاً إلى GPU: نماذج المحادثة المكمّمة 7B إلى 27B وembeddings وWhisper small تعمل غالباً على CPU. ابدأ بالقياس قبل الترقية.
هل تحتاج إلى VPS مزوّد بـGPU، أم تكفي وحدة المعالجة المركزية؟
يغيّر VPS المزوّد بـGPU أمرين عند تشغيل نموذج بنفسك: سرعة خروج الرموز، وحجم النموذج الذي يمكن أن يتسع له الذاكرة أساساً. ولا يغيّر أي شيء آخر. إذا كان عبء العمل لديك نموذج محادثة مكمّماً بحجم 7B إلى 27B يجيب شخصاً واحداً في كل مرة، أو مهمة توليد embeddings بحجم منخفض، أو نسخاً صوتياً باستخدام Whisper small، فإن VPS عادياً يعتمد على CPU ويمتلك قدراً كافياً من RAM ينجز المهمة بالفعل. ابدأ باستخدام CPU، وقِس الرقم الذي يسبب لك المشكلة، ثم انتقل إلى مستوى أعلى.
السبب هو عرض نطاق الذاكرة. عندما يولّد نموذج لغوي رمزاً واحداً، فإنه يقرأ من الذاكرة كل الأوزان التي يحتاج إليها. يبلغ حجم نموذج 8B مكمّم إلى 4 bits نحو 4.7 GB على القرص، ويكون حجمه في الذاكرة قريباً من ذلك، لذا يتطلب إنتاج رمز واحد نقل نحو 4.7 GB. اقسم عرض نطاق ذاكرة الجهاز على هذا الرقم، وستحصل على الحد الأقصى النظري لعدد الرموز في الثانية. يفسّر هذا الحساب الواحد تقريباً كل benchmark ستقرأه.
ما الذي يوفّره GPU فعلياً
عرض النطاق الترددي. ينقل DDR5 في خادم حديث عشرات الجيجابايتات في الثانية. وتنقل ذاكرة GPU (VRAM، أو ذاكرة الفيديو) مئات الجيجابايتات إلى أكثر من ألف جيجابايت في الثانية. وهذه النسبة هي مقدار التسريع، وهي كبيرة.
السعة مع السرعة. يمكن لخادم CPU مزوّد بـ64 GB من RAM تحميل نموذج 70B بدقة 4 بت. لكنه سيعمل بوتيرة أقرب إلى القراءة منها إلى المحادثة. لا يساعد GPU هنا إلا إذا كان النموذج يتسع في VRAM، لأن الطبقات تعود إلى المسار البطيء فور انتقالها إلى RAM النظام.
إنتاجية المعالجة الدفعية. هذا هو الجانب الذي يستخف به الناس. عندما يولّد GPU استجابة لمستخدم واحد، يبقى معظم قدرته الحاسوبية خاملاً لأنه ينتظر الذاكرة. عند معالجة 20 طلباً في الوقت نفسه، تخدم قراءة الأوزان نفسها الطلبات العشرين كلها. ترتفع سرعة إنتاج الرموز الإجمالية عدة أضعاف، بينما ينخفض أداء كل مستخدم بدرجة طفيفة فقط. لا يفعل CPU ذلك. فعلى خادم CPU، يؤدي مستخدمان متزامنان تقريباً إلى خفض سرعة كل منهما إلى النصف. إذا كنت تبني API يستدعيه عدد كبير من العملاء، فالمعالجة الدفعية هي الحجة الأهم لاستخدام GPU، وتتجاوز أهمية السرعة الخام في مسار واحد.
معالجة المطالبة. تعتمد قراءة مطالبة طويلة على القدرة الحاسوبية، لا على عرض نطاق الذاكرة، وهنا تتفوق GPUs بأكبر هامش. يستغرق سياق من 30,000 رمز دقيقة واحدة لمعالجته على CPU، لكنه يستغرق بضع ثوانٍ على GPU. وتظهر هذه الميزة باستمرار في إعدادات الاسترجاع التي تضع المستندات داخل كل طلب.
الأرقام التقريبية وكيفية قراءتها
يتضمن المقطع أدناه أرقاماً نموذجية منشورة للتشغيل بمسار واحد لنموذج بحجم 8B وبتكميم 4-bit، وذلك حتى July 2026. وهي تقديرات تقريبية لرتبة المقدار وليست ضماناً. سيؤثر التكميم وطول السياق ومحرك الاستدلال فيها.
The data behind this chart
[
{
"label": "8 vCPU, DDR4",
"mem_bandwidth_gbs": 40,
"tokens_per_sec": 6
},
{
"label": "16 vCPU, DDR5",
"mem_bandwidth_gbs": 75,
"tokens_per_sec": 11
},
{
"label": "24GB GPU",
"mem_bandwidth_gbs": 300,
"tokens_per_sec": 50
},
{
"label": "40GB data-centre GPU",
"mem_bandwidth_gbs": 1555,
"tokens_per_sec": 130
}
]يعرض صف GPU بسعة 24 GB سرعة 50 token في الثانية، مقارنةً بسرعة 11 لجهاز مزود بوحدة CPU وذاكرة DDR5. وهذا يعادل تقريباً خمسة أضعاف، بما يتوافق مع نسبة عرض النطاق الترددي، لا مع اختلاف في القدرة الحسابية الخام. كما أن معدل النقل الفعلي يكون أقل من ناتج قسمة عرض النطاق الترددي على حجم النموذج، لأن الانتباه إلى سياق متزايد يضيف أعمالاً لا تأخذها القسمة البسيطة في الحسبان.
للمقارنة، يقرأ الشخص بسرعة تتراوح بين 5 و10 كلمات في الثانية. وأي سرعة تبلغ 15 token في الثانية أو أكثر تبدو بالفعل كالكتابة العادية لقارئ واحد. لذلك تكون إعدادات CPU-only الكثيرة مناسبة عملياً دون ضجيج.
حساب سعة VRAM قبل الشراء
حجم ملف النموذج هو الحد الأدنى، وليس المتطلب الفعلي. احسب سعة الأوزان، وأضف إليها KV cache (ذاكرة التخزين المؤقت للمفاتيح والقيم، وهي الذاكرة التي تحتفظ بها آلية attention لكل رمز)، ثم أضف نحو 1 GB للنفقات العامة.
قاعدة عملية اعتباراً من July 2026: خذ حجم ملف النموذج بالـgigabytes وأضف 20 بالمئة لسياق عادي يتراوح بين 8k و16k. يحتاج نموذج 8B بحجم 4.7 GB إلى نحو 6 GB من VRAM. ويبلغ حجم نموذج 27B بدقة 4 bits نحو 16 GB، ويحتاج تقريباً إلى 20 GB. أما نموذج 70B بدقة 4 bits فيبلغ حجمه نحو 40 GB، ويحتاج إلى بطاقة بسعة 48 GB أو إلى بطاقتين أصغر. وتظل هذه الحسابات صالحة مع أحجام أكبر بكثير، ويوضح حساب VRAM لنموذج يضم 2.8 trillion parameter مثل Kimi K3 النقطة التي لا يعود عندها اختيار البطاقة هو السؤال الأساسي.
تتجاوز السياقات الطويلة هذه القاعدة. ينمو KV cache خطياً مع طول السياق، وعند 128k tokens قد يتجاوز حجم الأوزان نفسها. إذا كنت تخطط لاستخدام سياقات طويلة، فاحسب السعة المطلوبة للتخزين المؤقت أولاً، وتحقق من خيارات محركك لضغط التخزين المؤقت كمّياً.
تحقق مما هو موجود فعلياً على الجهاز
على مثيل GPU، تأكد أولاً من أن برنامج التشغيل يتعرّف على البطاقة قبل تنفيذ أي خطوة أخرى.
nvidia-smiيجب أن يعرض الجدول اسم GPU وإصدار برنامج التشغيل والذاكرة المستخدمة من إجمالي الذاكرة. ظهور NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver يعني أن برنامج التشغيل مفقود، أو أن وحدة النواة لم تُعَدْ بناؤها بعد ترقية النواة. في صورة Ubuntu القياسية، يكون الإصلاح عادةً هو sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install، ثم إعادة التشغيل حتى تُحمَّل الوحدة الجديدة.
بالنسبة إلى الحاويات، لا يكفي برنامج التشغيل وحده. يحتاج 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، وتحتوي قائمة القدرات فيه على 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 عدة أضعاف تكلفة مثيل CPU مماثل، وتُحاسب عن كل ساعة تكون فيها قيد التشغيل، لا عن عدد الرموز التي تنتجها. ويُعد تشغيل GPU دائماً لمعالجة عدد محدود من الطلبات يومياً أغلى طريقة لتنفيذ الاستدلال. وتتمثل نقطة التعادل في معدل الاستخدام: يكون GPU المشغول منخفض التكلفة لكل رمز، بينما يمثّل GPU الخامل هدراً محضاً.
توجد ثلاث طرق عملية واضحة. شغّل الأعمال منخفضة الحجم والمستقرة على VPS يستخدم CPU. أرسل الطلبات الصعبة العرضية إلى API مستضاف وادفع مقابل كل رمز. استأجر GPU بالساعة للمهام الدفعية، أو الضبط الدقيق، أو تشغيل تضمين كبير، ثم أوقفه واحذفه. من الطبيعي الجمع بين هذه الطرق، وينطبق هنا أيضاً الانضباط المالي الموضح في التحكم في تكلفة وكيل AI على VPS يعمل دائماً، مع اختلاف أن وقت الخمول هو مصدر التسرب هنا، لا عدد الرموز.
ما الذي يظل يعمل جيداً من دون GPU
توليد Embeddings بمعدل منخفض. يعالج نموذج Embeddings صغير مئات المستندات القصيرة في الدقيقة باستخدام عدد قليل من أنوية CPU، كما أن الفهرس الذي تنشئه مرة واحدة لا يحتاج إلى سرعة عالية.
استخدم Whisper small وbase لتحويل الكلام إلى نص. ينفّذ Faster-whisper عملية التحويل على CPU بسرعة تقترب من الوقت الفعلي عند استخدام النموذج small، وهذا يكفي لخط أنابيب يعمل طوال الليل.
نماذج المحادثة المكمّمة حتى نحو 27B لمستخدم واحد أو مستخدمين. تكون بطيئة، لكنها مقروءة وقابلة للاستخدام.
أي مهمة يمكن اعتبارها مهمة batch. إذا لم يكن أحد يراقب الشاشة، فسرعة التنفيذ الفعلية تصبح مسألة جدولة، لا متطلباً أساسياً.
ما يحتاج فعلاً إلى GPU هو التدريب أو الضبط الدقيق الذي يتجاوز adapter صغيراً، وتقديم الخدمة لعدد كبير من المستخدمين المتزامنين، وتوليد الصور والفيديو، والكلام في الوقت الفعلي عندما تكون زمن الاستجابة جزءاً من المنتج.
FAQ
ما مقدار VRAM الذي أحتاج إليه لتشغيل نموذج 7B أو 8B؟
تحتاج إلى نحو 6 GB لتشغيل نموذج 8B مكمّم إلى 4-bit ضمن سياق عادي يتراوح بين 8k و16k. يبلغ حجم الأوزان نحو 4.7 GB، ويُستخدم باقي الذاكرة لذاكرة KV cache ونحو 1 GB للنفقات الإضافية. تتيح بطاقة بسعة 12 GB مساحة مريحة للسياقات الأطول. إذا كنت تخطط لتشغيل سياق بسعة 128k، فاحسب سعة الـcache بشكل منفصل، لأنّها قد تصبح أكبر من الأوزان.
هل يمكنني تشغيل 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. إذا ظهر تقسيم، فاستخدم تكميمًا أصغر أو نموذجًا أصغر. والسبب الشائع الآخر هو استخدام اختبار قصير يهيمن فيه وقت تحميل النموذج على القياس.
هل يستحق استئجار GPU VPS لمستخدم واحد؟
عادةً لا. يقرأ الشخص بسرعة تتراوح بين 5 و10 كلمات في الثانية، بينما ينتج خادم CPU الرموز بسرعة أعلى من ذلك لنماذج تصل إلى نحو 13B. الحالات التي تبرر التكلفة لمستخدم واحد هي المطالبات الطويلة، وتوليد الصور، والضبط الدقيق. ويكون تشغيل الخدمة لعدة مستخدمين في الوقت نفسه أقوى مبرر، لأن المعالجة الدفعية تتيح لـGPU واحد الإجابة عن عشرين طلباً بتكلفة تقترب من تكلفة الإجابة عن طلب واحد.
هل ينبغي استئجار GPU بالساعة أم تشغيله باستمرار؟
استأجره بالساعة عندما يكون العمل متقطعاً، مثل الضبط الدقيق، أو تشغيل تضمين جماعي، أو مهمة نسخ صوتي دفعية. شغّله باستمرار فقط عندما تظل البطاقة مشغولة، لأن مثيل GPU يُحاسَب على مدة وجوده، لا على عدد الرموز التي ينتجها. يكون المساعد منخفض حركة الاستخدام أقل تكلفة على CPU VPS أو عبر API مستضاف تُدفع تكلفته لكل token، مقارنةً بـGPU خاملاً.