免费大模型api有哪些，怎么做和怎么选

团队要接一个大模型做原型，预算一时批不下来，第一反应就是找免费 API。可免费额度写在哪儿、怎么算、哪天悄悄收紧，各家说法不一，跑通 demo 之后正式上线才发现限流、上下文被截、商用授权不清。这篇按「去哪找、额度怎么看、怎么验、怎么选」给你一套可执行的判断流程。

团队要接一个大模型做原型，预算一时批不下来，第一反应往往是找免费 API。问题是免费额度写在哪儿、怎么算、哪天被悄悄收紧，各家说法都不一样。demo 跑通很轻松，等到正式上线才发现限流、上下文被截、商用授权说不清楚，返工成本比省下的调用费高得多。

这篇按「去哪找、额度怎么读、接之前怎么验、怎么选、上线后怎么盯」给一套能直接照做的流程。判断标准写清楚适用场景，也写清楚什么情况下这套方法不成立——免费 API 适合原型验证和小流量试水，不适合当作长期生产依赖。

免费 API 一般从哪几个渠道冒出来

先把来源分清楚，再谈额度。常见的免费入口大概四类：官方平台给的免费档或新用户试用额度、开源模型托管平台提供的免费小模型位、聚合和中转站里的免费路由，以及自建本地推理——最后一种严格说不算 API，但调用费同样是零。四类渠道的稳定性差距很大，拿来当同一回事比较，很容易判断失误。

官方免费档 / 试用额度

条款和限制通常写在官方定价页，可查可追溯，适合当主要通道

开源模型托管平台免费位

常见于小参数模型或社区模型，能力和并发有限，适合实验和轻量任务

聚合站 / 中转站免费路由

上线和下架都比较随意，可能随时换模型，只适合临时试水

本地自建推理

没有调用费，吃的是硬件和运维成本，隐私敏感场景更合适

选渠道之前，先把你要的能力画出来：纯文本对话、长上下文文档处理、多模态、语音、函数调用，各自优先级排一下。不先明确能力边界，就会找到一堆看着免费、实际用不上的模型，来回比较浪费时间。比如做文档摘要的，上下文长度是硬指标；做实时客服的，延迟和并发才是关键。

• 纯文本问答：几乎每类渠道都能覆盖，重点看限流和稳定性
• 长上下文任务：优先确认免费档是否限制最大输入长度
• 多模态或语音：可用免费位少得多，要提前接受付费或自建
• 函数调用与流式输出：不是所有免费档都开放，接之前先试
• 商用场景：先看条款，免费额度默认不保证可商用

额度到底怎么读：三组数字别混

「免费」这两个字最容易误导人，因为限制至少分三组。第一组是单位时间的请求次数上限，比如每分钟多少次；第二组是 token 上限，输入和输出经常分开算，有的只限输入；第三组是并发数，同时能挂几个请求。很多所谓免费只免了其中一项，另外两项照样卡你。

超额之后的处理方式也要看清楚：有的直接返回错误码，有的自动降速排队，有的静默切到更小的模型。第三种最难排查——你以为是网络问题，其实是平台给你降级了。具体档位和限制各平台会调整，站内页面只作参考，去 /ai-nav/category/ai-model-platform 和 /official-api 核对当时的说法，以对方当前页面为准。

接之前先做三项验证

免费 API 的坑大多在接入之后才暴露，所以在写业务代码之前先做三项验证，成本很低，能省掉后面大量返工。验证的目标不是给平台打分，而是确认它在你的使用场景下能不能撑住。

1. 真模型验证用一组固定提示词测知识截止、指令遵循和语言风格，同一问题连问几次看输出是否明显漂移，判断有没有被替换成小模型或量化版本；站内 /tools/quality-check 和 /tools/verify 的检测思路可以借用
2. 限流验证写一个简单压测脚本，按你预估的峰值 QPS 打过去，记录首次触发 429 的阈值、恢复时间和降级表现，别等到上线才发现容量不够
3. 稳定性验证连续跑一周，记录错误率和延迟抖动；先用 /tools/speed-test 量好本地网络基线，避免把自家网络问题误判成平台限流

三项验证里，限流验证最容易被跳过，也最容易出问题。判断标准很简单：如果你的峰值 QPS 在十分钟压测内就触发了限制，那这个免费通道只能用于低频任务；如果不适用——比如你的业务本来就是低峰调用、可以接受排队——那限流严格一些反而无所谓。

免费额度最容易踩的四个坑

下面四个坑是按出现频率排的，不是按严重程度。每个坑都给了识别方法，接入前过一遍，能省掉不少线上排障时间。

• 上下文缩水：免费档常限制最大输入长度，长文档任务会被中途截断，识别方法是发一篇超长文本看返回是否完整
• 高峰期降级：免费请求可能排在付费请求后面，延迟拉长甚至超时，识别方法是同一请求在闲时和忙时各跑一遍对比
• 条款变更：免费档是平台调节用量的旋钮，随时可能收紧，识别方法是订阅对方的公告渠道，并准备备用 provider
• 数据与授权：免费不等于可用于生产或商用，涉及用户数据时务必看数据使用条款和模型许可

这四个坑里，数据与授权最需要提前确认，因为它不是技术问题，排查不出来。什么情况下这条不适用：如果你只拿免费 API 做内部原型、不接触真实用户数据、也不对外提供服务，那授权风险可以放低，但仍要避免把敏感内容发出去测试。

低成本接入的常用架构：主用+备用+本地兜底

单依赖一个免费通道风险很高，低成本接入的常见做法是三层：主用一个额度明确、文档稳定的免费或低价通道，备用换另一家不同厂商，本地小模型兜住溢出流量和隐私敏感请求。三层不必同时上线，但代码结构要提前留好位置。

关键是抽象层。统一按 OpenAI 兼容格式调用，业务代码只认接口不认厂商，切换 provider 时改配置而不是改代码。这样哪天主用通道收紧额度，切备用是分钟级的事，而不是一次重构。

本地兜底不是必须项。如果调用量很小、也没有隐私约束，两层就够，硬上本地部署反而增加运维负担。判断标准是：数据能不能出内网、突发流量损失能不能接受，两个问题有一个答案是否，才需要考虑本地。

一张选型清单：五个问题决定用不用

面对一个免费 API，不用纠结它是不是「最好」，按下面五个问题依次问一遍，答不上来的就是风险点。五个都过了再接入，过不了就换一家或者直接考虑付费。

这张清单的用法是逐项打勾，而不是打分排序。任何一项不合格，都意味着这个通道只能放在实验位置，不能进生产链路。价格和额度数字不在这里写死，去 /price-watch 和 /official-api 看当时的记录更可靠。

跑起来之后怎么盯住它

免费通道的问题很少一次性爆发，多数是慢慢收紧的：延迟一点点变长，429 比例一点点升高，等你察觉时体验已经掉下来了。所以跑起来之后要有监控，而且免费通道要单独打标，不能和付费通道混在一个指标里。

• 给免费通道单独打标，监控错误率、429 比例、P95 延迟，超阈值自动切备用
• 记录每次请求的 token 用量和折算费用，判断什么时候该升级到付费
• 订阅平台的公告和状态页，变动往往先体现在限流上
• 定期复跑接入前的三项验证，确认能力没有被悄悄降级

监控指标设多少阈值，取决于你的业务容忍度：实时交互类应用对 P95 延迟更敏感，批处理任务只看错误率即可。站内 /price-watch 和 /ai-status 可以辅助看变动趋势，但具体数字以当次页面为准。