Как использовать Aider с собственным сервером

MAATRIX

Aider — терминальный ИИ-напарник, который читает ваш репозиторий, правит файлы по запросу и сам коммитит изменения в git. Штука отличная, пока не столкнётесь с тем, что из России запросы к OpenAI и Anthropic то виснут по таймауту, то обрываются на середине ответа, а долгая сессия рефакторинга не переживает сон ноутбука или обрыв VPN. Разберём, как поставить Aider на собственный сервер, подключить его к модели тремя разными способами и держать сессию живой сутками.

Зачем Aider вообще переносить на сервер

Aider — это Python-пакет aider-chat, который запускается прямо в терминале поверх вашего git-репозитория: вы описываете задачу, модель предлагает правки, Aider применяет их к файлам и делает коммит. Никакого веб-интерфейса и отдельного сервера для самого инструмента не нужно — он одинаково легко стартует и на ноутбуке, и на VPS. Вопрос не в весе Aider, а в трёх типовых ситуациях, где ноутбук — плохая площадка.

Первая — доступ к провайдерам из России нестабилен. Прямое соединение с api.anthropic.com или api.openai.com из РФ часто рвётся на TLS-хендшейке или висит до таймаута:

curl: (28) Failed to connect to api.anthropic.com port 443 after 75012 ms: Couldn't connect to server

Через VPN бывает лучше, бывает хуже — соединение живёт, пока жив туннель, а туннель на домашнем роутере переживает не каждый вечер.

Вторая — долгие сессии. Прогнать рефакторинг на полсотни файлов — это час-два диалога с моделью, где Aider держит контекст всего проекта. Закрылась крышка ноутбука, ушёл в спячку Wi-Fi, разрядился аккумулятор — и сессию приходится поднимать заново.

Третья — команда. Если несколько разработчиков хотят одинаково настроенный Aider с общим прокси к модели и едиными бюджетами на токены, проще держать одну машину с готовым конфигом, чем повторять установку на каждом ноутбуке.

Если ни один из трёх пунктов не про вас — ставьте Aider локально, pipx install aider-chat, и сервер тут не обязателен. Дальше — как раз для тех, кому обязателен.

Устанавливаем Aider на чистый сервер

Возьмём Ubuntu 24.04 на свежем VPS: система уже несёт Python 3.12, отдельно ставить интерпретатор не нужно.

python3 --version
# Python 3.12.3

У Aider два официальных способа установки. Первый — установочный скрипт, который разворачивает изолированное окружение и не трогает системный Python:

curl -LsSf https://aider.chat/install.sh | sh

Второй — через pipx, если вы уже держите Python-инструменты именно так:

sudo apt update && sudo apt install -y pipx
pipx ensurepath && source ~/.bashrc
pipx install aider-chat

Для установки через pipx и обычный pip разработчики Aider указывают диапазон Python 3.9–3.12 — Ubuntu 24.04 попадает в него ровно по верхней границе. После установки проверьте команду:

aider --version
# aider 0.86.2

Aider работает только внутри git-репозитория — без него он сам предложит сделать git init. А если репозиторий свежий и вы ещё не представились git, первая же правка упадёт со стандартной ошибкой:

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

Задайте личность один раз на сервер:

git config --global user.email "dev@example.com"
git config --global user.name "Dev Server"

Дальше — либо git clone git@github.com:you/project.git по ключу, либо git init в пустой папке под новый проект.

Первый запуск: подключение напрямую к провайдеру

Простейший путь — тот же, что и на ноутбуке, только ключ теперь живёт на сервере. Экспортируйте переменную окружения и запустите Aider в папке проекта:

export ANTHROPIC_API_KEY=sk-ant-api03-...
cd ~/project
aider --model anthropic/claude-sonnet-4-5

Без ключа или с опечаткой в нём Aider не проверяет его заранее — он честно уходит в запрос и возвращает то, что ответил провайдер:

litellm.AuthenticationError: AnthropicException - {"type":"error","error":{"type":"authentication_error","message":"x-api-key header is required"}}

Экспорт в shell живёт до закрытия сессии — на сервере удобнее файл .env в корне репозитория, Aider подхватывает его сам при старте:

ANTHROPIC_API_KEY=sk-ant-api03-...

