大模型 API 频繁限流怎么办？并发控制与 API 稳定性提升实战指南

为什么你的大模型 API 总是触发限流？

很多开发者在调用大模型 API 时都遇到过 HTTP 429 错误——请求被限流拒绝了。大模型 API 的限流比传统 Web API 更复杂，通常有两个维度：RPM（每分钟请求数）和 TPM（每分钟 Token 数）。这意味着即使你的并发连接数不高，一旦单次请求输出了很长的推理文本，也可能瞬间触发 TPM 限制。

常见的限流原因包括：短时间内请求频率激增、单次请求 Token 量过大、账号配额耗尽、高峰期服务端负载过高等。要彻底解决限流问题，需要从客户端控制和服务端策略两方面入手。

客户端并发控制：信号量 + 令牌桶

最有效的方案是在客户端主动限速，而不是等触发 429 再退避。两种核心手段：

信号量控制并发数：设置最大并发请求数（如 10-20），超过上限的请求排队等待。这在 Python 中可用 asyncio.Semaphore 实现，在 Node.js 中可用 p-limit 库。

令牌桶限制 RPM：按平台允许的每分钟请求数，匀速释放请求令牌。令牌桶算法能将突发流量平滑为匀速输出，有效避免触发限流。

实际开发中，两者需要配合使用：先获取 RPM 令牌，再获取并发信号量，避免出现占住并发槽位却无令牌可用的死锁。

指数退避重试：被限流后的自救

即使做了前置限流，高峰期仍可能触发 429。此时应使用指数退避重试策略：首次失败后等待 1 秒重试，第二次等 2 秒，第三次等 4 秒，并加入随机抖动避免多个客户端同时重试造成二次拥塞。

import asyncio, random

async def call_with_retry(api_func, max_retries=5):
    for i in range(max_retries):
        try:
            return await api_func()
        except Exception as e:
            if i == max_retries - 1:
                raise
            wait = (2 ** i) + random.uniform(0, 1)
            await asyncio.sleep(wait)

模型降级容灾：多模型 Fallback 路由

生产环境中，单依赖一个模型风险很大。成熟的架构会在网关层配置动态路由：当主用模型持续返回 429 或 5xx 时，自动将请求切换到同级别的备用模型。例如主用 DeepSeek，降级到通义千问，再降级到豆包。

这种多模型降级策略能显著提升服务可用性，但前提是你有一个支持多模型路由的统一入口。不墨 AI API 提供多模型聚合能力，支持在 DeepSeek、千问、豆包等模型间灵活切换，配合流式输出和函数调用 function calling 功能，满足复杂业务场景需求。

流式输出与 function calling 的限流注意点

流式输出虽然能提升用户体验（逐字返回），但流式会话会长时间占用并发连接，对服务端并发能力要求更高。部分平台对流式会话单独设置并发配额，使用时需注意控制流式连接数量。

函数调用 function calling 场景下，模型可能需要多轮调用（先返回函数参数，执行后再次请求），实际请求量会翻倍。建议为 function calling 场景预留更多 RPM 余量，或使用带缓存的模型减少重复调用。

想要更省心地解决限流和稳定性问题？不墨 AI API 平台提供稳定的 API 中转服务，内置并发管理和自动重试机制，让你专注于业务逻辑而非运维细节。