Сравнение лимитов AI API: OpenAI, Anthropic, DeepSeek, DashScope, SiliconFlow (2026)

Rate limits определяют, сколько запросов и token ваше приложение может отправить через LLM API за минуту. Они сильно различаются между провайдерами — от пятиуровневой системы OpenAI до модели DeepSeek, основанной только на concurrency — и понимание этих различий критически важно для решений по routing в production.

Мы сравнили структуры rate limiting у OpenAI, Anthropic, DeepSeek, DashScope (Alibaba Cloud Model Studio) и SiliconFlow. Эта страница — справочник, который мы создали для настройки нашего собственного fallback routing и обновляем при изменении лимитов провайдеров.

Краткий обзор — таблица сравнения rate limits

Данные получены 30 июня 2026 г. OpenAI: developers.openai.com. Anthropic: platform.claude.com. DeepSeek: api-docs.deepseek.com. DashScope: alibabacloud.com. SiliconFlow: docs.siliconflow.cn.

Что такое rate limits API и почему они важны

OpenAI-совместимость означает, что провайдер предоставляет endpoint chat-completions, чей контракт запроса и ответа достаточно близок к API OpenAI, чтобы немодифицированный вызов OpenAI SDK работал после замены трёх значений: API key, base URL, название модели. Минимальная поверхность на практике —POST /v1/chat/completions с messages, model и потоковым ответом в форме OpenAI.

Rate limits ограничивают количество запросов (RPM) и token (TPM), которые ваша организация может отправить в API за единицу времени — обычно за минуту. GPU-ресурсы конечны: без лимитов один активный пользователь может заблокировать доступ для всех остальных.

При принятии решений по routing rate limits не менее важны, чем pricing. Провайдер, берущий $1/M token, бесполезен, если в пиковые часы он ограничивает вас до 10 RPM. Ключевые вопросы:

• Сколько одновременных пользователей может обслуживать моё приложение до появления ошибок 429?
• Как быстро восстанавливается доступ после срабатывания лимита?
• Можно ли повысить лимиты без корпоративного контракта?
• Учитываются ли кэшированные token в лимите?

Каждый провайдер отвечает на эти вопросы по-разному. Разберём подробно.

OpenAI: пятиуровневая система по совокупным тратам

OpenAI использует наиболее структурированный подход: шесть уровней (Free — Tier 5), определяемых суммой совокупных платежей. Каждый уровень открывает более высокие RPM и TPM для всех моделей.

Пороги квалификации уровней

Ключевые особенности:

• Лимиты на уровне организации и проекта. Все API key под одной организацией делят общую квоту. Проекты могут иметь собственные подлимиты.
• Разные лимиты по моделям внутри уровня. GPT-5.5 на Tier 1 имеет лимиты, отличные от GPT-4o на том же уровне. Тяжёлые модели ограничены сильнее.
• Shared limits для семейств моделей. Некоторые модели делят общий пул TPM — вызов любой модели семейства расходует общий бюджет.
• Доплата за длинный контекст. Модели с большим контекстным окном (GPT-5.5) имеют отдельные, более низкие rate limits для запросов с длинным контекстом.
• Автоповышение. При превышении порога совокупных трат — автоматический переход на следующий уровень.

Заголовки rate limit

OpenAI возвращает состояние rate limit в каждом ответе:

x-ratelimit-limit-requests: 60
x-ratelimit-remaining-requests: 59
x-ratelimit-reset-requests: 1s
x-ratelimit-limit-tokens: 150000
x-ratelimit-remaining-tokens: 149984
x-ratelimit-reset-tokens: 6m0s

Это упрощает client-side throttling — можно считывать оставшуюся ёмкость и замедляться до получения ошибки 429.

Источник: Документация OpenAI Rate Limits, получено 30 июня 2026 г.

Anthropic: единая модель уровней с учётом кэша

API Claude от Anthropic использует четырёхуровневую систему (Start, Build, Scale, Custom) с отличительной особенностью: кэшированные input token для большинства моделей не учитываются в лимите ITPM.

Структура уровней

Ключевые особенности:

• Раздельные лимиты input и output token. Anthropic разделяет TPM на ITPM (input tokens per minute) и OTPM (output tokens per minute), давая чёткую видимость ограничивающего измерения.
• Cache-aware ITPM. Только некэшированные input token и token создания кэша учитываются в ITPM. cache_read_input_tokens не учитываются. При 80% cache hit rate эффективная пропускная способность в 5 раз выше номинального ITPM.
• Алгоритм token bucket. Ёмкость пополняется непрерывно, а не сбрасывается в фиксированные интервалы. Короткие burst-нагрузки допускаются, если средняя скорость остаётся в пределах лимита.
• Acceleration limits. Даже в рамках уровня резкий скачок трафика может вызвать ошибки 429. Anthropic рекомендует наращивать трафик постепенно.
• Настройка на уровне workspace. Можно установить лимиты ниже уровня организации для контроля затрат.