Обратите внимание на сам факт: проблема из первого раздела — обрывы до api.anthropic.com из России — снята уже тем, что сервер физически не в России. Те же команды, что виснут с домашнего ноутбука, с сервера в Лондоне отрабатывают штатно, без танцев с VPN вокруг самого Aider.

Расход токенов виден прямо в чате: команда /tokens показывает, сколько контекста съедено и во сколько обошёлся диалог, а /clear сбрасывает историю, если контекст разросся зря. Для запуска без диалога — например, из cron — есть флаг --message: aider --message "добавь докстринги" file.py отправляет один запрос, применяет правку и завершается, не открывая интерактивный чат.

Свой прокси вместо прямых ключей: Aider поверх LiteLLM

У прямого ключа в .env два минуса: он один на всех, кто заходит на сервер, и если завтра нужно поставить бюджет или лимит по каждому разработчику отдельно — начинаются самодельные костыли. Aider внутри сам построен на библиотеке litellm, поэтому вместо ключа провайдера он готов принять адрес любого OpenAI-совместимого эндпоинта — включая собственный LiteLLM Proxy на соседнем порту.

Поднимите LiteLLM Proxy на том же сервере — pip install 'litellm[proxy]' и litellm --config config.yaml --port 4000 — и укажите Aider не ключ провайдера, а адрес прокси с его собственным виртуальным ключом:

export OPENAI_API_BASE=http://127.0.0.1:4000/v1
export OPENAI_API_KEY=sk-...   # виртуальный ключ из LiteLLM, не ключ OpenAI
aider --model openai/gpt-4o-mini

Формально Aider думает, что говорит с OpenAI — под капотом запрос уходит на 127.0.0.1:4000/v1, а уже LiteLLM решает, к какому реальному провайдеру и с каким ключом его отправить. Имя модели в --model просто должно совпадать с тем, что прописано в model_list конфига LiteLLM, и точно так же можно завести запись под Anthropic или любого другого провайдера за прокси.

Выгода связки: у каждого разработчика — свой sk-...-ключ с лимитом max_budget и rpm_limit, отозвать его можно одной командой, не трогая общий доступ к провайдеру. Расплата — лишний процесс на сервере и точка отказа: если LiteLLM не поднялся, Aider получит не 401 от Anthropic, а Connection refused от собственного localhost, и разбираться придётся уже в логах прокси, а не в ключах.

Локальная модель через Ollama: честно про скорость

Третий способ подключения — не звать внешнего провайдера вообще, а поднять модель локально через Ollama на том же сервере:

curl -fsSL https://ollama.com/install.sh | sh
OLLAMA_CONTEXT_LENGTH=8192 ollama serve &
ollama pull qwen2.5-coder:7b
export OLLAMA_API_BASE=http://127.0.0.1:11434
aider --model ollama_chat/qwen2.5-coder:7b

Обратите внимание на префикс: документация Aider явно рекомендует ollama_chat/, а не ollama/ — с обычным префиксом модель хуже держит формат правок в ответах. И на OLLAMA_CONTEXT_LENGTH: без этой переменной Ollama по умолчанию режет контекст до 2 тысяч токенов и молча отбрасывает всё, что не влезло, — а Aider на каждый запрос отправляет карту репозитория плюс историю чата, это заведомо больше.

Честно про скорость — без выдуманных таблиц. Мы гоняли Ollama 0.33.1 на своём сервере AMD EPYC 9554 (16 vCPU — 8 физических ядер с Hyper-Threading) с моделью qwen2.5:7b в квантовании Q4_K_M и меняли только num_thread:

Генерация выходит на полку уже на 4 потоках — дальше упирается не в CPU, а в пропускную способность памяти. А 32 потока на 16 vCPU дают не ускорение, а обвал в двадцать раз: планировщик тратит больше времени на переключение контекста, чем на счёт. На CPU-сервере параметр num_thread в .aider.model.settings.yml стоит выставлять руками, а не доверять автоопределению по числу ядер.

Другие модели того же класса на 16 потоках: llama3.1:8b — 12,8 ток/с, mistral:7b — 12,1, gemma2:9b — 8,8, qwen2.5:3b — 34,1. По памяти: qwen2.5:3b — 2,2 ГБ, mistral:7b — 5,0 ГБ, qwen2.5:7b — 5,1 ГБ, llama3.1:8b — 5,6 ГБ. Для фоновой рутины вроде докстрингов 7–8 ток/с не мешают, но для интерактивной работы, где вы ждёте ответа после каждой реплики, это заметно медленнее прямого ключа к облачной модели. Если Aider — основной рабочий режим, а не редкие фоновые правки, CPU-инференс скорее раздражает, чем экономит: тут выгоднее GPU или всё-таки платный API через прокси из раздела выше.

