Маршрутизация по задаче
Сервис просит не конкретную модель, а класс задачи: подешевле, побыстрее, поточнее. Шлюз сам выбирает, куда отправить. Модель можно поменять для всей компании в одном месте, не трогая код сервисов.
Proxy Broker live
Proxy Broker: шлюз к языковым моделям
Единая точка входа для всех AI-запросов компании. Переключает провайдеров при отказах, режет расходы маршрутизацией и не даёт одному сломавшемуся сервису утянуть за собой остальные.
- Python
- PostgreSQL
- Redis
- Docker
- Grafana
- Prometheus
Задача
Когда каждый сервис ходит к моделям сам, получается три проблемы сразу. Ключи расползаются по проектам, расходы никто не видит целиком, а отказ одного провайдера роняет всё, что на него завязано.
Добавьте к этому лимиты частоты запросов: провайдер начинает отвечать отказом на пике нагрузки, ровно тогда, когда сервис нужнее всего.
Как устроено
Переключение при отказах
Отказ по лимиту или ошибка сервера означают не ошибку пользователю, а переход к следующему провайдеру в списке. Проблемный провайдер временно исключается и проверяется позже.
Локальные модели как резерв
В конце цепочки стоят модели на собственном железе. Они бесплатны и доступны всегда, поэтому полный отказ означал бы отказ вашего же сервера.
Учёт и наблюдение
Все запросы проходят через одну точку, поэтому видно, сколько потрачено, каким сервисом и на какой задаче. Метрики, логи и оповещения собираются отдельным контуром.
Что это даёт
- Расходы на модели снижаются: дешёвые задачи не уходят на дорогие модели
- Отказ провайдера перестаёт быть аварией
- Ключи и лимиты живут в одном месте, а не в десяти проектах
- Видно, куда уходят деньги, в разрезе сервисов и задач
Кому подходит
Компаниям, у которых больше одного сервиса ходит к языковым моделям, и тем, кто хочет видеть и контролировать расходы на них.
Система работает у нас в боевой эксплуатации. Разворачиваем такую же на вашей инфраструктуре или дорабатываем под ваш процесс.
Частые вопросы
Что происходит, когда провайдер упирается в лимит?
Запрос уходит следующему провайдеру. Раньше отказ по лимиту считался обычной ошибкой и возвращался пользователю - мы это изменили, потому что на пиках такое случается регулярно.
Как шлюз понимает, что провайдер сломался?
Считает ошибки за короткий промежуток. Если их становится слишком много, провайдер отключается на время, потом пробуется снова одним запросом. Так сломавшийся сервис не собирает на себя всю нагрузку.
Можно ли поставить такой шлюз у себя?
Да, это обычный сервис в контейнере рядом с вашей инфраструктурой. Локальные модели ставятся на ваше железо, если приватность важнее качества.
Нужно похожее решение?
Расскажите про задачу, посмотрим, что из этого применимо у вас.