Обзор моделей

Используйте страницу «Модели» или API моделей для просмотра доступных текстовых моделей. Метаданные модели включают производителя, обслуживающего провайдера, модальность, длину контекста, поддерживаемые семейства API, поддерживаемые возможности, доступность, ограничения на уровне аккаунта и цены в кредитах.

Конечная точка: GET /v1/models Назначение: Список моделей, доступных текущему аккаунту.

Копироватьcurl --request GET \
  --url https://api.basicrouter.ai/api/v1/models \
  --header "Authorization: Bearer $BASICROUTER_API_KEY"

Матрица возможностей

Матрица совместимости семейств API

Аутентификация

Каждый API-запрос использует bearer-токен. Храните ключи в серверных переменных окружения, ротируйте их при изменении доступа команды и записывайте идентификаторы запросов для отладки.

Рекомендации по безопасности ключей

1. Храните API-ключи на сервере. Не раскрывайте ключи в браузерном или мобильном клиентском коде.
2. Используйте отдельные ключи для разработки, staging-окружения, продакшена и сторонних интеграций.
3. Ограничивайте область действия ключей по окружению, сервису, клиенту или тенанту при наличии.
4. Ротируйте ключи после ухода сотрудников, изменения доступа подрядчиков или при подозрении на утечку.
5. Храните ключи в менеджерах секретов или переменных окружения, а не в исходном коде.

Использование консоли

Консоль BasicRouter — это операционная плоскость управления для доступа к API, доступности моделей, политик маршрутизации, мониторинга использования и администрирования биллинга. Она предоставляет администраторам аккаунта централизованное представление ключей, моделей, запросов, кредитов и средств управления на уровне аккаунта для продакшен-трафика моделей.

Управление ключами API

Создавайте, ротируйте, отзывайте и помечайте API-ключи из консоли. Используйте отдельные ключи для разработки, staging-окружения, продакшена и отдельных сервисов, чтобы использование можно было аудировать и изолировать по окружению или приложению.

Список моделей

Используйте страницу «Модели» для просмотра моделей, доступных аккаунту. Каждая запись о модели может включать вендора, обслуживающего провайдера, модальность, поддерживаемые семейства API, длину контекста, флаги возможностей, статус доступности и информацию о ценах.

Для продакшен-приложений проверяйте возможности моделей перед включением трафика. Некоторые параметры и функции зависят от модели и могут не поддерживаться во всех семействах API.

Использование и журналы

Представление «Использование и журналы» обеспечивает оперативную видимость API-трафика. Команды могут проверять объём запросов, выбранные модели, разрешённые цели маршрутизации, потребление кредитов, задержку, коды ошибок и идентификаторы запросов.

• Устранение неполадок неудачных запросов.
• Выявление дорогостоящих рабочих нагрузок.
• Сравнение использования моделей между приложениями и окружениями.
• Проверка поведения маршрутизации и резерва.
• Исследование проблем задержки или доступности провайдера.
• Предоставление идентификаторов запросов при обращении в поддержку.

Каждый ответ API включает или раскрывает идентификатор запроса BasicRouter. Сохраняйте этот идентификатор в журналах вашего приложения для повышения эффективности отладки в продакшене и эскалации поддержки.

Резерв

Резерв (fallback) — это механизм отказоустойчивости BasicRouter. Когда основная модель или политика маршрутизации даёт сбой, система автоматически переключается на резервную модель, чтобы продолжить обработку запроса. Это сохраняет отзывчивость приложения и минимизирует риск нарушения работы сервиса.

Почему важен резерв

В продакшене сервисы моделей могут столкнуться с рядом непредсказуемых проблем:

• Сбой сервиса модели: вышестоящий API временно недоступен или превышает время ожидания.
• Колебания производительности: высокая нагрузка на модель приводит к медленным или неудачным ответам.
• Сбой маршрутизации: все модели-кандидаты, выбранные умной маршрутизацией, становятся недоступными.

Резерв поддерживает доступность вашего приложения, предоставляя надёжный резервный путь.

Ключевые преимущества

Глобальная конфигурация резервной модели

BasicRouter поддерживает настройку глобальной резервной модели из бэкенда консоли. Все запросы автоматически используют эту модель в качестве резерва при сбое.

Как настроить:

1. Перейдите на страницу настроек стратегии BasicRouter.
2. Найдите настройку Модель резерва по умолчанию.
3. Выберите вашу глобальную резервную модель из выпадающего списка.
4. Сохраните настройку, чтобы применить её немедленно.

Преимущества глобальной конфигурации:

• Изменения кода не требуются: настройте один раз, и это применяется глобально, без необходимости повторять настройку в каждом запросе.
• Централизованное управление: управляйте политикой резерва в одном месте для более удобной корректировки и мониторинга.
• Упрощённое обслуживание: снижает сложность кода и вероятность ошибок конфигурации.
• Гибкое переопределение: конфигурация резерва на уровне запроса имеет приоритет и может переопределять глобальную настройку для конкретных сценариев.

Конфигурация резерва на уровне запроса

Для конкретных бизнес-сценариев можно указать резервную модель в отдельном запросе, чтобы переопределить глобальную конфигурацию.

Укажите резервную модель с помощью параметра router.fallBackModels:

Копировать{
  "model": "claude-sonnet-4",
  "messages": [
    {
      "role": "user",
      "content": "Explain what quantum computing is"
    }
  ],
  "router": {
    "fallBackModels": ["glm-5.2"]
  }
}

Правила приоритета

При наличии нескольких конфигураций резерва приоритет распределяется от высшего к низшему:

