Skip to main content

Command Palette

Search for a command to run...

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

Updated
3 min readView as Markdown

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

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

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

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

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

  • Свой клиент + внешний API — интерфейс, история чатов и ключи у вас; генерация идёт к провайдеру модели. Приватность — это контроль над тем, куда и что уходит, а не «ничего никуда не уходит».

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

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

# docker-compose.yml
services:
  lobechat:
    image: lobehub/lobe-chat
    ports: ["3210:3210"]
    restart: unless-stopped
    environment:
      - NEXT_AUTH_SSO_PROVIDERS=
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 вы задаёте сами, и видите его же в логах.

# быстрый 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; тарификация по моделям — в USD.

Дальше

Гид по десяткам клиентов: seven7763.github.io/daoxe-guide/ru. Вопросы — Telegram @daoxe_ai.

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