Исключение: Claude Haiku 3.5 учитывает cache_read_input_tokens в ITPM. Все остальные модели исключают кэшированные чтения.

Подход с учётом кэша означает, что приложения, использующие prompt caching, получают эффективную пропускную способность значительно выше номинальных цифр.

Источник: Документация Anthropic Rate Limits, получено 30 июня 2026 г.

DeepSeek: модель на основе concurrency, без RPM/TPM

DeepSeek применяет принципиально другой подход: никаких RPM или TPM. Вместо этого — лимиты concurrency, максимальное количество одновременных запросов в обработке.

Лимиты concurrency

Ключевые особенности:

• Нет RPM или TPM. Можно отправлять любое количество запросов в минуту, пока не превышены одновременные соединения.
• Соединение = запрос в обработке. Запрос учитывается с момента отправки до завершения ответа. Streaming-ответы удерживают соединение на всё время передачи.
• На уровне аккаунта, не API key. Все API key под одним аккаунтом делят пул concurrency.
• Плавная деградация. При высокой нагрузке DeepSeek не отклоняет запросы, а замедляет их. Вы получаете keep-alive сигналы (пустые строки для non-streaming, : keep-alive SSE-комментарии для streaming).
• Таймаут 10 минут. Если inference не начался за 10 минут, соединение закрывается.
• Бесплатное расширение. Если 500/2,500 соединений недостаточно, можно запросить увеличение бесплатно через форму Feishu. DeepSeek подбирает лимит под реальные потребности.

Изоляция через user_id

DeepSeek поддерживает изоляцию по пользователям через параметр user_id:

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[{"role": "user", "content": "Привет!"}],
    extra_body={"user_id": "your_user_id"}
)

Для аккаунтов с расширенным concurrency каждый user_id получает собственный подлимит (500 для V4 Pro, 2,500 для V4 Flash), предотвращая монополизацию ресурсов одним пользователем.

Источник: DeepSeek Rate Limit & Isolation, получено 30 июня 2026 г.

DashScope (Alibaba Cloud): лимиты по моделям с самообслуживанием

DashScope применяет rate limits на уровне аккаунта, отдельно по каждой модели. Формальной системы уровней нет — есть default-лимиты, которые можно расширить через консоль.

Default-лимиты (характерные модели)

Ключевые особенности:

• Агрегация на уровне аккаунта. Все RAM-пользователи, workspace и API key под одним аккаунтом Alibaba Cloud делят квоту по каждой модели.
• Посекундное ограничение. Помимо RPM и TPM, DashScope применяет RPS (RPM/60) и TPS (TPM/60). Burst из 100 запросов за одну секунду может сработать, даже если минутный RPM не превышен.
• Stable > snapshot по лимитам. Использование alias latest или stable даёт более высокие лимиты, чем привязка к snapshot с датой (например, qwen-plus-2025-07-14).
• Самообслуживание. Можно увеличить временную квоту TPM прямо в консоли Model Studio. Увеличение вступает в силу немедленно и действует 30 дней.
• Batch API в обход лимитов. Batch API DashScope не подчиняется real-time rate limits — подходит для offline-обработки.

Источник: Документация Alibaba Cloud Model Studio Rate Limiting, получено 30 июня 2026 г.

SiliconFlow: уровни потребления с фиксированными лимитами бесплатных моделей

SiliconFlow использует систему уровней по месячным тратам в RMB с раздельной обработкой бесплатных и платных моделей.

Квалификация уровней

Rate limits по типам моделей

Ключевые особенности:

• Бесплатные модели: фиксированные лимиты. Лимиты бесплатных моделей не зависят от уровня потребления. Они статичны и относительно низки.
• Платные модели: зависят от уровня. Более высокие месячные траты разблокируют более высокие RPM и TPM для платных моделей.
• На уровне аккаунта, по моделям. Как и DashScope, лимиты применяются по модели и по аккаунту. Превышение лимита одной модели не влияет на другие.
• Автоповышение. При превышении порога месячных трат — немедленный переход на следующий уровень.

Источник: Документация SiliconFlow Rate Limits, получено 30 июня 2026 г.

Дерево решений: когда rate limits должны влиять на выбор провайдера

Rate limits должны влиять на выбор провайдера в следующих сценариях:

1. Высокая concurrency в реальном времени (чат-боты, coding-ассистенты): модель concurrency DeepSeek или высокий default RPM DashScope подходят лучше, чем OpenAI Tier 1.

