Сортировать провайдеров и управлять резервным механизмом

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

Просмотреть как Markdown

На этой странице

Цена#

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

Задержка и пропускная способность#

Задержка использует наблюдаемое время выполнения завершенного запроса, а не время до первого токена. Пропускная способность использует наблюдаемые выходные токены за прошедшую секунду. Недавние наблюдения охватывают пятиминутное окно. Эти измерения направляют маршрутизацию; они не гарантируют время ответа или емкость.

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

Упорядочить перед сортировкой#

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

Политика	Допустимые варианты
`allow_fallbacks: true`	Можно рассмотреть других допустимых провайдеров, в рамках каждого жесткого ограничения.
`allow_fallbacks: false` с `order`	Только провайдеры, явно указанные в порядке.
`allow_fallbacks: false` без `order`	Только провайдер, занявший первое место.

Резервирование сохраняет ту же модель#

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

Обрабатывать прерванные запросы#

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

Примеры#

JSON

{
  "provider": {
    "sort": {
      "by": "latency",
      "direction": "asc"
    },
    "allow_fallbacks": true
  }
}

Чтобы предпочесть наивысшую пропускную способность, используйте {"by":"throughput","direction":"desc"}. Переверните любое направление только тогда, когда этот порядок соответствует вашему предполагаемому тесту или рабочей нагрузке.

Последнее обновление Сентябрь 16, 2026