# LobeChat в Docker + один ключ к нескольким моделям: как это собрать и что видно в логах

# LobeChat в Docker + один ключ к нескольким моделям: как это собрать и что реально видно в логах

*Руководство на русском: поднять собственный чат-клиент за пять команд и подключить к нему несколько LLM через один endpoint. Дисклеймер: мы ведём DaoXE, к которому ведёт часть конфигурации, — но сам клиент вы держите у себя, и это как раз цель статьи.*

## Почему «свой клиент» ≠ «полностью локальные модели»

Честно разделим два разных желания:

*   **Локальные модели** (Ollama, GGUF) — данные и вычисления не покидают вашу машину. Ценой: качество ниже фронтирных моделей, нужны GPU, а «приватность» достигается только тем, что запрос никуда не идёт.
    
*   **Свой клиент + внешний API** — интерфейс, история чатов и ключи у вас; генерация идёт к провайдеру модели. Приватность — это контроль над тем, **куда** и **что** уходит, а не «ничего никуда не уходит».
    

Эта статья про второй случай: поднять LobeChat в Docker и направить его на единый OpenAI-совместимый endpoint. Смысл этого пути — не держать десять разных клиентов и одиннадцать аккаунтов, сохранив при этом контроль над собственной частью стека.

## Шаг 1. Поднять LobeChat в Docker

```yaml
# docker-compose.yml
services:
  lobechat:
    image: lobehub/lobe-chat
    ports: ["3210:3210"]
    restart: unless-stopped
    environment:
      - NEXT_AUTH_SSO_PROVIDERS=
```

```bash
docker compose up -d
```

Откройте `http://localhost:3210`. Клиент локальный; ключи хранятся в вашем браузере/базе, а не у третьих сторон.

## Шаг 2. Подключить несколько моделей через один ключ

В настройках провайдера LobeChat:

*   **OpenAI**: Base URL `https://api.daoxe.com/v1`, ваш ключ → модели из `GET /v1/models`.
    
*   **Anthropic**: отдельно можно прописать нативный `/v1/messages` для Claude.
    

Один ключ, один баланс, много моделей — без отдельной подписки под каждую.

## Шаг 3. Что видно в логах (и зачем это нужно)

Главное преимущество своего клиента — **наблюдаемость**. Включите логирование запросов и смотрите:

*   `model` **в ответе** — та ли модель реально ответила (см. нашу статью про верификацию подмены);
    
*   `usage` — сколько токенов ушло; по нему сверяете биллинг endpoint'а. Расхождение больше, чем объясняет тариф, — это вопрос к поставщику;
    
*   **куда уходит запрос** — URL вы задаёте сами, и видите его же в логах.
    

```bash
# быстрый smoke-тест через ваш клиент-эндпоинт
curl -s https://api.daoxe.com/v1/chat/completions \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"model":"ТОЧНЫЙ_ID","max_tokens":16,"messages":[{"role":"user","content":"ping"}]}' \
  | jq '{model, usage}'
```

## Шаг 4. Модельный выбор: как не ошибиться

*   Нужен фронтир (сложный код, длинные контексты) → топовые Claude/GPT через endpoint.
    
*   Дешёвые массовые задачи (классификация, черновики) → открытые модели тем же ключом.
    
*   Чувствительные данные → держите отдельный локальный Ollama для того, что не должно уходить наружу, и не путайте его с облачным путём.
    

Гибрид «чувствительное — локально, остальное — облако через один ключ» — самый частый рабочий паттерн.

## Цены и оплата

Способы оплаты и актуальные цены по каждой модели — на [daoxe.com/pricing](https://daoxe.com/pricing?utm_source=hashnode&utm_medium=organic&utm_campaign=ru_test_0904&utm_content=hn_t5); тарификация по моделям — в USD.

## Дальше

Гид по десяткам клиентов: [seven7763.github.io/daoxe-guide/ru](https://seven7763.github.io/daoxe-guide/ru/?utm_source=hashnode&utm_medium=organic&utm_campaign=ru_test_0904&utm_content=hn_t5). Вопросы — Telegram @daoxe\_ai.

*Мы не обещаем «100% стабильности» и не утверждаем, что умеем доказывать происхождение токена. Мы утверждаем меньше: всё перечисленное выше можно проверить у себя в логах.*