如何防止 3900 美元的 LLM API 账单：为评测套件构建成本防护栏

想象一下，第二天早晨醒来，收到财务部门的通知，称你的 CI/CD 环境在短短 9 小时内消耗了 3900 美元的 LLM API 额度。这并非虚构，而是我们机器学习平台团队经历的真实惨痛教训。我们运行着一套包含 1200 个案例的强大 LLM-Judge 评测套件，每个案例都由 Claude 3.5 Sonnet 或 OpenAI o3 等高性能模型进行评分。虽然这套系统成功捕捉到了多次代码退化，但也隐藏了一个致命的成本漏洞，仅在一夜之间就耗尽了我们大部分的月度预算。

在 n1n.ai 看来，构建基于大语言模型的应用不仅仅是提示词工程（Prompt Engineering），更需要工业级的成本观测能力。本文将深度剖析这起事故，并提供我们随后部署的防护代码，以确保此类事件不再发生。

3900 美元账单的由来

我们的评测套件配置为在 GitHub 的每次 synchronize 事件（即每次代码推送）时运行。在 8 月 7 日凌晨，一个依赖更新机器人（Dependency Bot）在三小时内开启了 41 个 Pull Request（PR）。每个 PR 在首次推送、锁定文件更新以及合并队列（Merge Queue）重新基准化时，都会触发完整的评测套件。

灾难背后的算术题：

• 单次评测成本： 约 2,600 输入 Token + 约 550 输出 Token。
• 当时价格： 输入 2.50 美元/百万 Token，输出 10.00 美元/百万 Token（单个案例约 0.012 美元）。
• 单次全量运行： 1,200 案例 × 0.012 = 14.40 美元。
• 放大效应： 41 个 PR × 每个 PR 约 7 次运行 = 270 次总运行。
• 总计支出： 270 × 14.40 ≈ 3,888 美元。

在这短短的几个小时内，我们计费了超过 10 亿个 Token。最令人不安的是，所有评测运行都完美成功，没有任何 5xx 错误，也没有触发频率限制（Rate Limit）。这只是一个运行完美的系统，在执行一个极其昂贵的死循环。

为什么传统的监控手段失效了？

我们监控了系统的可用性和延迟，但 LLM 的成本监控完全是另一回事。以下是现有监控栈失效的原因：

1. 请求数 vs Token 密度： 270 次运行产生的请求量并不大，不足以触发报警。然而，每个请求中的 Token 数量极高。
2. 供应商延迟： 许多 API 供应商的计费控制台存在 24 小时左右的延迟。当我们在面板上看到峰值时，钱已经花掉了。
3. 200 OK 陷阱： 绝大多数生产事故都伴随着报错。但成本失控在供应商看来是“成功”的。只要你的信用卡还能扣款，供应商会非常乐意以 200 OK 的状态持续计费。

为了避免这种风险，开发者需要像 n1n.ai 这样能够提供多模型（如 DeepSeek-V3、GPT-4o）统一视图、更细粒度用量监控的平台。

防护措施 1：预检成本上限（Pre-flight Cost Cap）

最有效的防护措施是在发起 API 调用之前就设置一个“保险丝”。我们利用 tiktoken 库实现了一个预检功能，估算单次运行的成本，并检查是否会超过每日预算天花板。

import tiktoken

# 高性能模型定价（美元/百万 Token）
PRICE_IN_PER_M = 2.50
PRICE_OUT_PER_M = 10.00
DAILY_BUDGET_USD = 120.00  # CI 环境的硬性每日上限

def encoding_for(model: str):
    try:
        return tiktoken.encoding_for_model(model)
    except KeyError:
        # 针对 DeepSeek-V3 或 o3 等新模型的兼容处理
        return tiktoken.get_encoding("o200k_base")

def projected_cost(prompts: list[str], est_output_tokens: int, model: str) -> float:
    enc = encoding_for(model)
    # 统计输入 Token
    in_tokens = sum(len(enc.encode(p)) for p in prompts)
    # 估算输出 Token
    out_tokens = est_output_tokens * len(prompts)
    return (in_tokens / 1e6) * PRICE_IN_PER_M + (out_tokens / 1e6) * PRICE_OUT_PER_M

def cost_guard(prompts, est_output_tokens, model, spent_today):
    run_cost = projected_cost(prompts, est_output_tokens, model)
    if spent_today + run_cost > DAILY_BUDGET_USD:
        raise SystemExit(
            f"评测被拦截：预计支出 ${run_cost:,.2f} 将导致今日费用超过 ${DAILY_BUDGET_USD:,.2f} 的上限。"
        )
    return run_cost

防护措施 2：结果缓存（Result Caching）

在 CI 环境中，尤其是处理依赖更新时，模型针对相同问题的回答往往是字节级一致的。我们实现了一个缓存层，Key 值由 rubric_version（评分标准版本）、case_id（案例 ID）和 sha256(candidate_answer)（候选回答哈希）组成。

如果输入没有变化，为什么要重复付费让模型重新评分？在我们的事故中，如果开启了缓存，账单将从 3888 美元骤降至 14.40 美元，节省 99.6%。

防护措施 3：分层抽样（Stratified Sampling）

并非每个 PR 都需要全量 1200 个案例的评测。我们修改了 CI 逻辑：

• 主分支（Main）/ 合并队列： 100% 全量评测（1200 案例）。
• 特性分支 / 机器人 PR： 10% 分层抽样（120 案例）。

这确保了开发者在日常开发中依然能获得关于重大退化的反馈，而不会因为微小的文档修改或依赖升级而支付全额费用。

防护措施 4：实时支出速率告警

最后，我们将监控重心从“请求数”转向了“每小时支出金额”。现在，如果任何 API Key 的支出超过其过去 7 天每小时中位数的 3 倍，系统就会立即发出告警。这使我们的信号从“服务是否在线”转变为了“服务是否负担得起”。

总结

在 LLM 时代，系统稳定性不仅关乎正常运行时间（Uptime），更关乎财务稳定性。如果你正在使用 Claude 3.5 Sonnet 或 DeepSeek-V3 等先进模型，绝对不能仅依赖月度账单作为反馈回路。通过将防护逻辑直接集成到你的评测框架中，你可以在保持开发速度的同时，守住你的预算。

对于希望以更受控、更具成本效益的方式访问全球顶级模型，并获得统一监控能力的开发者，推荐尝试 n1n.ai 提供的 API 聚合服务。

立即在 n1n.ai 获取免费 API Key。