От десятка подписок к единому шлюзу LiteLLM: что пошло не по плану

Привет! Я Владимир Мокроусов, сисадмин в группе компаний «Синтека». Мы создаем софт для строительной отрасли и активно используем в работе ИИ-модели. 

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

Зачем мы собрали единый шлюз

Изначально каждый отдел сам покупал подписки на OpenAI, Anthropic и DeepSeek, но управлять учетками и лимитами становилось всё сложнее и затратнее. Решили перейти на единый шлюз — и развернули LiteLLM. 

По сути, LiteLLM — это маршрутизатор: через него мы делим пользователей на группы, даем сотрудникам доступ к моделям и смотрим логи. Если появляются ошибки или заканчиваются лимиты, идем разбираться именно сюда.

Вот как работает новая схема, если доступ к модели идет:

• По подписке/OAuth. В этом случае между LiteLLM и провайдером нужна дополнительная прослойка — это CLIProxyAPI. К ней подключаем учетные записи провайдеров и здесь же прописываем API-ключ. В CLIProxyAPI можно добавлять сразу несколько подписок и следить за их лимитами.

• По обычному API-ключу. Здесь LiteLLM обращается к провайдеру напрямую. Мы смогли подключить по подписке не всё: оказалось, это возможно лишь для любой модели Anthropic, а в OpenAI многие инструменты доступны только по токенам.

В итоге схема решила две глобальные задачи.

Получили контроль над подписками и лимитами. У каждой команды теперь есть свои ограничения. Мы можем контролировать, как расходуются ресурсы, и оперативно оперативно перераспределять их между отделами, если где-то нагрузка оказывается выше.

Упростили доступ командам. Теперь сотруднику не нужно разбираться с кучей учеток: он получает адрес сервера и один API-ключ к набору моделей. А дальше использует его в привычном инструменте — например, в Claude, OpenCode, Reactor, Codex или собственном коде.

Всё бы хорошо, но нас ждали впереди большие грабли.

Столкнулись с неявными лимитами у Anthropic

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

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

Кроме того, мы увидели отдельные ограничения для конкретных моделей. Так, для новой модели Fable 5 появился собственный лимит. Мы ей еще не пользовались, только собираемся попробовать. При этом исчерпание лимита одной модели не означает, что остальные тоже станут недоступны.

Так что важно отделять наш опыт и факты из ответов API от официальных правил Anthropic. Для организационного использования надежнее выбирать официальный API или корпоративный договор, чем объединять личные подписки.

Получили две блокировки учеток подряд

С блокировками учеток — похожая история: мы тоже столкнулись с неочевидными причинами, о которых провайдеры официально не пишут. Вот что показал наш опыт с OpenAI и Anthropic.

Блокировки у OpenAI. Было так: несколько учеток мы оплачивали одной картой, и в какой-то момент аккаунт заблокировали. Сейчас в CLIProxyAPI у нас подключены три учетные записи OpenAI. Они работают нормально: лимиты расходуются и балансируются между ними.

Блокировки у Anthropic. Тут всё пошло иначе. Мы подключили две личные учетки к одному CLIProxyAPI. Новую сразу заблокировали без объяснения причины. 

Тогда мы сделали новую учетку и подключили ее к CLIProxyAPI. Через полдня заблокировали и ее. Почему именно это произошло, мы не знаем. Я встречал версию, что Anthropic смотрит в том числе на возраст Gmail-аккаунта: если почту недавно создали и сразу зарегистрировали на нее учетку, это может выглядеть как поведение бота. Но это только гипотеза.

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

В итоге сейчас держим как минимум две рабочие учетки Anthropic, чтобы блокировка одной не оставила сотрудников без доступа к моделям.

Не смогли подключить новые модели по старой схеме

Когда у Claude появились новые модели Sonnet 5, Opus 5 и Fable 5, мы добавили их так же, как предыдущие. Но это не сработало.

Оказалось, что релиз модели еще не означает, что текущая версия LiteLLM ее поддерживает. Нужно обновить образ или иначе прописать маршрут. В нашем случае пришлось поправить роут для Anthropic, после чего модели заработали.

Далее идем по шагам:

• Определяем источник доступа. Доступ по подписке работает через CLIProxyAPI. Обычный API-ключ LLM-провайдера настраивается непосредственно в LiteLLM без CLIProxyAPI.

• Указываем адаптер и адрес. Новые модели Claude подключаются через anthropic/<model> с базовым адресом 0.0.0.0:8317 без /v1. Старые модели продолжают работать через openai/<model> по адресу 0.0.0.0:8317/v1.

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

  В итоге для подключения модели должны быть правильно настроены четыре совпадающих элемента: model ID, адаптер провайдера, базовый URL и способ авторизации. 

Стали разбираться в причинах ошибок

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

Ошибка 400: запрос отклонен. Дело может быть в неверном формате сообщений или ролей, из-за предзаполнения ответа (prefill), вызова инструментов или неподходящей конечной точкой API.

Ошибки 401 и 404: доступ и конфигурация. Чаще всего высвечиваются на экране, когда сотрудники прописывают модель вручную и возникают опечатки. Ошибка может быть в неверном ключе, базовом URL, псевдониме или в маршруте. 

Ошибка 429: лимиты и учетные записи. Обычно означает, что квота закончилась, период ожидания (cooldown) или все учетные записи временно недоступны.

Ошибки 500 и 503: сбой сервиса или потока. Они свежие, пока до конца с ними не разобрались. Скорее всего, такая ошибка может прилетать из-за перегрузки на стороне провайдера, обрыва streaming, проблемы с авторизацией или невозможностью переключиться на резервную модель. Еще одна возможная причина: не хватает ресурсов на сервере, где у нас развернуты CLIProxyAPI и LiteLLM.

Как ищем источник ошибки:

• Сначала смотрим не только на HTTP-код, но и на provider, model_group, request ID и вложенное сообщение upstream.

• Повторяем запрос напрямую к CLIProxyAPI или провайдеру, минуя LiteLLM.

• Упрощаем запрос: отключаем streaming и tools, а затем возвращаем функции по одной.

• Если прямой запрос успешен, проверяем адаптер и трансформацию LiteLLM. Если нет — авторизацию, лимиты и доступ к самой модели. 

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

Научились управлять лимитами

Поначалу все пользовались общими ресурсами, лимиты в LiteLLM заканчивались очень быстро. Поэтому каждой команде (разработчикам, тестировщикам и аналитикам) мы настроили свои ограничения и доступы:

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

• Устанавливаем технические ограничения. У нас есть разрешенный список моделей.

• Задаем финансовые ограничения. Определяем бюджет на период, учет потребления и предупреждения до исчерпания.

После этого разделения мы стали равномернее расходовать лимиты. Сейчас Anthropic работает у нас примерно неделю без резких скачков потребления.

Усилили защиту данных при работе с LLM

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

Но закрыть сам шлюз недостаточно. Всё, что сотрудники отправляют моделям, так или иначе уходит провайдеру. Поэтому мы не храним ключи в коде или конфиге, выдаем минимальные права и регулярно ротируем доступ.

И еще одно правило — не отдавать модели критичные процессы полностью на автоматическое выполнение. На практике я не раз видел, как в процессе решения задачи модель выбирает неверный путь. Если следить за ее действиями, можно вовремя скорректировать направление. Поэтому мы скорее за полуавтоматический режим: модель выполняет работу, а человек контролирует важные действия и при необходимости вмешивается.

Вместо вывода

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

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