هل تحتاج كرت شاشة GPU لتشغيل وكيل ذكاء اصطناعي؟ إجابة صريحة

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

لماذا يعمل الوكيل المعتمد على API جيدًا على CPU؟

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

عمليًا، سيرفر الوكيل يقضي معظم وقته في الانتظار. المعالج يعمل في دفعات قصيرة، والذاكرة تذهب إلى بيئة التشغيل (Node.js أو Python) وقاعدة البيانات وأي ذاكرة مؤقتة. ولو وضعت أقوى كرت شاشة على سيرفرك فلن يرد API النموذج أسرع.

متى تحتاج GPU فعلًا؟

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

• التدريب أو الـ Fine-tuning. حتى طرق الضبط الخفيفة بطيئة على CPU إلى درجة غير عملية، إلا مع النماذج الصغيرة جدًا.

• إنشاء Embeddings بكميات ضخمة. بضعة آلاف من المستندات لا مشكلة فيها على CPU، أما إعادة معالجة ملايين الأجزاء في وقت محدد فهي مهمة GPU.

• توليد الصور والفيديو والصوت. نماذج Diffusion والفيديو أحمال GPU بطبيعتها. وتحويل الكلام إلى نص يعمل على CPU للمقاطع القصيرة المتفرقة، لكنه يبطؤ كثيرًا مع الحجم الكبير.

• قواعد تمنع إرسال النصوص إلى API خارجي. إذا كان ممنوعًا خروج أي بيانات من بنيتك التحتية فعليك تشغيل النموذج بنفسك، ونموذج قوي بسرعة مقبولة يعني GPU.

تشغيل نماذج صغيرة محليًا على CPU: توقعات واقعية

أدوات مثل Ollama وllama.cpp تجعل تشغيل نماذج مفتوحة مضغوطة (Quantized) على سيرفر بلا GPU أمرًا سهلًا. الضغط يخزّن أوزان النموذج بعدد بتات أقل، مثل 4 بت بدل 16 بت، فينخفض استهلاك الذاكرة إلى جزء صغير مع خسارة في الجودة. وكتقدير تقريبي، نموذج بحجم 7 إلى 8 مليارات معامل مضغوط إلى 4 بت يحتاج نحو 4 إلى 6 GB من RAM بما فيها مساحة السياق، والنماذج الأكبر تحتاج أكثر.

ما الذي تتوقعه؟

• السرعة: على CPU يتحدد التوليد أساسًا بعرض نطاق الذاكرة. الردود أبطأ بوضوح من API مستضاف، وتختلف السرعة كثيرًا حسب المعالج وسرعة الذاكرة وحجم النموذج ومستوى الضغط.

• التزامن: سيرفر CPU يتحمل عددًا قليلًا جدًا من عمليات التوليد المتزامنة قبل أن تبدأ الطلبات في الانتظار.

• الجودة: النماذج الصغيرة جيدة في التصنيف واستخراج البيانات والتلخيص القصير والتوجيه البسيط، لكنها أضعف في التفكير متعدد الخطوات وفي استدعاء الأدوات بشكل موثوق، وهو ما يعتمد عليه الوكيل.

• التنافس على الموارد: التشغيل المحلي سيستهلك كل الأنوية المتاحة، فقد يبطئ قاعدة بيانات أو تطبيق ويب على نفس السيرفر. حدّد عدد الـ Threads أو خصص له سيرفرًا منفصلًا.

التشغيل على CPU معقول للمهام الدفعية غير الفورية، والأدوات الداخلية لعدد قليل من المستخدمين، والمعالجة المسبقة للبيانات الحساسة، والتجارب. لكنه نادرًا ما يكون المحرك المناسب لوكيل محادثة يتعامل مع العملاء مباشرة.

الحل الهجين: نموذج عبر API وEmbeddings محلية

إعداد شائع ومنطقي: نموذج التفكير الأساسي عبر API مستضاف، ونموذج Embeddings صغير يعمل محليًا على CPU للاسترجاع:

1. تُقسَّم المستندات إلى أجزاء وتُحوَّل إلى متجهات على سيرفرك بنموذج Embeddings صغير.

2. تُخزَّن المتجهات في PostgreSQL مع pgvector بجانب بقية بياناتك.

3. عند السؤال يُحوَّل سؤال المستخدم إلى متجه محليًا، وتُسترجع الأجزاء الأقرب، ولا يُرسل إلى نموذج الـ API إلا هذه الأجزاء مع السؤال.

بهذا تبقى مستنداتك تحت سيطرتك، وتتجنب رسوم الـ Embeddings لكل استدعاء أثناء الإدخال بالجملة. نماذج الـ Embeddings صغيرة، لذلك تكون سرعتها على CPU مقبولة عادة مع أحجام متوسطة من المستندات. وقاعدتان مهمتان: استخدم نفس نموذج الـ Embeddings في الإدخال والاستعلام، واجعل أبعاد عمود المتجه مطابقة لهذا النموذج. المخطط والاستعلامات موجودة في دليل RAG مع pgvector.

