想省点钱先用免费接口试水，很容易卡在两件事上：不知道去哪找，找着了又不确定能不能长期用。网上那种一长串名单，点进去一半是失效的，剩下的一半要么限速到没法用，要么随时改规则。这篇不给你排座次，只给一套自己判断的办法：先分清平台类型，再按几个硬指标筛一遍，接进来第一件事是测通而不是写业务，最后想清楚白嫖结束那天怎么办。
想省点钱先用免费接口试水，很容易卡在两件事上：不知道去哪找，找着了又不确定能不能长期用。网上那种一长串名单，点进去一半是失效的，剩下的一半要么限速到没法用，要么随时改规则。与其收藏一堆链接，不如自己掌握一套筛选口径。
这篇不给你排座次，只给一套自己判断的办法：先分清平台类型，再按几个硬指标筛一遍，接进来第一件事是测通而不是写业务，最后想清楚白嫖结束那天怎么办。全篇只讲判断标准和可执行动作，具体数字请到站内对应页面核对当时的口径。
先分清四类来源，别把它们混在一张表里比
免费接口最大的坑不是不好用，而是把性质完全不同的东西放到一张表里横向对比。官方试用额度、聚合平台免费位、开源托管试用、自建推理，这四类的额度规则、失效风险和接入成本压根不在一个量级。先归类，再比较，能省掉一大半无效调研。
| 来源类型 | 适合拿来做什么 | 主要不确定性 |
|---|---|---|
| 官方试用额度 | 验证自家产品对某家模型的效果 | 规则由厂商单方面调整，随时可能收紧 |
| 聚合平台免费位 | 一个 Key 横向试多家模型 | 路由和限速策略不透明，出问题难定位 |
| 开源模型托管试用 | 验证开源权重效果与部署可行性 | 可用模型和排队情况变化快 |
| 自建或本地推理 | 数据不出内网、长期零调用费 | 有硬件和电费成本，性能受设备限制 |
要说清楚一点：这四类来源都不适合需要商用级 SLA 或合规审计的场景。免费来源基本都满足不了稳定性承诺和数据出境要求，如果业务本身对这两点敏感，直接去付费通道看，别在免费方案上耗时间。
- 官方试用额度
- 厂商自己发的免费配额，行为最可预期，规则只有厂商说了算，去 /official-api 逐个核对当前口径
- 聚合平台免费位
- 一个 Key 打多家模型，常有若干免费模型，适合横向试模型
- 开源模型托管试用
- 面向开源权重的托管入口，适合验证效果，可用模型和排队情况变化快，去 /inference 看
- 自建或本地推理
- 零调用费用但有硬件和电费成本，判断边界参考 /local-deploy-vs-api
筛选就看五件事，其余都是噪音
名单类内容最没用的地方在于，它告诉你「有这个东西」，但不告诉你「它适不适合你」。下面五条是筛免费来源时真正起决定作用的维度，其余的宣传话术、页面美观度、模型数量多少，都可以先放一边。
- 额度口径：是每天重置还是一次性总额度、按请求数还是按 token 算，写下来再去 /ai-nav/category/ai-model-platform 对照平台说明
- 限速与并发：免费来源通常并发很低，先假设只能跑单线程，具体档位到 /free-api-rate-limit-guide 看分类口径
- 协议兼容：能不能直接换成 OpenAI 兼容的 Base URL 决定接入成本，判断标准见 /openai-compatible-interface-basics
- Key 获取门槛：要不要绑卡、要不要海外手机号，直接决定你团队里谁能拿到，也决定这事能不能在团队内持续
- 失效风险：免费位随时可能收紧，凡是把免费接口写进核心链路的方案都要留退路，不能只有一条路
判断标准要落到「什么情况下不适用」：如果这条链路对延迟敏感，那限速哪怕不低也未必够用；如果只是内部工具、每天几十次调用，那并发低一点完全能接受。同一套指标，用在不同场景下的结论可能相反。
拿到 Key 后的验证顺序：测通、测速、测限速，再写业务
很多人拿到 Key 第一件事就是改代码接进项目，结果报错时根本分不清是代码写错了还是接口本身不可用。正确的顺序是先确认接口能用，再确认接口好用，最后才动业务代码。这四步走完通常用不了多久，但能省掉大量排查时间。
- 测通只发一条最小请求，确认鉴权和地址没问题。别写业务逻辑，能返回结果就算通过，路径参考 /relay-connectivity-verification
- 测速到 /tools/speed-test 量一条你自己的延迟基线，别拿别人的体验当标准，网络环境不同结论可能完全不同
- 测限速手动连发几次，摸出限速是硬拒绝还是排队等待，报错形态对照 /429-concurrency-backoff，把这个特征记下来
- 再接业务前三步都过了再决定接不接进项目。如果跳过前面直接写业务，出问题时你连排查方向都没有
这里也要说清楚不适用的情况：如果这个接口只是临时跑一次脚本、用完就丢，那没必要走完四步，测通就够了。验证流程的价值随着使用时长和调用量上升，短期一次性使用可以简化。
白嫖结束那天怎么办：先设计退路再动手
免费额度收紧或取消是常态，不是意外。真正影响项目的不是「它会不会停」，而是「停了之后你要花多久恢复」。退路这件事应该在接进来那天就设计好，而不是等报错那天再想。
- 把模型名、Base URL、Key 三样抽成配置项，换来源时只改配置不改代码，做法见 /multi-model-routing-fallback
- 留一个付费兜底通道，免费来源挂了自动切过去，切换后的验证流程见 /relay-switch-api-verification
- 记好每个来源的额度和重置时间，别等报错才发现已经过期
- 如果团队真在用，尽早算一遍正常用量的成本，去 /tools/model-cost-calculator 估，避免把免费期当常态
换来源这件事，别看参数差不多就以为能无缝替换。不同来源对同一模型名的实现口径、上下文处理、报错方式都可能有差异，切换后必须重新走一遍验证顺序，别假设「换了个地址而已」。
一张自查清单，选型时逐条打勾
| 自查项 | 判断标准 | 勾选后意味着 |
|---|---|---|
| 额度口径 | 日/月/总额、按次还是按量写清楚 | 能预估能用多久 |
| 限速可接受 | 峰值并发够不够你那条链路 | 不会调用到一半被卡 |
| 协议兼容 | 改 Base URL 就能接 | 接入成本低 |
| 退路明确 | 挂了切哪、谁负责切 | 不会停摆 |
| 合规可接受 | 数据能不能发出去，参考 /safety | 绕开合规风险 |
四项以上打勾再用；只勾前两项的，适合做实验，别上生产。清单的意义不是打分排名，而是让你在动手前把风险点过一次，免得来回返工。如果某一项你自己都说不清楚，那说明调研还没做完。
下一步想直接对照各家平台当前的赠送额度和限速口径，去导航页按类别过一遍，比自己到处搜名单快，也方便后续复查。→常见问题
免费接口能直接用在正式项目里吗？
大多数情况不建议。免费来源普遍限速低、规则说改就改，也不承诺可用性。真要用就当成一层可替换的来源，外面套配置化和自动降级，主链路仍留一条付费或自建通道；纯内部实验、跑批任务这类对可用性不敏感的活可以先上。
同时接好几家免费平台会不会更稳？
会，但成本在维护不在接。每多一家就多一份额度口径、限速行为和报错形态要跟。务实做法是主用一个、备用一个，第三个等真出问题再加；多来源路由怎么配看 /multi-model-routing-fallback。
怎么判断一个免费平台是不是快不能用了？
看几个信号：限速越来越紧、免费模型列表在缩、公告里出现调整计费的措辞、社区反馈变多。这些不是精确指标，但出现两条以上就该准备切走。平台是否在线可以顺手看 /ai-status，切换后的连通性按 /relay-connectivity-verification 走一遍。
