调用大模型 API 的几个最佳实践：重试、降级与审计

wuwenzen@outlook.com (wuwj) — Mon, 05 Jun 2023 00:00:00 +0000

刚开始用大模型 API 时，大家一般关心的是：

这个模型效果好不好？回答聪不聪明？

但当你真的把它作为「线上能力」接入产品时，会发现很多工程问题：

API 偶尔超时 / 报错怎么办？
费用怎么控？
返回内容里如果有敏感信息怎么办？
出了问题，怎么排查某次请求？

这篇文章就是从这些「落地问题」出发，整理几条接入大模型 API 的最佳实践。

1. 超时与重试：别把前端一直挂着

1.1 超时要有明确上限

大模型生成本身需要时间，如果不设超时，前端可能会一直转圈。
我们一般做法：

在 BFF / 中间层对每个调用设定超时时间（例如 10–15 秒）；
超时后直接返回「超时错误」，由前端给出友好提示；
前端也设置请求超时，避免被挂死。

1.2 重试策略

常见错误类型：

临时网络抖动；
API 限流（429）；
服务端偶发异常。

对幂等请求（比如生成建议文案），我们采用：

指数退避重试：例如最多重试 2 次，间隔 500ms / 1000ms；
遇到某些错误码（如 4xx 中的参数错误）不重试。

伪代码：

async function callLLMWithRetry(payload) {
  const maxRetry = 2;
  let attempt = 0;

  while (true) {
    try {
      return await callLLM(payload);
    } catch (e: any) {
      if (!isRetryableError(e) || attempt >= maxRetry) {
        throw e;
      }
      attempt++;
      await sleep(500 * attempt);
    }
  }
}

2. 降级：模型不可用时要有「备胎」

大模型 API 作为外部依赖，不可能 100% 可用。
因此建议设计「降级方案」：

审计 on Saiga

调用大模型 API 的几个最佳实践：重试、降级与审计

1. 超时与重试：别把前端一直挂着

1.1 超时要有明确上限

1.2 重试策略

2. 降级：模型不可用时要有「备胎」