Установка и настройка LiteLLM Proxy на VPS: единый API интерфейс для управления всеми вашими LLM

1. Що ми налаштовуємо і навіщо: проблема фрагментації ШІ-сервісів

До 2026 року ландшафт великих мовних моделей (LLM) став вкрай фрагментованим. Розробникам доводиться інтегрувати API від OpenAI для GPT-5, Anthropic для Claude 4, Google для Gemini 2.0, а також локальні моделі через vLLM або Ollama для забезпечення приватності. Кожен провайдер має свої формати запитів, методи аутентифікації та системи лімітів.

LiteLLM Proxy вирішує цю проблему, виступаючи в ролі інтелектуального шлюзу. Він приймає запити в стандартному форматі OpenAI і "перекладає" їх на мову потрібного провайдера. Але це не просто проксі-сервер. Це повноцінна платформа управління (Governance Layer), яка дозволяє:

• Створювати віртуальні ключі для різних відділів або додатків, обмежуючи їх бюджет (наприклад, не більше 10$ в день).
• Налаштовувати "розумну" маршрутизацію: якщо OpenAI повернув помилку 500, запит автоматично йде на Anthropic.
• Логувати кожен запит і відповідь в базу даних PostgreSQL для подальшого аналізу якості та витрат.
• Використовувати семантичне кешування, щоб не платити двічі за ідентичні питання користувачів.

Вибір self-hosted рішення на VPS замість використання хмарних агрегаторів (типу OpenRouter) продиктований вимогами безпеки і бажанням уникнути додаткової націнки на токени. Маючи власний проксі, ви платите провайдерам безпосередньо і повністю контролюєте, куди йдуть ваші дані.

2. Який VPS-конфіг потрібен під цю задачу

LiteLLM Proxy сам по собі є легкою програмою на Python, але його вимоги ростуть в залежності від обсягу трафіку, використання бази даних для логів і кешування в Redis.

Для стабільної роботи системи з урахуванням бази даних PostgreSQL і кешу Redis, оптимальним вибором буде відповідний VPS з 4 ГБ оперативної пам'яті. Це забезпечить достатній запас для обробки паралельних запитів без затримок.

Коли потрібен Dedicated сервер? Якщо ви плануєте запускати локальні моделі (наприклад, Llama 3 70B) прямо на цьому ж сервері через Ollama. В цьому випадку вам знадобляться потужності з GPU (NVIDIA A100/H100) або величезний обсяг RAM для CPU-інференса. Для самого ж проксі-шару звичайного VPS більш ніж достатньо.

Локація: Вибирайте дата-центр, максимально близький до ваших основних серверів додатків або до ендпоінтів провайдерів (зазвичай це США або Європа), щоб мінімізувати мережеві затримки (TTFT — Time To First Token).

3. Підготовка сервера: безпека і базове ПЗ

Перш ніж встановлювати LiteLLM, необхідно підготувати середовище. Безпека критична, так як через цей сервер будуть проходити ваші API-ключі від платних сервісів.

Оновимо пакети та встановимо базові утиліти:

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl git wget build-essential software-properties-common

Створимо окремого користувача для запуску сервісів, щоб не використовувати root:

sudo adduser litellm-admin
sudo usermod -aG sudo litellm-admin
# Переключаємось на нового користувача
su - litellm-admin

Налаштуємо базовий фаєрвол UFW. Нам знадобляться порти 22 (SSH), 80 (HTTP) та 443 (HTTPS):

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Для захисту від брутфорсу SSH встановимо fail2ban:

sudo apt install -y fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

4. Встановлення Docker та необхідних компонентів

У 2026 році найнадійнішим способом розгортання LiteLLM Proxy залишається Docker. Це ізолює залежності Python та спрощує оновлення.

Встановлюємо Docker Engine та Docker Compose:

# Додаємо офіційний GPG ключ Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Додаємо репозиторій
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Додаємо користувача в групу docker
sudo usermod -aG docker $USER
# Застосуйте зміни груп без перезавантаження
newgrp docker

Перевіримо встановлення:

docker --version && docker compose version

5. Покрокове встановлення LiteLLM Proxy

Ми будемо використовувати зв'язку з трьох контейнерів: сам LiteLLM, PostgreSQL (для зберігання ключів та логів) та Redis (для кешування запитів та rate limiting).

Створимо робочу директорію:

