كم يحتاج وكيل البرمجة من RAM على VPS؟

كم يحتاج VPS مخصّص لوكيل برمجي من RAM؟

ابدأ بـ 4 GB من RAM و2 vCPU لوكيل برمجي واحد يعمل باستمرار داخل مستودع. انتقل إلى 8 GB و4 vCPU فور انضمام language server أو عملية Docker build إلى الجلسة. يحدث ذلك في معظم المستودعات منذ اليوم الأول. عملية الوكيل نفسها صغيرة، لذلك ما يستهلك موارد الخادم هو toolchain الذي يديره الوكيل نيابةً عنك.

[
  {
    "plan": "Minimum viable",
    "ram_gb": 4,
    "vcpu": 2,
    "disk_gb": 50
  },
  {
    "plan": "Comfortable",
    "ram_gb": 8,
    "vcpu": 4,
    "disk_gb": 100
  },
  {
    "plan": "Team, 4 sessions",
    "ram_gb": 16,
    "vcpu": 8,
    "disk_gb": 200
  }
]

يفترض كل صف أعلاه أن النموذج يعمل في مكان آخر، خلف API تستدعيه عبر الشبكة. يحدد هذا الافتراض مسألة تحديد الموارد بالكامل، لذلك احسمه أولاً.

هل تشغّل الوكيل أم النموذج؟

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

تشغيل النموذج بنفسك منتج مختلف يتطلب عتاداً مختلفاً. تبقى أوزان النموذج في الذاكرة طوال فترة تشغيل الخادم. يحتاج نموذج يضم 7 billion parameters ومكمّم إلى 4 bits إلى نحو 5 GB للأوزان وحدها، قبل إضافة key/value cache الذي يزداد حجمه مع طول السياق. عند استخدام CPU فقط، ينتج vCPU مشترك بضع وحدات token في الثانية، وقد تصدر مهمة وكيل واحدة آلاف وحدات token. لذلك فإن العمل الذي يستغرق أقل من دقيقة عند استخدام API يستغرق معظم ساعة عند تشغيله محلياً. إذا كان هذا هو ما تريده، فحدّد الموارد وفق VRAM (ذاكرة الفيديو في GPU)، واقرأ ما الذي يوفّره VPS مزوّد بـGPU فعلياً بدلاً من قراءة هذه الصفحة.

يفترض كل ما يلي استخدام نموذج سحابي.

ما الذي يستخدم الذاكرة فعلياً

[
  {
    "label": "Agent CLI process, idle",
    "typical_mb": 250,
    "peak_mb": 600
  },
  {
    "label": "TypeScript language server",
    "typical_mb": 700,
    "peak_mb": 2000
  },
  {
    "label": "rust-analyzer, large workspace",
    "typical_mb": 1200,
    "peak_mb": 4000
  },
  {
    "label": "Headless Chrome, one tab",
    "typical_mb": 350,
    "peak_mb": 900
  },
  {
    "label": "Node test run, 4 workers",
    "typical_mb": 1600,
    "peak_mb": 3000
  },
  {
    "label": "Docker image build",
    "typical_mb": 800,
    "peak_mb": 2500
  }
]

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

يحتوي المخطط على 6 صفاً، ويُعد الوكيل الأقل استهلاكاً. يستهلك نحو 250 MB في وضع الخمول، لأنه يحتفظ بمحادثة وذاكرة تخزين مؤقت صغيرة للملفات ولا يفعل شيئاً آخر. يصل خادم لغة TypeScript إلى نحو 2000 MB أثناء الفهرسة، لأنه ينشئ رسم أنواع لكل ملف يمكن الوصول إليه من tsconfig.json، ثم يحتفظ بهذا الرسم في الذاكرة للإجابة عن الطلب التالي بسرعة. ويتجاوز rust-analyzer عادةً 4000 MB في مساحة عمل كبيرة للسبب نفسه، عبر كل crate في مساحة العمل.

