看到「送你几亿 token」的宣传，注册进去却发现额度藏在某个控制台角落，或者领了却因为没实名、没绑卡、区域不对而用不了。这篇不讲哪家给得多，讲的是先把大额 token 的来源分成几类，再按固定顺序去领、去核，避免白跑注册流程。具体数字和名额随时会变，领之前到站内对应页面看当时的口径。
看到「送你几亿 token」的宣传，注册进去却发现额度藏在控制台某个角落，或者领了却因为没实名、没绑卡、区域不对而用不了。这篇不讲哪家给得多，讲的是先把大额 token 的来源分成几类，再按固定顺序去领、去核，避免白跑注册流程。具体数字和名额随时会变，领之前到站内对应页面看当时的口径。
另外提醒一句：大额额度和「长期可用」是两回事。注册赠送通常有窗口期和并发限制，把它当成一笔一次性预算来规划，比当成基础设施更贴近现实。下面先分来源，再给领取顺序，最后讲怎么核对真实口径。
先分清大额额度从哪来：四种来源，领法完全不同
| 来源类型 | 入口位置 | 到账前提 | 典型适用场景 |
|---|---|---|---|
| 云厂商/平台注册赠送 | 厂商控制台或云市场 | 实名或绑卡后到账，有效期短 | 短期集中跑批、接口压测 |
| 模型厂商开发者试用金 | 模型厂商控制台，不在产品端 | 账号开通、部分需企业认证 | 试模型效果、对比输出质量 |
| 聚合平台或中转渠道拉新 | 渠道站内活动页 | 按平台内部单位计价，要折算 | 持续做开发、按量切模型 |
| 活动型发放 | 邀请、竞赛或限时窗口 | 名额与规则随时变 | 一次性冲量、演示项目 |
- 第一类是云厂商/平台的注册赠送，通常在实名或绑卡后才到账，且有效期短，适合短期集中跑批；
- 第二类是模型厂商自己的开发者试用金，额度挂在控制台而非产品端；
- 第三类是聚合平台或中转渠道的拉新赠送，额度以平台内部单位计价，要折算才能对比；
- 第四类是活动型发放，靠邀请、竞赛或限时窗口，名额和规则随时变，不适合写进长期预算。
判断自己属于哪种需求：只是想试模型效果，走第一类最快；要做持续开发，第三类的折算口径更值得先看清，去站内的 /official-api 和 /reseller-quota-conversion 相关页面核对折算关系。什么情况下不适用：如果业务要求数据不出境、或必须走企业合同开票，个人注册送的额度基本用不上，别在这上面花时间。
领取顺序清单：先领能立刻用的，再碰要绑卡的
- 第一步：官方控制台先开户在模型厂商官方控制台注册并开通开发者账号，确认试用金是否已挂到账号下。验证方式：控制台额度页能看到余额条目，且不是「待激活」状态。
- 第二步：写最短调用验一次额度一到就发一段最短的请求，确认返回正常且额度确实被扣。验证方式：对比调用前后的用量数字，差值为正才说明链路通了，不通就别继续往下注册。
- 第三步：再拿聚合平台或渠道额度聚合平台、中转渠道的赠送通常需要站内激活，按活动页说明点领取。验证方式：同样用短请求验一次，注意它扣的是平台内部单位，要按折算关系换回 token 口径。
- 第四步：最后才碰要绑卡或要外币卡的渠道这类一旦失败，时间和资料都白搭，所以放在最后。验证方式：绑卡成功后仍要跑一次最小调用，别只看「领取成功」的提示。
每一步做完立刻验一次，验不通就别往下走，否则后面分不清是哪一层的问题。必备材料提前备好：手机号、邮箱、实名信息、可能的支付方式，缺哪样就先补哪样，不要在注册到一半时才找。额度到账后第一件事是记下有效期和适用范围，能用在哪些模型、能不能和付费额度叠加、用超了怎么扣，这些可以在 /free-credit-overage-order 这类站内页面找到通用口径对照。
别信宣传数字：去哪核对额度的真实口径
看官方定价与规格页，而不是营销页。模型库和官方 API 价格页里通常写明了免费档的适用模型与限制条件，到 /official-api 和 /models 核对当时的说明，那里给的才是能写进预算的口径。
看额度重置与失效的规律：很多平台的赠送额度按自然月或按活动周期重置，错过窗口就没了，/resets 这类页面可以用来判断当前是不是好时机。看渠道可信度也别省：如果额度是通过中转站或第三方渠道发的，先确认这个站本身靠不靠谱，/tools/verify 和 /sites 有检测与目录，别为了白嫖额度把 key 交出去。
- 官方口径：去 /official-api 和 /models 看适用模型与限制条件；
- 重置时机：去 /resets 看当前周期和下一次刷新窗口；
- 渠道可信度：去 /tools/verify 和 /sites 检测发额度的一方；
- 折算关系：走渠道额度时，去相关站内页面核对内部单位与 token 的换算。
什么情况下不适用：如果额度来自你已经在用的官方账号，且账单里能看到对应抵扣项，那就不用再额外核一遍，直接用用量页对账更实在。
大额免费额度的现实边界：能干什么、不能指望什么
| 用途 | 适不适合 | 判断依据 |
|---|---|---|
| 接口压测、延迟摸底 | 适合 | 对额度连续性要求低，断了不影响主线 |
| 跑一批离线数据做效果对比 | 适合 | 单次批量，用完即止 |
| 团队 Demo 演示 | 适合 | 只求跑通，不追求长期稳定 |
| 当作生产环境长期供给 | 不适合 | 并发限制、模型白名单、频率上限会卡住业务 |
适合拿来做的事，是那些对额度连续性要求低、断了也不影响主线的场景。不适合拿来做的事，是当成生产环境的长期供给：免费档通常伴随并发限制、模型白名单或调用频率上限，一旦被限速，业务就卡住了，参考 /relay-billing-rate-rpm 里的限速口径。
用量要留痕。免费额度和付费额度混用时，账单会变得难以归因，团队里最好从一开始就用带标签的 key 分开调用，具体字段可参考站内用量日志类文章。一个判断标准：如果这个额度需要你改代码架构去适配它，那它就不叫免费，叫有成本的迁移。
下一步领之前先花两分钟确认发额度的一方可信、额度口径能对上，再按顺序动手注册；站内检测与目录页有现成的判断依据。→常见问题
这些大额免费额度一般能领多久，会不会突然没了？
绝大多数平台都不承诺长期有效，活动型额度尤其可能随时调整或下线，条款里通常写着「平台有权变更」。稳妥的做法是领到手就当临时资源用，别写进长期预算，真正要长期跑的部分还是走付费额度。具体有效期到站内官方 API 价格页和额度重置追踪页看当时的说明。
同一个平台能不能多个账号反复领？
技术上能不能是一回事，值不值得是另一回事。多数平台会按实名、手机号、支付方式或设备做去重，被判定为重复领取后可能直接封号，连带把正常账号也拖下水。如果只是短期验证想法，正常领一份就够用；要做正式业务，结算成本本来就是该付的钱。
领了大额额度但调用报错，先查什么？
按这个顺序排：先确认额度是否已到账且没过期；再确认调用的模型在不在免费档的适用范围内；然后看是不是触发了频率或并发限制；最后才怀疑 key 或网络。很多「额度用不了」其实是模型不在白名单里，或者额度只在某个区域控制台生效。排查口径可参考站内限速与扣费顺序相关页面。
