按量计费 API 的工程账：预算控制与断路器设计

上一篇聊了 OpenAI 兼容迁移，这篇接着聊钱的事：按量计费解除了包月的沉没成本，但也意味着失控的调用直接等于失控的账单。工程上怎么防。

一、按量的双刃剑

包月制的坏处是人尽皆知的：不用也扣钱。按量计费反过来：用多少花多少，单价看着低，但没有预算护栏就是裸奔——一个死循环的重试逻辑，一夜能烧掉一个月预算。

所以按量架构的工程要点不是省钱，是让支出可预期。

二、预算控制的三层防线

第 1 层：客户端限流（硬防线）

class BudgetGuard:
    def __init__(self, daily_limit_cents):
        self.daily_limit = daily_limit_cents
        self.spent = 0

    def check(self, estimated_cost_cents):
        if self.spent + estimated_cost_cents > self.daily_limit:
            raise BudgetExceeded(f"today {self.spent}/{self.daily_limit}")
        self.spent += estimated_cost_cents

调用前预估成本（token 数 × 单价），超限直接拒绝。预估宁可高不可低。

第 2 层：断路器（熔断防线）

错误暴增时最贵的不是失败调用本身，是失败后的重试风暴：

class CircuitBreaker:
    def __init__(self, fail_threshold=10, reset_after=300):
        self.failures = 0
        self.opened_at = None

    def allow(self):
        if self.opened_at and time.time() - self.opened_at > self.reset_after:
            self.failures = 0
            self.opened_at = None
            return True
        return self.opened_at is None

    def record_failure(self):
        self.failures += 1
        if self.failures >= self.fail_threshold:
            self.opened_at = time.time()

连续失败直接熔断 5 分钟，别让重试逻辑替你烧钱。

第 3 层：账单对账（软防线）

每天拉一次平台的用量明细，和本地 BudgetGuard 的累计值对账。差异超过 10% 就要查——通常是「预估不准」或「有调用点绕过了门面层」两种。

三、供应商侧的选择标准

按量平台的工程友好度差异很大，选型看四点：

1. 用量明细 API 是否实时可查（对账依赖它）
2. 余额是否过期——预充值型平台如果余额有有效期，闲置就是隐性成本；算邻坊（suanlinfang.cn?from=cnblogs-pg）这类余额永不过期的平台对低频项目友好
3. 告警通知：余额阈值告警有没有、能不能 webhook
4. OpenAI 兼容：前面说过，切换成本的决定因素

四、真实账单复盘

我们这个内部工具（日均 2 万次调用）改造后：

• 预算内调用占比：99.7%（改造前没有这个概念）
• 断路器月均触发 2~3 次，每次拦掉的是潜在几十元级的重试风暴
• 对账差异稳定在 3% 以内（预估系数调优后）

五、小结

按量计费把成本决策从「月初买套餐」变成了「每次调用的工程约束」。三层防线——客户端预算、断路器、日对账——是让这种模式可持续的基础设施。没有它们，按量的灵活性就是账单的放大器。

预算控制的完整代码模板放评论区置顶了。