يستهلك Headless Chrome نحو 350 MB للمتصفح مع علامة تبويب واحدة، وكل علامة تبويب إضافية هي عملية أخرى في نظام التشغيل. يؤدي تشغيل اختبارات Node مع أربعة عمال إلى إنشاء أربع عمليات Node، لذلك يبلغ ذروة تقارب 3000 MB. ويبلغ إنشاء صورة Docker ذروة تقارب 2500 MB، لأن عملية الإنشاء تشغّل مترجم مشروعك نفسه داخل الحاوية، بينما يكتب البرنامج الخفي الطبقات.

sudo apt update && sudo apt install -y time
/usr/bin/time -v -o /tmp/build.rusage npm run build
grep "Maximum resident set size" /tmp/build.rusage

اقرأ العمود available من free -h، لا العمود free. يستخدم Linux كل صفحة متاحة في ذاكرة التخزين المؤقت على القرص، لذلك تكون قيمة free صغيرة على خادم سليم تماماً ولا تخبرك بشيء. أما available فهي الذاكرة التي يمكن لعملية جديدة الحصول عليها فعلياً.

ثلاثة تكوينات عملية

الحد الأدنى العملي: 4 GB من RAM، و2 vCPU، و50 GB من مساحة القرص. جلسة واحدة للوكيل، ومستودع واحد، وخادم لغة واحد، وعمليات build يمكنك الانتظار حتى تكتمل. يعمل هذا المستوى، لكنه سيواجه OOM killer عندما تتزامن أول عملية اختبار كبيرة مع فهرسة خادم اللغة. أضف swap وحدّد عدد workers الخاصة بعملية build.

مريح: 8 GB من RAM، و4 vCPU، و100 GB من مساحة القرص. وكيل واحد، بالإضافة إلى Docker ومتصفح headless للاختبارات، مع سعة احتياطية لذروة واحدة في عملية build. هذا هو المستوى الذي ينبغي لمعظم المطورين الأفراد شراؤه. كما أن مضاعفة عدد vCPU تقلل وقت انتظار build إلى النصف تقريباً، وستلاحظ ذلك كثيراً أكثر من ملاحظتك لنقص الذاكرة.

للفريق: 16 GB من RAM، و8 vCPU، و200 GB من مساحة القرص. أربع جلسات متزامنة، لكل منها نسخة checkout وسلسلة أدوات مستقلة. حدّد الحجم وفق ذروة الاستخدام، لأن تكلفة أربعة وكلاء خاملة تكاد لا تُذكر، بينما تكلف أربع عمليات اختبار تعمل في اللحظة نفسها أربعة أضعاف قيمة الذروة في الصف السابق.

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

لماذا ينفد القرص قبل نفاد RAM

[
  {
    "label": "Ubuntu 24.04 base and toolchain",
    "typical_gb": 6
  },
  {
    "label": "One JS monorepo checkout",
    "typical_gb": 3
  },
  {
    "label": "node_modules across 3 branches",
    "typical_gb": 4
  },
  {
    "label": "Docker images and build cache",
    "typical_gb": 20
  },
  {
    "label": "Agent logs and journal, 90 days",
    "typical_gb": 2
  }
]

بجمع هذه البنود، يصبح قرص بسعة 50 GB شبه ممتلئ قبل أن تكتب سطرًا واحدًا من التعليمات البرمجية. أكبر عنصر منفرد هو Docker، ويستهلك نحو 20 GB، لأن BuildKit يحتفظ بكل طبقة وسيطة لكل عملية بناء إلى أن تطلب منه حذفها.

docker system df
docker builder prune --filter until=168h

يطبع docker system df المساحة القابلة للاسترداد لكل فئة، لذا شغّله قبل التنظيف وبعده. يحذف المرشح until=168h ذاكرة التخزين المؤقت لعمليات البناء الأقدم من أسبوع، ويُبقي ذاكرة هذا الأسبوع، وهي التي ما زالت توفر الوقت. يذهب docker image prune -a إلى أبعد من ذلك ويحذف كل صورة لا تستخدمها أي حاوية، لذا توقّع أن تسحب عملية البناء التالية الصور مرة أخرى.