Постоянная сессия: tmux, автокоммиты и безопасность

Разрыв SSH — не повод терять часовой диалог с моделью. Держите Aider в tmux, а не в голой сессии:

sudo apt install -y tmux
tmux new -s aider
cd ~/project && aider --model anthropic/claude-sonnet-4-5
# Ctrl+b, затем d — отключиться, сессия продолжает работать
tmux attach -t aider   # вернуться позже, хоть с телефона

Обрыв связи убивает SSH-канал, но не процесс внутри tmux — вернувшись, вы увидите тот же диалог на том же месте.

По умолчанию Aider коммитит в git каждую принятую правку — это часть рабочего цикла, а не побочный эффект: если правка не понравилась, /undo в чате откатывает именно последний коммит Aider, не трогая ваши собственные. Если хотите сначала посмотреть diff и коммитить руками — aider --no-auto-commits отключает автокоммиты целиком, а /diff в чате покажет изменения без коммита.

Файлы, которые Aider не должен видеть даже как часть карты репозитория — секреты, дампы, сборки — перечисляются в .aiderignore в корне репозитория, синтаксис как у .gitignore:

.env
*.sqlite3
node_modules/
dist/

Для регулярной рутины не обязательно сидеть в чате: флаг --yes-always убирает все запросы на подтверждение, и в связке с --message Aider можно вызывать из cron — например, ночным проходом добавлять недостающие тесты. Но у этого есть цена: --yes-always вместе с автокоммитами означает, что модель правит и коммитит без вашего одобрения — на боевой ветке так не запускают, только в отдельной рабочей ветке с последующим ревью PR.

И про пользователя: не держите сессию Aider под root. Заведите отдельного пользователя с доступом только в рабочую директорию — если Aider через /run выполнит опасную команду или предложит правку, которая ломает систему, ущерб останется в границах его собственного $HOME.

Какой сервер и локация нужны под Aider

Сам Aider не просит мощного железа — это тонкий клиент, вся тяжесть в модели, к которой он подключается. Конфигурация сервера зависит от того, какой из трёх способов подключения из разделов выше вы выбрали.

Честный минимум: 1 vCPU, 2 ГБ RAM, 20 ГБ NVMe. Хватает для прямого ключа к Anthropic или OpenAI и работы через tmux — сам Aider занимает десятки мегабайт, основная нагрузка уходит по сети к провайдеру. На это железо не ставьте одновременно локальную модель: даже qwen2.5:3b в Q4 — это ещё 2,2 ГБ весов сверх того, что нужно системе и самому процессу.

Комфортный вариант: 4 vCPU, 8 ГБ RAM, 60 ГБ NVMe. Этого достаточно и для связки с собственным LiteLLM Proxy — плюс Postgres под виртуальные ключи, — и для локальной модели уровня qwen2.5:7b или llama3.1:8b с оговорками из раздела про Ollama выше. Если на один сервер параллельно заходят несколько разработчиков — берите этот вариант, а не минимум.

Локация — Великобритания. Из раздела про первый запуск: половина проблем прямого доступа к OpenAI и Anthropic из России снимается уже тем, что сервер стоит не в РФ. Лондон добавляет к этому низкий пинг до остальной Европы — если в команде есть разработчики не только в России, разница с сервером в США будет заметна на каждой правке. Для одиночной работы из России расстояние до Лондона и до Нью-Йорка ощущается на первом токене ответа почти одинаково, а на потоковом выводе Aider эти миллисекунды не критичны.

Сервер отдаётся чистым — Ubuntu 24.04 или Debian, без предустановленного Aider: это инструмент из тех, что ставятся по инструкции выше, а не одной кнопкой из каталога приложений. Зато рядом с ним в каталоге apps.maatrix.io есть готовые сборки LiteLLM и Ollama — той самой связки для второго и третьего способа подключения, которые не придётся поднимать вручную. Оплата — картами российских банков, СБП, криптовалютой или токеном MAAT; для сервера в Лондоне иностранная карта не требуется.

Частые вопросы