什么是成本上限？防止 API 账单失控的设置

成本上限指在 AI 开放平台上预先设置的费用或用量限制：达到阈值就停止服务或触发预警，用来防止 API 调用把账单推到失控的地步。它的价值是把风险从「月底账单见分晓」提前到「过程中就被拦住」，凡是接 API 做应用或批量处理，都应该在写第一行调用代码之前先把上限设好。

账单为什么会失控

失控几乎都源于三个漏洞。其一是循环与重试：代码里的重试逻辑在服务异常时反复调用，几百次失败重试叠加起来就是一笔可观的费用。其二是用量预估失真：测试阶段一次调用几分钱，上线后调用量放大百倍，按测试期的直觉设预算必然不够。其三是密钥泄露：密钥被提交到公开仓库或写进前端代码，被他人盗用产生调用。三种情况有共同点——单次调用便宜到可以忽略，累计起来才发现不对，这正是上限存在的意义。还有一种容易被忽略的情形：缓存失效导致重复生成，同样的请求反复计费，用量曲线看着正常，账单却对不上，排查时要把它算进嫌疑名单。

成本上限靠哪些设置兜底

主流平台提供三类闸门。余额与限额类：预充值模式下天然有余额下限，余额耗尽调用即停；后付费模式则可设置消费上限，到达即暂停服务。用量类：按请求数、token 数设置日限额与月限额，从量上封顶。告警类：消费达到设定比例时发送通知，比如消费过半就推送提醒，留出人工介入的时间窗。三类叠加使用更稳妥：告警负责提前看见，限额负责硬性截停，缺了任何一层，异常流量的代价都要真金白银去付。设置完成后用一次小规模压测验证闸门真的生效，别等到真出事故才发现限额没配对。

用 DeepSeek 前先算一笔账

接 DeepSeek 这类按 token 计费的服务，动手前值得估算一遍：假设应用每天处理一万次请求，平均每次输入输出合计两千 token，按官方公布的当前单价算出月账单，再乘以二到三的波动系数作为预算基数。这个估算不需要精确到分，量级对了就够，官方价格以最新公告为准。估算完直接把月限额设在这个数附近，超限即停，宁可中断服务排查，也不要无条件放行调用。

限流与预警怎么搭配

除了成本上限，调用侧也该做限流：控制每分钟请求数，避免突发流量瞬间烧掉大额费用。工程上的常见组合是三层——账户层设月度消费上限，应用层按日设 token 限额，代码层做请求间隔与重试上限。预警通知务必发到有人看的渠道，发到一个无人订阅的邮箱等于没设。每月固定看一次用量报表，对比预算与实际的偏差，发现异常调用模式及时排查密钥与代码，把小异常拦在变成大账单之前。多人协作的项目还要管好密钥分配：一个项目一把密钥，用量能对应到具体业务，出了问题也知道该找谁、该停哪把钥匙。

延伸阅读：按量计费突然变贵的原因、预算告警阈值怎么设、请求被拒的 429 是什么。

上线前先补的五个漏点

• 测试环境单独设一个很小的日限额
• 重试逻辑加次数上限，防止循环烧钱
• 一个项目一把密钥，别写进前端代码
• 告警发到有人看的渠道，别发空邮箱
• 设完做一次小规模压测确认闸门生效

五条里最常被跳过的是压测这一步，限额配了却没生效，等于没设。

API 成本上限设多少合适，超出之后会怎样？

• 上限触发后服务立即中断吗？：多数平台在达到硬上限后拒绝新的调用，进行中的请求执行完毕，恢复方式是提额或等下一周期，具体策略以各平台文档为准。
• 测试阶段也要设上限吗？：更要设。测试代码最容易写出死循环与疯狂重试，给测试环境单独设一个很小的日限额，是成本最低的保险。
• 密钥泄露了第一时间做什么？：立即在控制台吊销该密钥并换新，同时检查用量报表确认异常调用的时间段与数量，必要时联系平台协助处理。