تفشل مشاريع Node بطريقة أكثر غرابة. ينشئ npm install مئات الآلاف من الملفات الصغيرة، لذلك قد ينفد نظام الملفات من inodes بينما يظل df -h يعرض غيغابايتات متاحة. عندها تفشل عملية الكتابة بالخطأ No space left on device على قرص يبدو نصفه فارغًا.

df -h /
df -i /

إذا كان IUse% يعرض القيمة 100، فاحذف أدلة node_modules الخاصة بالفروع التي لم تعد تعمل عليها، أو انتقل إلى pnpm، الذي يخزّن كل إصدار من الحزمة مرة واحدة ويربطه بروابط صلبة داخل كل مشروع.

السجلات هي العامل الهادئ. يكتب وكيل يعمل باستمرار نصوص الجلسات، وتنمو journal الخاصة بـsystemd افتراضياً لتستهلك جزءاً من القرص.

sudo journalctl --disk-usage
sudo journalctl --vacuum-size=200M
du -xh --max-depth=1 / 2>/dev/null | sort -h | tail

اضبط SystemMaxUse=200M في /etc/systemd/journald.conf، ثم شغّل sudo systemctl restart systemd-journald لجعل هذا الحد دائماً، لأن عملية vacuum لمرة واحدة تستعيد مساحة اليوم فقط.

Swap: ما الذي يقدّمه وما الذي يخفيه

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

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
swapon --show

يجب أن يعرض swapon --show الآن /swapfile بالحجم الذي طلبته. من دون سطر /etc/fstab، تختفي Swap بعد إعادة التشغيل التالية ويعود الخادم بصمت إلى سلوكه السابق. إذا أعاد fallocate القيمة Operation not supported، فأنشئ الملف باستخدام sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 وتابع من chmod.

echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

تجعل قيمة swappiness المنخفضة النواة تستعيد ذاكرة التخزين المؤقت على القرص قبل نقل ذاكرة البرامج إلى القرص، ما يحافظ على استجابة language server.

وهنا ما تخفيه Swap. عندما تحتاج مهمة فعلياً إلى ذاكرة أكبر من سعة الخادم، تقضي النواة وقتها في نقل الصفحات بين RAM والقرص بدلاً من تشغيل عملية البناء. لا يحدث انهيار. لكن كل شيء يصبح بطيئاً جداً، ويرتفع load average بينما تكون وحدة المعالجة المركزية في وضع خمول.

vmstat 1 10

تعني القيم المستقرة وغير الصفرية في العمودين si وso حدوث swapping مستمر. لذلك يكون الحل تقليل التوازي أو زيادة RAM، وليس زيادة Swap مطلقاً. على الخادم الصغير، يوفّر sudo apt install -y zram-tools مساحة Swap مضغوطة داخل RAM، ويمكن ضبطها في /etc/default/zramswap. وهي أسرع بكثير من ملف Swap، لكنها تستهلك RAM لتوفير RAM، ولذلك تفيد مع الصفحات غير النشطة، ولا تفيد مع عملية بناء تحتاج إلى ذاكرة عمل فعلية.

لماذا يبدو أن وكيل البرمجة لديك يتوقف

هذا أكثر فشل يُساء تشخيصه على خادم صغير مخصص للوكيل. يعرض أحد الأوامر بلا مخرجات، وينتظر الوكيل، وتبدو الجلسة متجمّدة. لقد أنهى kernel العمليةَ قاتلُ نفاد الذاكرة (OOM). تلقت العملية الإشارة SIGKILL، لذلك لم تتمكن من طباعة خطأ، أو تفريغ سجل، أو إبلاغ الوكيل بما حدث. يرى الوكيل نتيجة فارغة ولا يرى رسالة خروج.

