كم يحتاج وكيل البرمجة من 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 تستدعيه عبر الشبكة. يحدد هذا الافتراض مسألة تحديد الموارد بالكامل، لذلك احسمه أولاً.

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

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

تشغيل النموذج بنفسك منتج مختلف يعمل على عتاد مختلف. تبقى الأوزان في الذاكرة طوال مدة تشغيل الخادم. يحتوي نموذج يضم 7 billion parameters ومكمّم إلى 4 bits على نحو 4 GB من الأوزان (يصدر Llama 2 7B بحجم 3.83 GB في Q4_0 وبحجم 4.08 GB في Q4_K_M)، ويذكر ناشره أن تشغيله دون GPU يحتاج إلى 6.3 إلى 6.6 GB من RAM بعد احتساب الحمل الإضافي لبيئة التشغيل. وتتطلب السياقات الأطول ذاكرة أكبر، لأن ذاكرة التخزين المؤقت key/value تنمو مع طول السياق. عند استخدام CPU فقط، ينتج vCPU مشترك بضعة tokens في الثانية، وقد تصدر مهمة وكيل واحدة آلاف الـtokens، لذلك فإن العمل الذي يستغرق أقل من دقيقة عند استخدام 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 من مساحة القرص. جلسة واحدة للوكيل، ومستودع واحد، وخادم لغة واحد، وعمليات بناء تقبل انتظارها. يعمل هذا المستوى، لكنه سيؤدي إلى تشغيل قاتل نفاد الذاكرة في أول مرة تتزامن فيها عملية اختبار كبيرة مع خادم لغة للفهرسة. أضف swap وحدد عدد عمال البناء.

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

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

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

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

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

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

df -h /
df -i /

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

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

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، ولذلك تفيد مع الصفحات غير النشطة، ولا تفيد مع عملية بناء تحتاج إلى ذاكرة عمل فعلية.

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

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

لكن النواة تسجل الحدث:

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 مقدار الذاكرة التي كانت العملية تستخدمها عند إنهائها. انتبه إلى العملية التي اختيرت: تعتمد النواة غالباً على مقدار الذاكرة المستخدمة، لذلك قد تنهي language server أو الوكيل بدلاً من عملية build التي دفعت الجهاز إلى تجاوز الحد. ولهذا تحديداً يبدو العطل وكأن "الوكيل تعطل".

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

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

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

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

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

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

تطبيق الحد مرة واحدة باستخدام حدود الذاكرة في 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.