В этом материале
Выдавайте приложению отдельный виртуальный ключ и проверяйте фактические ограничения. Наличие записи ключа не означает, что его права и бюджет соответствуют ожиданиям команды.
Виртуальный ключ LiteLLM позволяет отделить доступ одного приложения от другого, не раздавая всем административный master key. Для полезной настройки нужно определить разрешённые модели, владельца, применимый бюджет и порядок отзыва. Затем эти ограничения проверяются реальными тестовыми вызовами.
Описание относится к текущей документации на 1 ноября 2026 года. Установка без нужной базы и выбранная редакция продукта могут иметь другой набор функций.
Подготовьте режим с состоянием
Virtual Keys описывает настройку базы и управление ключами. Убедитесь, что gateway подключён к необходимому хранилищу и сохраняет записи после перезапуска. Минимальный прокси, который принимает master key, не является подтверждением готовности всей системы управления.
Создавайте ключ для конкретного приложения или сервисного назначения. Внутреннее имя должно позволять найти владельца и понять, зачем существует доступ. Не включайте сам секрет в название, тикет или общий реестр оборудования.
Опишите права явно
| Свойство | Решение перед выдачей |
|---|---|
| Модели | Какие имена клиент вправе вызывать |
| Владелец и команда | К какому назначению относится доступ |
| Расходы и частота | Какие ограничения реально применяются |
| Срок использования | Когда доступ пересматривается или заканчивается |
| Административные операции | Нужны ли они этому клиенту вообще |
Не выводите все права автоматически из того, кто нажал кнопку создания. Поведение наследования зависит от конкретного свойства и настройки. Для рабочей схемы сохраняйте проверенный результат, а не предположение о роли владельца.
Сверьте бюджетный уровень
Budgets and Rate Limits описывает бюджеты и ограничения разных сущностей. Ключ, пользователь и команда не следует считать независимыми одинаковыми кошельками без проверки применимого правила. Особенно важно состояние ключа, который включён в команду.
Условная компания выдаёт доступ двум приложениям одного отдела. Им может требоваться общий отделовой бюджет, но разные разрешённые модели. Это две разные части политики: одна ограничивает сумму, другая — множество доступных операций.
Испытайте разрешённый и запрещённый вызов
Сначала выполните короткий запрос к разрешённой модели. Затем обратитесь к модели, которая не должна быть доступна. Зафиксируйте оба результата и состояние учёта. Проверка только успешного запроса подтверждает маршрут, но не ограничение доступа.
Отдельно отзовите тестовый ключ и убедитесь, что старый клиент получает ожидаемый отказ. Для замены действующего доступа нужен план переключения, чтобы отзыв не затронул неизвестную зависимость. У каждого процесса должно быть понятно, откуда он получил секрет.
Проверяйте изменения после обновления
Сохраните версию LiteLLM, настройки ключа и набор контрольных запросов. После обновления или смены способа аутентификации повторите именно граничные случаи: запрещённая модель, превышенный предел и отозванный ключ. Изменившийся интерфейс панели не заменяет такую проверку.
Для развёртывания пригодится Docker Compose, для расходов — бюджеты LiteLLM. Первичная заявка должна описывать ресурс и условия эксплуатации, а не содержать ключи к существующим сервисам.