يسجّل kernel الحدث فعلياً:

sudo dmesg -T | grep -iE "out of memory|killed process"
sudo journalctl -k -b | grep -i oom

يبدو السطر الفعلي هكذا:

[Thu Aug  6 11:02:14 2026] Out of memory: Killed process 4711 (node) total-vm:4210880kB, anon-rss:3820104kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:8236kB oom_score_adj:0

توضح anon-rss مقدار الذاكرة التي كانت العملية تشغلها عند إنهائها. انتبه إلى العملية التي اختارها kernel: يعتمد التقييم أساساً على الذاكرة المستخدمة، لذلك غالباً ما ينهي خادم اللغة أو الوكيل بدلاً من عملية البناء التي دفعت الخادم إلى تجاوز الحد. ولهذا تحديداً يبدو العَرَض وكأن «الوكيل تعطل».

داخل Docker، يترك الحدث نفسه مؤشراً أوضح. تخرج الحاوية برمز 137، وهو 128 مضافاً إليه الإشارة 9.

docker ps -a
docker inspect "$(docker ps -lq)" | grep -i oomkilled

تؤكد "OOMKilled": true أن الحاوية اصطدمت بحد الذاكرة، ولم تتعطل من تلقاء نفسها.

الحل هو تحديد سقف خاص للأمر الذي يستهلك موارد كبيرة، بحيث تفشل عملية البناء بدلاً من الوكيل:

systemd-run --user --scope -p MemoryMax=4G -- npm run build

تنتهي عملية البناء الآن عند 4 GB، بينما يستمر الوكيل في العمل. يحوّل ذلك التوقف الغامض إلى أمر فاشل عادي برمز خروج واضح. يتطلب هذا جلسة مستخدم في systemd، لذا شغّل loginctl enable-linger $USER على خادم لا تصل إليه إلا عبر SSH. تعمل MemoryHigh= على خنق العملية عند بلوغ الحد بدلاً من إنهائها، وغالباً ما يكون ذلك الإعداد الأنسب لعملية بناء تفضّل أن تكتمل ببطء.

تطبيق الحد مرة واحدة باستخدام حدود الذاكرة في Compose

إذا كانت أدوات الوكيل تعمل داخل حاويات، فضع الحد الأقصى في ملف Compose حتى يُطبَّق في كل تشغيل.

services:
  agent:
    image: node:22-bookworm
    deploy:
      resources:
        limits:
          memory: 2g
          cpus: "1.5"

يطبّق Docker Compose v2 ‏deploy.resources.limits عند استخدام docker compose up عادي، لذلك لا يكون وضع swarm مشتركاً. وما زال المفتاح الأقدم mem_limit: 2g يعمل. يشرح الدليل الكامل لحدود الذاكرة في Compose الحجوزات وما يحدث عند بلوغ الحاوية حدها الأقصى. إذا لم يكن Docker مثبتاً على الخادم بعد، فثبّت Docker على VPS أولاً.

هناك خطأ واحد يكلّف بعض المستخدمين ساعات من العمل. تظل الحاوية المقيّدة بذاكرة قدرها 2 GB تقرأ قيمة /proc/meminfo من المضيف وعدد وحدات CPU فيه، لأن أياً منهما لا يخضع لعزل مساحة الأسماء. سيبدأ مشغّل الاختبارات الذي يحدد عدد العمال من عدد وحدات CPU ثمانية عمال داخل حاوية سعتها 2 GB على مضيف يضم 8 vCPU، ثم يتوقف بالرمز 137. حدّد القيم يدوياً:

npx jest --maxWorkers=2
export NODE_OPTIONS=--max-old-space-size=1536

تُقاس قيمة --max-old-space-size بالـMB، وتضع حداً أعلى لذاكرة V8. اضبطها أدنى من حد الحاوية حتى يعرض Node خطأً يمكنك قراءته بدلاً من اختفائه:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

