BYOK

Используйте свои собственные ключи API

LLMSTORE поддерживает как кредиты LLMSTORE, так и возможность использовать собственные ключи провайдера (BYOK). Когда вы используете кредиты LLMSTORE, ваши тарифные ограничения каждый провайдер управляется LLMSTORE. Использование ключей провайдера позволяет напрямую контролировать ограничения тарифов и расходы через учетную запись провайдера. Ключи вашего провайдера надежно зашифрованы и используются для всех запросов, направляемых через указанного провайдера. Управляйте ключами в настройках рабочего пространства BYOK. Стоимость использования пользовательских ключей поставщика в LLMSTORE составляет % того, сколько обычно будет стоить та же модель/провайдер LLMSTORE и будут вычтены из вашего LLMSTORE. кредитов. Эта плата не взимается за первые запросы BYOK в месяц.

Ключевой приоритет и резервный вариант

Каждый ключ BYOK принадлежит одному из двух разделов:

Приоритет — Попытка по порядку, до падения обратно к эндпоинтам LLMSTORE. Используйте этот раздел для своих ключи основного поставщика.
Резервный — Пробуется только после эндпоинтов LLMSTORE. были предприняты попытки, по порядку. Используйте этот раздел для резервные ключи, которые вы хотите использовать только в крайнем случае.

Клавиши можно перетаскивать между разделами на провайдере страница подробностей (например. /workspaces/default/byok/openai). По умолчанию, если все ключи в обоих разделах имеют ограничение скорости или сбой, LLMSTORE вернется к с использованием общих эндпоинтов LLMSTORE. Вы можете включить “Всегда использовать для этого провайдера” на отдельные приоритетные ключи, чтобы предотвратить возврат к Эндпоинты LLMSTORE. При включении LLMSTORE будет только используйте свои ключи для запросов к этому провайдеру, который может приведет к ошибкам ограничения скорости, если ваши ключи исчерпаны, , но гарантирует, что все запросы проходят через вашу учетную запись. Если у вас есть несколько ключей для одного и того же провайдера, LLMSTORE пробует их в порядке приоритета (см. Несколько ключей BYOK). Если первый ключ не сработает, он переходит к следующему соответствующий ключ перед возвратом к общей емкости.

BYOK с заказом у поставщика

При объединении ключей BYOK с заказом поставщика, LLMSTORE всегда в первую очередь отдает приоритет эндпоинтам BYOK, независимо от того, где этот поставщик появляется в указанном вами порядке. После того как все эндпоинты BYOK исчерпаны, LLMSTORE возвращается к общей емкости в указанном вами порядке. Это означает, что ключи BYOK фактически отменяют порядок вашего провайдера для первоначальных попыток маршрутизации. В настоящее время нет способа изменить это поведение. Например, если у вас есть ключи BYOK для Amazon Bedrock, Google Vertex AI и Anthropic, и вы отправляете запрос с:

{
  "provider": {
    "allow_fallbacks": true,
    "order": ["amazon-bedrock", "google-vertex", "anthropic"]
  }
}

Порядок маршрутизации будет следующим:

Amazon Bedrock (ваш ключ BYOK)
Google Vertex AI (ваш ключ BYOK)
Anthropic (ваш ключ BYOK)
Amazon Bedrock (общая емкость LLMSTORE)
Google Vertex AI (совместная емкость LLMSTORE)
Anthropic (совместная мощность LLMSTORE)

Частичный BYOK с заказом у поставщика

Если у вас есть ключ BYOK только для некоторых поставщиков в вашем заказе, сначала будет проверен поставщик BYOK. Например, если вы укажете order: ["amazon-bedrock", "google-vertex"] , но у вас есть только ключ BYOK для Google Vertex AI:

{
  "provider": {
    "allow_fallbacks": true,
    "order": ["amazon-bedrock", "google-vertex"]
  }
}

Порядок маршрутизации будет следующим:

Google Vertex AI (ваш ключ BYOK)
Amazon Bedrock (общая емкость LLMSTORE)
Google Vertex AI (совместная емкость LLMSTORE)

Обратите внимание, что хотя Amazon Bedrock указан первым в списке order , эндпоинт Google Vertex AI BYOK имеет приоритет. Если вы хотите предотвратить возврат к эндпоинтам LLMSTORE полностью, включите “Всегда использовать для этого провайдера” на ключи BYOK в вашем настройки BYOK рабочей области.

