摘要

  • 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”——在所读文本中既无计划表，也无限制数值，更无处理层级说明。任何试图仅凭公开页面确定哪个计划对应哪一段边界的人，都无法在这一页上结案：计划与限制的对应关系，并未由本组文档确立。

上限随模型移动，而模型也会在你脚下移动

由于限制按模型逐行呈现，这个边界在结构上就是模型专属的：换掉所服务的模型，约束的形状随之改变，用单一数字表述的容量规划在出错之前就已欠缺规定。

按其呈现方式，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 日取得；它们都没有标注发布或最后修改日期，因此本文描述的任何限制都无法附上生效日期。

关于该实体本身，参见 BTW 名录中的 Groq Inc. 条目。