Скільки RAM потрібно VPS для coding agent

Скільки RAM потрібно VPS для coding agent?

Почніть із 4 GB RAM і 2 vCPU для одного coding agent, який постійно працює з репозиторієм. Перейдіть на 8 GB RAM і 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 мережею. Це припущення визначає весь підхід до вибору конфігурації. Спочатку потрібно встановити, чи воно виконується.

Ви запускаєте агент чи модель?

Coding agent, який викликає cloud model, — це мережевий клієнт із підключеною shell. Він надсилає файли та план до API, очікує відповідь, а потім локально редагує файли й виконує команди. Під час очікування він використовує майже нульовий обсяг CPU. Обсяг його власної пам’яті вимірюється сотнями мегабайтів, тому оптимальним для нього є сервер із помірною потужністю CPU.

Самостійний запуск моделі — це інший продукт, якому потрібне інше обладнання. Ваги моделі залишаються в пам’яті, доки працює сервер. Для моделі з 7 мільярдами параметрів, квантизованої до 4 бітів, потрібно приблизно 5 GB лише для ваг, без урахування key/value cache, який збільшується зі зростанням довжини контексту. Якщо використовувати лише CPU, спільний vCPU забезпечує кілька токенів за секунду. Одне завдання агента може генерувати тисячі токенів, тому робота, яка через API займає менше хвилини, локально триватиме більшу частину години. Якщо вам потрібен саме такий сценарій, підбирайте конфігурацію за обсягом VRAM (відеопам’яті GPU) і прочитайте що насправді дає VPS із GPU замість цієї сторінки.

Усе нижче стосується сценарію з cloud model.

Що насправді використовує пам’ять

