阿里云免费额度用完即停

很多人第一次碰到「免费额度已用完」是在半夜，接口突然全部报错，以为是账号被封或者服务下线。实际多数情况是免费额度触顶后系统按规则停掉了调用，付费没开、余额不够、或者套餐没续上都会走到这一步。这篇把判定顺序和恢复动作按能照着做的顺序列出来，具体阈值和当前额度数字请到站内阿里云百炼页面核对。

很多人第一次碰到「免费额度已用完」是在半夜，接口突然全部报错，第一反应是账号被封或者服务下线。实际多数情况是免费额度触顶后系统按规则停掉了调用，付费没开、余额不够、或者套餐没续上都会走到这一步。这篇把判定顺序和恢复动作按能照着做的顺序列出来，具体阈值和当前额度数字请到站内 /sites 里阿里云相关页面核对。

先记住一件事：报错信息只是现象，不是原因。同一个「调用失败」，可能是额度停了、可能是被限速、也可能是模型侧临时波动。下面这套顺序的核心思路是先把「钱和额度」这条线排干净，再去看其他因素。

先分清是「额度停」还是「账户停」

额度停

免费额度本周期用尽，且账号没有可用的付费通道，调用被直接拒绝

账户停

欠费、余额不足或未实名等账户级问题，跟用了多少免费额度关系不大

限速停

单位时间请求过多触发的拒绝，额度可能还剩不少，等一会儿或降并发就能恢复

三种情况表现都是接口报错，但处理路径完全不同。排查顺序建议固定下来：先看控制台的额度与计费状态页，再看最近一次调用返回的错误码，最后看有没有欠费记录。不要一上来就重建 API Key，这个是白忙，Key 本身没问题的话重建只会把已经跑通的服务弄断。

• 如果状态页显示额度归零且计费未开通，那是额度停，按下一节的处理顺序走
• 如果状态页显示有余额但调用仍失败，优先怀疑限速或模型侧问题
• 如果同时有多个项目共用同一账号，先确认是不是别的项目把额度吃掉了
• 如果是模型下线公告导致的报错，那不是额度问题，去站内公告或模型目录页核对

恢复服务前按这个顺序确认四件事

这四件事的顺序不建议打乱。因为每往下一步走，能排除的可能性就少一层，先做后面的步骤容易反复试错。确认完基本能定位到是「补通道」、「换模型」还是「查内鬼」。

第二项里「够一次最小调用」这个判断容易被忽略。余额不是零但不够覆盖一次请求，系统同样会拒绝，看起来就像免费额度的问题。具体最低扣费门槛到站内 /price-watch 核对当时的数字，别凭印象判断。

恢复调用的处理步骤

1. 切通道开通按量付费或充值，把账号状态从「仅免费」切到「可付费」。这一步做完通常不是立刻生效，等几分钟再测。
2. 不想付费时的替代动作切到还有免费额度的模型、降低调用频率、把批量任务挪到离线时段。三条可以同时做，效果比单做一条稳。
3. 验证恢复后先跑一次最小请求，确认返回正常，再逐步放开流量。不要一口气把积压任务全放出去。
4. 加护栏给团队加预算告警和单任务请求上限，把「跑飞一整晚」这类事限制住。

换模型这一步要注意兼容性：不同模型的入参格式、返回结构、上下文长度都可能不一样，直接改个模型名就上线，很可能报的是参数错误而不是额度错误，最后排查方向又跑偏。先在测试环境验证一轮再切。

下次不想再被停：几条低成本习惯

上面说的是被停之后怎么救。真正省事的是别让它停，下面几条习惯成本很低，但能挡掉大部分半夜报错。

• 把免费额度和付费额度分开记账，混用时成本归属算不清，参考站内关于免费额度与付费额度混用的分摊方法
• 在客户端做额度余量检查，剩得少时自动降级到便宜模型或排队
• 给非关键任务设请求上限，宁可少跑也不要半夜断掉线上功能
• 定期对一遍用量记录和账单，别等停了才发现用量早就翻了几倍
• 把额度检查做进健康检查接口，停之前能先收到自己的告警而不是用户的投诉

最后提醒一句判断标准：免费额度适合验证和小流量跑通，不适合承载有稳定用户的功能。如果你的服务已经有人在用，就应该按付费通道来设计容量，免费额度只当缓冲。什么时候可以继续依赖免费额度？只有在调用量小、可随时中断、断了也不影响别人的场景下才成立。