mkdir ~/litellm-stack && cd ~/litellm-stack

Створимо файл docker-compose.yaml. Цей конфіг актуальний для версій 2026 року та включає автоматичний перезапуск та перевірку здоров'я контейнерів:

cat < docker-compose.yaml
services:
  db:
    image: postgres:16-alpine
    volumes:
      - ./postgres_data:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: litellm
      POSTGRES_USER: litellm_user
      POSTGRES_PASSWORD: your_strong_password
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U litellm_user -d litellm"]
      interval: 5s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7-alpine
    command: redis-server --appendonly yes
    volumes:
      - ./redis_data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 5s
      retries: 5

  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    volumes:
      - ./config.yaml:/app/config.yaml
    environment:
      - DATABASE_URL=postgresql://litellm_user:your_strong_password@db:5432/litellm
      - REDIS_HOST=redis
      - REDIS_PORT=6379
      - LITELLM_MASTER_KEY=sk-master-key-2026-very-secret
      - UI_USERNAME=admin
      - UI_PASSWORD=admin-password-change-me
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    command: ["--config", "/app/config.yaml", "--port", "4000", "--detailed_debug"]
EOF

Примітка: Обов'язково замініть your_strong_password та LITELLM_MASTER_KEY на свої унікальні значення. Майстер-ключ буде використовуватися для первинного доступу до адмін-панелі та створення віртуальних ключів.

6. Глибоке налаштування: моделі, секрети та маршрутизація

Серце LiteLLM - це файл config.yaml. Тут ми визначаємо список моделей та правила їх роботи.

Створимо приклад конфігурації:

cat < config.yaml
model_list:
  - model_name: gpt-4
    litellm_params:
      model: openai/gpt-4-turbo
      api_key: "os.environ/OPENAI_API_KEY"
      
  - model_name: claude-3-5
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20240620
      api_key: "os.environ/ANTHROPIC_API_KEY"

  - model_name: global-llm
    model_info:
      base_model: gpt-4
    litellm_params:
      model: openai/gpt-4
      api_key: "os.environ/OPENAI_API_KEY"
      tpm: 10000
      rpm: 500
  
  - model_name: global-llm
    model_info:
      base_model: claude-3-5
    litellm_params:
      model: anthropic/claude-3-5-sonnet
      api_key: "os.environ/ANTHROPIC_API_KEY"

router_settings:
  routing_strategy: usage-based-routing-v2
  enable_pre_call_checks: true

litellm_settings:
  drop_params: true
  set_verbose: false
  cache: true
  cache_type: redis
  success_callback: ["database"]
  failure_callback: ["database"]
EOF

В даному прикладі ми налаштували:

• Прямі моделі: Звернення до конкретних GPT-4 або Claude.
• Групу моделей (Load Balancing): При запиті до global-llm, проксі сам вибере менш завантажену модель або переключиться на альтернативу при збої.
• Redis Caching: Повторні запити не будуть відправлятися провайдеру, економлячи гроші.
• Database Logging: Всі успішні та невдалі виклики зберігаються в PostgreSQL.

Для передачі API-ключів створимо файл .env:

cat < .env
OPENAI_API_KEY=sk-proj-xxxx...

ANTHROPIC_API_KEY=sk-ant-xxxx...
EOF

Тепер оновимо docker-compose.yaml, щоб він підхоплював змінні оточення з .env (додайте секцію env_file: .env в сервіс litellm).

Запускаємо стек:

docker compose up -d

7. Налаштування HTTPS через Caddy для захисту API

Відкривати порт 4000 напряму в інтернет небезпечно. Нам потрібен зворотний проксі з автоматичним отриманням SSL-сертифікатів. Caddy — ідеальний вибір для 2026 року завдяки простоті налаштування.

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Налаштуємо Caddyfile (замініть api.yourdomain.com на ваш реальний домен, направлений на IP сервера):

sudo nano /etc/caddy/Caddyfile

Вміст файлу:

api.yourdomain.com {
    reverse_proxy localhost:4000
    
    header {
        # Базовий захист
        Strict-Transport-Security "max-age=31536000;"
        X-Content-Type-Options nosniff
        X-Frame-Options DENY
        Referrer-Policy no-referrer-when-downgrade
    }
}

Перезапустимо Caddy:

sudo systemctl restart caddy

