Установка платформы

Доступные сервисы

• compressa/compressa-pod:0.3.10 - базовый образ Compressa для инференса моделей
• compressa/compressa-entrypoint:0.3.10 - центральная часть Compressa, диспетчер
• compressa/compressa-autotest:0.3.10 - сервис автотестировоания моделей
• compressa/compressa-layout-gpu:0.3.10 - ETL сервис
• compressa/compressa-ui:0.3.10 - UI чата и ETL
• nginx:latest - для подключения к внешнему адресу
• opensearchproject/opensearch:2.13.0 - ELK
• opensearchproject/opensearch-dashboards:2.13.0 - ELK дашборд
• opensearchproject/data-prepper:2.6.0 - ELK хранилище данных
• compressa/compressa-auth:0.3.10 - авторизация

Могут быть скачаны через docker pull...

Аутентификация в Docker

Пройдите аутентификацию в Docker с вашим токеном:

export PAT=<TOKEN>
echo $PAT | docker login -u compressa --password-stdin

Базовая настройка

Термины

• central pod (диспетчер) - сервис, управляющий составными частями платформы и проксирующий запросы к моделям
• pod - составная часть платформы, универсальный контейнер на основе compressa-pod
• Каждая pod имеет 2 порта - порт 5100 (API) и порт 5000 (порт модели). API и модель могут работать независимо друг от друга
• state (state.yaml) - обновляемый файл состояния pods
• конфиг - конфигурационный файл, редактируемый пользователем с указанием типа задач, моделей и устройств для pods

Сначала клонируйте репозиторий с конфигурацией:

git clone git@github.com:compressa-ai/compressa-deploy.git
cd platform

Хранилища

Настройте права доступа к рабочим директориям chmod 777 -R %folder_name% По умолчанию контейнеры используют следующие пути:

• RESOURCES_PATH - ./data/compressa
• HF_HOME - ./data/compressa
• platform/build - папка для конфигурационных и state файлов
• platform/test_results - результаты автотестов

Настройка переменных окружения:

• AUTODEPLOY - автоматическая сборка платформы. Для docker compose рекомендуется True
• UI_LOGIN - требуется ли авторизация для доступа к UI (finetune, chat, layout)
• RUN_TESTS - автоматический запуск тестов. Для docker compose рекомендуется True
• RESOURCES_PATH - путь к файлам модели, аналогично одиночному инстансу Compressa
• HF_HOME - путь к кэшу, аналогично одиночному инстансу Compressa
• COMPRESSA_API_KEY - ваш ключ
• POD_NAME - алиас проекта, будет использоваться в именах контейнеров Compressa
• DISPATCHER_HOST - имя центрального контейнера Compressa
• DISPATCHER_PORT - адрес порта центрального контейнера
• NGINX_LISTEN_PORT - порт nginx внутри docker сети, используется для запуска автотестов
• NETWORK - имя docker сети
• PROJECT - имя проекта, будет использоваться в именах служебных контейнеров
• LOG_LEVEL - уровень логирования

Настройка порта Nginx

По умолчанию сервисы используют порт 8080. Его можно настроить в файле docker-compose.yaml и в nginx.conf:

  nginx:
    image: nginx:stable-alpine3.19-slim
    ports:
      - "8080:80" <----
...

Запуск диспетчера и сервисных контейнеров

• создайте docker сеть docker network create test_network
• отредактируйте конфиг, чтобы определить какие модели будут использоваться deploy/platform/build/config.yaml
• перейдите в папку cd deploy/platform
• инициализируйте переменные окружения

set -a
source .env
set +a

• запустите диспетчер и сервисные контейнеры docker compose up
• диспетчер автоматически сгенерирует compose файл для запуска Compressa deploy/platform/build/auto.yaml
• запустите сгенерированный файл docker compose -f ./build/auto.yaml up
• диспетчер и все модели будут доступны через nginx по адресу http://localhost:8080/
• ELK дашборд будет доступен по адресу http://localhost:5601/

Вы также можете запускать отдельные элементы Compressa независимо, как описано в compressa-local-llm. Для этого в переменных окружения каждой поды нужно указать адрес диспетчера, убедиться чтот все контейнеры находятся в одной docker сети и задать переменные окружения диспетчера AUTODEPLOY и RUN_TESTS - False. Тогда все контейнеры автоматически подключатся к диспетчеру.

Пример конфигурационного файла (6 сервисов)

settings:
  base_image: "compressa/compressa-pod:0.3.10"

pods:
  - engine: vllm
    task: llm
    model_name: "Qwen/Qwen3-14B"
    gpu_id: "0"
    gpu_memory_utilization: 0.9
  - engine: vllm
    task: embeddings
    model_name: "Salesforce/SFR-Embedding-Mistral"
    gpu_id: "1"
    gpu_memory_utilization: 0.7
  - engine: infinity
    task: rerank
    model_name: "mixedbread-ai/mxbai-rerank-large-v1"
    gpu_id: "1"
  - engine: asr_backend
    task: asr
    model_name: "t-tech/T-one"
    gpu_id: "1"
  - engine: coqui
    task: tts
    model_name: "compressa-ai/XTTS-v2"
    gpu_id: "1"
  - engine: llamacpp
    task: llm
    model_name: "TheBloke/Mistral-7B-Instruct-v0.1-GGUF"
    quantization: "Q8_0"

