Создание своего SaaS или продукта на базе LLM

Проблема

При создании SaaS или продукта на базе LLM команде нужно решить не одну, а связку инфраструктурных задач:

• Биллинг и тарифные планы. У каждого клиента — свой план: Free, Pro, Enterprise. План = денежный лимит на месяц и квота на количество запросов. Лимит должен сбрасываться в день обновления подписки, а не «через месяц после последнего сброса», иначе картина биллинга не совпадает с тем, что видит клиент.
• Программный onboarding. Когда новый клиент регистрируется в SaaS, его аккаунт, ключ и квота должны создаваться автоматически, без ручных шагов через UI шлюза.
• Изоляция между клиентами. Перерасход или утечка ключа одного клиента не должны затрагивать остальных.
• Размещение под клиента. Крупный enterprise-клиент с регулируемыми данными требует развёртывания LLM-шлюза в его собственной инфраструктуре (on-premise или в его облаке). Маленькие клиенты обслуживаются из вашей общей multi-tenant инсталляции.
• Прозрачность для клиента. Клиент хочет видеть, сколько он израсходовал за текущий период подписки, без обращения в поддержку.

Для качественного решения этих задач своими силами потребуется проинвестировать в высоконадежную и отлаженну систему, да еще и поддержать API множества провайдеров.

Кого это касается: основатели и команды SaaS, продуктовые команды строящие AI-функции на пользовательских данных, B2B-интеграторы, упаковывающие LLM-возможности для корпоративных клиентов.

Решение

• Готовый биллинг-механизм. calendar_aligned бюджеты и доступ к расходу конкретного клиента через API закрывают задачи биллинга AI-расходов в SaaS.
• Программный onboarding. Регистрация клиента → создание Customer и VK через 1–3 API-вызова, без ручных шагов в UI.
• Изоляция клиентов из коробки. Бюджет, rate limit и aтомарное списание — на уровне Customer; полный расход ого клиента не затрагивает других.
• Гибкое размещение. От одной общей инсталляции до полностью изолированных on-premise развёртываний для регулируемых клиентов — без изменения вашего кода.
• Прозрачность для клиента. Real-time расход, остаток бюджета, история — всё читается через API и встраивается в личный кабинет.
• Защита от перерасхода. Оценка запроса и rate limits не дают одному клиенту «съесть» провайдерскую квоту вашего SaaS (подробнее — Защита от опустошения бюджета и отказа в обслуживании).

Что предлагает Meridian

Meridian спроектирован так, что конечный клиент вашего SaaS становится сущностью Customer в Meridian-иерархии:

• Customer — представляет одного клиента SaaS. Внутри Customer — собственный бюджет (от назначенного Вами тарифного плана) и один или несколько Virtual Keys для аутентификации запроса.
• Календарно-выровненные бюджеты (calendar_aligned: true) — лимит сбрасывается на границе календарного периода в UTC (день/неделя/месяц/год), а не как скользящее окно. Подходит для подписочных моделей с прозрачным «месячным» биллингом.
• Полный Management API — все операции (создание Customer, VK, изменение бюджета, отзыв ключа, чтение использования) доступны программно через REST. Никаких операций, доступных только в UI.
• Гибкое размещение — Meridian разворачивается из Docker-образа или Helm-чарта. Возможные варианты:
  • multi-tenant SaaS-инсталляция — одна инсталляция Meridian обслуживает всех ваших клиентов, изоляция через Customer/VK;
  • отдельная инсталляция — отдельная инсталляция Meridian в инфраструктуре крупного клиента (его VPC, on-premise, регион с особым compliance);
  • гибрид — общая инсталляция для основной массы клиентов + выделенные инсталляции для регулируемых enterprise-клиентов.

Сценарий

Команда строит SaaS-продукт «ассистент для контакт-центров». Тарифы:

• Free — $5 LLM-запросов в месяц лимит в 3 запроса за минуту.
• Pro — $200/мес, 50 req/min.
• Enterprise — индивидуальный лимит или без лимита, отдельное окружение или размещается на выделенном шарде, on-premise по запросу.

Onboarding нового клиента (Free → Pro):

1. Клиент регистрируется в SaaS через ваш UI.
2. Ваш бэкенд в момент регистрации вызывает Meridian API: создаёт Customer с бюджетом $5/мес, calendar_aligned: true, выпускает один VK для клиента, сохраняет customer_id и vk_value в вашей БД.
3. Клиент получает в личном кабинете SaaS доступ к Вашим функциям, используеющие LLM-модели.
4. При апгрейде до Pro ваш бэкенд вызывает Meridian API: обновляет бюджет Customer (max_limit: 200), обновляет rate limit VK.

Биллинг и прозрачность:

5. Конец месяца — calendar_aligned бюджет автоматически сбрасывается в 00:00 UTC выбранного числа. Это совпадает с границей биллингового периода в вашем SaaS.
6. На дашборде клиента вы можете опционально показывать «израсходовано $137 из $200 за май» — данные читаются из Meridian API.

Enterprise on-premise:

7. Крупный клиент требует развёртывания LLM-функции внутри его периметра. Ваша команда разворачивает Meridian-инсталляцию в VPC клиента (Docker, Kubernetes), подключает её к корпоративному OpenAI-аккаунту клиента (или к собственному on-prem vLLM), создаёт там один Customer без денежного лимита.
8. Ваше SaaS-приложение в их периметре указывает на их инсталляцию Meridian; данные клиента не покидают их инфраструктуру.

