Свой агрегатор нейросетей на VPS: несколько LLM за одним API

Один эндпоинт, за которым живут OpenAI, Anthropic, локальные модели и облачные провайдеры — с единым ключом, логами и лимитами. Разбираем, как собрать такой шлюз на своём сервере за вечер.

Зачем нужен агрегатор

Когда в проекте больше одной модели, зоопарк ключей и SDK быстро превращается в боль: разные форматы запросов, разные лимиты, разные счета. Агрегатор (LLM-gateway) прячет всё это за единым OpenAI-совместимым API — код приложения общается с одним адресом, а маршрутизация решается конфигом.

• Один формат — везде вызовы вида /v1/chat/completions.
• Фолбэк — если провайдер лёг, запрос уходит на резервную модель.
• Учёт и лимиты — токены, бюджеты и ключи по командам.
• Приватность — свой шлюз на своём сервере, а не чужое SaaS.

Держать такой шлюз удобно на VPS рядом с приложением: минимальная задержка и полный контроль. На тарифах MAATRIX (AMD EPYC + NVMe) хватает даже базовой конфигурации — сам gateway почти не ест CPU, работа идёт в сеть.

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

Готовим сервер

Возьмём Ubuntu 22.04/24.04, обновимся и поставим Docker — это самый быстрый путь.

sudo apt update && sudo apt -y upgrade
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER
newgrp docker

Проверяем, что Docker жив.

docker run --rm hello-world

Ставим LiteLLM Proxy

LiteLLM — популярный open-source шлюз: понимает 100+ провайдеров и отдаёт единый OpenAI-формат. Поднимем его в контейнере.

docker run -d --name litellm \
  -p 4000:4000 \
  -e OPENAI_API_KEY=sk-... \
  -e ANTHROPIC_API_KEY=sk-ant-... \
  -v $(pwd)/config.yaml:/app/config.yaml \
  ghcr.io/berriai/litellm:main-latest \
  --config /app/config.yaml --port 4000

Минимальный config.yaml с двумя моделями и мастер-ключом.

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
  - model_name: claude
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20241022
general_settings:
  master_key: sk-my-secret-key

Роутинг, фолбэк и балансировка

Сила агрегатора — в правилах. Можно завести один «виртуальный» model_name, за которым несколько реальных развёртываний, и раздавать запросы по кругу с автоматическим фолбэком при ошибке.

router_settings:
  routing_strategy: simple-shuffle
  num_retries: 3
  fallbacks:
    - gpt-4o: ["claude"]

Теперь клиент всегда зовёт gpt-4o, а если OpenAI недоступен — запрос молча уходит на Claude. Тот же приём работает для локальных моделей: добавь в model_list указатель на свой vLLM или Ollama.

Стратегий маршрутизации несколько, и выбор зависит от задачи. simple-shuffle просто раскидывает нагрузку по кругу и хорош, когда за одним именем несколько одинаковых развёртываний. least-busy шлёт запрос туда, где меньше активных соединений — полезно при неравномерной длине ответов. А если важна цена, можно завязать роутинг на дешёвую модель по умолчанию и поднимать «тяжёлую» только для сложных запросов на уровне приложения. Ретраи с экспоненциальной паузой сглаживают кратковременные 429 от провайдеров, не доводя их до пользователя.

Отдельно стоит настроить таймауты: без них зависший апстрим держит соединение и съедает воркеры. Разумный request_timeout в 60–120 секунд плюс num_retries закрывают большинство сетевых сбоев, а фолбэк добавляет второй уровень надёжности поверх ретраев.

Проверяем API

Шлюз говорит на языке OpenAI, поэтому подойдёт любой клиент. Простейшая проверка через curl.

curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-my-secret-key" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o","messages":[{"role":"user","content":"Привет!"}]}'

В коде достаточно поменять base_url — и весь зоопарк моделей доступен через привычный SDK.

from openai import OpenAI
client = OpenAI(base_url="http://SERVER_IP:4000/v1", api_key="sk-my-secret-key")
r = client.chat.completions.create(model="claude",
    messages=[{"role":"user","content":"Ping"}])
print(r.choices[0].message.content)

Безопасность и частые ошибки

• Не открывай 4000 в мир голым — прикрой Nginx с TLS и Basic-auth, либо пусти только по приватной сети.
• master_key обязателен — иначе любой сможет тратить твои токены.
• Ключи провайдеров — в env или secrets, а не в git.
• Лимиты на пользователя спасают от разорения при утечке ключа.

Мини-конфиг Nginx для TLS-обёртки.

server {
  listen 443 ssl;
  server_name api.example.com;
  location / { proxy_pass http://127.0.0.1:4000; }
}

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