买了 ChatGPT Plus，为什么 API 还是没额度？这个问题我这一年被问了不下二十次，问的人里有刚跑通第一个 demo 的学生，也有已经把工具挂到线上的独立开发者。他们的表情几乎一样：困惑里带一点被冒犯——我每个月都在付费，凭什么调接口的时候告诉我余额不足？更让人难受的是，报错信息还特别含糊，有时候是 429，有时候是 insufficient_quota，有时候干脆一个 401 甩过来，让人根本不知道该去充值还是该去改代码。

这篇就专门把这件事讲透：订阅会员和 API 额度到底是不是一回事，为什么平台方要把它们拆成两套账，充值之后为什么还会撞上限流，以及一条从零把 API 跑通的最小闭环该怎么走。不管你是刚注册完账号想试水的新手，还是已经在生产环境里烧 token、需要做成本控制的老手，下面的内容都能直接拿去用。我尽量不说空话，每一步都给出理由和踩过的坑。

1. 先把"额度"这两个字拆开看

1.1 三种"没额度"，成因完全不同

很多人把"没额度"当成一个状态，实际上它至少对应三种完全不同的情况，处理方式差得极远。第一种是账户余额（credit balance）真的是 0，这种情况无论你怎么重试都没用，必须去账单页充值。第二种是余额还在，但你自己或者团队管理员在后台设了一个用量上限（usage limit），请求一旦触到这个上限就会被拦下来，报错文本里往往带着insufficient_quota。第三种最容易被误判：余额充足、上限也没设，但你在短时间内打得太猛，撞上了速率限制（rate limit），这时候返回的是 429，等几十秒重试就能过。

这三种情况表面上都表现为"用不了"，但一个要花钱、一个要改配置、一个只要等。把它们混在一起排查，效率会低到让人抓狂——我见过有人明明是撞了限流，却跑去连充了三次值，最后发现余额堆在那里根本没用上。所以排查的第一步永远是分类，而不是急着掏钱包。

这张表建议直接存下来。我自己的习惯是：看到报错先把错误码和 message 原文完整复制出来，对照这张表定位到某一类，再往下查。凭感觉猜是最费时间的。

1.2 订阅费和 API 余额是两本账

回到最开始那个疑问。订阅会员（比如各种对话产品的 Plus、Pro、Team 套餐）买的是"对话端产品的使用权"：你在网页或者客户端里聊天、传文件、用内置工具，这些消耗已经被包月费用摊掉了，平台不会按次跟你算钱。而 API 是另一条产品线，它的计费单位是 token，用多少算多少，扣的是你预先充进账户的余额。

这两者在账号体系里是两个独立的账本。你用同一个邮箱登录，看起来像是在同一个地方，但订阅状态那一栏写着"已生效"，不代表账单页里的余额会跟着变动。打个比方：健身房的年卡让你能随时进场锻炼，但私教课是按节单独计费的，年卡再贵也抵扣不了私教课的钱。你不是被坑了，你只是买了两样不同的东西。

需要说明的是，平台方在不同时期对"新账号是否赠送试用额度"的政策调整过，早期注册的账号可能拿到过一笔带有效期的体验金，后来的新账号则普遍需要先充值才能调用。所以如果你看到别人的教程里说"注册就送额度"，而你自己注册完一分没有，大概率不是操作错了，而是政策变了。这条以你登录后账单页的实际显示为准，别拿老文章当依据。

2. 平台方为什么非要把两套计费拆开

2.1 包月是摊薄，API 是精算

站在产品设计角度看，这个拆分几乎是必然的。对话端产品的用户行为分布很有规律：绝大多数人一天问几十个问题，峰值可控，单用户成本可以比较准确地估计出来，所以适合做成固定月费——平台承担用量波动的风险，用户获得确定性。这就是"摊薄"。

API 则完全相反。调用方是程序，跑一个批处理任务可能几小时烧掉几百万 token，也可能一个月只发几百次请求。用量方差大到无法用一个固定价格覆盖，只能用"按量计费 + 预付费余额"的方式，谁用谁付，用完为止。如果允许订阅用户拿会员身份无限调 API，那等于把一个方差极大的成本项塞进固定价格里，任何一家公司都撑不住。

