AI 代理

所有主流 AI 平台都会限制您可以发送的请求数量。OpenAI、Anthropic、Google、DeepSeek——它们都按账户、按分钟、按天设有用量上限。当您构建产品、运行自动化任务或批量处理数据时，一个账户加一个 IP 很快就会触及上限。您会收到 429 错误，排队的请求不断堆积，整个流水线陷入停滞。

AI 代理服务器位于您的应用程序与 AI 服务商之间。您将请求发送到代理，代理将其分发到多个 API 密钥，每个密钥通过各自独立的 IP 地址发出。服务商看到的是多个独立用户，而非一个负载过重的账户。您的总容量成倍增长，同时每个密钥都安全地保持在限额之内。实际使用中，配置良好的代理每个请求仅增加 15–30ms 的延迟——对于批量处理来说完全可以忽略，即使在实时聊天应用中也几乎察觉不到，因为模型本身的生成时间通常在 500–3000ms。

这之所以有效，是因为 AI 平台将速率限制绑定到账户而非 IP——但它们确实会监控 IP 模式。如果一个地址在短时间内轮转 10 个不同的 API 密钥，就会被标记为异常。为每个密钥分配独立的独享代理，确保一切看起来自然。您还需要一套故障转移策略：监控每个密钥的错误率，一旦某个 IP 开始持续返回 429 或 403 错误，就自动将其从池中移除，并将该密钥的流量路由到备用 IP。每 60 秒对每个密钥-IP 组合进行一次健康检查，可以在问题扩散之前及时发现。

实际配置效果

无论使用哪个服务商，大多数 AI API 代理的搭建模式都是相同的。您运行一个轻量级代理服务器（FastAPI、Node、Go——取决于您的技术栈），其中维护一个 API 密钥池。当请求到达时，代理选择下一个可用的密钥，通过该密钥对应的 IP 路由请求，然后返回响应。如果某个密钥收到 429（速率限制错误），代理自动切换到下一个。以下是一个使用 FastAPI 和 httpx:

import httpx, itertoolsfrom fastapi import FastAPI, Request, Response

@app.post("/v1/chat/completions")async def proxy(request: Request): body = await request.json() slot = next(keys) async with httpx.AsyncClient(proxy=slot["proxy"]) as client: r = await client.post( "https://api.openai.com/v1/chat/completions", json=body, headers={"Authorization": f"Bearer {slot['api_key']}"}, ) # TODO: Add retry logic on 429 — try next key/IP before returning error to caller return Response(content=r.content, status_code=r.status_code)

注意：此最小示例使用 itertools.cycle 以简化演示，但不会自动处理 429 错误重试。在生产环境中，请添加重试逻辑——跳过被限流的密钥，尝试下一个可用的密钥-IP 对，然后再向调用方返回错误。由于几乎所有 AI 供应商现在都支持 OpenAI API 格式，一个代理即可处理各 AI 供应商所需的格式转换——路由到正确的供应商，您的应用程序无需感知差异。只需按供应商切换 base URL 和密钥池，同一个 20 行代码的服务器即可覆盖 OpenAI、Anthropic、Google 和 DeepSeek。