大模型 API 限流 429 报错怎么办？限流、并发与流式输出实战指南

大模型 API 限流机制：RPM 与 TPM

调用大模型 API 时，429 错误是开发者最常遇到的问题。几乎所有大模型厂商都设置了双重限流：RPM（每分钟请求数）和 TPM（每分钟 Token 数）。OpenAI API 对每个账户按 Usage Tier 分配不同额度，Tier 1 仅支持较低的 RPM 和 TPM，充值后自动升级。国产模型方面，DeepSeek 官方未设硬性并发上限，但负载高时会动态限流；阿里云百炼按 UID 限流，不同模型额度独立。

一个常见误区是：很多人以为开了流式输出（Streaming）就能省 Token，实际上流式输出只是分块返回内容，Token 计量方式与同步调用完全相同，省的只是用户等待时间。

429 报错的三种典型场景

第一，RPM 超限：短时间内发送过多请求。第二，TPM 超限：长 Prompt 消耗大量输入 Token，一条请求就可能打满 TPM 额度。第三，增速保护：请求频率短时间激增，即使总量未超限也会被拦截。排查时注意查看 429 响应的 Retry-After 头，它会告诉你需要等待多少秒。

指数退避 + 随机抖动：标准重试策略

解决 429 的核心方法是指数退避重试，配合随机抖动避免惊群效应：

import time, random
def call_with_retry(client, messages, max_retries=5):
    for attempt in range(max_retries):
        try:
            return client.chat.completions.create(model='deepseek-chat', messages=messages)
        except Exception as e:
            if '429' in str(e) and attempt < max_retries - 1:
                wait = (2 ** attempt) + random.uniform(0, 1)
                time.sleep(wait)
            else:
                raise

并发控制：Semaphore + 令牌桶

仅靠重试不够，还需主动控制并发。关键区别：Semaphore 控制同时在飞的请求数量，令牌桶控制每分钟发送频率，两者缺一不可。建议将并发数设置为 RPM 上限的 50%-70%，留出缓冲。

import asyncio
semaphore = asyncio.Semaphore(10)
async def chat_one(prompt):
    async with semaphore:
        return await client.chat.completions.create(...)

Function Calling 与流式输出的配合

使用 Function Calling（函数调用）时，流式输出可以实时获取工具函数名称与入参信息，提升用户体验。阿里云百炼文档指出，千问 Omni 模型仅支持流式输出，在获取工具信息时必须设置 stream=True。工作流程为：模型返回工具调用信息，客户端执行函数，再将结果返回模型，模型生成最终回复。

选择稳定的中转服务

自建限流和重试逻辑虽然有效，但维护成本不低。不墨 AI API 提供稳定的 API 中转服务，内置智能负载均衡和自动重试机制，后端有多通道冗余，单个模型服务限流时自动切换通道，开发者无需自行实现复杂的容错逻辑。

小结

大模型 API 限流是工程实践中不可回避的问题。核心应对策略：客户端主动限速（Semaphore + 令牌桶）+ 指数退避重试 + 多模型 Fallback。对于追求稳定性的生产环境，选择一个靠谱的 API 中转服务 可以将限流处理交给平台，让开发者专注于业务逻辑。