Что приходится держать под контролем после запуска общего LLM-прокси

Когда командам нужны языковые модели, первый вариант выглядит просто: каждый отдел заводит свою подписку у OpenAI, Anthropic и DeepSeek и работает с ней напрямую. Через несколько месяцев этот вариант превращается в десяток учёток, разрозненные лимиты и невозможность понять, кто и на что тратит бюджет. Единый шлюз на базе LiteLLM убирает этот хаос на входе, но добавляет собственный набор задач по эксплуатации. Ниже — устройство такой схемы и те места, где она ломается на практике.

Зачем ставить шлюз между командой и провайдером

LiteLLM работает как маршрутизатор запросов к моделям. Через него удобно делить пользователей на группы, выдавать доступ к конкретному набору моделей, собирать логи и считать расход. Когда у сотрудника падает запрос или заканчивается квота, разбираться идут в одну точку, а не в личный кабинет каждого провайдера.

Со стороны пользователя схема сводится к двум вещам: адрес сервера и один API-ключ к набору моделей. Дальше этот ключ подставляется в привычный инструмент — CLI-клиент, редактор с поддержкой моделей, Codex-подобный агент или собственный код. Никто не хранит десять отдельных токенов и не помнит, какая подписка к какому отделу привязана.

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

Два способа доступа к моделям

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

Доступ по подписке или OAuth. Между LiteLLM и провайдером ставится прослойка — CLIProxyAPI. К ней подключаются учётные записи провайдеров, там же прописывается API-ключ, и там же видно расход по каждой подписке. В одну прослойку можно завести сразу несколько подписок и балансировать нагрузку между ними.

Доступ по обычному API-ключу. Здесь LiteLLM обращается к провайдеру напрямую, без CLIProxyAPI. Подписочная модель доступна не везде: часть провайдеров открывает весь набор инструментов только по токенам, и тогда прямой ключ остаётся единственным рабочим вариантом.

Для корректного подключения модели должны совпасть четыре вещи: идентификатор модели (model ID), адаптер провайдера, базовый URL и способ авторизации. Ошибка в любом из четырёх полей даёт сбой, который легко принять за проблему на стороне провайдера.

Лимиты подписок ведут себя сложнее, чем написано

Подписка удобна тем, что бюджет предсказуем: оплата по токенам напрямую зависит от объёма запросов и быстро растёт при активной работе агентов. Но у самой подписки лимитов больше, чем два очевидных окна «на несколько часов» и «на неделю».

На реальный расход влияют выбранная модель, длина контекста, набор используемых инструментов и текущая нагрузка на провайдера. Поверх основной квоты может существовать отдельная платная квота вроде Extra Usage, которая тратится независимо и сообщает о себе только в момент исчерпания. У отдельных, особенно новых моделей встречаются собственные лимиты: одна модель упёрлась в потолок, а остальные продолжают отвечать.

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

Блокировки учёток без объявленной причины

Отдельная категория проблем — блокировки, о причинах которых провайдеры публично не пишут.

С одним провайдером блокировка прилетела за оплату нескольких учёток одной банковской картой. После перехода на схему с тремя записями в CLIProxyAPI лимиты стали расходоваться и балансироваться между ними нормально.

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

Практический вывод: держать минимум две рабочие учётки у каждого критичного провайдера, чтобы блокировка одной не оставила команду без доступа.

Новые модели не появляются в шлюзе автоматически

Выход новой модели не означает, что установленная версия LiteLLM её поддерживает. Иногда достаточно обновить образ, иногда приходится править маршрут вручную.

Типичная правка выглядит так:

Источник доступа. Подписка идёт через CLIProxyAPI, обычный API-ключ настраивается прямо в LiteLLM.
Адаптер и адрес. Новое поколение моделей одного из провайдеров подключается через адаптер anthropic/<model> с базовым адресом без суффикса /v1; прежние модели продолжают работать через адаптер openai/<model> по адресу с /v1.
Проверка. После смены маршрута прогоняется обычный запрос до публикации ключа пользователям.

Как локализовать ошибку по слоям

Сбой в такой схеме возникает на одном из трёх уровней: сам запрос, LiteLLM или сторона провайдера. Клиенту LiteLLM всегда показывает ошибку от своего имени, поэтому HTTP-код — только отправная точка.

400 — запрос отклонён: неверный формат сообщений или ролей, предзаполнение ответа (prefill), вызов инструментов, неподходящая конечная точка. Тот же код прилетает при исчерпании дополнительной квоты.
401 и 404 — доступ и конфигурация: неверный ключ, базовый URL, псевдоним модели или маршрут. Чаще всего появляется, когда модель прописывают руками и делают опечатку.
429 — лимиты: квота закончилась, идёт период ожидания (cooldown) или все учётные записи временно недоступны.
500 и 503 — сбой сервиса или потока: перегрузка на стороне провайдера, обрыв streaming, проблема с авторизацией, невозможность переключиться на резервную модель либо нехватка ресурсов на сервере со шлюзом.

Порядок разбора:

Смотреть не только на код, но и на поля provider, model_group, request ID и вложенное сообщение upstream.
Повторить запрос напрямую к CLIProxyAPI или провайдеру, минуя LiteLLM.
Упростить запрос: отключить streaming и инструменты, затем возвращать их по одному.
Если прямой запрос проходит — искать причину в адаптере и трансформации LiteLLM. Если нет — в авторизации, лимитах и доступе к модели.

Разделение лимитов между командами

Общий пул ресурсов заканчивается быстро и непредсказуемо. Управляемость появляется после того, как каждой команде — разработчикам, тестировщикам, аналитикам — назначены отдельные ограничения:

Виртуальный ключ на пользователя, команду или сервис, с указанием владельца и возможностью отзыва.
Технические ограничения — разрешённый список моделей.
Финансовые ограничения — бюджет на период, учёт потребления и предупреждения до исчерпания квоты.

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

Защита данных вокруг шлюза

Шлюз и прослойку разумно держать в закрытом сетевом периметре: доступ только из корпоративной сети, снаружи сервисы недоступны. Но закрытого периметра мало — всё, что сотрудники отправляют в модель, уходит провайдеру. Отсюда базовые правила: не хранить ключи в коде и конфигах, выдавать минимальные права, регулярно ротировать доступ.

И ещё одно ограничение по опыту: критичные процессы не стоит целиком отдавать модели на автоматическое выполнение. Модель в ходе задачи периодически выбирает неверный путь, и полуавтоматический режим с контролем важных действий человеком оказывается надёжнее полного автопилота.

Что остаётся после настройки

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