要約

  • GroqCloud の自社文書は、八つの名称付き単位で組織単位のスループットを計測し、実際に適用される数値は各顧客自身のアカウント設定ページへと送り返す。公開ページは上限である前に計測の約束事である。
  • 二つの異なる失敗信号が二つの異なる原因に対応している。計測されたレートを超えたときは 429、Flex の容量が得られないときは 498 であり、どちらかを契約上の義務に変えうる文書は今回参照したページ群には含まれていない。

制限とは、数値である前に計測の約束事である

レート制限のページは、何を許すかではなく何を数えるかを最初に列挙する。保持された抜粋はこう記す。「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 は単位、集約の単位、裁定規則、キャッシュ済みトークンの除外、一つのプランの基礎境界、モデルごとの構造、そしていずれか一方にのみ顧客向け指針が付く二つの失敗コードを公表している。読まれたページにおいて、アカウントごとの数値、変更手続き、全プラン分のモデル別数値表、救済を伴う可用性コミットメントは公表されていない。七つの文書はいずれも 2026 年 10 月 19 日に取得された。いずれにも公開日や最終更新日の記載がなかったため、本稿が述べるいかなる制限にも発効日を付すことはできない。

エンティティ自体については、Groq Inc. の BTW ディレクトリ項目を参照されたい。