BYOK с политиками данных

На эндпоинты BYOK распространяются ваши политики в отношении данных. Внесение собственных изменений ключа, которые удостоверяют подлинность восходящего запроса — это не меняет того, к каким эндпоинтам вам разрешено маршрутизироваться. Политики данных вашего поставщика, учетной записи и защиты применяются до создания эндпоинтов BYOK, поэтому BYOK осуществляет маршрутизацию только к эндпоинтам, которые уже соответствуют им. Это означает, что ключ BYOK не освобождает поставщика от ваших обязательств нулевого хранения данных или Сообщения data_collection ограничения. Если вы применяете ZDR (через provider.zdr, настройки конфиденциальности учетной записи или ограждение) и эндпоинт провайдера сохраняет подсказки, эта эндпоинт остается неприемлемой, даже если вы предоставляете свой собственный ключ. Например, если вы применяете ZDR и отправляете запрос, который в противном случае использовал бы ключ BYOK для поставщика, эндпоинт которого сохраняет запросы:

{
  "provider": {
    "zdr": true
  }
}

Сохраняющая эндпоинт отфильтровывается до того, как ваш ключ BYOK будет рассмотрен, и запрос не будет выполнен, если не останется никакой эндпоинта, совместимой с ZDR, даже если у вас есть действительный ключ для этого провайдера. Чтобы использовать провайдера через BYOK, убедитесь, что это разрешено вашей политикой данных: эндпоинт провайдера должна соответствовать любому ZDR или data_collection ограничения, которые вы включили. См. Нулевое сохранение данных. и Маршрутизация поставщика.

BYOK и бюджеты

По умолчанию затраты на инференс BYOK не учитываются в бюджетах — учитываются только расходы на кредиты LLMSTORE. Это означает, что бюджет может оказаться далёк от предела даже после значительного использования BYOK. Чтобы учитывать расходы BYOK в бюджете, включите опцию Включить расходы BYOK (или установите include_byok_in_budgets в true через API). Тогда сумма, которую LLMSTORE списал бы, если бы запрос не использовал ваш собственный ключ провайдера, добавляется в бюджет вместе с расходами по кредитам, и запросы блокируются, как только общая сумма достигает предела. Настройки применяются сразу ко всем интервалам бюджета — ежедневному, еженедельному, ежемесячному и за весь срок действия.

Несколько ключей BYOK для одного и того же провайдера

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

Приоритетный порядок

Ключи проверяются в указанном вами порядке в пределах их раздел. Сначала пробуются приоритетные ключи, затем Эндпоинты LLMSTORE, затем Резервные ключи. Вы можете измените порядок ключей, перетащив их на сведения о поставщике. страница (например. /workspaces/default/byok/openai). При сбое ключа (например, ограничение скорости или ошибка), LLMSTORE переходит к следующему соответствующему ключу. Например, если у вас есть три ключа OpenAI:

Приоритетный раздел: Первый ключ, Второй ключ.
Резервный раздел: Резервный ключ.

LLMSTORE попробует: Первый ключ, затем Второй ключ, , затем эндпоинты LLMSTORE, затем Резервный ключ.

Ключевые фильтры

Каждый ключ BYOK поддерживает дополнительные фильтры для контроля его использования:

Фильтр моделей — Ограничьте использование ключа определенными моделями (например, используйте этот ключ только для openai/gpt-4o). Если этот ключ установлен, ключ используется только для запросов к перечисленным моделям. Другие модели того же поставщика пропустят этот ключ.
Фильтр ключей API — Ограничьте, какие из ваших ключей API LLMSTORE могут использовать этот ключ BYOK. Полезно для изоляции использования BYOK для конкретных приложений или сред.
Фильтр участников — Ограничьте список участников рабочей области, которые могут использовать этот ключ BYOK. Полезно для предоставления разным членам команды доступа к различным учетным записям поставщиков.

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

Объединение фильтров с несколькими ключами

Фильтры и несколько ключей работают вместе, обеспечивая гибкую стратегию маршрутизации. Например:

Ключ A: OpenAI, фильтр модели = [openai/gpt-4o], «Всегда использовать для этого провайдера» включено
Ключ B: OpenAI, без фильтра моделей (подходит ко всем моделям)

