选型之后：怎么持续监控你的 API 供应商

为什么第三方监测不够

本站的监测数据有用，但有两个局限：

1. 测量点不是你的位置 —— 你的网络到该站的线路可能完全不同
2. 不测你的业务流 —— 它测可达性，不测你实际调用的模型是否正常

所以自建一个轻量探针是值得的。不复杂，几十行代码。

探针测什么

不要只测「网站能不能打开」。至少要覆盖：

「实际调用」这一项最重要 —— 站点可达但模型全挂的情况是存在的。

一个最小探针

import time, requests

def probe(name, base_url, key, model):
    t0 = time.time()
    try:
        r = requests.post(
            f"{base_url}/v1/chat/completions",
            headers={"Authorization": f"Bearer {key}"},
            json={"model": model, "messages": [{"role": "user", "content": "ping"}],
                  "max_tokens": 3},
            timeout=20,
        )
        return {"name": name, "ok": r.status_code == 200,
                "status": r.status_code, "ms": int((time.time() - t0) * 1000)}
    except Exception as e:
        return {"name": name, "ok": False, "status": 0,
                "ms": int((time.time() - t0) * 1000), "err": str(e)[:60]}

结果写进一张表（哪怕就是 CSV），跑一周你就有了一份符合自己网络环境的可靠性数据。

阈值怎么定

不要照搬别人的标准，用自己的历史数据定：

1. 先跑一周，收集基线
2. 算出正常时的 P95 延迟
3. 把告警阈值设为 P95 的 2 倍
4. 失败率同样处理

这样定出来的阈值才不会天天误报。 拍脑袋定一个「超过 1 秒告警」的结果通常是：告警天天响，然后你开始忽略它。

什么时候该换供应商

触发切换评估的情况：
- 连续 3 天失败率明显高于基线
- 延迟中位数翻倍且持续
- 出现稳定性之外的问题（如客服失联）
- 计费开始出现无法解释的偏差

「无法解释的计费偏差」特别值得警惕 —— 它可能是配置问题，也可能是更严重的事情。

配套的三件事

一、余额告警。 余额不足是最常见的「故障」，且完全可预防。设一个阈值（比如低于 3 天用量时告警）。

二、记录切换事件。 如果配置了多通道互备，记录每次切换。切换频率上升是供应商质量下降的早期信号。

三、定期人工检查。 每月花十分钟：看一眼用量趋势、看一眼有没有新公告、试一次客服响应。自动化能发现问题，但判断质量问题还需要人。

一个容易被忽略的指标

你的实际单位成本（元/百万 token）的趋势。

算法：本月支出 ÷ 本月消耗 token 量。

如果这个数字在上升（而使用结构没变），可能是：站点调价了、计费口径变了（比如缓存不再生效）、或你的 token 结构变了。

这个指标能捕捉到那些从账单总额上看不出来的变化。

相关阅读

• 怎么给项目配置多家 API 互备
• 从官方价到你的账单：一次完整的成本换算演练
• 可用率是怎么测出来的：本站的统计口径与局限