8. Бекапи, моніторинг та обслуговування

Ваш проксі тепер зберігає критичні дані: віртуальні ключі користувачів та історію витрат. Втрата бази даних PostgreSQL буде болючою.

Автоматизація бекапів

Створимо простий скрипт для щоденного дампу бази в S3-сумісне сховище або на інший сервер:

#!/bin/bash
# backup-db.sh
BACKUP_DIR="/home/litellm-admin/backups"
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
mkdir -p $BACKUP_DIR

docker exec litellm-stack-db-1 pg_dump -U litellm_user litellm > $BACKUP_DIR/litellm_backup_$TIMESTAMP.sql

# Видаляємо бекапи, старіші за 30 днів
find $BACKUP_DIR -type f -mtime +30 -name "*.sql" -delete

Додайте його в cron (crontab -e):

0 3 * * * /bin/bash /home/litellm-admin/backup-db.sh

Оновлення LiteLLM

Розробники LiteLLM випускають оновлення майже щодня. Щоб оновитися без втрати даних:

cd ~/litellm-stack
docker compose pull
docker compose up -d

Моніторинг

LiteLLM надає вбудований дашборд. Після встановлення він доступний за адресою https://api.yourdomain.com/ui. Використовуйте логін та пароль, вказані в docker-compose.yaml. Там ви побачите графіки використання, активні ключі та помилки провайдерів в реальному часі.

9. Troubleshooting + FAQ

1. Помилка "Connection refused" при спробі доступу до API?

Перевірте, чи запущені контейнери: docker compose ps. Якщо контейнер litellm постійно перезавантажується, подивіться логи: docker compose logs litellm. Найчастіше проблема в неправильному форматі config.yaml або відсутньому DATABASE_URL.

2. Як додати нову модель без перезавантаження всього стека?

LiteLLM підтримує гаряче перезавантаження конфігурації. Відредагуйте config.yaml та відправте сигнал SIGHUP контейнеру або просто виконайте docker compose up -d — Docker перезапустить тільки змінений сервіс з мінімальним простоєм.

3. Який VPS-конфіг мінімально підійде для особистого використання?

Для одного користувача достатньо 1 vCPU та 2 ГБ RAM. Однак, якщо ви включите детальне логування в PostgreSQL та почнете активно використовувати UI-панель, система може почати "свопитися". 4 ГБ — це "золотий стандарт" для комфортної роботи.

4. Що обрати — VPS або dedicated для цієї задачі?

В 95% випадків VPS — найкращий вибір. Dedicated сервер потрібен тільки в двох сценаріях: 1) У вас величезний трафік (мільйони запитів в день), що вимагає гарантованих ресурсів CPU. 2) Ви хочете запускати open-source моделі локально (Llama, Mistral) на цьому ж залізі.

5. Як обмежити бюджет для конкретного API-ключа?

Це робиться через Admin UI або API. При створенні ключа ви можете вказати параметр max_budget та budget_duration (наприклад, 50$ в місяць). LiteLLM автоматично заблокує ключ при досягненні ліміту.

6. Чи підтримує LiteLLM потокову передачу (streaming)?

Так, LiteLLM повністю підтримує stream: true. Це критично для чат-ботів, щоб користувач бачив текст по мірі його генерації. Проксі коректно прокидає чанки даних від провайдера до клієнта.

10. Висновки та наступні кроки

Ми розгорнули відмовостійкий, масштабований та безпечний шлюз для роботи зі штучним інтелектом. Тепер у вас є єдина точка входу для всіх LLM, захищена HTTPS та контрольована через базу даних.

Що робити далі:

• Інтеграція: Перенаправте свої додатки (LangChain, AutoGPT або кастомні скрипти) на новий ендпоінт https://api.yourdomain.com/v1.
• Оптимізація: Налаштуйте fallbacks в config.yaml, щоб ваші сервіси не падали, коли у OpenAI трапляються технічні роботи.
• Аналітика: Через тиждень роботи вивчіть дашборд LiteLLM, щоб зрозуміти, які моделі обходяться вам найдорожче та де можна зекономити, перейшовши на дешевші аналоги (наприклад, з GPT-4 на Claude Haiku для простих задач).

Використання власного проксі-сервера — це важливий крок до зрілої ШІ-інфраструктури, який дає незалежність від політики одного провайдера та повний контроль над витратами.