共计 1426 个字符,预计需要花费 4 分钟才能阅读完成。
背景痛点
在调用 ChatGPT 大模型 API 时,开发者经常会遇到以下几个典型问题:

- Token 消耗计算 :长文本请求会导致 Token 消耗剧增,成本难以控制
- 速率限制 :API 有严格的每分钟请求数限制(RPM)和每分钟 Token 限制(TPM)
- 长文本处理 :当上下文超过模型最大限制(如 gpt-3.5-turbo 的 4096 tokens)时,请求会被直接拒绝
常见错误场景包括:
- 收到 429 状态码(请求过多)
- 上下文长度超出模型限制
- 流式响应在网络波动时中断
技术方案
同步 vs 异步调用
通过基准测试对比(1000 次 API 调用):
- 同步方式:平均耗时 42 秒,吞吐量 23.8 请求 / 秒
- 异步方式:平均耗时 8.7 秒,吞吐量 114.9 请求 / 秒
连接池优化
使用 aiohttp 实现连接池复用的关键配置:
conn = aiohttp.TCPConnector(
limit=100, # 最大连接数
limit_per_host=50, # 单域名最大连接
enable_cleanup_closed=True # 自动清理关闭连接
)
指数退避重试策略
设计包含熔断机制的重试逻辑:
- 初始等待时间:1 秒
- 最大重试次数:3 次
- 退避因子:2(每次等待时间翻倍)
- 熔断阈值:连续 5 次失败后暂停请求 30 秒
代码实现
异步 API 客户端核心类
class AsyncChatGPTClient:
def __init__(self, api_keys: list):
self.api_keys = deque(api_keys) # API 密钥轮换队列
self.semaphore = asyncio.Semaphore(100) # 并发控制
self.token_counter = TokenCounter() # 令牌消耗统计
async def send_request(self, messages):
async with self.semaphore:
current_key = self._rotate_key()
try:
return await self._send_with_retry(messages, current_key)
except MaxRetryError:
# 触发熔断逻辑
self._circuit_breaker()
令牌消耗计算
def calculate_tokens(text):
# 近似计算:英文 1token≈4 字符,中文 1token≈2 字符
chinese_chars = len(re.findall(r'[\u4e00-\u9fa5]', text))
other_chars = len(text) - chinese_chars
return math.ceil(chinese_chars/2 + other_chars/4)
生产级优化
监控指标设计
推荐采集的关键指标:
- P99 延迟:<500ms
- 每分钟成功请求数:≥1000
- Token 消耗速率:≤80% 配额
冷启动预热方案
- 服务启动时预先建立 10 个连接
- 发送 5 个低优先级测试请求
- 逐步提高并发量至目标水平
避坑指南
上下文超长处理
自动分割策略:
- 按句子边界分割文本
- 保留最近 3 轮对话上下文
- 添加连续性标记(如 [续接上文])
敏感数据过滤
建议采用双重过滤:
- 客户端过滤:使用正则匹配手机号 / 邮箱
- 服务端过滤:配置内容审核 API
突发流量应对
分级降级方案:
- 一级降级:关闭流式响应
- 二级降级:限制上下文长度
- 三级降级:返回缓存结果
开放性问题
在实际应用中,如何平衡以下因素:
- 响应延迟(用户等待时间)
- Token 消耗(API 调用成本)
- 回复质量(最大上下文长度)
欢迎在评论区分享你的实践经验。
正文完
