Гайд · TNWS AI
Почему Cloudflare Workers AI возвращает 429 и как проверить лимит
Актуальные rate limits Workers AI по task type и моделям, учёт локального inference, измерение RPM, backoff с jitter и корректная диагностика 429.
Что именно решаем
Материал отвечает на запрос «почему Cloudflare Workers AI возвращает 429». Фактическая часть сверена 12 сентября 2026 года с официальной документацией Cloudflare. Здесь нет обещаний о цене, квоте или постоянной доступности модели: эти параметры проверяют в своём аккаунте и актуальном Workers AI Models catalog перед запуском.
Применимость
Workers AI GA. Значения ниже сверены 12 сентября 2026 года; перед нагрузочным тестом их повторно проверяют на странице Limits, потому что отдельные модели и beta-функции имеют свои ограничения.
Результат считается готовым не после первого HTTP 200, а после проверки формального ответа и контрольного бизнес-условия. Зафиксируйте дату теста, полный model ID, способ вызова — binding, native REST или OpenAI-compatible endpoint — и версии Wrangler/SDK. Это позволяет отличить изменение кода от обновления сервиса.
Проверенные параметры
- Default limit для Text Generation указан как 300 requests per minute.
- Default limit для Text Embeddings указан как 3000 requests per minute, но
@cf/baai/bge-large-en-v1.5имеет 1500 RPM. - Inference в local mode через Wrangler тоже учитывается в лимитах.
- Beta models могут иметь более низкие limits; для некоторых frontier models опубликованы отдельные per-account, per-model значения.
Не переносите параметры между моделями автоматически. Text generation, embeddings, reranking и batch имеют разные формы входа и результата. Значения <ACCOUNT_ID>, <MODEL_ID> и <GATEWAY_ID> в шаблонах заменяют фактическими идентификаторами, а не догадками.
Контрольный пример
Вход: Ступенчатая нагрузка 1, 2, 4, 8 RPS с одной моделью, одинаковыми prompt и max_tokens, включая отдельный local-mode прогон.
Ожидаемый результат: Зафиксирована граница появления 429; клиент сглаживает скорость и ограничивает повторы, а отчёт не смешивает task-type limit с отдельным limit модели.
Сохраните очищенное тело запроса, HTTP-код, Cloudflare success, массив errors, request ID, model ID и время выполнения. API token, персональные данные и закрытые документы в тестовый артефакт не попадают. Для модельного ответа разделяйте технический PASS и смысловой PASS: корректный JSON может содержать неверный факт.
Настройка по шагам
- Создайте отдельный тестовый проект. Секрет передайте через
CLOUDFLARE_API_TOKEN; Account ID можно хранить как конфигурацию, но токен нельзя помещать во frontend, репозиторий или скриншот. - Откройте актуальную карточку модели и подтвердите требуемую функцию. Поддержка обычного inference не означает автоматически JSON Mode, function calling, batch или prompt caching.
- Выберите один интерфейс для первого теста. Для Worker binding имя в Wrangler должно совпадать с полем
env; для REST проверьте Account ID, endpoint и Bearer header; для OpenAI SDK — base URL. - Отключите автоматические retry на диагностическом запуске. Выполните минимальный пример и запишите исходную ошибку целиком после маскировки токена.
- Проверьте Cloudflare envelope и предметный контракт. Пустой result,
success=false, неполный массив или неверный тип поля — это FAIL даже при успешном транспорте. - Добавьте отрицательный тест: неверный тип, отсутствующее обязательное поле, неизвестный resource либо превышенный локальный лимит. Приложение должно отказать безопасно и не повторять неисправимый запрос.
- Прогоните 20–50 обезличенных случаев реального распределения: кириллицу, пустые строки, длинный вход, граничные числа и ожидаемые отказы. Только затем включайте concurrency, cache и retry.
Рабочий шаблон
for attempt in range(6):
r=requests.post(URL,headers=HEADERS,json=payload,timeout=90)
if r.status_code!=429: r.raise_for_status(); break
time.sleep(min(30,2**attempt)+random.random())
else: raise RuntimeError('retry budget exhausted')
Шаблон показывает проверяемый контракт, но не заменяет production-обвязку. Добавьте timeout, ограничение размера тела, централизованное удаление секретов из логов, correlation ID и allowlist ресурсов. Любая операция, меняющая данные, требует отдельной авторизации и идемпотентности.
Готовый промпт для проверки
Выполни только одну задачу на данных ниже.
Не добавляй факты, которых нет во входе.
Если обязательного значения нет, верни MISSING_FIELD.
Соблюдай указанный формат буквально, без Markdown и пояснений.
Вход: {CONTROL_INPUT}
Ожидаемые маркеры: {EXPECTED_MARKERS}
Промпт — воспроизводимый fixture, а не средство безопасности. JSON Schema, проверка типов, авторизация tool arguments и фильтрация результата выполняются кодом. Инструкцию из загруженного документа нельзя повышать до системной команды.
Как проверить результат
- task type определён
- model-specific limit проверен
- RPS измерен
- jitter включён
- локальные вызовы учтены
Создайте журнал case_id | input_hash | model | parameters | expected | actual | pass. Для latency отдельно измеряйте time to first token, полное время p50/p95 и процент ошибок. Сравнивайте варианты на одинаковых входах, с одной моделью и фиксированными параметрами.
Нагрузку повышайте ступенчато от одного параллельного запроса. Длина входа и максимальный вывод остаются постоянными. Иначе нельзя понять, вызвано ухудшение rate limit, длиной prompt или моделью. Повторный прогон после прогрева не смешивают с холодным baseline.
Типичные ошибки и что не делать
- Применять 300 RPM ко всем task types и моделям.
- Не учитывать вызовы из
wrangler dev. - Повторять 429 немедленно и без retry budget.
Не повторяйте 400, 401, 403 и 404 как временные ошибки: исправьте payload, токен, permissions или resource ID. Для 429 и отдельных 5xx используйте ограниченный retry budget, exponential backoff и jitter. Бесконечные повторы усиливают перегрузку.
Не доверяйте тексту модели как разрешению на оплату, удаление или публикацию. Tool name проверяют по allowlist, arguments — по схеме, объект — по ACL текущего пользователя. Чувствительные операции требуют явного подтверждения и audit trail без секретов.
Регрессионная проверка
После смены модели, prompt, JSON Schema, Wrangler, SDK, binding или gateway повторите весь набор. Сравнивайте техническую успешность, бизнес-PASS, p95 latency и число ручных исправлений. Улучшение одной метрики не доказывает готовность к релизу.
Для A/B используйте стабильное разбиение по case_id и одинаковые входы. Сохраняйте дату проверки: Cloudflare обновляет модели, функции и limits, поэтому пример нельзя считать вечной гарантией поддержки.
FAQ
Достаточно ли HTTP 200?
Нет. Проверьте success, errors, форму result и предметный критерий.
Где хранить API token?
Только на backend — в переменной окружения или менеджере секретов.
Можно ли взять любое имя модели?
Нет. Используйте полный актуальный model ID из Workers AI Models catalog.
Нужно ли повторять тест после обновления?
Да. Смена модели, Wrangler, SDK, prompt или схемы требует regression-прогона.
Официальный источник
Частые вопросы
Достаточно ли HTTP 200?
Нет, проверьте success, errors и предметный результат.
Можно ли хранить API token во frontend?
Нет, постоянный токен остаётся на backend.
Нужно ли проверять model ID?
Да, используйте актуальный Workers AI Models catalog.
Нужен ли отрицательный тест?
Да, он проверяет безопасный отказ.
Читайте также
Как настроить function calling в Cloudflare Workers AI безопасно
Traditional function calling в Workers AI: описание tools, JSON-аргументы, allowlist, schema validation, авторизация и двухшаговый вызов внешнего API.
Как подключить AI Gateway к Cloudflare Workers AI
Маршрутизация Workers AI через AI Gateway: cf-aig-gateway-id, Bearer token, прежний ai/v1 endpoint, проверка логов и безопасная передача metadata.
Как подключить OpenAI SDK к Cloudflare Workers AI
OpenAI-compatible endpoint Workers AI: правильный baseURL с Account ID, Cloudflare API token, chat.completions, responses и embeddings без ложной совместимости.
Комментарии
Пока тихо. Скажите первое слово