Кратко

  • Документация GroqCloud измеряет пропускную способность в восьми названных единицах на уровне организации, а затем отправляет каждого клиента в настройки его собственной учётной записи за действующим числом: публичная страница является соглашением об измерении прежде, чем быть потолком.
  • Два разных сигнала отказа соответствуют двум разным причинам — 429 при превышении измеренной скорости, 498 при недоступности ёмкости Flex, — и документ, способный превратить любой из них в договорное обязательство, в число полученных для этого обзора страниц не вошёл.

Лимит — это соглашение об измерении прежде, чем число

Страница лимитов скорости начинается с перечисления того, что считается, а не того, что разрешено. Сохранённый фрагмент гласит: «Rate limits are measured in: RPM: Requests per minute RPD: Requests per day TPM: Tokens per minute TPD: Tokens per day ASH: Audio seconds per hour ASD: Audio seconds per day ITPM: Input tokens per minute OTPM: Output tokens per minute.»

Этот список сообщает больше, чем одна цифра пропускной способности. Восемь измерений вместо одного означают, что у оболочки восемь стен. Две из них выражены в аудиосекундах, что указывает: речевые модели считаются по другим часам, нежели текстовые. Ещё две разделяют учёт токенов на входные и выходные, и это существенно, поскольку нагрузки с преобладанием подсказок и нагрузки с преобладанием генерации расходуют разные бюджеты. И две являются суточными, а не минутными: всплеск может быть выдержан в коротком горизонте и всё же исчерпать день.

Та же страница фиксирует уровень агрегации и правило разрешения ничьей собственными словами: «Rate limits apply at the organization level, not individual users. You can hit any limit type depending on which threshold you reach first.» Там же сказано: «Cached tokens do not count towards your rate limits» — реальная уступка для тех, кто повторяет подсказки со стабильным префиксом.

Сложите эти три утверждения, и практическая форма ограничения проявится. Десять сервисов, пять команд и один пакетный пересчёт под единой организацией делят одну оболочку. Связывающей оказывается та стена, которая сдастся первой, и ни одна опубликованная страница не говорит конкретному оператору, какая именно, потому что чисел там нет.

Действующее число передано на страницу за аутентификацией

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

Публичным остаётся соглашение вместе с указанием, куда идти. Команда может узнать единицы, уровень агрегации и правило разрешения ничьей из открытой сети. Свой собственный потолок из открытой сети она узнать не может, и третья сторона, оценивающая сервис, — аналитик по закупкам, журналист, конкурент, готовящий аргумент о замене, — тоже.

Один тариф публикует базу, остальные лимиты лишь описаны как более высокие

Каталог моделей — место, где числа действительно появляются, и оно аккуратно очерчивает их рамки: «Need higher rate limits? Upgrade to Developer plan to access higher limits, Batch and Flex processing, and more. Note that the limits shown below are the base limits for the Developer plan, and higher limits are available for select workloads and enterprise use cases.»

Отсюда следуют три вещи. Опубликованная таблица является нижней границей для одного тарифа, а не потолком сервиса. Более высокие лимиты описаны как существующие для неназванных избранных нагрузок и корпоративных случаев, что делает их результатом переговоров, а не опубликованным условием. И формулировка «base limits» допускает различие, не называя его измерений.

Эта уступка объясняет, почему важен документ о ценах и почему его молчание является находкой. Сохранённая для этого обзора страница цен — текст позиционирования: «Groq is the premier neocloud for fast inference … Fast or affordable is no longer a tradeoff. We're building hundreds of megawatts of capacity, with many more on the way» — без таблицы тарифов, без значений лимитов и без описания уровней обработки в прочитанном тексте. Тот, кто попытается установить по публичным страницам Groq, какой тариф покупает какую оболочку, не закроет вопрос на этой странице. Соответствие тарифа и лимита документами этого набора не установлено.

Потолок движется вместе с моделью, а модель может двинуться под вами

Поскольку лимиты представлены построчно по моделям, оболочка по построению является модель-специфичной. План ёмкости, выраженный одним числом, оказывается недоопределённым ещё до того, как что-либо пойдёт не так: смените обслуживаемую модель, и форма ограничения изменится.

В том виде, в каком таблица отображается, в таблице тарифа Developer среди прочих строк указана openai/gpt-oss-120b — 250K токенов в минуту и 1K запросов в минуту. Это значение передано из отображения поставщиком одной строки таблицы, а не прочитано здесь как полная таблица, и годится как иллюстрация формата, а не как спецификация сервиса.

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

Два кода отказа несут два разных смысла

