Cradle как услуга ЦОД

Поставляйте Cradle как managed-услугу в датацентре: модель услуги, топологии T0–T2 и жёсткая изоляция тенантов.

Cradle можно поставлять как управляемую услугу ЦОД. Вместо аренды GPU вы продаёте верифицированный результат: клиент даёт задачу и данные, агенты Cradle отрабатывают под контролем двухуровневой СУР, оператор одобряет или правит, клиент получает проверенный ответ с полным аудитом и цитатами источников.

[задача + данные] ──► [Cradle: триаж + агент + RAG] ──► [СУР: одобрить/править/отклонить] ──► [результат]
                                                            │
                                                            └─► аудит: risk_assessments,
                                                                ticket_sources (цитаты),
                                                                cost_events, api_key_usage

Это почти бесплатно ложится на Cradle: двухуровневая СУР, аудит-лог и учёт стоимости уже существуют. Биллинг становится хуком на событие approve тикета, а не новой подсистемой.

Терминология

Тенант — один изолированный клиент. У каждого тенанта своя инфраструктура и своя БД; тенанты нельзя держать в одном контуре. Тенант = отдельный cradle-server (свой data-dir / БД / периметр), а не запись в общей таблице.
Проект (project) — подгруппа внутри тенанта (свои агенты, KB, тикеты, ключи). projectId разбивает данные внутри контура тенанта, но не заменяет изоляцию между тенантами.
Топология — где физически стоит каждый компонент и кто с кем общается.

Топологии (от простого к сложному)

T0 — всё на одном сервере (рекомендуемый старт)

cradle-server + локальный LlamaCppRunner (CUDA) на GPU-ноде. Client — тонкий пульт по API. Мозг и ИИ живут вместе. Минимум нового кода.

[GPU-нода]
  cradle-server + LlamaCppRunner(CUDA)   ◄──API── [Client] (пульт)
       ▲ внешний трафик коннекторов
       (Telegram / widget / API напрямую в Server)

T1 — control-plane + data-plane

Cradle управляет инференс-демоном на отдельном GPU-боксе: lifecycle/выбор модели по управляющему каналу, трафик инференса по HTTP. Реализуется как remote-gpu-провайдер поверх существующего паттерна + тонкий контроллер.

[cradle-server]  ──control── start/stop daemon, load model
        │        ──HTTP────► generate / embed
        ▼
[GPU-бокс]  llama.cpp-server / vLLM (managed)

T2 — общий пул GPU + очередь

Масштабирование, спот-инстансы, авто-распределение задач по пулу. Это уже серьёзный уровень — сюда не лезть, пока не работает T0.

Изоляция тенантов

Жёсткое требование: у каждого тенанта своя инфраструктура и своя БД, тенанты нельзя держать в одном контуре. Изоляция — instance-per-tenant: отдельный cradle-server (свой data-dir / БД / периметр) на каждого тенанта. Shared-instance с «project = tenant» исключён, потому что это нарушило бы периметр.

[контур тенанта A]               [контур тенанта B]
  cradle-server  ~/.cradle-A        cradle-server  ~/.cradle-B
    ├─ project A1                     ├─ project B1
    └─ project A2                     └─ ...
  (своя БД, свои ключи)            (своя БД, свои ключи)

projectId работает внутри контура тенанта: разбивает агентов, KB, тикеты, cost_events, поддерживает scoped API-keys и X-Cradle-Project, per-project бюджеты с auto-disable. Между тенантами изоляция обеспечивается разными инстансами, а не projectId.

Почему SQLite, а не Postgres

В модели instance-per-tenant в закрытом контуре SQLite — осознанный выбор:

Embedded. SQLite живёт внутри процесса cradle-server как файл — нет отдельного демона, порта, ролей, отдельного backup. «Данные не покидают периметр» становится буквально: один файл в директории тенанта.
Векторный поиск встроен. RAG работает на sqlite-vec в той же БД и процессе. Postgres-аналог потребовал бы pgvector-сервер — обмен «zero infrastructure» на целый database server ради векторного индекса.
Профиль нагрузки подходит. Один инстанс на тенанта, оператор-driven triage (единицы/сотни сообщений), single-writer better-sqlite3 с запасом. Бутылочное горлышко — GPU, а не БД.

Postgres становится актуален только на этапе T2-пула, и даже там изоляция per-tenant склоняет к отдельной БД на тенанта, а не к одной общей.

Лестница изоляции

ЦОД выбирает уровень изоляции в зависимости от требований периметра:

Уровень	Механизм	Периметр	Стоимость
Process per tenant	отдельный `cradle-server` + data-dir, общая ОС	слабый (общее ядро)	дёшево
Container per tenant	Docker/Podman namespaces, cgroups, GPU через nvidia-container-toolkit	средний	умеренно
VM per tenant	отдельная VM (prebuilt-образ)	сильный — данные буквально не покидают	дорого

GPU между инстансами: целая карта на тенанта (простейший), партиция через MIG (A100/H100) или time-slicing, или общий пул через remote-gpu-провайдер (T1), когда инстансы тенантов делят пул, а не железо напрямую.

Модели доставки

Curl installer — для открытых / self-hosted случаев с интернетом.
Self-contained tarball — bundled JS + prebuilt нативные модули, для закрытых сетей без реестра.
VM-образ — ЦОД держит золотой образ с предустановленным Cradle Server; клиент скачивает только Client и вставляет credentials.

Чтобы обсудить managed-развёртывание, напишите нам. Механика установки описана в удалённом сервере.

Cradle как услуга ЦОД

On this page