DraftReviewPublishedArchived

8 天前最快的免费模型,今天开始收费了

八天前我测过 21 个免费大模型入口,当时最快的是 Cerebras 上的 gpt-oss-120b,593 毫秒,我推荐它当首选。今天拿同一份脚本再跑一遍,它返回的是「Payment required to access this resource」。同在 Cerebras 的另一个入口更干脆,模型已归档。顶上来的是 Groq,545 毫秒,成了新的最快,而它跑的正是同一个模型。另外还有件事:我的脚本第一轮把这两个明确的死亡判成了「空返回」,原因值得所有做可用性监控的人看一眼。

By Joker2026/08/255 min

八天前我测了 21 个免费大模型入口,写过一篇,说当时有 9 个能用。那篇里速度最快的是 Cerebras 上的 gpt-oss-120b,593 毫秒,我明确推荐它当首选。

今天我拿同一份脚本、同一道题,又跑了一遍。

Cerebras 那个入口现在返回的是这么一句:

Payment required to access this resource. Visit your billing tab.

要付费了。

八天,账本变成这样

可用 9 个变成 8 个,限流 5 个变成 3 个,已死或报错 7 个变成 10 个。

数字上看只少了一个,但成分换了。

出局的是 Cerebras 的两个入口。而且是两种完全不同的死法。

gpt-oss-120b 撞的是付费墙,错误码 payment_required,意思是这个 key 的免费额度到头了,想继续用得去账单页。

zai-glm-4.7 是另一回事,返回:

Model zai-glm-4.7 is archived and unavailable for the organization.

错误码 model_archived。这个模型被归档了,对这个组织来说已经不存在。

一个是「你还能用,但要给钱」,一个是「这东西没了」。做备份方案的时候这两种要分开对待:前者充钱就能复活,后者充多少钱都没用。

顶上来的是 Groq。

八天前 Groq 的 gpt-oss-120b 在限流,我当时把它归进「限流 5 个」那一档,还写了一句「它限流是常态但恢复也快」。今天它恢复了,545 毫秒,是全场最快的一个。

也就是说,速度榜易主了,而且新科第一和退位的那个,跑的是同一个模型

还有两个变化容易被忽略

NVIDIA Nemotron-49B 慢了将近四倍。八天前 4058 毫秒,今天 15574 毫秒。它还活着,返回也正常,但如果你把它放在有人等着的地方,用户体验已经是另一回事了。

「能用」和「好用」在这里不是一回事,这话我上篇写过一次,这次它自己又演了一遍。

Mistral 上的 GLM-5.2 从「限流」变成了「订阅层级不支持」。

八天前它报的是限流,我归到「明天可能就好了」那一档。今天它报的是:

This model is not available in your subscription tier

这个性质变了。限流是等一等的事,订阅层级不支持是等不来的。当时那个判断是错的,或者说,当时那个错误信息掩盖了真实情况。

我的脚本把这两个死亡判成了「空返回」

这部分是这次复测里我自己最意外的地方。

第一轮跑完,Cerebras 那两个入口显示的不是「已死」,是「空返回」,就是那种拿到了 200、但内容是空的状态。我当时以为是限流的另一种表现,直到单独去看原始响应,才发现人家早就把话说明白了。

原因是各家的错误 JSON 结构不一样。

OpenAI 兼容的常见写法是把错误包在 error 里:

{"error": {"message": "...", "code": "..."}}

Cerebras 不是。它是顶层直接给:

{"message": "Payment required to access this resource.",
 "type": "payment_required_error",
 "code": "payment_required"}

没有 error 这个字段。

而我脚本里判错的那一行写的是 if (j.error || j.status >= 400 || j.object === 'error')。三个条件一个都不命中,于是程序继续往下走,去读 j.choices[0].message.contentchoices 压根不存在,取到空字符串,最后落进了「空返回」那一档。

一个明明白白告诉你「要付费」的响应,被我判成了「返回了个空的」。

上一篇我讲过一个刚好相反的坑:推理模型把内容放在 reasoning 字段里,只读 content 会把活的判成死的。这次是只认 error 字段,把死的判成了空的。

两个坑合起来是同一句话:你的监控看到的是什么,取决于你打算看哪个字段。而各家根本没商量好把话放在哪。

如果你也在做这类可用性检查,判错的条件至少要覆盖三种:error 对象、顶层 messagecode、以及 HTTP 状态码本身。只要 choices 不存在就应该当异常处理,而不是当成空内容。

上一篇的建议,这次自己验证了

八天前那篇的核心结论是一句话:同一个模型,配多个平台的入口,比配多个不同模型更有效。理由是换平台请求体基本不用动,换模型要改代码。

当时 gpt-oss-120b 有三个入口:Cerebras 能用而且最快,Cloudflare 能用,Groq 限流。我给的排法是走 Cerebras,备 Cloudflare,Groq 留着别删。

八天后这三个入口的状态是:Cerebras 撞付费墙,Cloudflare 还活着但慢到 4205 毫秒,Groq 恢复并且成了最快。

如果你当时照着那个排法配了,这八天你的服务不会中断,甚至可能没感觉到主力已经换过一轮。

我把这件事单独拎出来说,不是因为我猜对了。是因为这次的数据说明了一个更实际的问题:这类免费入口的寿命是以天计的,任何一份「谁最好用」的清单,包括我写的,保质期都很短。清单会过期,配置结构不会。

现在这一版怎么配

按今天的数据,如果你在项目里挂免费模型:

gpt-oss-120b 这个模型改走 Groq。545 毫秒,全场最快。Cloudflare 留着做备用,它慢但稳定活着。Cerebras 那个入口先摘掉,等你愿意付费再说。

要国内直连不折腾网络环境,智谱 GLM-4-Flash 仍然是兜底首选。它这次慢了一些,1590 毫秒变成 2546 毫秒,但一直没出过事。

Nemotron-550B 系列可以放在 NVIDIA 和 OpenRouter 两个入口上。今天 NVIDIA 是 1377 毫秒、OpenRouter 是 1437 毫秒,两边都健康,互为备份。

NVIDIA Nemotron-49B 挪去跑离线任务。15 秒不适合放在有人等着的地方。

别再往 Cerebras 的 GLM-4.7 上花时间。模型归档了,这个跟额度没关系。

几句边界

这是一个账号、一个时间点的快照,2026 年 8 月 25 日。限流的那三个明天可能就好了,能用的那八个明天可能就限了。

「已死」这一档里要区分两种情况:GitHub 那两个是服务本身退役了,谁都用不了;而欠费、余额不足、订阅层级、付费墙这几个,严格说是「我这个账号用不了」,换个账号或者充钱就能复活。Cerebras 撞付费墙只说明我这个 key 的免费额度用完了,不代表它对所有人都开始收费。

另外我只测了能不能正常返回结果,没测质量,也没跑穿额度看上限。

想自己核一遍的话,记住上面那个判错的坑:别只看 error 字段。

QUEST COMPLETEREWARD: +30 XP, +1 EPIC ITEM
Build Progress100%
无信号
PULSE
0PULSES