Страница ошибок отдаёт видимую клиенту половину одной фразой: «429 Too Many Requests: Too many requests were sent in a given timeframe. Implement request throttling and respect rate limits.» Согласно тому, как отображается страница лимитов, 429 — единственный случай, когда выставляется заголовок retry-after, а заголовки лимитов, доступные клиентам, включают x-ratelimit-limit-requests для запросов в сутки и x-ratelimit-limit-tokens для токенов в минуту. Эти заголовки — единственное доказательство во время исполнения, которое приложение получает о том, к какой стене оно приближается.

Затем документация Flex Processing публикует второй, совершенно иной сигнал: «Flex Processing is a service tier optimized for high-throughput workloads that prioritizes fast inference and can handle occasional request failures. … If flex capacity is unavailable, requests will fail quickly with status 498 and error capacity_exceeded.» Сообщается, что Flex предлагает в десять раз более высокие лимиты скорости, чем уровень по требованию, по той же цене, для платящих клиентов, а страница ошибок перечисляет 498 как особый статус, запрос при котором «не будет обработан», без списания за запросы, возвращающие серверные коды ошибок.

Прочитанные вместе, 429 и 498 отвечают на разные вопросы. 429 говорит, что вызывающая сторона превысила измеренную скорость и должна замедлиться. 498 говорит, что у поставщика не нашлось ёмкости для этого класса работы и запрос вообще не предпринимался. Политика повторов, написанная только против 429, будет считать 498 шумом, немедленно повторит попытку и создаст нагрузку, которая не может увенчаться успехом; честное поведение клиента при 498 — это решение об отсрочке, а не расчёт выдержки.

Документация Batch обостряет это различие: она описывает «an asynchronous batch of requests to Groq with 50% lower cost, no impact to your standard rate limits, and 24-hour to 7 day processing window». Batch не поднимает синхронный потолок. Он выводит работу из этого потолка, меняя временной контракт, по которому работа приобретается, — более дешёвый и медленный маршрут в обход стены, остающейся на месте.

Документ, который превратил бы это в обязательство, не читался

Единственная страница набора, говорящая в регистре обязательства, — условия обслуживания, и её язык представляет собой отказ от гарантий, ограниченный сайтом: «YOUR USE OF THE WEBSITES (INCLUDING ANY THIRD-PARTY MATERIALS) IS AT YOUR SOLE RISK. THE WEBSITES … ARE PROVIDED ON AN “AS IS” AND “AS AVAILABLE” BASIS. … GROQ MAKES NO WARRANTY THAT (A) THE WEBSITES WILL MEET YOUR REQUIREMENTS, (B) THE WEBSITES WILL BE UNINTERRUPTED, TIMELY, SECURE, OR ERROR-FREE.» С той же страницы передаётся и ограничение ответственности в сто долларов США по претензиям, связанным с сайтами.

Здесь необходимо чётко обозначить две границы. Первая: этот фрагмент регулирует сайты. Переносить отказ от гарантий по сайтам на обязательство о доступности API было бы категориальной ошибкой, и настоящая статья её не совершает. Вторая: ни полный документ условий, ни заказ, ни корпоративный договор, ни отдельное соглашение об уровне обслуживания для этого обзора не получены. Отсутствие процентов доступности и сервисных кредитов в одном фрагменте — свидетельство о фактически прочитанном тексте и ни о чём больше.

Класс документа, который решил бы вопрос, существует ли привязанное к GroqCloud обязательство о доступности с мерой возмещения, — это подписанный документ об уровне обслуживания или заказ: бумаги, которые скорее согласуют, чем публикуют, и первое, что следует запросить серьёзному покупателю.

Что команда может планировать, а что нет

Поверхность управления обыденна и весома. Инженерные команды определяют параллелизм, устанавливают бюджеты повторов и пишут клиентскую выдержку исходя из опубликованного лимита, который читают как операционную оболочку. Текст, который их действительно связывает, — процедура изменения, вариация по моделям, уровни отсрочки и наличие или отсутствие обязательства с кредитами, — лежит в документах, которые почти никогда не читают рядом с таблицей лимитов.

Когда число из справочного центра потребляется как договорный потолок, следуют три отказа подряд. Нагрузка рассчитывается по числу, которое может сдвинуться. Логика повторов настраивается под семантику ошибки, которую никто не проверял. И разрыв проявляется на пике спроса как ограничение, которого модель ёмкости команды не содержала, — именно тогда, когда у очереди меньше всего запаса, чтобы его поглотить.

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

Все семь документов получены 19 октября 2026 года; ни один не содержал даты публикации или последнего изменения, поэтому ни одному описанному здесь лимиту нельзя приписать дату вступления в силу.

О самой организации см. запись справочника BTW о Groq Inc..