Cloudflare AI Gateway: как не оплачивать чужие запросы

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

Cloudflare AI Gateway: кто платит за запрос

AI Gateway умеет отправлять запрос к модели по нескольким маршрутам авторизации. Учётные данные — это ключ, по которому внешний провайдер модели определяет счёт для оплаты.

До этого изменения порядок был простым. Сначала Cloudflare искала ключ провайдера в самом запросе. Если его не было, использовала Bring Your Own Key, или BYOK, сохранённый в шлюзе под псевдонимом default. Когда не находилось ни одного из этих ключей, Cloudflare могла подставить собственные учётные данные через Unified Billing и списать стоимость из кредитного баланса аккаунта Cloudflare.

Такой резервный вариант полезен, если платить должна Cloudflare. Но он превращается в утечку бюджета, когда запрос принадлежит клиенту, который обязан передать собственный ключ OpenAI, Anthropic, Google или другого провайдера.

Теперь для трафика сторонних провайдеров этот третий шаг можно убрать. Включите для шлюза Require provider credentials — в API настройка представлена как byok_only: true — и запрос без подходящих клиентских учётных данных остановится с HTTP 400. То же ограничение можно применить к отдельному запросу заголовком cf-aig-no-wholesale: true. Полный порядок проверки учётных данных и оба способа управления описаны в документации Cloudflare.

Проще всего представить три возможных источника оплаты как очередь:

1. Ключ из запроса. Клиент передаёт ключ провайдера вместе с вызовом. AI Gateway пересылает его без изменений, поэтому провайдер выставляет счёт аккаунту, которому принадлежит ключ.
2. Ключ, сохранённый в шлюзе. В запросе нет ключа провайдера, и AI Gateway берёт ключ из Cloudflare Secrets Store. Для конечных точек Unified Billing подходящий сохранённый ключ должен иметь псевдоним default.
3. Cloudflare Unified Billing. Если нет ни клиентского, ни подходящего сохранённого ключа, Cloudflare может использовать свои управляемые учётные данные и списать кредиты с аккаунта Cloudflare.

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

Расходы теперь отсекаются до сверки счетов

При покупке кредитов для Unified Billing взимается комиссия 5%. В примере Cloudflare всё предельно ясно: за $100 кредитов списывается $105, при этом стоимость инференса у самого провайдера передаётся без наценки.

Теперь рассмотрим клиентский процесс. Если задача должна выполняться за счёт аккаунта провайдера, принадлежащего клиенту, но его ключ пропал, использование модели на $100 может списаться из кредитов оператора в Cloudflare. Пополнение этих кредитов обойдётся в $105. В аккаунте клиента у провайдера такого резервного расхода не будет, а оператору придётся оплачивать все $105 и затем доказывать, чей запрос создал затраты.

Главная проблема не в комиссии 5%. Важно то, что вся нагрузка стоимостью $100 ушла не в тот бюджет. Дополнительные $5 лишь увеличивают цену ошибки.

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

Кому нужен этот режим

Агентству с клиентскими автоматизациями

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

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

SaaS-команде, которая принимает ключи клиентов

SaaS-продукт, работающий с ключами провайдеров от клиентов, может трактовать HTTP 400 как признак незавершённой настройки. Пользователю можно сразу сообщить, что ключ провайдера отсутствует, не допуская запрос к собственному пулу кредитов Cloudflare.

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

Платформенному инженеру, который начинает с одного маршрута

Заголовок запроса позволяет развернуть изменение в минимальном масштабе. Добавьте cf-aig-no-wholesale: true к одному маршруту стороннего провайдера, проверьте поведение без ключа и подключите ошибку к мониторингу до изменения всего шлюза.

Приоритет работает только в сторону ужесточения. Заголовок запроса может сделать разрешающий шлюз строже. Но запрос не сможет передать false и ослабить шлюз, в котором уже включена настройка Require provider credentials. Cloudflare описывает эти ограничения как суммирующиеся.

FinOps-специалисту, который разделяет плательщика и бюджет

Эта настройка определяет, какому аккаунту разрешено платить. Лимиты расходов AI Gateway определяют, сколько можно потратить. Это разные механизмы, и проверять их нужно независимо.

Лимиты расходов могут учитывать запросы как с BYOK, так и через Unified Billing, если Cloudflare известна цена модели. Их можно задать по модели, провайдеру или метаданным. Но стоимость рассчитывается приблизительно, а для точной сверки Cloudflare рекомендует кабинет провайдера. Считайте правило обязательных учётных данных границей ответственности за оплату, а потолок расходов проверяйте отдельно.

Как включить режим без неожиданного простоя

1. 1

   Определите плательщика для каждого маршрута

   Отделите трафик сторонних провайдеров от Workers AI. Для каждого стороннего маршрута зафиксируйте, должен ли ключ провайдера приходить в запросе или браться из сохранённого в шлюзе ключа default. Не включайте режим fail-closed, пока эта ответственность не определена явно.

2. 2

   Выберите минимальную область действия

   Для одного маршрута передавайте cf-aig-no-wholesale: true. Для всего шлюза откройте AI > AI Gateway, выберите шлюз, перейдите в Settings, включите Require provider credentials и подтвердите изменение. В запросе обновления шлюза через API используется byok_only: true.

3. 3

   Проверьте оба допустимых способа авторизации

   Отправьте тестовый запрос с ключом провайдера. Затем отправьте запрос, который использует сохранённый ключ default. В обоих случаях убедитесь, что расход появился в нужном аккаунте провайдера. Если конечная точка Unified Billing рассчитывает на ключ production, сначала исправьте псевдоним.

4. 4

   Намеренно уберите ключ

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

5. 5

   Назначьте ответственного и очередь для ошибки

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

Честно о компромиссах

Вместо незаметного резервного маршрута эта настройка даёт явный сбой. Если Unified Billing намеренно служил способом сохранить доступность, после включения правила сторонние запросы лишатся этой подстраховки. Просроченный или недействительный ключ из запроса тоже будет передан провайдеру, а не заменён другим платёжным маршрутом, поэтому внешний провайдер по-прежнему сможет отклонить запрос.

Главное исключение — Workers AI. Такие запросы не используют учётные данные сторонних провайдеров, остаются разрешёнными и продолжают работать с отдельным режимом оплаты Workers AI. Включение byok_only не означает, что Cloudflare вообще больше ничего не сможет списать.

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

Что сделать в понедельник

Выберите один маршрут стороннего провайдера, который оплачивает клиент. Сначала добавьте ограничение на уровне запроса, затем в тестовой среде проверьте сценарий без учётных данных. Успешный тест — это контролируемый HTTP 400 без работающего резервного маршрута. Направьте ошибку в очередь команды интеграции или платформы, назначьте человека, который восстановит ключ, и только после этого рассматривайте включение правила для всего шлюза.

Если команда намеренно проводит весь сторонний трафик через Cloudflare Unified Billing, оставьте правило выключенным. Если используется только Workers AI, настройка не изменит этот счёт. Если платить должны клиентские аккаунты или аккаунты подразделений у провайдера, не откладывайте: проверьте сценарий сбоя до того, как его неожиданно проверит следующая ротация ключей.

Больше прикладных разборов подобных изменений — в рассылке.