2. Работа с длинным контекстом и повторяющимися промптами: cache-aware ITPM Anthropic даёт 5x+ эффективной пропускной способности при кэшировании системных промптов.

3. Пакетная/offline обработка: Batch API DashScope и OpenAI обходят real-time rate limits. Отсутствие RPM у DeepSeek тоже подходит для пакетных задач.

4. Стартапы с ограниченным бюджетом: бесплатные модели SiliconFlow имеют фиксированные, но рабочие лимиты. Бесплатное расширение DeepSeek позволяет масштабироваться без дополнительных трат.

5. Enterprise с предсказуемым высоким объёмом: Custom-уровень Anthropic и Tier 5 OpenAI предлагают максимальные лимиты, но требуют значительной истории трат. Самообслуживание DashScope может быть быстрее в получении.

Аспект fallback routing

Rate limits — основная причина для настройки multi-provider fallback routing. Когда провайдер A возвращает 429, приложение должно автоматически повторить запрос через провайдера B. TheRouter поддерживает provider/model routing и fallback при наличии живых product paths — настройка цепочки приоритетов означает, что ошибки rate limit на одном провайдере автоматически переключают на следующего.

Обработка ошибок 429: стратегии по провайдерам

Универсальная практика по всем провайдерам:

import time
from openai import OpenAI, RateLimitError

client = OpenAI(base_url="https://your-provider.com/v1", api_key="...")

def call_with_backoff(messages, max_retries=5):
    for attempt in range(max_retries):
        try:
            return client.chat.completions.create(
                model="your-model",
                messages=messages
            )
        except RateLimitError as e:
            wait = min(2 ** attempt, 60)
            print(f"Rate limit, ожидание {wait} сек...")
            time.sleep(wait)
    raise Exception("Превышено максимальное число попыток")

Часто задаваемые вопросы

В: У какого провайдера самые высокие rate limits «из коробки»?

У DeepSeek нет RPM или TPM — только concurrency: 500 (V4 Pro) и 2,500 (V4 Flash). Среди RPM-провайдеров DashScope по умолчанию предлагает до 1,200 RPM для Qwen-Plus и Qwen-Turbo.

В: Можно ли увеличить rate limits без перехода на enterprise?

Да. DeepSeek бесплатно расширяет concurrency по запросу. DashScope поддерживает самообслуживание для временного увеличения TPM. OpenAI автоматически повышает уровень по мере роста трат. Для Custom-уровня Anthropic нужно обращаться в отдел продаж.

В: Учитываются ли кэшированные token в rate limits?

Зависит от провайдера. Anthropic исключает cache_read_input_tokens из ITPM для большинства моделей — значительное преимущество для кэшированных нагрузок. OpenAI и DashScope учитывают все token. DeepSeek не имеет token-лимитов.

В: Как rate limits влияют на routing между несколькими провайдерами?

Rate limits — основной триггер для fallback routing. Когда провайдер возвращает 429, слой routing должен автоматически повторить через альтернативного провайдера. Комбинация провайдеров с разными моделями лимитов (OpenAI RPM + DeepSeek concurrency) даёт более широкую эффективную ёмкость. TheRouter поддерживает provider/model routing и fallback при наличии живых product paths.

В: Какой провайдер лучше для пакетной обработки больших объёмов?

DashScope и OpenAI предлагают Batch API, обходящие real-time rate limits. Модель concurrency DeepSeek тоже хорошо работает для пакетных задач из-за отсутствия RPM.

В: Как лимиты китайских провайдеров соотносятся с западными?

Китайские провайдеры (DashScope, SiliconFlow) при сопоставимом уровне трат обычно предлагают более высокий RPM по умолчанию. Default RPM DashScope 1,200 для Qwen-Plus превышает лимиты OpenAI Tier 1 для сопоставимых моделей. Платные уровни SiliconFlow предлагают до 10,000 RPM для языковых моделей.

Связанные ресурсы

• Руководство по fallback routing для LLM API — настройка multi-provider fallback для обработки ошибок rate limit
• Руководство по оптимизации затрат с OpenAI Prompt Caching — влияние кэширования на стоимость и эффективные rate limits
• Полное руководство по DeepSeek API — полное руководство по DeepSeek API с управлением concurrency
• Руководство по Aliyun Bailian API — настройка DashScope
• Руководство по routing бесплатных моделей SiliconFlow — бесплатный уровень SiliconFlow и routing
• Полное руководство по Anthropic Claude API — настройка Claude API с управлением rate limit
• Страница провайдера OpenAI — модели OpenAI в TheRouter
• Страница провайдера Anthropic — модели Anthropic в TheRouter
• Страница провайдера DeepSeek — модели DeepSeek в TheRouter