В этой настройке:

Запросы на openai/gpt-4o сначала попробуйте Ключ A, затем Ключ B, если ключ A не работает (общая емкость пропускается, поскольку для ключа A включена опция «Всегда использовать для этого провайдера»)
Запросы на другие модели OpenAI (например. openai/gpt-4o-mini) используйте только Ключ B, с общей емкостью в качестве запасного варианта.

Названия клавиш

Каждому ключу можно дать необязательное имя (например, «Производство», «Команда А», «Только GPT-4»), чтобы упростить организацию ключей, если у вас есть несколько ключей для одного и того же поставщика.

Ключи API Azure

Azure имеет два типа ресурсов, каждый из которых использует свой домен:

Azure AI Foundry — ресурсы по адресу *.services.ai.azure.com. Использует каталог моделей и не требует развертывания для каждой модели.
Azure OpenAI — ресурсы по адресу *.openai.azure.com. Требует явного развертывания для каждой модели.

Конфигурация Foundry (рекомендуется)

Самый простой способ настроить Azure BYOK — использовать конфигурацию Foundry. Укажите свой ключ API, имя и тип ресурса:

[
  {
    "api_key": "your-azure-api-key",
    "resource_name": "your-resource-name",
    "resource_type": "ai_foundry"
  }
]

api_key: ваш ключ API Azure, который можно найти в разделе «Ключи и эндпоинт» на портале Azure.
resource_name: имя вашего ресурса Azure (субдомен URL-адреса вашей эндпоинта).
resource_type: Либо "ai_foundry" для ресурсов Azure AI Foundry (*.services.ai.azure.com) или "openai" для ресурсов Azure OpenAI (*.openai.azure.com). По умолчанию "openai" , если опущено.

Эта конфигурация работает для всех моделей, доступных в вашем ресурсе Azure — настройка для каждой модели не требуется.

Конфигурация для каждого развертывания (устаревшая версия)

Для большего контроля вы можете указать отдельные развертывания с полными URL-адресами эндпоинтов:

[
  {
    "model_slug": "mistralai/mistral-large",
    "endpoint_url": "https://example-project.openai.azure.com/openai/deployments/mistral-large/chat/completions?api-version=2024-08-01-preview",
    "api_key": "your-azure-api-key",
    "model_id": "mistral-large"
  },
  {
    "model_slug": "openai/gpt-5.2",
    "endpoint_url": "https://example-project.openai.azure.com/openai/deployments/gpt-5.2/chat/completions?api-version=2024-08-01-preview",
    "api_key": "your-azure-api-key",
    "model_id": "gpt-5.2"
  }
]

Для каждой конфигурации развертывания требуется:

endpoint_url: полный URL-адрес эндпоинта развертывания, включая /chat/completions и версию API. См. документацию по Azure Foundry.](https://learn.microsoft.com/en-us/azure/ai-foundry/model-inference/concepts/endpoints?tabs=python) для подробностей.
api_key: ваш ключ API Azure.
model_id: имя развертывания вашей модели в Azure.
model_slug: идентификатор модели LLMSTORE, для которого вы хотите использовать этот ключ.

Вы можете смешивать конфигурации Foundry и конфигурации для каждого развертывания в одном массиве. Конфигурации для каждого развертывания имеют приоритет при обнаружении соответствующего пула модели.

Ключи API AWS Bedrock

Чтобы использовать Amazon Bedrock с LLMSTORE, вы можете пройти аутентификацию с помощью ключей API Bedrock или традиционных учетных данных AWS.

Вариант 1: Ключи API Bedrock (рекомендуется)

Ключи API Amazon Bedrock обеспечивают более простой метод аутентификации. Просто укажите ключ API Bedrock в виде строки:

your-bedrock-api-key-here

Примечание. Ключи API Bedrock привязаны к определенному региону AWS и не могут использоваться для изменения региона. Если вам нужно использовать модели в разных регионах, воспользуйтесь опцией учетных данных AWS ниже. Ключи API Bedrock можно сгенерировать в Консоли управления AWS. Подробную информацию см. в документации по ключам API Amazon Bedrock.](https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html).

Вариант 2: учетные данные AWS

