# LiteLLM через Docker Compose: что нужно для пилотного gateway

LiteLLM Docker Compose для пилота: официальный compose-файл, gateway и Postgres, секреты, сохранение состояния, проверка моделей и отличие от запуска без базы данных.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/litellm-docker-compose-start/
Language: ru

LiteLLM через Docker Compose удобно запускать как ограниченный пилот собственного AI gateway. Важно сразу выбрать режим: один контейнер для простой проверки API или связка с базой для управления ключами, моделями и расходами. Эти варианты не дают одинаковый набор возможностей.

Материал основан на официальной документации, проверенной 1 ноября 2026 года. Ниже описан порядок подготовки; он не означает, что произвольный Compose-файл из интернета подходит для рабочего окружения.

## Возьмите официальный пример

[LiteLLM Docker Quickstart](https://docs.litellm.ai/docs/proxy/docker_quick_start) описывает Compose-связку gateway и Postgres. Сначала прочитайте файл и проверьте образы, переменные, порты и тома. Зафиксируйте конкретную версию образа, которую будете испытывать, вместо неявного обновления при каждом запуске.

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

## Определите состав состояния

| Компонент | Что требуется понять |
| --- | --- |
| Gateway | Какой порт слушает и какие модели разрешены |
| Postgres | Где хранятся записи ключей, конфигурации и расходов |
| Переменные окружения | Кто управляет секретами и их заменой |
| Постоянные тома | Что переживёт пересоздание контейнера |

[Virtual Keys](https://docs.litellm.ai/docs/proxy/virtual_keys) описывает требования к базе для соответствующего управления доступом. Не переносите поведение режима с базой на минимальный контейнер без неё. Успешный ответ модели не подтверждает работу бюджетов и учётных функций.

## Проверьте конфигурацию до старта

После подготовки официального файла и окружения можно сначала изучить состав сервисов:

```bash
docker compose -f docker-compose.quickstart.yml config --services
```

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

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

## Добавьте одну модель и один клиент

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

Условный пилот имеет два результата: модель отвечает через gateway, а после перезапуска сохраняются нужные записи. Если подтверждён только первый, эксперимент ещё не проверил жизненный цикл сервиса. Восстановление следует испытать на тестовых данных до регулярной нагрузки.

## Сохраните план завершения

Определите, какие контейнеры останавливаются, какие данные сохраняются и кто отвечает за внешний счёт модели. Остановка gateway не отменяет ресурсы, оплачиваемые в другом облачном аккаунте. Для следующего шага пригодятся [виртуальные ключи](/ru/journal/litellm-virtual-key-scopes/) и [LiteLLM UI](/ru/journal/litellm-ui-setup/).

Собственный gateway управляет вызовами, но не создаёт спрос на инференс автоматически.