Cloudflare AI Gateway делает маршрутизацию только BYOK явным контролем выставления счетов.

Cloudflare добавила небольшой, но важный элемент управления в AI Gateway: теперь команды могут запрашивать учетные данные стороннего поставщика, прежде чем запрос будет разрешен к выполнению. Если шлюз не находит подходящие учетные данные, запрос завершается с ошибкой HTTP 400 вместо возврата к единому биллингу, управляемому Cloudflare.

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

Что изменилось

Обновление Cloudflare от 14 сентября добавляет два способа обеспечения нового поведения. На уровне шлюза администраторы могут включить параметр byok_only. Во время запроса вызывающие абоненты могут отправить заголовок cf-aig-no-wholesale, чтобы предотвратить возврат оптового выставления счетов для этого запроса.

Когда применяется элемент управления и учетные данные поставщика недоступны, AI Gateway возвращает HTTP 400. Cloudflare заявляет, что запросы Workers AI остаются разрешенными, поэтому политика конкретно касается запросов сторонних поставщиков, которые в противном случае могли бы маршрутизироваться через учетные данные, управляемые Cloudflare.

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

Почему откат к оплате опасен

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

Поставщик SaaS, агентство или команда внутренней платформы могут пообещать, что трафик данного арендатора будет проходить только через учетную запись OpenAI, Anthropic, Google или другого поставщика этого арендатора. Если вместо этого шлюз молча использует оптовые учетные данные, запрос все равно может быть успешным, но коммерческое значение изменилось. Оператор платформы может взять на себя расходы, передать их неправильно или потерять возможность сверить использование со счетом поставщика услуг клиента.

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

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

Кого это затрагивает

Непосредственной аудиторией является любая команда, использующая Cloudflare AI Gateway с сочетанием учетных данных, принадлежащих поставщику, и биллинга, управляемого Cloudflare. Это изменение имеет наибольшее значение в тех случаях, когда несколько арендаторов, сред или бизнес-подразделений используют одну и ту же конфигурацию шлюза.

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

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

Пользователи Model Gate сталкиваются с одной и той же основной проблемой, когда они управляют командами, ключами API, аналитикой использования и доступом для партнеров. Ключ на уровне клиента — это не просто токен аутентификации; это может подразумевать режим выставления счетов, лимит расходов, учетную запись поставщика и набор ожиданий аудита. Если эти значения не будут соблюдаться последовательно, аналитические панели и счета-фактуры могут отойти от того, что, по мнению клиентов, они купили.

Практические последствия

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

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

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

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

Что остается неясным

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

Большое направление достаточно ясно. Многомодельные шлюзы становятся плоскостями финансового контроля так же, как и прокси-серверы API. Параметр Cloudflare «Только BYOK» — это узкая функция, но она устраняет реальный режим сбоя: запрос, который технически работает, но нарушает предполагаемую модель выставления счетов.