DashScope rate-limit fallback routing: Alibaba превращает 429 в модельную политику

DashScope rate-limit fallback routing больше не выглядит как мелкая обработка ошибок за ответами 429. Alibaba Cloud Model Studio описывает rate limits как account-level operational surface: RPM, TPM, short-burst protection, model-specific quotas, исключения для Batch API, retry через backup model, hourly monitoring, spending alerts и временное повышение TPM на 30 дней. Для команд, которые route Qwen и сторонние модели через DashScope, вывод простой: rate-limit policy должна жить в gateway, а не в одном SDK retry loop.

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

Страница Alibaba Cloud Model Studio о rate limits объясняет, что DashScope считает лимиты на уровне primary account. Calls от RAM subaccounts, workspaces и API keys объединяются. У разных моделей есть отдельные quota tables, но traffic внутри одной model family всё равно может конфликтовать, если несколько приложений делят один account и одинаковые workspace assumptions.

Docs разделяют несколько failure modes, которые многие клиенты сводят к одному 429. Requests rate limit exceeded или You exceeded your current requests list означает RPM pressure. Allocated quota exceeded или You exceeded your current quota указывает на TPM pressure. Request rate increased too quickly — отдельный случай: Alibaba описывает его как stability-protection trigger для внезапных bursts, даже когда общий RPM или TPM ещё не достиг табличного потолка. Страница также отмечает, что limits могут применяться на per-second RPS и TPS granularity, рассчитанной из per-minute limits.

Самая важная для operator часть — список mitigation steps от Alibaba. Docs советуют выбирать high-limit models вроде qwen-plus, когда это подходит; учитывать, что stable или latest aliases могут иметь более широкие limits, чем dated snapshots; снижать request frequency при RPM errors; сокращать prompts или ограничивать output при TPM errors; сглаживать bursts через queues и exponential backoff; переключаться на backup models, когда модель ограничена; дробить крупные jobs; использовать Batch API для non-realtime work; и запрашивать temporary TPM increases в console. Пример кода делает retry с qwen-plus-2025-07-28 на qwen-plus-2025-07-14 после 429.

Почему это важно для AI-инженерных команд

DashScope rate-limit fallback routing важен потому, что один provider account часто обслуживает несколько workloads: chat completions, coding agents, document processing, voice или multimodal experiments и внутренние eval jobs. Если всё это делит API key или workspace без routing policy, один bursty agent run может сделать обычный production chat похожим на ненадёжный provider.

Описанные failure modes требуют разных реакций. RPM pressure означает слишком много requests. TPM pressure означает слишком большой token consumption. Burst protection означает слишком резкий schedule. Наивный fallback, который отправляет каждый 429 в более дешёвую модель, может сохранить API shape, но потерять quality, context window, structured output, tool support или compliance constraints. Хуже того, он переносит traffic во второй model quota bucket, не исправляя burst pattern, который вызвал первую ошибку.

Model table усиливает этот вывод. Текущие DashScope listings показывают high-limit rolling aliases вроде qwen3.7-max, qwen3.7-plus и qwen3.6-flash рядом с dated snapshots с гораздо более низким RPM. Значит, model IDs — это не только capability labels; это capacity contracts. Команды, которые pin dated snapshots ради reproducibility, должны планировать более узкую realtime capacity или отправлять больше work в Batch API.

Взгляд со стороны роутинга и эксплуатации

Router/operator angle — классифицировать DashScope 429 до выбора fallback. Практичная policy должна воспринимать error reason как routing signal:

1. RPM pressure: queue, shed low-priority traffic или переключать только idempotent requests на совместимую backup model.
2. TPM pressure: сокращать input, снижать max_tokens, уменьшать reasoning или thinking budget либо route summaries перед повтором полной задачи.
3. Burst protection: добавлять jitter, сглаживать concurrency и не переносить весь spike сразу в другой model bucket.
4. Realtime vs batch: отправлять non-interactive jobs в Batch API, а не заставлять их конкурировать с interactive user traffic.
5. Temporary capacity: запрашивать 30-day TPM increase для известных campaigns или migrations, но фиксировать expiry date в routing plan.

Это меняет и observability. DashScope operators должны помечать каждый request workload class, workspace, model alias, versioned model ID, retry reason, fallback target и то, пришёл ли final response от rolling alias или pinned snapshot. Без такого ledger успешный fallback может скрыть, что одна product team расходует quota другой команды.

TheRouter users стоит переносить эти lanes в provider policy, а не размазывать их по application code. Начните с TheRouter docs по request routing concepts, затем сопоставьте это с прежними материалами DashScope workspace endpoint routing analysis и Qwen3.7-Plus default-tier routing analysis. Вместе они задают три части устойчивого DashScope route: endpoint/workspace, model tier и rate-limit behavior.

Что стоит проверить или попробовать пользователям TheRouter

Сначала разделите DashScope traffic по workload class, прежде чем добавлять больше backup models. Interactive chat, coding agents, eval batches, document extraction и media-adjacent jobs не должны делить один недифференцированный quota path. Если нельзя разделить accounts, разделите хотя бы keys, metadata, dashboards и retry budgets.

Затем явно опишите fallback compatibility. Backup model для qwen-plus может подойти conversational tasks, но быть небезопасной для structured-output routes, long-context analysis или tool-using agents. Храните required context window, structured-output support, tool policy, latency target и maximum acceptable cost рядом с каждым route.

Наконец, считайте temporary TPM increases operational debt. 30-day increase может быть правильным решением для launch, migration или eval campaign, но он должен создавать expiry reminder, cost review и post-event rollback plan. DashScope rate-limit fallback routing работает лучше всего, когда capacity, cost и model quality планируются вместе, а не обнаруживаются через 429 в production.