Как работает диспетчер

Ручной режим (Autodeploy=False)

Действие пользователя	Что происходит
Запуск central pod	Стартует диспетчер и прочие вспомогательные контейнеры (nginx, auth...). Если уже есть запущенные поды, которые подключились к диспетчеру - следующие шаги не выполнять.
POST create-pods	Читаем состояние из state если есть или из конфига, если конфиг отличается от state - используем его, создаем docker compose для pods.
Запуск docker-compose	запускается нужное количество pods без деплоя
POST deploy-pods	Читаем состояние из state если есть или из конфига, если конфиг отличается от state - используем его, посылаем соответствующие post запросы на деплой pods
Running	Дожидаемся что все модели задеплоены (имеют статус running), формируем или обновляем state

Автоматический режим (Autodeploy=True)

Действие пользователя	Что происходит
Запуск central pod	Стартует диспетчер и прочие вспомогательные контейнеры (nginx, auth, etc), генерирует compose для pods, ожидает готовности pods
Запуск compose
Running	Дожидаемся что все модели задеплоены (имеют статус running), формируем или обновляем state, запускаем автотесты

При работе сервиса у пользователя остается возможность передеплоить модели, поменяв конфиг и отправив post запрос на deploy-pods. При этом передеплоиваться будут только те модели, которые изменились. Перед повторным деплоем будет завершен предыдущий. Ограничение - нельзя онлайн поменять количество pods. Необходимо перезапускать сервис.

Обработка ошибок

Событие	Поведение системы
Падение диспетчера	pods продолжают посылать отчеты диспетчеру (не успешно), недоступно проксирование запросов, но каждая pod доступна локально по портам 5100, 5000. При рестарте диспетчера сперва происходит проверка наличия работающих pods и если они доступны и в статусе running - передеплоя не происходит, соединение восстанавливается
Падение одной или всех pod (остановка контейнеров)	По таймауту неполучения отчета от pod диспетчер переводит pod в статус неактивной. Периодически пытается подключиться и повторно задеплоить модель. При перезапуске pod происходит деплой, работоспособность восстанавливается
Падение модели на одной или нескольких pod (недоступен порт 5000, но доступен порт 5100). Например, out of memory с последующим завершением работы модели со стороны движка или принудительно посланный запрос на завершение деплоя в обход диспетчера	Pod помечается как “модель недоступна”. По таймауту недоступности модели (10 минут) происходит передеплой
Неуспешный деплой (статус failed). Как правило, падение в самом начале, например, из-за неправильного конфига или out of memory. Если failed возникает позже - обрабатывается внутри pod	Предпринимаем 3 попытки повторного деплоя, затем посылаем запрос на рестарт контейнера. После рестарта предпринимаем еще 3 попытки, и если не достигли успеха - снова рестартим контейнер. Помечаем поду как проблемную. Затем если конфиг не изменился - не делаем ничего, информируем пользователя что надо исправить, если изменился - передеплоиваем
Все порты pod открыты, но модель не работает (500 error)	При превышении счетчиком ответов с 500 error заданного порога происходит передеплой pod (по умолчанию счетчик выключен, можно задать через переменную окружения MAX_SERVER_ERRORS. При успешном ответе или после передеплоя счетчик сбрасывается

Использование

После успешной установки всех модулей и запуска моделей, они готовы к использованию. Как отправлять запросы через REST API или Python клиент рассказываем здесь.

Тестирование

Успешный деплой проверяется встроенными тестами (отчеты выводятся в консоль и сохраняются в папку test_reports), также работу моделей можно проверить с помощью следующих запросов:

LLM Модель

curl -X 'POST' "$SERVER_NAME:$PORT/v1/chat/completions" \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' -d '{
  "model": "Compressa-LLM",
  "messages": [{"role": "user", "content": "Напиши сказку на ночь про добрый искусственный интеллект!"}],
  "stream": false
}'

Embeddings Модель

curl -X 'POST' "$SERVER_NAME:$PORT/v1/embeddings" \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' -d '{
  "model": "Compressa-Embedding",
  "input": "Document 1",
  "encoding_format": "float"
}'

Rerank Модель

curl -X POST "$SERVER_NAME:$PORT/v1/rerank" -H "accept: application/json" -H "Content-Type: application/json" -d '{
  "model": "Compressa-ReRank",
  "query": "Query?",
  "documents": [
    "document 1",
    "document 2",
    "document 3"
  ],
  "return_documents": false
}'

Для работы с модулем InsightStream RAG, вам понадобится выполнить еще один шаг