很多人拿到 API key 之后卡在同一个地方:代码写好了,一跑就报额度不足或者权限错误,但不知道该去哪儿充、充完怎么确认、钱到底进的是哪个账号。这篇按「先分清你手上是什么、再走充值流程、最后在项目里验证」三段来拆,每段都给你可勾选的动作,也会说清哪些做法在团队共用或代充场景下不适用。
拿到 API key 之后卡住的人,绝大多数不是卡在代码上,而是卡在「钱该往哪儿放」。代码写好了,一跑就报额度不足或者权限错误,但不知道去哪个后台充、充完怎么确认到账、充的到底是哪个账号。这篇按「先分清你手上是什么、再走充值流程、最后在项目里验证」三段来拆,每段都给可勾选的动作。
有一个前提先说明白:下面这套流程讲的是官方开发者账号这条线。如果你拿到的是别人分发的 key,或者用的是第三方中转站的凭证,路径完全不同,硬套会白忙一场。所以第一步不是急着找付款按钮,而是先确认自己属于哪种情况。
先搞清:你充的是账号,不是那串 key
这是最容易搞混的一点。充值对象永远是组织或账号级别的余额,那串以 sk- 开头的 key 只是这张余额的取用凭证。你在后台重置一个 key、重新生成一个新 key,钱包里的钱一分不会少,也不会跟着 key 搬家。反过来,把 key 删了也不会退钱,余额还挂在账号上。
- 官方开发者账号余额
- 按实际调用的 token 量计费,余额花完调用就直接被拒,充值入口在生成 key 的那个后台里。
- 官方订阅制产品
- 按人头按月收费,和 API 余额不是一回事,充了它也不代表 API 能调用。
- 第三方中转站预付额度
- 你先把钱充进站点自己的后台,再由站点替你转发请求,余额是站点账本上的数字。
- 看 key 是从哪个后台生成的,就以那个后台为准去操作,别拿另一个平台的经验套过来。
- 同时登录两个后台截图对比,确认自己看的是同一个账号下的余额页面。
- 如果 key 是团队管理员统一分发的,先确认自己有没有充值权限,多数情况是没有的。
- 充之前先记下当前余额数字,充完之后再回同一个页面比对,这是最直接的到账确认方式。
充值路径怎么走:官方这条线的步骤顺序
官方这条线的关键不是「找到付款按钮」,而是按顺序走完,中间任何一步没完成都会卡住后面的步骤。顺序错了,比如账号信息没补全就去绑卡,页面会直接不让你继续。下面这几步照着勾一遍。
- 登录生成 key 的后台进 billing 或用量与付款相关区域,先看当前余额和是否已经绑过付款方式,把这两个状态记下来。
- 补全账号信息姓名、地区、税务相关信息缺哪补哪,这一步不做完,后面绑定和充值都会被拦。
- 绑定可用的付款方式能否成功和地区、卡种、账号风控状态都有关,具体支持哪些方式到 /official-api/providers/openai 核对当时的说明,别照搬别人的经验。
- 选择充值额度并确认扣款额度选项和可用区间以页面当下的显示为准,确认后在后台发起扣款。
- 回来比对余额回到刚才那个余额页面,看数字有没有变。没变就不要继续往下走,先查付款是否真的成功。
充完之后别急着上业务代码,先做一次最小金额验证:用最便宜的小模型发一条极短请求,只要正常返回内容,就说明额度和权限这条链路是通的。这一步花不了多少额度,但能把问题定位在前端,省掉后面一堆排查。
| 现象 | 先怀疑什么 | 下一步动作 |
|---|---|---|
| 余额没变 | 付款未真正完成 | 回付款记录页看状态,确认是否被风控拦下 |
| 余额变了但调用报权限错 | key 与账号不匹配 | 核对 key 是不是当前账号生成的那一个 |
| 调用能通但偶尔失败 | 速率或并发限制 | 降并发重试,观察是否稳定 |
| 一直报额度不足 | 模型或账号限额 | 检查是否用了受限模型,以及账号本身的限额设置 |
在项目里验证:从一条请求到稳定调用
额度到位之后,项目里第一件事不是把 key 贴进代码,而是把它放进环境变量。写死在代码里的 key,一是容易跟着仓库泄露出去,二是团队里换 key 时你得挨个文件改。先跑通一条最小请求,再往里接业务逻辑,出问题时才分得清是链路问题还是业务问题。
export OPENAI_API_KEY="你的key"\ncurl -s https://api.openai.com/v1/chat/completions \\\n -H "Authorization: Bearer $OPENAI_API_KEY" \\\n -H "Content-Type: application/json" \\\n -d '{"model":"当前可用的小模型","messages":[{"role":"user","content":"ping"}]}'- key 是否有效:用同一条命令换个最简请求再试,排除请求体写错的可能。
- 余额是否为正:回后台余额页面看一眼,这是最容易忽略却最常见的原因。
- 模型名是否可用:换成账号权限范围内的另一个模型测试,区分是模型问题还是权限问题。
- 网络能否出去:在服务器上单独测一次连通性,本地能通不代表线上能通。
- 是否撞到速率限制:看返回里的提示信息,降并发再试一轮。
排查就按这个顺序一层层往下走,别跳着猜。另外建议给调用加上用量日志和异常兜底,余额被打空这件事不会提前通知你,服务可能静默失败,日志能帮你事后复盘。想先量一下延迟和可用性基线,可以用 /tools/speed-test 跑一遍,把正常状态下的结果记下来,出问题时才有参照物。
官方充不上时,中转这条备选怎么用
如果官方这条线因为地区、卡种或者风控原因走不通,中转站是很多人的备选。但要清楚它是另一套账:充值入口在站点自己的后台,凭证也是站点发的,和官方账号余额互不相通。官方那边余额没花完,不代表中转这边能用。
| 对比项 | 官方账号 | 中转站 |
|---|---|---|
| 充值入口 | 生成 key 的那个官方后台 | 站点自己的后台 |
| 账本归属 | 挂在你自己账号下 | 记在站点账本上 |
| 账单凭证 | 能拿到官方口径的记录 | 通常给不了等价凭证 |
| 适用场景 | 正式项目和合规要求 | 只求把请求跑通 |
- 选站之前先做小额实测,充一点跑几条请求,看返回内容和延迟是否和描述一致。
- 挑站可以到 /sites 看站点档案和可信度信息,别只看宣传页。
- 价格变动和调整记录到 /price-watch 看历史,一次充大额之前先确认站点没有频繁调价。
- 对账时把站点的用量记录和你的调用日志比对,差太多就别继续加钱。
还有一点要提醒:中转这条线只适合「你在意的只是把请求跑通,且能接受数据经过第三方」这个前提。一旦涉及生产环境的敏感数据,或者公司层面要求可追溯的账单,这条路就不适用了,宁可花时间把官方那条线走通。
下一步先按上面的步骤把充值和最小请求跑通,再拿正常状态的结果去对比。如果你还想顺带量一下当前的延迟和可用性,可以直接去跑一遍基线,把数字记下来,将来出问题的时候这就是你的参照物。→常见问题
充值成功了,但代码里还是报额度不足或者鉴权失败,先查哪个?
先确认 key 和余额是不是同一个账号下的:很多人是 A 账号拿的 key、B 账号充的值。再依次确认 key 有没有被撤销、有没有前后空格、模型名是否写对、账号是否被风控限制。逐项排除之后再怀疑网络和速率限制。
充进去的余额会过期吗,能退吗?
这类条款各家不一样,而且会改。充值前到对应官方页面或站点自行确认有效期、退款和提现规则,别按印象操作。原则是第一次别充大额,用多少充多少,把「余额能不能退」当成选站的前置条件而不是事后问题。
一个人的账号能不能几个同事一起用?
技术上可以,但共用一把 key 会带来两个麻烦:一是谁用超了分不清,二是某个人泄露或违规会连带整个账号。人数多的时候走组织/子账号体系去分权限,或者按项目拆 key,出事时好定位也好止损。