免费大模型，谁告诉你还剩多少，谁让你自己撞墙

用免费大模型的人早晚会碰到同一个问题：我到底还能调多少次。

不是「能不能调通」，那个我前几篇一直在测。是调通之后，白嫖的额度什么时候见底，一分钟能发几个请求，会不会跑着跑着突然被拦。

今天我把这个问过了一遍，两种办法：先看各家在响应头里给不给额度信息，再连续快发 8 个请求，看谁先把我拦下来。

结论是这么一句：10 家里只有 2 家会告诉你还剩多少。而卡得最死的那家，一个字都不说。

先说个昨天刚发生的事

测之前我照例先探活，然后看到 NVIDIA 那个 Nemotron-49B 返回了 410：

The model 'nvidia/llama-3.3-nemotron-super-49b-v1' has reached its end of life on 2026-08-26T09:00:00Z and is no longer available.

到期时间 2026 年 8 月 26 日 09:00，精确到秒。

两天前我复测的时候它还活着，虽然慢到 15 秒。我在那篇里给的建议是「把它挪去跑离线任务」。第二天它就下线了。

这事我得认，建议的保质期比我以为的还短。不过 NVIDIA 这个做法在这批供应商里算体面的：给了明确的 EOL 时间戳，而不是某天你调用时突然发现模型名不存在了。前几篇里 Groq 的 Llama-3.3、ModelScope 的 DeepSeek 都是后一种死法，报的是「模型不存在」，你根本不知道是自己写错了还是它没了。

谁会告诉你还剩多少

一次正常的调用，响应头里其实可以带很多信息。给不给，是各家自己的选择。

Groq 给得最规矩：

x-ratelimit-limit-requests: 1000
x-ratelimit-limit-tokens: 8000
x-ratelimit-remaining-requests: 999
x-ratelimit-remaining-tokens: 7912
x-ratelimit-reset-requests: 1m26.4s
x-ratelimit-reset-tokens: 659ms

请求数和 token 数分开计量，各自还带剩余量和重置倒计时。注意这两个重置节奏并不一样，请求数要等 1 分 26 秒，token 数 659 毫秒就回满。也就是说你可能 token 还够但请求数用完了，反过来也一样。

Mistral 给得更细：

x-ratelimit-limit-tokens-minute: 250000
x-ratelimit-remaining-tokens-minute: 249980
x-ratelimit-tokens-query-cost: 20
x-ratelimit-limit-req-minute: 4
x-ratelimit-remaining-req-minute: 3

它连「你这一次查询花掉了多少 token」都单独告诉你（query-cost: 20）。

但看那个 limit-req-minute：4。每分钟四个请求。token 给到 25 万，请求数卡在个位数。

剩下 8 家，响应头里一个字都没有。NVIDIA、OpenRouter、智谱、Cloudflare、Kimi、Cerebras、Gemini，全都不给。

你想知道自己还剩多少，只有一个办法：撞上去。

那就撞一次

我对还活着的几个入口连续快发 8 个请求，中间不等待，看谁先拦我。

Groq、OpenRouter、智谱、Cloudflare：8 个全过。这四个跑批量任务可以放心排队。

NVIDIA Ultra-550B：第 7 个开始报 503。

但这里要分清楚，它返回的是：

Service temporarily overloaded

这是过载，不是限流。两者性质完全不同：限流是「你超了配额」，过载是「我这会儿忙不过来」。写重试逻辑的时候这两种要分开处理，503 可以立刻重试，429 立刻重试只会接着撞墙。

Kimi：第 4 个就挂了。

返回是 429，里面写着：

request reached organization max RPM: 3

每分钟三个请求。第 4 个到第 8 个，连续五个全部被拒。

而它的响应头里，关于这个 3 什么都没说。

说了的那家反而宽松

最有意思的对比出在 Mistral 和 Kimi 之间。

Mistral 明明白白写着每分钟 4 个请求，我连发 8 个，它没拦我。

Kimi 什么都没写，我连发 8 个，它第 4 个就把我拦了。

标称严格的实际宽松，什么都不说的卡得最死。

这里我得补一句严谨的：Mistral 那 8 个请求里，第 5 个我这边 curl 报了超时。但我去看落盘的响应体，里面是完整的正常返回，带 id、model、usage 都有。说明服务端把这个请求处理掉了，是我这侧的超时判断问题，不能算它拦我。真正能说明问题的是另外 7 个都正常通过了。

所以准确的说法是：Mistral 标了 4 RPM，但这次没有严格执行。反过来讲，这也意味着它随时可能开始执行，你不能把「实测没拦」当成可以依赖的前提。

这些数字怎么用

要跑并发或者批量任务，走 Groq、OpenRouter、智谱、Cloudflare 这四个。8 连发无压力，排队跑没问题。

Kimi 只能串行，而且两次请求之间要留 20 秒以上。按 3 RPM 折算就是这个节奏。它当兜底可以，拿来跑批量必挂。

NVIDIA 要单独写 503 重试。它那个不是限流是过载，可以立刻重试，不需要退避等待。

重试逻辑必须区分 429 和 503。这是这次实测里最能直接落进代码的一条：429 要退避，503 可以立刻重试。混在一起用一套逻辑，要么白等，要么一直撞。

别把标称值当承诺。Mistral 标 4 实际不拦，这次是你占便宜；哪天它开始执行，你的服务就崩了。真要依赖某个额度，自己压一遍是唯一可靠的办法。

几句边界

这是一个账号、一个时间点的快照，2026 年 8 月 27 日。免费层的额度是各家最容易调整的东西，这些数字随时会变。

8 连发是个很轻的压力，只能测出「每分钟几个请求」这个量级的限制，测不出日额度、月额度，也测不出长时间高频调用会不会触发别的风控。我没有把任何一家的额度真正打穿，那样做对人家不厚道，对我这个账号也不划算。

Kimi 那条限流返回里带了账号和密钥的片段，我做了剔除，只留了限额那一句。

最后，NVIDIA Nemotron-49B 那个 EOL 提醒了我一件事：这类清单的保质期是以天计的。两天前我还在推荐它。你要是照着我前几篇配的，现在该把那一条摘掉了。