هذه الرسالة مفيدة لأنها تذكر الحد الذي تم بلوغه والعملية التي بلغته. أما قاتل OOM فلا يفعل ذلك.

تشغيل عدة جلسات للوكلاء على خادم واحد

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

حدّد سقفاً صارماً لكل مستخدم حتى لا تؤدي جلسة خارجة عن السيطرة إلى تعطيل الخادم بالكامل:

id -u alice
sudo mkdir -p /etc/systemd/system/user-1001.slice.d
printf '[Slice]\nMemoryMax=6G\n' | sudo tee /etc/systemd/system/user-1001.slice.d/limit.conf
sudo systemctl daemon-reload
systemctl show user-1001.slice -p MemoryMax

استبدل 1001 بـ UID الذي طبعه id -u. يجب أن يطبع systemctl show القيمة MemoryMax=6442450944 مرة واحدة بعد تسجيل المستخدم الدخول. عندما يتجاوز إجمالي كل ما في جلسة ذلك المستخدم 6 GB، تقتل النواة عملية داخل شريحته، وتستمر جميع الجلسات الأخرى في العمل. إذا كان الوكيل يعمل كخدمة بدلاً من العمل داخل طرفية، فضع MemoryMax= في ملف وحدته بدلاً من ذلك. هذا هو النمط الواجب اتباعه عند استضافة وكيل ذاتيّاً كخدمة تعمل دائماً.

FAQ

هل تكفي ذاكرة RAM بسعة 2 GB لوكيل برمجي؟

تكفي لعملية الوكيل، نعم. لكنها نادراً ما تكفي للعمل الذي ينفذه. تستهلك عملية الوكيل نحو 250 MB، لكن خادم لغة واحداً لـTypeScript يمكن أن يصل إلى 2000 MB في مستودع متوسط الحجم، وهذا وحده يدفع خادماً بسعة 2 GB إلى استخدام swap. تكفي سعة 2 GB لتحرير ملفات الإعداد والبرامج النصية الصغيرة. استخدم 4 GB حداً أدنى لأي شيء يترجم الشيفرة أو يشغّل مجموعة اختبارات.

هل أحتاج إلى GPU لتشغيل وكيل برمجي على VPS؟

لا، إذا كان الوكيل يستدعي نموذجاً سحابياً عبر API. يعتمد هذا الحمل على الشبكة، لذلك يكون VPS عادي مزود بـCPU هو الخيار المناسب، بينما تبقى GPU خاملة بتكلفة أعلى بكثير. تحتاج إلى GPU فقط عندما يعمل النموذج نفسه على الخادم ذاته. عندئذ ينتقل السؤال من RAM إلى VRAM وحجم النموذج.

ما مقدار swap الذي ينبغي أن أضيفه إلى VPS الخاص بالوكيل؟

أضف نصف سعة RAM، وبحد أقصى يقارب 4 GB. تحميك swap من الزيادة المؤقتة في استهلاك الذاكرة، لأن kernel يستطيع نقل الصفحات غير النشطة إلى القرص بدلاً من إنهاء عملية. لكنها لا تضيف ذاكرة قابلة للاستخدام. إذا أظهر vmstat 1 حركة مستمرة في العمودين si وso، فهذا يعني أن الخادم يعاني من thrashing. والحل هو تقليل عدد العمال المتوازيين أو اختيار خطة أكبر.

لماذا يتجمّد الوكيل البرمجي في منتصف عملية البناء؟

من شبه المؤكد أن kernel OOM killer أنهى عملية البناء. يرسل OOM killer الإشارة SIGKILL، لذلك لا يُطبع شيء وينتظر الوكيل pipe لن يمتلئ أبداً. شغّل sudo dmesg -T | grep -i "killed process" وابحث عن اسم العملية وقيمة anon-rss الخاصة بها. عالج المشكلة بتحديد حد للبناء باستخدام systemd-run --user --scope -p MemoryMax=4G وتقليل عدد العمال، أو بالانتقال إلى فئة أعلى من حيث RAM.