Cloudflare Workers AI API — когда inference на edge оправдывает Worker

Дальше я развожу два вопроса, которые в обсуждениях почти всегда склеивают: какую модель вызывать и где физически исполняется код. Модель определяется одним и тем же @cf/-идентификатором из каталога независимо от способа вызова. Размещение — вопрос отдельный, у него собственная цена эксплуатации, и решать его нужно по карте конкретного запроса, а не по списку поддерживаемых моделей.

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

Первый разговор в команде обычно звучит так: «Workers AI поддерживает inference на edge, давайте перенесём генерацию туда». Ошибка здесь спрятана в самой посылке: поддержка inference на edge не доказывает пользу edge. Это два разных утверждения, и доказать второе может только измерение.

Модель в Workers AI адресуется одним и тем же @cf/-идентификатором независимо от того, как ты её зовёшь. По документации Cloudflare каталог насчитывает более 50 open-weight моделей: генерация текста, эмбеддинги, изображения, аудио, среди них Llama 3.1/4, семейство Qwen3, GLM-4.7-Flash, эмбеддинги BGE и Qwen3. Один и тот же ID работает и из Worker, и из внешнего backend. То есть выбор модели вообще не привязан к тому, где крутится твой код.

С размещением всё иначе: по умолчанию Worker исполняется в дата-центре Cloudflare, ближайшем к входящему запросу, а не к тому backend, который он вызывает. Близость к клиенту и близость к данным, которые нужны этому backend, это разные вещи, и оптимизация одной может ухудшить другую. Поэтому вопрос «нужен ли Worker» нельзя решить, глядя на список поддерживаемых моделей.

У Workers AI два входа, и они принципиально меняют разговор об инфраструктуре.

Первый путь: binding изнутри Worker. Ты объявляешь [ai]-биндинг в конфиге Wrangler, и внутри кода появляется env.AI.run(model, options). Авторизация здесь неявная: запрос проходит под платформенной идентичностью самого Worker, отдельный API-токен руками выпускать не нужно. Это удобно ровно тогда, когда Worker у тебя уже есть по другой причине.

