Сколько RAM нужно VPS для coding agent

Сколько оперативной памяти нужно VPS для работы агента разработки?

Начните с 4 ГБ оперативной памяти и 2 vCPU для одного постоянно запущенного агента разработки, работающего с репозиторием. Переходите на 8 ГБ и 4 vCPU, как только к сессии подключается language server или процесс сборки Docker, что для большинства репозиториев происходит в первый же день. Сам процесс агента потребляет мало ресурсов, поэтому основную нагрузку создают инструменты, которые агент запускает от вашего имени.

[
  {
    "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, к которому вы обращаетесь по сети. Это допущение определяет весь вопрос выбора размера ресурсов, поэтому сначала определитесь с ним.

Вы запускаете agent или саму модель?

Coding agent, который обращается к облачной модели, — это сетевой клиент с подключённой оболочкой. Он отправляет файлы и план в API, ждёт ответ, затем локально изменяет файлы и выполняет команды. Пока agent ждёт ответ, он почти не использует CPU. Сам agent занимает сотни мегабайт памяти. Поэтому для него подходит недорогой сервер с обычным CPU.

Самостоятельный запуск модели — это другой продукт, которому требуется другое оборудование. Веса модели остаются в памяти всё время работы сервера. У модели с 7 миллиардами параметров, квантованной до 4 бит, веса занимают около 4 GB (Llama 2 7B поставляется с объёмом 3.83 GB в Q4_0 и 4.08 GB в Q4_K_M), а её издатель указывает от 6.3 до 6.6 GB RAM для запуска без GPU с учётом накладных расходов runtime. Для более длинного контекста требуется больше памяти, поскольку размер key/value cache увеличивается вместе с длиной контекста. Только на CPU общий vCPU обеспечивает несколько токенов в секунду, а одна задача agent может сгенерировать тысячи токенов. Поэтому работа, которая через 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 МБ, так как поддерживает сессию и небольшой кэш файлов, не выполняя других задач. Языковой сервер TypeScript достигает примерно 2000 МБ во время индексации, поскольку он строит граф типов для каждого файла, доступного из вашего tsconfig.json, а затем удерживает этот граф в оперативной памяти для быстрого ответа на последующие запросы. rust-analyzer в крупном рабочем пространстве обычно превышает 4000 МБ по той же причине, обрабатывая все крейты в проекте.

Headless Chrome потребляет около 350 МБ для браузера и одной вкладки, при этом каждая дополнительная вкладка — это отдельный процесс операционной системы. Запуск тестов Node с четырьмя воркерами создает четыре процесса Node, поэтому пиковое потребление приближается к 3000 МБ. Сборка Docker-образа достигает пика около 2500 МБ, так как сборка запускает компилятор вашего проекта внутри контейнера, пока демон записывает слои.

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

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

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

По состоянию на август 2026 года последняя конфигурация стоит примерно в четыре раза дороже первой по ежемесячной цене при годовой оплате VPS: в нижней части списка — однозначное число долларов в месяц, в верхней — десятки долларов. Перед планированием проверьте текущие тарифы, поскольку эти значения меняются. Сервер редко бывает самой дорогой частью. Для тех, кто ежедневно использует agent, счёт за API модели быстро превышает стоимость сервера. Поэтому сначала ограничьте сумму, которую agent может потратить, и только потом уменьшайте конфигурацию сервера. Для самой сборки пошаговое руководство по запуску coding agent на VPS описывает настройку учётной записи и сохранение сессии после отключения.

Почему место на диске заканчивается раньше, чем оперативная память

[
  {
    "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 ГБ окажется почти заполненным еще до того, как вы напишете строку кода. Самый объемный элемент — Docker, занимающий около 20 ГБ, так как 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, который хранит каждую версию пакета в одном экземпляре и создает жесткие ссылки на него в каждом проекте.

Логи — это скрытая угроза. Постоянно работающий агент записывает транскрипты сессий, а системный журнал 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. На сборочном сервере редко есть смысл делать его больше.

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 указывает ядру освобождать дисковый кэш, прежде чем вытеснять память программ на диск, что позволяет языковому серверу оставаться отзывчивым.

Теперь о том, что скрывает swap. Когда задаче действительно требуется больше памяти, чем есть на сервере, ядро тратит время на перемещение страниц между RAM и диском вместо выполнения сборки. Ничего не падает. Все начинает работать крайне медленно, а load average растет, пока CPU простаивает.

vmstat 1 10

Постоянные ненулевые значения в столбцах si и so означают непрерывный свопинг. Решение — уменьшить параллелизм или добавить RAM, но никогда не увеличивать swap. На небольшом сервере sudo apt install -y zram-tools предоставляет сжатый swap в RAM, который настраивается в /etc/default/zramswap. Это намного быстрее, чем swap-файл; этот механизм тратит RAM для экономии RAM, поэтому он помогает с «холодными» страницами, но не помогает при сборке, которой требуется реальная рабочая память.

Почему ваш кодинг-агент кажется зависшим

Это самая часто неверно диагностируемая проблема на серверах с агентами. Команда не возвращает результат, агент ждет, и сессия выглядит зависшей. Процесс был завершен OOM-киллером (Out-Of-Memory) ядра. Он получил сигнал 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 — это объем памяти, который занимал процесс в момент завершения. Обратите внимание, какой именно процесс был выбран: ядро оценивает процессы преимущественно по объему используемой памяти, поэтому оно часто убивает языковой сервер или самого агента, а не ту сборку, которая привела к исчерпанию ресурсов. Именно поэтому симптом выглядит как «агент сломался».

Внутри 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 ГБ, а агент продолжит работу. Это превращает загадочное зависание в обычную ошибку выполнения команды с понятным кодом выхода. Для этого требуется менеджер пользователей systemd; обычный вход по SSH запускает его автоматически, поэтому команда работает через SSH в текущем виде. loginctl enable-linger $USER нужен только для того, чтобы пользовательские юниты продолжали работать после вашего выхода из системы. 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, так как ни то, ни другое не изолировано через namespaces. Тестовый раннер, который определяет количество воркеров по числу ядер, запустит восемь воркеров внутри контейнера на 2 GB на хосте с восемью 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 killer такой информации не предоставляет.

Запуск нескольких сеансов агента на одном узле

Планируйте ресурсы исходя из количества сеансов, а не пользователей. Два сеанса в одном репозитории означают два запущенных языковых сервера, два набора кэшей сборки в оперативной памяти и два параллельных запуска тестов, если оба агента станут активны одновременно. Именно поэтому строка для команды увеличивается до 16 ГБ.

Установите для каждого пользователя жесткий лимит, чтобы один вышедший из-под контроля сеанс не привел к падению всего узла:

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 ГБ, ядро завершит процесс в его срезе (slice), при этом остальные сеансы продолжат работу. Если агент работает как служба, а не в терминале, добавьте MemoryMax= непосредственно в файл юнита. Это стандартный подход, если вы разворачиваете агент как постоянно работающую службу.

FAQ

Достаточно ли 2 GB оперативной памяти для агента разработки?

Для самого процесса агента — да. Для задач, которые он выполняет — редко. Агент потребляет около 250 MB, но один language server для 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 защищает от кратковременных пиков потребления, так как ядро может переместить неактивные страницы памяти на диск вместо завершения процесса. Это не добавляет полезной оперативной памяти. Если vmstat 1 показывает постоянную активность в столбцах si и so, система работает в режиме thrashing, и решение заключается в уменьшении количества параллельных задач или переходе на более мощный тариф.

Почему агент разработки зависает во время сборки?

Сборка почти наверняка была принудительно завершена OOM killer, который отправляет SIGKILL. В результате ничего не выводится в лог, а агент ожидает данных из канала, который никогда не заполнится. Запустите sudo dmesg -T | grep -i "killed process" и проверьте имя процесса и его значение anon-rss. Исправьте проблему, ограничив сборку через systemd-run --user --scope -p MemoryMax=4G и уменьшив количество рабочих процессов, либо перейдите на тариф с большим объемом RAM.