Архитектура надёжности

Мы считаем «стабильность» функцией продукта номер один. На этой странице объясняется, как мы этого добиваемся и что происходит, когда что-то идёт не так.

Почему надёжность так сложна?

Разработчики, которые подключаются напрямую к официальному API, сталкиваются с такими вещами, как:

• Региональные ограничения скорости / недоступность
• Блокировка единственного платёжного канала или аккаунта
• Проблемы совместимости при смене версий модели
• Очереди в часы пик и всплески задержки до первого токена

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

Наша архитектура маршрутизации из нескольких источников

Для каждого вызова API запрос обрабатывается по следующему пути:

Ключевые механизмы:

• Пул из нескольких вышестоящих источников: несколько независимых каналов стоят за одной и той же моделью, что позволяет избежать единичных точек отказа
• Проверка работоспособности: мы непрерывно отслеживаем для каждого вышестоящего источника долю успешных запросов, задержку до первого токена и частоту ограничений скорости, и неработоспособные каналы автоматически понижаются в весе или удаляются
• Автоматическое переключение при сбоях: когда основной канал возвращает 5xx / ограничение скорости / тайм-ауты, запрос переключается на резервный канал в течение миллисекунд, обычно без влияния на вашу сторону
• Переподключение при обрыве потока: когда потоковый ответ обрывается на середине, мы пытаемся возобновить его на протоколах, которые это поддерживают

Уровень обслуживания (SLA)

Наши внешние обязательства основаны на том, «что мы действительно можем обеспечить» — мы не даём пустых обещаний.

Тариф Economy предназначен для индивидуальных разработчиков, которые хотят получить максимальную выгоду и могут мириться с периодическими колебаниями; если у вашего бизнеса жёсткие требования к надёжности, выберите тариф Enterprise или свяжитесь с нашим отделом продаж для индивидуального плана.

Как измеряется доступность:

• Мы учитываем только долю успешных запросов «на стороне LMU AI», исключая сетевые проблемы на стороне пользователя, ошибки параметров и отказы по содержанию от самой вышестоящей модели
• Единичный сбой продолжительностью < 60 секунд не учитывается
• Ежемесячный отчёт включает доли успешных запросов и задержку P95 в разбивке по модели и по периоду времени

Что происходит во время инцидента

Кратковременный джиттер (< 5 минут)

• Уровень маршрутизации автоматически переключает вышестоящие источники, без объявления
• Страница статуса фиксирует событие

Отказ одного вышестоящего источника (< 1 часа)

• Уровень маршрутизации завершает переключение; если это заметно для некоторых пользователей/моделей, мы публикуем это на странице статуса
• Пользователи Standard и Enterprise уведомляются по электронной почте

Региональное или одновременное влияние на несколько вышестоящих источников

• Событие закрепляется на странице статуса с периодическими обновлениями
• Пользователи Enterprise получают обновления о ходе в реальном времени по электронной почте
• Разбор инцидента публикуется в течение 48 часов после его завершения

Что мы не делаем

Чтобы не вводить пользователей в заблуждение, в настоящее время мы не обещаем следующего:

• Переключение с нулевой задержкой без разрывов: переключение при сбоях добавляет дополнительную задержку от миллисекунд до секунд, поэтому оно никогда не будет полностью бесшовным
• Компенсацию совместимости между моделями: если сама вышестоящая модель выведена из эксплуатации (например, версия модели прекращена поставщиком), мы объявляем об этом, а не молча переключаемся на другую модель
• Неограниченные повторы: неудачные запросы повторяются ограниченное число раз согласно политике, поэтому вы не платите за неожиданные повторные вызовы

FAQ

Последнее обновление: 2026-09-10