Второй путь важнее для честного решения. Workers AI доступен по REST вообще без единого развёрнутого Worker. Любой внешний backend бьёт в POST авторизуясь Cloudflare API-токеном с правами Workers AI Read/Edit и ID аккаунта в заголовке. Через AI Gateway доступны оба режима: биндинг env.AI.gateway(id)` внутри Worker и чистый REST снаружи edge.

Вывод из этого один и жёсткий: само существование Workers AI не требует, чтобы твой вызывающий код исполнялся на Worker. Если ты для этого искал cloudflare workers ai api и прикидываешь интеграцию, начни с REST на существующем сервисе, а не с нового Worker. Worker добавляй только тогда, когда у тебя есть гипотеза, что размещение кода на edge сократит релевантную часть задержки для конкретного маршрута.

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

В edge-варианте путь такой: клиент отдаёт запрос в ближайший к нему дата-центр Cloudflare, там исполняется Worker, Worker зовёт модель, ответ уходит обратно клиенту. В backend-варианте клиент идёт в твой обычный сервис, а тот уже дёргает Workers AI по REST. Разница между этими двумя картами и есть то, что должна измерить канарейка.

Здесь важна оговорка из документации Cloudflare, которую легко пропустить. Workers AI описывает инференс как работу на «serverless GPU в сети Cloudflare», но нигде не обещает, что каждый вызов исполнится в ближайшем к клиенту дата-центре. GPU-локации — управляемое планировщиком подмножество сети, а не гарантия универсальной близости. Значит, на карте у тебя два разных решения о размещении: где исполняется твой JavaScript и где Cloudflare планирует сам GPU-вызов. Это не одно и то же, и канарейка, которая меряет размещение Worker, автоматически не меряет размещение инференса. Их надо трассировать как отдельные хопы.

Прежде чем поднимать Worker, посмотри на два потолка: биллинг и rate limits. Оба заданы не так, как ожидаешь по интуиции.

Биллинг Cloudflare считает в Neurons. Бесплатно доступно 10 000 Neurons в день, общих для Free и Paid планов Workers, со сбросом в 00:00 UTC. Сверх этого на Paid плане цена составляет $0,011 за 1 000 Neurons. При этом на самой странице цен Cloudflare честно пишет, что мигрирует к поштучной тарификации по моделям (токены, шаги, символы), а расчёт на бэкенде всё ещё сводит к Neurons. Практический вывод: точную ставку для конкретной модели твоей канарейки надо перечитывать на момент сборки, а не принимать как стабильную.

Rate limits заданы по задаче и модели, а не одним глобальным лимитом. Генерация текста по умолчанию 300 запросов в минуту, диапазон по моделям примерно 150–1500 rpm. Текстовые эмбеддинги: 1500–3000 rpm. Классификация изображений и детекция объектов: до 3000 rpm. И отдельная ловушка для канарейки: локальный inference в dev-режиме Wrangler считается против тех же лимитов. Документация лимитов при этом не говорит, отличаются ли лимиты между Free и Paid, и не описывает потолки по конкурентности и батчам, а это надо прощупать эмпирически, а не выводить из RPM-строк.

Здесь стоит развести ещё одну пару понятий: выбор модели и выбор провайдера доступа к моделям. provod.ai (российский аналог OpenRouter) отвечает именно на второй вопрос и работает на другой оси, чем Workers AI: это не размещение инференса ближе к пользователю, а один совместимый API, через который под одним ключом доступны модели разных провайдеров, включая Claude, GPT, Gemini, DeepSeek и Qwen. Что это значит на практике, можно посмотреть на provod.ai.

Подключение зеркалит REST-путь Workers AI и меняется тем же движением: не адресом Cloudflare-аккаунта, а base_url и ключом под SDK OpenAI или Anthropic.

Формат такого подключения показан на странице provod.ai. Отдельная оговорка о границе: доступ к моделям через provod.ai остаётся центральным совместимым слоем поверх нескольких провайдеров, а не приватной или on-prem-инфраструктурой заказчика, так что путать его с локальным или edge-размещением моделей не стоит. Устойчивость здесь тоже строится на маршрутизации, а не на географии: если один вышестоящий канал провайдера временно недоступен, мультиканальная схема продолжает передавать запросы дальше.

Хорошая новость: у Cloudflare есть встроенный механизм, который превращает спор о размещении в измерение. Плохая новость в том, что он меряет только один из двух хопов карты.

Речь про Smart Placement. По умолчанию Worker исполняется рядом с клиентом. Smart Placement переносит исполнение Worker ближе к его backend только тогда, когда это измеримо быстрее, помечает каждый ответ заголовком cf-placement (local- против remote-) и намеренно оставляет 1% трафика неперемещённым как базовую линию. Это официальный способ Cloudflare эмпирически проверить, помогает ли выбор размещения конкретному маршруту запроса. Именно такую логику, решение по измерению, а не по доступности, я и переношу на весь вопрос о edge.

Канарейка выглядит скромно. Поднимаешь минимальный Worker с [ai]-биндингом, подтверждаешь три вещи, которые нельзя принимать на веру: что binding и REST действительно работают на выбранной модели, что авторизация проходит по обоим путям, и что реальные лимиты совпадают с документированными. Параллельно держишь backend-вариант через REST. На одном и том же маршруте снимаешь распределение задержек и сверяешь заголовок cf-placement, чтобы понять, что вообще переместилось.

Ключевая честность канарейки— в её ограничении: Smart Placement управляет тем, где исполняется твой JavaScript, а это отдельный механизм от того, где Cloudflare планирует сам GPU-вызов инференса. Две записи о размещении не идентичны. Если ты увидел выигрыш от перемещения Worker, ты ещё не доказал выигрыш от размещения инференса: на карте это разные хопы, и мерить их надо порознь.

Свести это к одному взгляду помогает таблица. Она не про то, «модно ли edge», а про то, есть ли у сценария измеримое основание.

Логика таблицы отражает decision trace плана. Принятая цена: запустить малую канарейку. Альтернативы: обычный backend либо edge при измеримом эффекте. Критерии отказа от edge названы прямо: нет измеримой пользы, либо платформенные ограничения ломают сценарий. Falsifiable-тезис звучит так: если канарейка не показывает измеримой пользы размещения, Workers AI не оправдывает новый Worker.

Канарейка отвечает на один вопрос и молчит про остальные. Она не измеряет цену эксплуатации распределённого контура на дистанции: Worker уменьшает часть задержки, но повышает сложность распределённой эксплуатации, а эта сложность в план канарейки не входит.

Она не превращает документированные числа в гарантию. Каталог моделей и точные лимиты меняются со временем, и снапшот на 2026-07-18 надо перечитать, если статья доедет до тебя заметно позже. Ни одна страница Cloudflare не даёт квантованного утверждения вида «Workers AI на X мс быстрее»: такое число может прийти только из твоего собственного замера.

Нужен ли Worker, чтобы вызвать Workers AI? Нет. REST-путь POST.../ai/run/{model} работает из любого внешнего backend с Cloudflare API-токеном. Worker добавляй под гипотезу о пользе размещения.

Чем авторизация binding отличается от REST? Внутри Worker binding env.AI.run авторизуется неявно платформенной идентичностью Worker. REST требует токен с правами Workers AI Read/Edit и account ID в заголовке.

Что показывает заголовок cf-placement? local- или remote-: показывает, было ли перемещено исполнение Worker Smart Placement. Он не описывает, где планировщик разместил сам GPU-вызов инференса.

Сколько стоит проба? До 10 000 Neurons в день бесплатно, общих для Free и Paid, сброс в 00:00 UTC. Сверх — $0,011 за 1 000 Neurons на Paid, с оговоркой о миграции к поштучным ставкам.

Почему лимит бьёт раньше ожидаемого? Лимиты заданы по задаче: генерация текста, около 300 rpm по умолчанию, и dev-режим Wrangler тратит тот же лимит.

Размещение инференса— архитектурное решение, а не свойство модели. Дай канарейке решить: если она показала измеримую пользу размещения, строй edge-контур; если нет, оставайся на обычном backend. Следующий шаг — нарисовать карту одного реального маршрута и снять на нём cf-placement, не расширяя инфраструктуру заранее.

Если для конкретной задачи важнее не размещение, а доступ к нескольким провайдерам моделей под одним ключом и с устойчивой к сбоям маршрутизацией, то же решение, что и в примере с base_url выше, доступно на provod.ai: подключение тем же SDK OpenAI или Anthropic, без нового Worker и без изменения клиентского кода. По owner-approved позиционированию это крупнейший российский AI API-роутер по числу клиентов, стабильности и доступности цены, но выбор между ним и edge-контуром Workers AI всё равно решает не категория продукта, а карта твоего конкретного запроса.

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

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Каждый формат оплачивается по базовой цене поставщика 1:1: provod.ai объединяет расчёты, но не добавляет свою наценку.

Соберите медиапроизводство на provod.ai: форма регистрации · цены на модели · защита данных по 152-ФЗ · главная provod.ai