为什么顺序比额度更重要
大模型厂商官网的 Free Tier 通常有三种门槛：仅邮箱注册、需要手机号或支付方式验证、仅对特定地区或组织开放。多数人失败的原因不是额度不够，而是先用最稀缺的资源（一个能收验证码的手机号、一张能过预授权的卡）去试一个本来不需要这些的接口，结果第一次请求就报 429 或 401，资源已经消耗掉了。
正确做法是把「验证」从注册环节挪到前面：先用零门槛批次确认你的调用链路是通的，再决定要不要动用稀缺资源。
操作步骤
第一步：建立可用性批次清单
把你要激活的厂商按门槛分成三批，写进一张表：
- A 批（仅邮箱）：注册即可拿到 API Key，控制台里能看到 free tier 的模型列表与速率限制。
- B 批（需手机号或支付方式验证）：注册后需要额外验证才能启用免费额度，部分厂商会做小额预授权（通常 1 美元上下，随后撤销）。
- C 批（地区/组织限制）：需要企业邮箱、学校域名或特定国家地区，个人邮箱注册会直接失败。
表格字段建议：厂商、批次、免费模型范围、速率限制（RPM/TPM）、额度刷新周期、是否需绑卡、当前状态。
第二步：先用 A 批打通链路
选 1–2 家 A 批厂商，拿到 Key 后立刻做三件事：
- 用最小请求验证鉴权：
curl一个/models或等价端点，确认 Key 有效。 - 发一条真实的短 prompt，记录返回的 usage 字段，确认计费口径（是否计入免费额度）。
- 把 Key 写进本地环境变量或密钥管理器，不要直接写进代码仓库。
这一步的目标不是拿量，而是确认「请求—计费—额度扣减」这条链在你的环境里是闭合的。
第三步：用 B 批扩容，一次只动一个稀缺资源
A 批跑通后，再逐个激活 B 批。关键纪律：每次只消耗一个手机号或一张卡，激活后立刻发一次真实请求确认免费额度生效，再动下一个。如果某家厂商在验证后仍返回额度不足，说明该账号的免费层未开通或已过期，此时应停止投入，而不是换卡重试。
对于需要预授权的厂商，使用一张专门用于订阅验证的卡，避免主卡被反复预授权触发风控。
第四步：C 批放到最后，且只走官方通道
C 批的额度通常最大，但验证成本也最高。只在你有真实对应的身份（学校邮箱、企业域名、所在地区）时才去申请，并且只走官网的正式申请入口。不要为了凑额度去购买或借用他人身份，这类账号在后续的合规审查中极易被批量冻结。
第五步：把额度刷新写进登记表
Free Tier 的额度通常按日、按月或按账期刷新。在表里记录每家的刷新时间点和当前剩余量，设置日历提醒，在刷新后第一天做一次真实调用确认额度已回补。这样你才知道哪家是稳定供给、哪家已经悄悄改规则。
注意事项
- 不要用同一张卡或同一个手机号连续注册多家：部分厂商的风控会跨账号关联，导致后续全部验证失败。
- 免费额度的模型范围通常受限：旗舰模型往往不在免费层内，先用免费层验证链路，再按需升级。
- 速率限制比总额度更容易卡住你：即使额度充足，RPM/TPM 超限也会返回 429，需在客户端做退避重试。
- 条款会变：免费层的模型列表、刷新周期和验证要求都可能调整，以官网控制台显示为准。
- 不要用免费额度跑生产流量：免费层通常无 SLA，且可能被限流或回收。
适用场景
- 个人开发者想在零成本下搭一条可用的推理链路。
- 小团队在正式采购前做模型选型与成本评估。
- 教学或实验环境需要一条稳定但不承诺 SLA 的调用通道。
验证脚本示例
用一个简单的 Python 脚本对每家 Key 做统一探测：读取环境变量中的 base_url 与 api_key，请求模型列表端点，再发一条 8 token 左右的 prompt，记录 HTTP 状态码、延迟和返回的 usage。把结果追加写入 CSV，配合第一步的登记表，你就能一眼看出哪家批次已打通、哪家需要重新验证。