# نموذج Embeddings محلي عبر Ollama على سيرفر بلا GPU
ollama pull nomic-embed-text
curl http://localhost:11434/api/embed \
  -d '{"model": "nomic-embed-text", "input": "ما هي سياسة الاسترجاع لديكم؟"}'

اترك واجهة Ollama مربوطة على localhost كما هو الإعداد الافتراضي، أو ضعها خلف مصادقة، ولا تجعلها متاحة من الإنترنت.

اختيار المعالج والذاكرة لوكيل يعتمد على API

احسب الموارد لما يعمل حول النموذج، لا للنموذج نفسه. هذه نقاط بداية معتادة وليست قواعد ثابتة:

• بوت واحد أو وكيل بسيط (بوت تيليجرام أو واتساب أو ديسكورد يستدعي API بذاكرة خفيفة): 1 vCPU و2 GB RAM تكفي غالبًا.

• وكيل مع PostgreSQL وpgvector وبضعة آلاف من المستندات: نحو 2 vCPU و4 GB تمنح قاعدة البيانات مساحة للتخزين المؤقت والفهارس.

• عدة وكلاء وWorkers وطوابير، أو n8n بجانب الوكلاء: 4 vCPU و8 GB أو أكثر.

• متصفحات Headless (Playwright أو Puppeteer للوكلاء الذين يتصفحون أو يجمعون البيانات): كل نسخة متصفح قد تستهلك مئات الميجابايت، فاحسب الذاكرة لكل متصفح متزامن.

• Embeddings محلية أو نموذج محلي صغير: أضف ذاكرة للنموذج، وتوقع أن يشغل عدة أنوية أثناء عمله.

قِس ولا تخمّن. شغّل الوكيل تحت حمل واقعي وراقب htop وfree -h وdocker stats. إذا بقيت الذاكرة أقل من الحد بهامش مريح وكان المعالج خاملًا بين الطلبات، فالحجم مناسب. وتفاصيل التخزين والشبكة في متطلبات سيرفر تطبيقات الذكاء الاصطناعي.

ماذا يعني هذا لقرار الاستضافة؟

إذا كان وكيلك يستدعي API، فاختر سيرفر CPU يعمل باستمرار بذاكرة كافية وتخزين NVMe سريع، في موقع سيرفر قريب من مستخدميك ومن الخدمات التي تستدعيها. وفي مقارنتنا أين تستضيف وكيل الذكاء الاصطناعي وازنّا بين الـ VPS والـ Serverless والمنصات المُدارة. أما إذا كنت تحتاج فعلًا لاستضافة نموذج كبير بنفسك، فخصص ميزانية لبنية GPU من مزوّد متخصص، وأبقِ بقية المنظومة (منطق الوكيل، قاعدة البيانات، الطوابير، الـ Webhooks) على سيرفرات CPU عادية تكلفتها أقل بكثير للتشغيل على مدار الساعة.

أسئلة شائعة

هل يمكن تشغيل نموذج لغوي مفتوح المصدر على VPS بلا GPU؟

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

هل يحتاج وكيل الذكاء الاصطناعي ذاكرة RAM كبيرة؟

عملية الوكيل نفسها تحتاج القليل عادة. الذاكرة تكبر مع ما يعمل بجانبها: قاعدة بيانات، أو متصفحات Headless، أو نماذج Embeddings محلية، أو نموذج لغوي محلي.

هل تحتاج الـ Embeddings إلى GPU؟

ليس مع الأحجام المتوسطة، فنماذج الـ Embeddings الصغيرة تعمل على CPU بسرعة مقبولة. الـ GPU يفيد عندما تعالج مجموعات ضخمة جدًا في وقت قصير.

هل سيجعل الـ GPU وكيلي المعتمد على API أسرع؟

لا. زمن الرد يتحدد أساسًا بـ API النموذج والشبكة. لتسريع الوكيل استخدم نموذجًا أسرع، واختصر الـ Prompt ونافذة الذاكرة، وفعّل بث الرد، واستضف الوكيل قريبًا من مستخدميك.

تشغيل وكلاء الـ API على IM HOST

تقدم IM HOST سيرفرات CPU وليس سيرفرات GPU، وهذا ما يناسب الوكلاء الذين يستدعون نماذج عبر API. باقات استضافة وكلاء الذكاء الاصطناعي تبدأ من 1 vCPU و2 GB وتصل إلى 12 vCPU و32 GB، وعليها Docker وNode.js وPython وPostgreSQL مع pgvector مثبتة مسبقًا، مع نسخ احتياطي يومي مجاني. وللمهام الجانبية الثقيلة على المعالج مثل الـ Embeddings المحلية، تتضمن باقات سيرفر VPS لينكس خيارات AMD EPYC 7313P وAMD Ryzen 9 9950X في بولندا وألمانيا.