理解了这一层，你就不会再问"我买了会员为什么接口还要钱"，而会问"我这个场景大概要烧多少钱"。后一个问题才有工程价值。

2.2 滥用面不同，配额颗粒度不同

除了成本，还有一个更实际的原因：滥用面。对话端有前端页面、有账号风控、有使用频率的自然约束；API 是赤裸裸的机器入口，一个泄露的密钥可以在几分钟内被打出天量账单。所以 API 侧必须有一整套配额体系：账户级余额、组织级预算、项目级上限、密钥级权限、模型级速率，每一层都能单独设卡。

这也是为什么你会在后台看到一堆看起来很绕的名词——组织（organization）、项目（project）、密钥（API key）。很多"我明明充了钱却用不了"的案例，根子就在这里：钱充在组织 A 上，密钥却建在项目 B 里，而项目 B 被管理员设了一个 0 美元的预算上限。账面上你确实有钱，但那条调用链路上一分钱都流不过去。

我见过一个挺典型的场景：某团队几个人共用一个账号，一个人负责充值，另一个人负责建密钥。结果负责建密钥的那位在自己账号下建了个新项目，默认预算没配，一上线全组报错，排查了整整一个下午。后来他们的规范是：任何新建项目必须同步检查预算上限和模型权限，先跑通一个最小请求再交付。

2.3 组织、项目、密钥的三层模型

把这三层关系理清楚，后面所有排查都会轻松很多。组织是计费和结算的主体，余额、发票、税率、层级全挂在组织上；项目是资源和额度的隔离单元，同一个组织下可以有多个项目，各自有独立的用量统计和预算；密钥是挂在项目下面的凭证，一个项目可以签多个密钥，方便按服务拆分或轮换。

调用时的鉴权顺序是：密钥 → 定位到所属项目 → 定位到所属组织 → 检查组织余额和层级 → 检查项目预算 → 检查模型权限 → 检查速率限制。整条链路上任何一环不通，你都会收到一个看起来差不多的错误。所以排查时不要只盯着"余额"一个数字，要把这条链路从上往下撸一遍。

提示：密钥一旦创建，绝大多数平台只会在创建时完整显示一次，之后就只能看到前后几位。如果你手上只有一个残缺的密钥，别浪费时间试，直接签新的。同时旧密钥记得删除，避免留着一个没人管的有效凭证。

3. 从零跑通：充值、建密钥、发出第一个请求

3.1 充值门槛和层级的关系

绝大多数平台的 API 都是预付费模式：先把钱充进余额，调用时按实际 token 消耗实时扣减。首次充值通常有一个最低金额门槛，量级在几美元，目的主要是验证支付方式有效、防止刷号。充值成功后，账单页会显示可用余额和最近一笔交易记录。

这里有个很多人不知道的机制：累计充值金额会决定你的账户层级（tier），而层级直接决定你的速率上限。刚充完最低金额的账号，往往处在最低层级，每分钟能发的请求数和能消耗的 token 数都相当有限。当你写了个循环批量跑数据时，很容易几分钟就撞上限流，然后误以为是余额花光了。

具体的金额门槛和等待天数各平台会调整，务必以你后台或官方文档的实时说明为准，上表只帮你建立量级概念。有一点是通用的：层级是按累计充值算的，不是按当前余额算的。也就是说你先充后花，花光了余额层级也不会掉回去，这对做容量规划挺友好。

3.2 建密钥时最容易忽略的两件事

签密钥本身是个点两下鼠标的事，但有两个细节经常被忽略。第一是密钥归属的项目。后台通常默认给你一个默认项目，如果你有多个业务，建议按业务拆项目，这样用量统计能分得清，出问题也能快速定位是哪条业务在烧钱。

第二是密钥的权限范围。不少平台支持给密钥设置权限，比如只读、只允许调用某些模型、只允许某些端点。生产环境里我强烈建议按最小权限来配：一个只做文本补全的服务，没必要给它开通文件上传和微调的权限。万一密钥泄露，攻击面能小一大截。

密钥拿到手之后，正确的做法是立刻放进环境变量或者密钥管理服务，绝对不要硬编码进代码里再推到公开仓库。这个坑每年都有人踩，而且代价很高——有人写了个爬虫脚本，密钥写在源码里，仓库设成公开，第二天早上收到账单通知。