[
  {
    "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 у великому workspace зазвичай перевищує 4000 MB з тієї самої причини — для кожного crate у workspace.

Headless Chrome використовує близько 350 MB для браузера з однією вкладкою, а кожна додаткова вкладка запускає ще один процес операційної системи. Запуск тестів Node із чотирма worker — це чотири процеси Node, тому пікове споживання наближається до 3000 MB. Під час збирання Docker image пікове споживання наближається до 2500 MB, оскільки всередині контейнера запускається власний compiler проєкту, а daemon записує layers.

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 диска. Один сеанс агента, один репозиторій, один language server і збірки, завершення яких ви готові чекати. Ця конфігурація працює, але під час першого великого запуску тестів, що збігається з індексацією language server, процеси зіткнуться з out-of-memory killer. Додайте swap і обмежте кількість build workers.

Комфортна конфігурація: 8 GB RAM, 4 vCPU, 100 GB диска. Один агент, Docker і headless browser для тестів із запасом ресурсів для одного пікового навантаження під час збірки. Більшості окремих розробників варто придбати саме цю конфігурацію. Подвоєння кількості vCPU також приблизно вдвічі скорочує час очікування збірки, і це відчувається значно частіше, ніж нестача пам’яті.

Командна конфігурація: 16 GB RAM, 8 vCPU, 200 GB диска. Чотири одночасні сеанси, кожен із власною робочою копією та власним toolchain. Розраховуйте ресурси для пікового навантаження, оскільки чотири неактивні агенти майже не створюють витрат, тоді як чотири одночасні запуски тестів коштують у чотири рази більше за пікове значення з верхнього рядка.

Станом на August 2026 перехід від першого рядка до останнього означає приблизно чотириразове збільшення місячної ціни за умови річної оплати VPS: унизу — однозначні суми в доларах на місяць, угорі — десятки доларів. Перед плануванням перевірте поточні пропозиції, оскільки ці значення змінюються. Сервер рідко є найдорожчою складовою. Для тих, хто щодня працює з агентом, рахунок за model API швидко перевищує вартість сервера, тому обмежте суму, яку агенту дозволено витрачати, перш ніж зменшувати конфігурацію. Для самої збірки покроковий посібник із запуску coding agent на 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 створює сотні тисяч малих файлів, тому у файловій системі можуть закінчитися іноди, хоча df -h усе ще показує вільні гігабайти. Після цього запис завершується помилкою No space left on device на диску, який виглядає наполовину вільним.

df -h /
df -i /

Якщо IUse% показує 100, видаліть каталоги node_modules для гілок, у яких ви більше не працюєте, або перейдіть на pnpm. Він зберігає кожну версію пакета один раз і створює жорсткі посилання на неї в кожному проєкті.

Журнали — найнепомітніша причина. Постійно активний агент записує стенограми сеансів, а журнал 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, щоб це обмеження стало постійним. Одноразове очищення лише тимчасово звільняє місце, зайняте на цей момент.

Swap: що він дає і що приховує

Swap варто додати, оскільки він перетворює короткочасне перевищення доступної пам’яті на повільну роботу, а не на завершення процесу. Розмір swap задайте на рівні половини обсягу RAM, але не більше ніж приблизно 4 GB. На build-сервері немає особливих причин збільшувати його далі.

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 вказує kernel спочатку звільняти дисковий кеш, а вже потім переміщати пам’ять програм на диск. Це допомагає language server залишатися чутливим до запитів.

Тепер про те, що приховує swap. Якщо завданню справді потрібно більше пам’яті, ніж доступно на сервері, kernel витрачає час на переміщення сторінок між RAM і диском замість виконання build. Нічого не завершується аварійно. Усе працює вкрай повільно, а load average зростає, хоча CPU простоює.

vmstat 1 10

Стабільні ненульові значення у стовпцях si і so означають безперервний swap, тому потрібно зменшити кількість паралельних операцій або збільшити обсяг RAM, але не додавати swap. На невеликому сервері sudo apt install -y zram-tools надає стиснений swap, що зберігається в RAM і налаштовується у /etc/default/zramswap. Він значно швидший за swap file і використовує RAM для економії RAM, тому допомагає для неактивних сторінок, але не для build, якому справді потрібна робоча пам’ять.

Чому здається, що ваш coding agent зависає

Це найчастіше неправильно діагностована проблема на невеликому сервері для agent. Команда не повертає результату, agent чекає, а сесія виглядає завислою. Процес завершив kernel out-of-memory (OOM) killer. Він отримав SIGKILL, тому не зміг вивести помилку, записати дані в журнал або повідомити agent про те, що сталося. Agent бачить порожній результат і не отримує повідомлення про завершення.

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 переважно оцінює процеси за обсягом використаної пам’яті, тому часто завершує language server або agent, а не build, через який сервер перевищив доступний ліміт. Саме тому симптом виглядає так, ніби «зламався agent».

У Docker така сама подія залишає чіткіший слід. Контейнер завершується з кодом 137, тобто 128 плюс сигнал 9.

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

"OOMKilled": true підтверджує, що контейнер досяг свого ліміту пам’яті, а не завершився через власний збій.

Рішення — встановити окремий ліміт для ресурсомісткої команди, щоб завершувався build, а не agent:

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

Тепер build буде завершено після досягнення 4 GB, а agent продовжить працювати. Незрозуміле зависання перетворюється на звичайну невдалу команду з кодом завершення, який можна прочитати. Для цього потрібна користувацька сесія systemd, тому виконуйте loginctl enable-linger $USER на сервері, доступ до якого ви маєте лише через SSH. 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 mode не використовується. Старий ключ mem_limit: 2g також працює. Повний посібник з обмежень пам’яті Compose охоплює резервування та пояснює, що відбувається, коли контейнер досягає встановленого обмеження. Якщо Docker ще не встановлено на сервері, спочатку встановіть Docker на VPS.

Одна помилка може коштувати кількох годин. Контейнер з обмеженням 2 GB усе одно бачить значення /proc/meminfo хоста та кількість CPU хоста, оскільки ці ресурси не ізольовані через namespace. Тестовий runner, який визначає кількість worker-процесів за кількістю CPU, запустить вісім worker-процесів усередині контейнера з обмеженням 2 GB на хості з вісьмома vCPU, а потім завершиться з кодом 137. Задайте ці значення вручну:

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

--max-old-space-size задається в MB і обмежує heap V8. Встановіть його нижче за ліміт контейнера, щоб Node вивів помилку, яку можна прочитати, а не завершився без повідомлення:

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

Це повідомлення корисне, оскільки містить назву досягнутого обмеження та процесу, який його досяг. OOM killer такої інформації не надає.

Запуск кількох сесій агентів на одному сервері

Плануйте ресурси для кожної сесії, а не для кожного користувача. Дві сесії в одному репозиторії означають два language server, два набори build cache у пам’яті та два запуски тестів, якщо обидва агенти одночасно отримують навантаження. Саме тому в рядку для команди вказано 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, kernel завершить один із процесів у його slice, а всі інші сесії продовжать працювати. Якщо агент працює як service, а не в terminal, укажіть MemoryMax= у його unit file. Саме цей підхід слід використовувати, коли ви самостійно розгортаєте агента як постійно запущений service.

FAQ

Чи достатньо 2 GB RAM для coding agent?

Для процесу agent — так. Для виконання його завдань — рідко. Agent використовує близько 250 MB, але один TypeScript language server у репозиторії середнього розміру може використовувати до 2000 MB. Цього достатньо, щоб сервер із 2 GB почав використовувати swap. 2 GB достатньо для редагування конфігураційних файлів і невеликих скриптів. Для всього, що компілює код або запускає набір тестів, використовуйте 4 GB як мінімальний обсяг.

Чи потрібен GPU, щоб запускати coding agent на VPS?

Ні, якщо agent викликає cloud model через API. Таке навантаження залежить від мережі, тому звичайний VPS із CPU є оптимальним варіантом, а GPU простоює за значно вищої вартості. GPU потрібен лише тоді, коли сама model працює на цьому сервері. У такому разі потрібно оцінювати не RAM, а VRAM і розмір model.

Скільки swap потрібно додати на VPS для agent?

Половину обсягу RAM, але не більше приблизно 4 GB. Swap захищає від короткочасного перевищення доступної пам’яті, оскільки kernel може перемістити неактивні сторінки на диск замість завершення процесу. Swap не збільшує обсяг доступної пам’яті. Якщо vmstat 1 показує стабільний трафік у стовпцях si і so, сервер перевантажений операціями swap. Зменште кількість паралельних worker або виберіть більший тарифний план.

Чому мій coding agent зависає посередині build?

Найімовірніше, kernel OOM killer завершив build. Він надсилає SIGKILL, тому жодне повідомлення не виводиться, а agent очікує дані з pipe, який більше не заповниться. Виконайте sudo dmesg -T | grep -i "killed process" і перевірте назву процесу та його значення anon-rss. Щоб усунути проблему, обмежте build за допомогою systemd-run --user --scope -p MemoryMax=4G і зменште кількість worker або перейдіть на один рівень RAM вище.