كلاود
ذكاء اصطناعي

GPU مقابل CPU للاستدلال: متى يستحق المعالج الرسومي أن تدفع مقابله

كلاود|٢ أكتوبر ٢٠٢٦|6 دقائق قراءة|١٥٧ مشاهدة

المعالج العادي يكفي لتشغيل النماذج الصغيرة المكمّمة بحمل خفيف، بينما يصبح المعالج الرسومي ضرورياً حين تكبر النماذج أو يرتفع عدد الطلبات المتزامنة. القاعدة: ابدأ بـCPU واختبر tokens في الثانية قبل أن تلتزم بعتاد أغلى.

الجواب المباشر: إذا كنت تشغّل نموذجاً صغيراً مكمّماً (بحجم 3B إلى 8B معاملاً بتكميم Q4) لعدد محدود من المستخدمين، فالمعالج العادي CPU يكفيك، وتحصل على سرعة معقولة تتراوح من 10 إلى 30 رمزاً في الثانية على خادم سحابي بـ8GB إلى 16GB رام. أما إذا كبر النموذج فوق 13B معاملاً، أو ارتفع عدد الطلبات المتزامنة، أو احتجت زمن استجابة منخفضاً لتجربة محادثة حيّة، فهنا يصبح المعالج الرسومي GPU هو الفرق بين ثوانٍ مقبولة ودقيقة كاملة انتظار. الفرق العملي ضخم: مهمة تستغرق 40 ثانية على CPU قد تنتهي في ثانيتين على GPU لائق، لأن الاستدلال في نماذج اللغة عملية ضرب مصفوفات متوازية، وهذا بالضبط ما صُمّم له المعالج الرسومي بآلاف أنوية المعالجة الصغيرة مقابل عشرات الأنوية في CPU.

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

لماذا يتفوق GPU في الاستدلال أصلاً

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

لكن التفوق ليس مطلقاً. النماذج الصغيرة المكمّمة صُمّمت لتعمل بكفاءة على CPU، والتكميم يقلّص حجم المعاملات من 16 بت إلى 4 بت مثلاً، فيخفّ الحمل على الذاكرة والمعالج معاً. إذا كان النموذج صغيراً والحمل خفيفاً، فرق GPU يصبح ترفاً لا حاجة. تفصيل التكميم وأثره على الجودة والذاكرة يستحق قراءة مستقلة لأنه المفتاح الأول لتشغيل نموذج أكبر على عتاد أقل.

جدول: ماذا تختار حسب حجم النموذج والحمل

الحالةحجم النموذجالحملالاختيارسرعة تقريبية
مساعد داخلي لفريق صغير3B إلى 8B مكمّم Q4مستخدم أو اثنان في وقت واحدCPU يكفيمن 10 إلى 30 رمزاً/ث
روبوت دعم بحجم متوسط8B إلى 13Bعدة طلبات متزامنةGPU مفضّلمن 40 إلى 80 رمزاً/ث
خدمة إنتاج بزيارات عالية13B فأكثرعشرات المتزامنينGPU ضرورييتوقف على البطاقة
توليد صور Stable Diffusion-أي حمل عمليGPU ضروري عملياًثوانٍ مقابل دقائق

حساب تكلفة الملكية لا سعر البطاقة

المعالج الرسومي أغلى في الشراء والتشغيل، فلا تنظر لسعره وحده بل للتكلفة الكلية مقابل ما يقدّمه. إذا كان نموذجك الصغير يخدم عشرة موظفين بأسئلة متفرّقة خلال اليوم، فأنت تدفع مقابل بطاقة تجلس عاطلة 95% من الوقت. في هذه الحالة خادم سحابي عادي بموارد كافية أوفر بكثير ويؤدي الغرض. تبدأ باقات الخادم السحابي من كلاود بـ3,450 ريالاً سنوياً لباقة أساس، وترقّي الرام والمعالج فوراً حين تكبر حاجتك، فتدفع على قدر ما تستهلك فعلاً لا على قدر ما قد تحتاج نظرياً. راجع الأسعار والباقات لتقارن الموارد بالريال قبل القرار.

المقابل، إذا كان الاستدلال جوهر منتجك وكل ثانية تأخير تكلّفك عميلاً، فالبطاقة الرسومية استثمار لا ترف، لأن بطء التجربة نفسه تكلفة خفية. المعادلة تتلخّص في سؤال واحد: هل التأخير الحالي على CPU يضرّ العمل أم يُحتمل؟ إن كان يُحتمل، وفّر المال. إن كان يضرّ، ادفع مقابل السرعة.

التزامن والذاكرة: العاملان اللذان يقلبان القرار

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

العامل الثاني هو الذاكرة، وهو قيد كثيراً ما يُنسى. النموذج يجب أن يُحمّل كاملاً في الذاكرة ليعمل، فنموذج بحجم 8B معاملاً بتكميم Q4 يحتاج نحو 5GB إلى 6GB، ويجب أن تسع رام السيرفر النموذج مع هامش لنظام التشغيل وطلبات المستخدمين. إن لم تكفِ الرام، يفشل التحميل أو يبطؤ بشدة. على المعالج العادي، سرعة الاستدلال تحكمها أيضاً عرض نطاق الذاكرة لا عدد الأنوية وحده، لأن كل رمز يتطلب قراءة معاملات النموذج من الرام، حيث يملك المعالج الرسومي ذاكرة أسرع بمراحل وهذا جزء أساسي من تفوّقه. الخلاصة: قدّر رامك على حجم النموذج أولاً، ثم فكّر في التزامن، فالرقمان معاً يحدّدان حاجتك الحقيقية للعتاد لا سرعة رمز معزول.

كيف تختبر قبل أن تلتزم

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

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

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

القرار العملي في خطوات

ابدأ من CPU دائماً حتى يثبت العكس. هذه خلاصة قابلة للتطبيق مباشرة:

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

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

مشاركة