# 放进环境变量，别写进源码 export API_KEY="sk-你的密钥"

如果你用的是容器化部署，就把这个变量走部署平台的密钥配置，别写进 Dockerfile。团队协作时，密钥轮换要有固定节奏，比如每季度换一次，旧密钥下线前确认没有服务还在用。

3.3 第一个请求，以及怎么从响应头读额度

最小验证请求我建议就用最简单的单轮对话，参数尽量少，先把链路打通再谈优化。用官方 SDK 大致是这样：

import os from openai import OpenAI client = OpenAI( api_key=os.environ["API_KEY"], base_url=os.environ.get("API_BASE"), # 如果你的平台给了自定义网关地址 ) resp = client.chat.completions.create( model="你的模型名", messages=[{"role": "user", "content": "用一句话说明什么是 token"}], max_tokens=64, ) print(resp.choices[0].message.content) print(resp.usage) # 看这次到底花了多少 token

resp.usage这个字段非常关键，它告诉你本次请求的输入 token、输出 token 和总量。养成每次调试都打印它的习惯，你对成本的感觉会一点点建立起来。

如果你更喜欢用命令行验证，可以顺手把响应头存下来，那里藏着限流信息：

curl -sS "$API_BASE/chat/completions" \ -H "Authorization: Bearer $API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"你的模型名","messages":[{"role":"user","content":"ping"}],"max_tokens":16}' \ -D ./resp_headers.txt grep -i "ratelimit" ./resp_headers.txt

响应头里通常会有x-ratelimit-limit-requests、x-ratelimit-remaining-requests、x-ratelimit-reset-requests以及对应的 token 版本。这几个头的价值在于：你能提前知道自己还剩多少配额，而不是等报错才知道。生产服务里我一般会把它们采集进监控，剩余量低于阈值就告警。

3.4 把 token 折算成钱

新手最缺的是钱感。以主流模型目前的公开价位为例，量级大概是输入每百万 token 几美元、输出每百万 token 十几美元，输出通常是输入的 3 到 4 倍。按 1 美元约 7 元人民币粗略换算，一美元大概是七块钱。

中文的 token 换算比英文"贵"一些，因为一个汉字在不同分词器下大概对应 0.6 到 1.5 个 token 不等，新一些的分词器对中文更友好。别去背精确比例，直接实测：拿一段你业务里真实的文本，发一次请求看usage，那个数字才是你该用的。

有了这个直觉，很多决策就变简单了。比如要不要把整篇文档塞进上下文，你可以先算：一万字的文档大概一万多 token 输入，成本几分钱，跑一百次也就几块钱，完全可以接受；但如果你每次都把这一万字带上，再让模型输出两千字，那输出侧的成本会迅速超过输入侧，这时候就该考虑缓存或者换更小的模型。

4. 报错定位实录：按这个顺序查，少走弯路

4.1 401 和 403：先别怀疑钱包

401 几乎永远是凭证问题，跟钱没关系。常见成因有四种：密钥复制时带上了看不见的空格或换行，尤其是从网页复制到配置文件时特别容易；环境变量名写错，代码里读到的是空字符串；密钥已经被删除或轮换过；请求头格式不对，Bearer后面少了空格或者大小写搞错。

我调试这类问题的土办法很有效：先打印一下密钥的长度和前六位后四位，确认它不是空的、也不是别的项目的密钥混进来了。然后再用一个最简的 curl 打一次，排除 SDK 封装的干扰。十次里有八次能当场发现是复制粘贴出的问题。

403 通常是权限问题，不是你这个人没权限，是这把密钥、这个项目、或者这个组织没有被允许访问某个模型或端点。常见触发场景是：新模型刚上线，需要单独申请或者组织完成某种验证才能调用；团队管理员给项目设了模型白名单；密钥本身被限制成只能调某几个端点。遇到 403 别急着重试，先去看该模型在后台的可用状态。

4.2 429 的两种面孔

429 是最容易误判的一个。它有两种完全不同的含义，而它们的 message 文本长得很像，都是"你超出了什么什么"。

第一种是速率限制，message 里通常会出现rate limit reached for requests或者rate limit reached for tokens，意思是你在单位时间内打得太快或消耗太多。处理方式是降速：加指数退避重试、加并发控制、把批量任务拆成小批错峰跑。如果业务量确实大，就去提层级或者申请提额。

第二种是配额耗尽，message 里会出现insufficient_quota。这个不是限流，重试一万次都没用，因为它代表你的余额不够或者用量上限到了。很多人看到 429 就无脑重试，结果在一个死循环里空转，日志刷满，问题一点没解决。

区分方法很简单：看 message 里有没有 quota 字样。有 quota 就去账单页，有 rate limit 就去改代码节奏。

import time from openai import RateLimitError, APIStatusError def call_with_backoff(fn, max_retries=5): delay = 1.0 for attempt in range(max_retries): try: return fn() except RateLimitError as e: # 先看是不是配额问题，配额问题重试无意义 if "quota" in str(e).lower(): raise time.sleep(delay) delay = min(delay * 2, 32) except APIStatusError as e: if e.status_code >= 500: time.sleep(delay) delay = min(delay * 2, 32) else: raise raise RuntimeError("重试次数用尽")

这段退避逻辑我在好几个项目里都用过，核心就两点：指数增长加封顶，以及配额类错误不重试。别小看第二条，它能把很多无意义的账单和日志噪音挡在门外。

4.3 insufficient_quota：多数是自己设的上限

这是我最想单独拎出来说的一类。后台的用量设置里通常有几个开关：软上限（到点发邮件提醒）和硬上限（到点直接拒绝请求）。有些平台默认给新项目设一个很低的硬上限，甚至默认 0，意思是"想花钱得你自己明确打开"。

于是就出现了最经典的误判场景：钱充了，余额显示得好好的，但每次请求都返回insufficient_quota。人第一反应是"钱没到账"，跑去看账单，确认到账，然后陷入迷茫。真相是那个硬上限还停在初始值。

排查顺序我建议这样：先看余额是否大于 0，再看组织的月度预算是否被设成了很小的值，再看当前项目有没有独立的预算上限，最后看这个密钥有没有被单独限流。四步走完，百分之九十的配额类问题都能定位。

4.4 账单环节的几个坑

充值时最常见的是支付方式被拒。这时候别反复试，先看账单页给出的具体提示，再核对卡片的有效期、账单地址、是否开通了境外支付、银行侧有没有风控拦截。有些银行对小额境外交易会先拦后放，过一会儿再试可能就过了。

第二个坑是自动充值。不少平台支持余额低于阈值时自动扣款续充，这个功能很方便，但如果你的卡过期了或者额度受限，某天半夜任务跑着跑着就断了，第二天早上才发现。要么把它关掉改成手动监控告警，要么确保绑定的支付方式长期有效，并且把阈值设得够高，别等到余额只剩几毛钱才触发。

第三个坑是第三方代充。我明确不建议走这条路：账号主体、账单归属、发票开具都会出问题，而且密钥和账单信息交到别人手里，风险完全不可控。金额不大的话，自己按官方流程充，省下来的时间和心理成本远超那点差价。

还有一个容易被忽略的点：订阅会员和 API 余额虽然同属一个账号，但它们的账单周期是分开的。会员到期不会影响 API 余额，反之亦然。所以别把两个日期记混，做一个简单的到期提醒，比事后拍大腿强。

5. 让预算撑得更久：工程侧的几个习惯

5.1 上下文长度是最大的一笔开销

几乎所有超支的案例，根子都在上下文。很多人做多轮对话时图省事，把全部历史消息原样带上，聊到第二十轮，单次请求的输入可能已经涨到几万 token，而用户其实只问了一句"刚才那个数是多少"。你付的是全部历史的钱，拿到的却是一句简短回答。

我的做法是三层裁剪：第一层保留最近若干轮原文，保证对话连贯；第二层把更早的历史压成一段摘要，摘要本身也用便宜的小模型生成；第三层把长期有用的事实抽成结构化字段存起来，需要时再拼进 prompt。这套组合拳下来，长对话的成本通常能压到原来的三分之一甚至更低。

还有一个低成本技巧：把固定不变的部分放在 prompt 最前面。很多平台对前缀相同的请求有缓存机制，命中缓存的那部分输入按更低价格计费。这对那种"超长系统提示 + 短用户问题"的场景特别有效，前提是你的系统提示要一字不差地稳定，别每次都动态拼进去时间戳之类的变量。

5.2 缓存、批处理与小模型分流

缓存不用多解释：同样的输入不要算两遍。业务里重复率往往高得惊人，用户问的很多问题本质上是同一批，做一层结果缓存，命中率能到两三成。缓存键记得带上模型名和关键参数，不然换模型后会返回错的结果。

批处理适合那些不要求实时返回的任务，比如离线打标、内容审核、批量摘要。很多平台对异步批处理有折扣价，代价是返回时间可能延迟几小时。对夜间跑的定时任务来说，这个交换非常划算。

小模型分流是我最推荐的习惯：先用便宜的小模型做意图分类和难度判断，简单问题它自己就答了，复杂问题才转给大模型。实际跑下来，七八成的请求根本不需要最强模型，光这一条就能把账单砍一半。判断逻辑不用做得多精细，几个关键词加一个分类 prompt 就够用。

5.3 监控与熔断

再省也不如有个刹车。我在所有会调用 API 的服务里都会加三样东西：按小时统计的 token 消耗曲线、单次请求的 token 上限、以及一个总预算的熔断开关。前两个是日常观测，第三个是保命的——一旦当天消耗超过预设值，服务自动降级到缓存或者直接返回兜底文案，宁可体验差一点，也不能让一个 bug 在一夜之间烧掉一个月预算。

max_tokens这个参数一定要显式设置。不设的话，模型可能一直生成到自然结束，遇到那种爱长篇大论的 prompt，输出长度能吓你一跳。设成业务实际需要的长度，比如摘要任务给 500，分类任务给 20，多一个字都不给。

6. 被问得最多的几个问题

6.1 关于充值和层级

充了最低金额，为什么还是慢？因为层级是按累计充值算的，最低门槛只够进第一层，速率上限本来就低。要么等业务量证明需求后追加充值提升层级，要么在代码里做好限流和排队，别指望瞬间拿到生产级配额。

余额会过期吗？自己掏钱充的余额一般不会过期，但平台赠送的体验额度通常带有效期，过期就清零。这条各平台政策不同，以账单页的说明为准。稳妥做法是别一次充太多，按两三个月的实际消耗量来，既不怕政策变动，也不占资金。

会员到期了，API 会停吗？不会，两套系统独立计费。反过来说，会员在有效期内的这段时间，也不会给你 API 多加一分钱额度。

6.2 关于密钥安全

密钥不小心提交到公开仓库了怎么办？第一动作是立刻去后台删除或轮换这把密钥，别先去改仓库。删除是秒级生效的，改仓库历史再快也要几分钟，这几分钟足够被打出不小的量。删完之后再清理提交历史，顺便把账单告警阈值调低一点，观察几天。

一个项目签几把密钥合适？按调用方拆，一个服务一把，方便单独统计和单独吊销。别全公司共用一把，出了问题既定位不到人，也不敢随便删。

6.3 关于长期成本

怎么估算一个月的花费？拿真实业务样本跑一百次，记录平均输入和输出 token，乘以日均调用量，再乘单价，最后加三成余量。别用"感觉差不多"来估，我见过太多估算和实际差五倍的案例，原因基本都是忽略了上下文累积和输出长度。

什么时候该考虑自建或者换方案？我的经验线是：当 API 月支出稳定超过一个你自己部署同等规模服务的成本，并且调用模式非常固定、对模型能力要求不高时，才值得考虑。绝大多数场景在优化 prompt、加缓存、做模型分流之后，成本能降到原来的几分之一，远没到需要换方案的程度。

最后分享一个我自己的小习惯：每次充值后，我会在后台把硬上限设成充值金额的 80%，然后把告警邮箱打开。这个动作花不了一分钟，但它救过我两次——一次是某段代码忘了退出循环，一次是有人拿测试密钥跑了压测。额度这东西，本质上是给"用程序花钱"这件事装一道闸门，闸门装好了，你才能放心让程序跑。