Альтернативно вы можете использовать традиционные учетные данные AWS в формате JSON. Эта опция позволяет указать регион и обеспечивает большую гибкость:

{
  "accessKeyId": "your-aws-access-key-id",
  "secretAccessKey": "your-aws-secret-access-key",
  "region": "your-aws-region"
}

Эти значения можно найти в вашей учетной записи AWS:

accessKeyId: это идентификатор вашего ключа доступа к AWS. Вы можете создать или найти ключи доступа в Консоли управления AWS в разделе «Учетные данные безопасности» своей учетной записи AWS.
secretAccessKey: это ваш секретный ключ доступа AWS, который предоставляется при создании ключа доступа.
регион: регион AWS, в котором развернуты ваши модели Amazon Bedrock (например, «us-east-1», «us-west-2»).

Убедитесь, что ваш пользователь или роль AWS IAM имеет необходимые разрешения для доступа к сервисам Amazon Bedrock. Как минимум, вам потребуются разрешения для:

bedrock:InvokeModel
bedrock:InvokeModelWithResponseStream (для потоковой передачи ответов)

Пример политики IAM:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "*"
    }
  ]
}

Для повышения безопасности мы рекомендуем создавать выделенных пользователей IAM с ограниченными разрешениями специально для использования с LLMSTORE. Дополнительную информацию можно найти в статье AWS Bedrock: Начало работы с API документация, Настройка разрешений IAM или Справочник по AWS Bedrock API.

Ключи API Google Vertex

Чтобы использовать Google Vertex AI с LLMSTORE, вам необходимо предоставить ключ учетной записи службы Google Cloud в формате JSON. Ключ сервисного аккаунта должен включать все стандартные поля сервисного аккаунта Google Cloud с необязательным полем. Поле region для указания региона развертывания.

{
  "type": "service_account",
  "project_id": "your-project-id",
  "private_key_id": "your-private-key-id",
  "private_key": "-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----\n",
  "client_email": "your-service-account@your-project.iam.gserviceaccount.com",
  "client_id": "your-client-id",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/your-service-account@your-project.iam.gserviceaccount.com",
  "universe_domain": "googleapis.com",
  "region": "global"
}

Эти значения можно найти в Google Cloud Console:

Ключ сервисного аккаунта: перейдите в Google Cloud Console, выберите «IAM и администратор» > «Сервисные аккаунты», выберите свой сервисный аккаунт и создайте/загрузите ключ JSON.
регион (необязательно): укажите регион для развертывания Vertex AI. Использование "global" , чтобы разрешить выполнение запросов в любом доступном регионе, или укажите конкретный регион, например "us-central1" или Сообщения "europe-west1".

Убедитесь, что ваша учетная запись службы имеет необходимые разрешения для доступа к службам Vertex AI:

aiplatform.endpoints.predict

Пример политики IAM:

{
  "bindings": [
    {
      "role": "roles/aiplatform.user",
      "members": [
        "serviceAccount:your-service-account@your-project.iam.gserviceaccount.com"
      ]
    }
  ]
}

Подробную информацию можно найти в документации Google Cloud Vertex AI. и Руководство по настройке сервисной учетной записи.

Отладка проблем BYOK

Если ваши запросы BYOK не выполняются, вы можете устранить проблему, просмотрев ответы поставщика на странице «Активность».

Просмотр ответов поставщика

Перейдите на свою страницу активности. на панели управления LLMSTORE.
Найдите поколение, которое вы хотите отладить, и щелкните его, чтобы просмотреть подробную информацию.
Нажмите «Просмотреть необработанные метаданные», чтобы отобразить необработанные метаданные в формате JSON.
В JSON найдите Поле provider_responses , в котором отображается код состояния HTTP для каждой попытки поставщика. Поле

Объект provider_responses содержит массив ответов от каждого провайдера, предпринятого во время маршрутизации. Каждая запись включает имя поставщика и код состояния HTTP, которые могут помочь вам выявить проблемы с разрешениями, ограничениями скорости или другие ошибки.

Распространенные коды ошибок BYOK

При отладке проблем BYOK ищите следующие общие коды состояния HTTP в ответах провайдера:

