Как перестать писать адаптеры для нейросетей и взять под контроль расходы на токены

Недавно переписывал интеграцию с Claude на обновленный клиент и поймал себя на мысли. В один день заказчики просят подключить GPT-4o, в другой требуют Anthropic, а еще через неделю финансовый отдел спрашивает, откуда взялся счет на несколько сот долларов за тесты. Каждый раз приходится дописывать логику обработки ошибок, следить за ключами и руками высчитывать расход токенов.

Решить эту рутину помогает LLM Gateway от команды The Open Co. Проект представляет собой единый API-шлюз, который принимает вызовы в стандартном формате OpenAI и перенаправляет их нужным провайдерам.

Одинаковый запрос для любых моделей

Главная идея проекта простая. Вместо подключения десятка SDK вы отправляете обычный HTTP-запрос на ваш локальный или облачный шлюз. Контроллер сам понимает, к какому провайдеру адресован запрос, преобразует формат и возвращает ответ.

Сейчас поддерживаются основные провайдеры:

• OpenAI
• Anthropic
• Google Vertex AI
• Другие сервисы с совместимым API

Вот так выглядит стандартный запрос к шлюзу:

curl -X POST https://api.llmgateway.io/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $LLM_GATEWAY_API_KEY" \
  -d '{
  "model": "gpt-4o",
  "messages": [
    {"role": "user", "content": "Hello, how are you?"}
  ]
}'

Если потребуется заменить модель на Claude 3.5 Sonnet, структура JSON в вашем приложении останется прежней. Меняется лишь название модели в теле запроса.

Учет расходов и метрики latency

Когда с нейросетями работают несколько сервисов или разработчиков, контролировать лимиты становится сложно. Бывает, что кто-то запустил скрипт с некорректным промптом в бесконечном цикле и за час сжег месячный бюджет.

Шлюз берет учет на себя. Каждая транзакция сохраняется в базе данных, а система автоматически рассчитывает:

• Количество входных и выходных токенов
• Итоговую стоимость каждого вызова
• Время отклика модели
• Общую статистику по ключам и проектам

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

Структура проекта и запуск в Docker

Авторы собрали монорепозиторий на TypeScript. Под капотом используются проверенные технологии:

• Hono отвечает за проксирование API-запросов
• Next.js управляет веб-интерфейсом и плейграундом
• Drizzle ORM работает с базами данных PostgreSQL и Redis
• TypeScript гарантирует сквозную типизацию компонентов

Развернуть собственный сервис можно за пару минут через Docker. Авторы собрали готовый образ, объединяющий основные компоненты.

docker volume create llmgateway_postgres
docker volume create llmgateway_redis

docker run -d \
  --name llmgateway \
  --restart unless-stopped \
  -p 3002:3002 \
  -p 3003:3003 \
  -p 3005:3005 \
  -p 3006:3006 \
  -p 4001:4001 \
  -p 4002:4002 \
  -v llmgateway_postgres:/var/lib/postgresql/data \
  -v llmgateway_redis:/var/lib/redis \
  -e AUTH_SECRET="$(openssl rand -base64 32 | tr -d '\n')" \
  -e GATEWAY_API_KEY_HASH_SECRET="$(openssl rand -base64 32 | tr -d '\n')" \
  ghcr.io/theopenco/llmgateway-unified:latest

Маленькая деталь из документации: не монтируйте папку с хостовой машины напрямую в /var/lib/postgresql/data. Из-за специфики инициализации прав PostgreSQL в контейнере процесс может упасть. Названные volumes в команде выше избавляют от этой проблемы.

Если хочется сначала покрутить систему без деплоя, у разработчиков есть облачная версия на сайте llmgateway.io.

Ограничения бесплатной версии

Репозиторий использует двойную лицензию. Основной код распространяется под AGPLv3, однако часть папок в исходниках относится к Enterprise-версии.

В бесплатном варианте с открытым кодом история вызовов хранится 30 дней. Если вам необходим неограниченный срок хранения логов, продвинутый билинг для пользователей или разделение на команды внутри организации, придется покупать коммерческую лицензию.

Кому пригодится этот инструмент

Если ваше приложение делает три запроса в день к одной модели, ставить отдельный прокси смысла нет. Вы только добавите лишнюю точку отказа и незначительную задержку сети.

Шлюз раскроет себя в следующих ситуациях:

• Проект использует модели разных провайдеров
• Требуется прозрачный учет расходов на токены по разным сервисам
• Нужно развернуть прокси в собственном контуре
• Планируется быстрый переключатель на запасную модель в случае сбоев

Попробовать проект можно на GitHub. README там достаточно минималистичный, но проект понятен и без длинных инструкций.