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

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

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

Кодирующий агент, обращающийся к облачной модели, является сетевым клиентом с подключенной оболочкой. Он отправляет файлы и план действий в API, ожидает ответа, а затем редактирует файлы и выполняет команды локально. Во время ожидания он почти не потребляет ресурсы процессора. Его собственный объем памяти измеряется сотнями мегабайт, поэтому для такой задачи достаточно сервера с умеренными характеристиками CPU.

Запуск модели на собственном оборудовании — это другой продукт, требующий иного аппаратного обеспечения. Веса модели остаются в оперативной памяти всё время, пока сервер включен. Модели с 7 миллиардами параметров, квантованной до 4 бит, требуется около 5 GB только для весов, без учета кэша ключей и значений (key/value cache), который растет вместе с длиной контекста. При работе только на CPU общее виртуальное ядро выдает несколько токенов в секунду. Поскольку одна задача агента может генерировать тысячи токенов, работа, которая через 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 ГБ ОЗУ, 2 vCPU, 50 ГБ диска. Один сеанс агента, один репозиторий, один языковой сервер и сборки, которые вы готовы ждать. Этот уровень работает, но он столкнется с OOM-killer (out-of-memory killer), как только запуск крупного теста совпадет по времени с индексацией языковым сервером. Добавьте swap и ограничьте количество воркеров сборки.

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

Командная: 16 ГБ ОЗУ, 8 vCPU, 200 ГБ диска. Четыре одновременных сеанса, каждый со своей копией репозитория и своим набором инструментов. Выбирайте размер под пиковую нагрузку, так как четыре простаивающих агента почти ничего не стоят, в то время как четыре одновременных запуска тестов потребуют в четыре раза больше ресурсов, чем указано в столбце выше.

По состоянию на август 2026 года разница в цене между первой и последней строкой составляет примерно четырехкратный размер ежемесячного платежа при годовой оплате VPS: от нескольких долларов в месяц в нижней категории до десятков долларов в верхней. Перед планированием проверьте актуальный прайс-лист, так как эти цифры меняются. Сервер редко является самой дорогой частью. Для тех, кто ежедневно использует агента, счет за API моделей быстро превысит стоимость сервера, поэтому ограничьте расходы агента, прежде чем уменьшать размер сервера. Что касается самой сборки, руководство по запуску агента программирования на 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-killer (Out-of-Memory killer) ядра. Он получил сигнал 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 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, так как ни то, ни другое не изолировано через 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.