1. router.fallBackModels на уровне запроса: резервная модель, указанная в отдельном запросе.
2. Глобальная модель резерва по умолчанию: глобальная резервная модель, настроенная в консоли.
3. Без резерва: если ни одна из них не настроена, запрос возвращает ошибку при сбое.

Администрирование аккаунта

В зависимости от типа аккаунта консоль может включать включение моделей на уровне аккаунта, элементы управления реселлером или дистрибьютором, конфигурацию биллинга и настройки доступа. Администраторы могут использовать эти элементы управления для согласования доступа к моделям, видимости использования и ответственности за биллинг с приложениями, клиентскими аккаунтами или бизнес-подразделениями.

Контрольный список производственных операций

Биллинг и кредиты

BasicRouter использует модель биллинга на основе кредитов для текстовых, графических, видеоматериалов и других поддерживаемых рабочих нагрузок моделей. Кредиты предоставляют единую единицу измерения для использования нескольких моделей и провайдеров, что позволяет командам согласованно управлять потреблением между модальностями и семействами API.

Подробная информация о ценах на модели доступна на странице «Модели» или через API метаданных моделей. Цены могут различаться в зависимости от модели, провайдера, модальности, разрешения, типа токенов, длины вывода, длительности задачи, типа аккаунта и коммерческого соглашения.

Пополнение и кошелёк

Аккаунты могут добавлять кредиты на кошелёк с оплатой по факту использования для гибкого использования. Кредиты кошелька используются после того, как кредиты месячного тарифа и пакеты ресурсов будут израсходованы, если к аккаунту не применяется пользовательское правило биллинга.

Кредиты кошелька не истекают, если иное не указано в применимых коммерческих условиях. При пополнении кошелька с оплатой по факту использования взимается сервисный сбор.

Месячные тарифы и пакеты ресурсов

Каждый пользователь или аккаунт может выбрать один активный месячный тариф. Месячные тарифы предоставляют определённый объём пропускной способности использования, коммерческие условия и конфигурацию доступа на уровне аккаунта для расчётного периода.

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

Порядок списания

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

Для аккаунтов с пользовательскими коммерческими условиями порядок списания, правила истечения срока действия, включённое использование и цены могут отличаться. Специфичные для аккаунта правила отображаются в консоли или предоставляются через коммерческое соглашение.

Индивидуальное ценообразование

Ценообразование может быть настроено для каждого пользователя или аккаунта. Корпоративные клиенты, аккаунты реселлеров, аккаунты дистрибьюторов и клиенты с большим объёмом использования могут иметь право на индивидуальное ценообразование. Свяжитесь с отделом продаж для получения предложения.

Индивидуальное ценообразование может быть настроено по аккаунту, модели, провайдеру, модальности, региону, объёму использования или коммерческому соглашению. Когда включено индивидуальное ценообразование, консоль и API биллинга отражают специфичные для аккаунта цены и правила списания там, где это доступно.

Единицы ценообразования

Разные модальности моделей используют разные единицы измерения. BasicRouter конвертирует эти единицы в кредиты в соответствии с правилами ценообразования модели.

Единицы ценообразования могут различаться в зависимости от модели. Всегда обращайтесь к странице сведений о модели или метаданным цен перед включением модели в продакшене.

Атрибуция использования

Использованием BasicRouter можно просматривать по аккаунту, API-ключу, модели, модальности или диапазону времени. Это позволяет командам относить затраты к приложениям, окружениям, клиентам или внутренним бизнес-подразделениям.

Баланс кредитов

Проверьте, сколько кредитов доступно на вашем аккаунте. Баланс разделён на три кошелька, которые списываются по порядку: месячный лимит тарифа, приобретённые пакеты ресурсов и кошелёк с оплатой по факту. Также доступен общий ресурсный итог (месячный тариф + пакеты ресурсов, без учёта оплаты по факту) для отслеживания включённого использования отдельно от расходов на пополнение.

Чтобы получить эти данные программно, см. GET /v1/billing/balance в Справочнике API.

Сведения об использовании

Просматривайте постраничный хронологический список отдельных записей об использовании для отчётности, мониторинга и внутреннего распределения затрат. Каждая запись показывает модель, тип модели (текст, изображение или видео), списанные кредиты и разбивку того, из какого кошелька было произведено каждое списание. Результаты можно фильтровать по конкретному диапазону времени.

Чтобы получить эти данные программно, см. GET /v1/usage в Справочнике API.

История транзакций

Используйте историю транзакций для просмотра движений кредитов, включая пополнения, распределения по тарифам, предоставления пакетов ресурсов, списания за использование, корректировки и административные исправления.

Чтобы получить эти данные программно, см. GET /v1/billing/transactions в Справочнике API.

Неудачные запросы и возвраты

Ошибки валидации, ошибки аутентификации и ошибки разрешений, как правило, не оплачиваются, поскольку выполнения модели не происходит. Запросы, достигающие вышестоящей модели или генерирующие частичный вывод, могут потреблять кредиты в зависимости от модели, провайдера и состояния ответа.

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

Пополнения, месячные тарифы, пакеты ресурсов и потреблённые кредиты возврату не подлежат, если иное не предусмотрено применимым коммерческим соглашением или не требуется по закону.

Эксплуатация

Ошибки

BasicRouter возвращает стабильные коды ошибок, чтобы приложения могли единообразно обрабатывать повторы, резервирование, проблемы с биллингом и отладку.

Совместимые с провайдерами конечные точки по возможности сохраняют форму ошибок исходного семейства API. Собственные конечные точки BasicRouter используют объект ошибок BasicRouter.

Соответствие HTTP-статусов и кодов ошибок

Частые коды ошибок