Конфигурация

curl -X POST http://meridian/api/governance/customers \
  -H "Content-Type: application/json" \
  -d '{
    "name": "acme-corp",
    "metadata": {
      "plan": "pro",
      "external_id": "u-12345",
      "signup_at": "2026-05-18T10:00:00Z"
    },
    "budget": {
      "max_limit": 200.00,
      "reset_duration": "1M",
      "calendar_aligned": true
    }
  }'

{
  "id": "customer-acme",
  "name": "acme-corp",
  "budget_id": "budget-customer-acme",
  "metadata": { "plan": "pro", "external_id": "u-12345", "signup_at": "2026-05-18T10:00:00Z" }
}

curl -X POST http://meridian/api/governance/virtual-keys \
  -H "Content-Type: application/json" \
  -d '{
    "name": "acme-corp-default",
    "customer_id": "customer-acme",
    "provider_configs": [
      { "provider": "openai", "weight": 1.0, "allowed_models": ["gpt-4o-mini"] }
    ],
    "rate_limit": {
      "request_max_limit": 600,
      "request_reset_duration": "1m"
    },
    "is_active": true
  }'

curl http://meridian/api/governance/customers/customer-acme

# Поднять бюджет
curl -X PUT http://meridian/api/governance/customers/customer-acme \
  -H "Content-Type: application/json" \
  -d '{ "budget": { "max_limit": 500.00, "reset_duration": "1M", "calendar_aligned": true } }'

# Поднять rate limit
curl -X PUT http://meridian/api/governance/virtual-keys/{vk_id} \
  -H "Content-Type: application/json" \
  -d '{ "rate_limit": { "request_max_limit": 1200, "request_reset_duration": "1m" } }'

curl -X PUT http://meridian/api/governance/virtual-keys/{vk_id} \
  -H "Content-Type: application/json" \
  -d '{ "is_active": false }'

{
  "client": {
    "enable_logging": true,
    "enforce_auth_on_inference": true
  },
  "config_store": {
    "type": "postgres",
    "config": { "dsn": "env.CONFIG_DB_DSN" }
  },
  "logs_store": {
    "type": "postgres",
    "config": { "dsn": "env.LOGS_DB_DSN" }
  },
  "providers": {
    "openai":    { "keys": [ { "id": "k1", "value": "env.OPENAI_API_KEY",    "models": ["*"], "weight": 1.0 } ] },
    "anthropic": { "keys": [ { "id": "k1", "value": "env.ANTHROPIC_API_KEY", "models": ["*"], "weight": 1.0 } ] }
  },
  "plugins": {
    "prometheus": { "enabled": true, "labels": ["customer_id", "provider", "model"] },
    "otel":       { "enabled": true, "endpoint": "env.OTEL_EXPORTER_OTLP_ENDPOINT" }
  }
}

Варианты размещения

Multi-tenant SaaS-инсталляция

Одна инсталляция Meridian обслуживает всех клиентов. Каждый клиент — отдельный Customer; изоляция через VK и бюджеты.

Когда подходит:

• Большинство клиентов на стандартных тарифах (Free/Pro).
• Нет требований по юрисдикции данных, отличных от вашей.
• Объём — десятки до тысяч клиентов.

Что нужно учесть:

• Используйте кластерную (Enterprise) сборку для надёжности: Raft-бэкенд для бюджетов гарантирует консистентность списаний при отказе узла.
• Включите Prometheus с меткой customer_id для пер-клиентской наблюдаемости.

Отдельная инсталляция (on-premise или облако клиента)

Отдельная инсталляция Meridian в инфраструктуре крупного клиента. Только один Customer в этой инсталляции — сам клиент.

Когда подходит:

• Регулируемые данные (банки, медицина, госсектор).
• Клиент использует собственный OpenAI-аккаунт или собственные модели (on-prem vLLM, Yandex GPT в РФ, Azure OpenAI в Европе).
• Объём оправдывает отдельный SLA.

Что нужно учесть:

• Развёртывайте из Docker-образа или Helm-чарта; см. Кластеризация и руководства по deployment.
• Координацию между вашим SaaS-control-plane и инсталляцией на стороне клиента реализуйте через тот же Management API: ваш control plane знает endpoint этой инсталляции и при необходимости делает CRUD-вызовы.
• Согласуйте с клиентом, кто отвечает за апгрейды и мониторинг инсталляции.

Гибрид

Общая инсталляция для основной массы + выделенные инсталляции для enterprise-клиентов. Ваш SaaS-control-plane маршрутизирует запросы клиента на нужную инсталляцию по его customer_id.

Связанные материалы

• Виртуальные ключи — основная сущность; Customer + VK = тарифный план + ключ клиента.
• Бюджеты и лимиты — включая calendar-aligned бюджеты.
• Защита от опустошения бюджета и отказа в обслуживании — обязательно к прочтению для multi-tenant инсталляции.
• Отладка и аудит LLM-приложений — пер-клиентские метрики и логи через метку customer_id.
• Кластеризация — production-надёжность multi-tenant инсталляции.
• Справочники API — полная спецификация Management API.