Promptra Team for provod.ai

Posted on Jul 31

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

#ai #llm #api #chatgpt

Workers AI умеет считать инференс на edge, и командам часто хватает этого одного факта, чтобы развернуть новый Worker. Только поддержки недостаточно: у той же модели есть путь, для которого Worker вообще не нужен — REST-вызов POST /accounts/{account_id}/ai/run/{model} прямо из существующего backend, с обычным Cloudflare API-токеном. Близость к пользователю сама по себе ничего не доказывает: пользу даёт не факт близости, а то, что она сокращает конкретную задержку на конкретном маршруте. Если размещение кода на edge её не сокращает, обычный backend остаётся правильным ответом, а новый 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» нельзя решить, глядя на список поддерживаемых моделей.

Два пути вызова, и почему второй ломает аргумент за Worker

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

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

Второй путь важнее для честного решения. Workers AI доступен по REST вообще без единого развёрнутого Worker. Любой внешний backend бьёт в POST https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/run/{model}, авторизуясь 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 сократит релевантную часть задержки для конкретного маршрута.

Как выглядит карта запроса «клиент—Worker—модель—ответ»

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

В 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.

export OPENAI_API_KEY="provod-key"
export OPENAI_BASE_URL="https://api.provod.ai/v1"

Формат такого подключения показан на странице 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, чтобы понять, что вообще переместилось.

// Worker-канарейка: подтверждаем binding, читаем cf-placement
export default {
  async fetch(request, env) {
    const r = await env.AI.run("@cf/meta/llama-3.1-8b-instruct", {
      prompt: "ping"
    });
    return Response.json({ ok: true, model: "@cf/…", out: r });
  }
};

# Backend-путь: тот же @cf/-идентификатор по REST, без Worker
curl -X POST \
  "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/ai/run/@cf/meta/llama-3.1-8b-instruct" \
  -H "Authorization: Bearer $CF_TOKEN" \
  -d '{"prompt":"ping"}'

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

Решающая таблица: edge или обычный backend

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

Ситуация на карте запроса	Сигнал из канарейки	Решение
`cf-placement` показывает `local-` и задержка релевантного хопа падает	измеримая польза размещения есть	edge-контур на Worker оправдан
Worker уже существует по другой причине, добавляется только `env.AI.run`	размещение не меняется, растёт удобство	binding как деталь, не как новый компонент
Выигрыш только на хопе Worker, инференс планируется в другой локации	польза не там, где сложность	оставить REST из backend
RPM или дневные Neurons упираются в потолок сценария	лимиты не подходят	обычный backend плюс пересмотр модели
Разницы задержек нет или она в пределах шума	нет эффекта размещения	обычный backend-контур

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

Чего это не решает

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

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

provod.ai — понятный расчётный контур для юридических лиц

Переведите 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.

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

FAQ

Нужен ли 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 всё равно решает не категория продукта, а карта твоего конкретного запроса.

Источники

Cloudflare, Workers AI bindings, accessed 2026-07-18 — developers.cloudflare.com/workers-ai/configuration/bindings/
Cloudflare, Workers AI REST API, accessed 2026-07-18 — developers.cloudflare.com/workers-ai/get-started/rest-api/
Cloudflare, Workers AI pricing, accessed 2026-07-18 — developers.cloudflare.com/workers-ai/platform/pricing/
Cloudflare, Workers AI limits, accessed 2026-07-18 — developers.cloudflare.com/workers-ai/platform/limits/
Cloudflare, Workers AI overview, accessed 2026-07-18 — developers.cloudflare.com/workers-ai/
Cloudflare, Workers AI models, accessed 2026-07-18 — developers.cloudflare.com/workers-ai/models/
Cloudflare, AI Gateway - Workers AI provider, accessed 2026-07-18 — developers.cloudflare.com/ai-gateway/usage/providers/workersai/
Cloudflare, Smart Placement, accessed 2026-07-18 — developers.cloudflare.com/workers/configuration/smart-placement/
Продуктовые факты provod.ai, owner-approved 2026-07-15

DEV Community