400 Неверный запрос: Формат запроса недействителен для провайдера. Убедитесь, что ваша модель и конфигурация ключей верны.
401 Несанкционировано: ваш ключ API недействителен или отозван. Проверьте свой ключ в консоли вашего провайдера.
403 Запрещено: у вашего ключа API нет разрешения на доступ к запрошенному ресурсу. Для AWS Bedrock убедитесь, что ваша политика IAM включает необходимые bedrock:InvokeModel разрешения. Для Google Vertex убедитесь, что в вашей учетной записи службы есть aiplatform.endpoints.predict разрешения.
429 Слишком много запросов: Вы достигли предела скорости для своей учетной записи провайдера. Проверьте настройки ограничения скорости вашего провайдера или подождите, прежде чем повторить попытку.
500 Ошибка сервера: Поставщик обнаружил внутреннюю ошибку. Обычно это временная проблема на стороне провайдера.

Проблемы с разрешениями на отладку

Если вы столкнулись с ошибкой 403 при использовании BYOK, проблема часто связана с разрешениями. Для AWS Bedrock убедитесь, что:

Ваш пользователь/роль IAM имеет bedrock:InvokeModel и Параметры bedrock:InvokeModelWithResponseStream разрешения.
Модель, к которой вы пытаетесь получить доступ, включена в вашей учетной записи AWS для указанного региона.
Ваши учетные данные (ключ доступа и секрет) верны и активны.

Для Google Vertex убедитесь, что в вашей учетной записи службы aiplatform.endpoints.predict разрешения. Вы можете проверить разрешения своего провайдера непосредственно в консоли провайдера (консоль AWS, консоль Google Cloud и т. д.), попытавшись сначала вызвать там модель.

Начало работы

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

Мультимодальность

Модели и роутинг

Варианты моделей

Возможности

Плагины

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

Приватность

Лучшие практики

SDK и интеграции

Используйте свои собственные ключи API

Ключевой приоритет и резервный вариант

BYOK с заказом у поставщика

Частичный BYOK с заказом у поставщика

BYOK с политиками данных

BYOK и бюджеты

Несколько ключей BYOK для одного и того же провайдера

Приоритетный порядок

Ключевые фильтры

Объединение фильтров с несколькими ключами

Названия клавиш

Ключи API Azure

Конфигурация Foundry (рекомендуется)

Конфигурация для каждого развертывания (устаревшая версия)

Ключи API AWS Bedrock

Вариант 1: Ключи API Bedrock (рекомендуется)

Вариант 2: учетные данные AWS

Ключи API Google Vertex

Отладка проблем BYOK

Просмотр ответов поставщика

Распространенные коды ошибок BYOK

Проблемы с разрешениями на отладку

​Используйте свои собственные ключи API

​Ключевой приоритет и резервный вариант

​BYOK с заказом у поставщика

​Частичный BYOK с заказом у поставщика

​BYOK с политиками данных

​BYOK и бюджеты

​Несколько ключей BYOK для одного и того же провайдера

​Приоритетный порядок

​Ключевые фильтры

​Объединение фильтров с несколькими ключами

​Названия клавиш

​Ключи API Azure

​Конфигурация Foundry (рекомендуется)

​Конфигурация для каждого развертывания (устаревшая версия)

​Ключи API AWS Bedrock

​Вариант 1: Ключи API Bedrock (рекомендуется)

​Вариант 2: учетные данные AWS

​Ключи API Google Vertex

​Отладка проблем BYOK

​Просмотр ответов поставщика

​Распространенные коды ошибок BYOK

​Проблемы с разрешениями на отладку

Используйте свои собственные ключи API

Ключевой приоритет и резервный вариант

BYOK с заказом у поставщика

Частичный BYOK с заказом у поставщика

BYOK с политиками данных

BYOK и бюджеты

Несколько ключей BYOK для одного и того же провайдера

Приоритетный порядок

Ключевые фильтры

Объединение фильтров с несколькими ключами

Названия клавиш

Ключи API Azure

Конфигурация Foundry (рекомендуется)

Конфигурация для каждого развертывания (устаревшая версия)

Ключи API AWS Bedrock

Вариант 1: Ключи API Bedrock (рекомендуется)

Вариант 2: учетные данные AWS

Ключи API Google Vertex

Отладка проблем BYOK

Просмотр ответов поставщика

Распространенные коды ошибок BYOK

Проблемы с разрешениями на отладку