当 AI 工具、自动化脚本或后端服务变慢时，盲目优化往往效果有限。本文介绍一种结构化的响应耗时分析与性能优化方法，帮助你快速定位慢请求。
为什么需要关注 API 响应耗时？
在本地测试时，接口响应稍微慢一点通常不会引起注意。但当程序进入实际运行阶段，可能会遇到这些情况：
- 整体响应时间变长，导致前端用户觉得卡顿
- 批量任务执行时间远超预期
- 无法判断延迟是由于网络、队列排队还是上游模型生成速度慢
- 偶尔出现某些请求耗时翻倍，但不知道原因
性能优化的前提是精确测量。如果不清楚瓶颈在哪个环节，优化往往只是凭感觉。
一、耗时分析的基本原则
一次典型的 AI API 请求可以拆分为以下几个阶段：
发起请求 → 本地 DNS与连接建立 → 发送请求体 → 上游排队与模型生成 → 接收响应数据
在 Python 中，不能只用“结束时间减去开始时间”来简单评估，还需要区分：
- 网络延迟（连接耗时、传输耗时）
- 模型生成延迟（首字延迟、完整生成耗时）
- 排队与限流耗时（本地限流或服务端队列等待）
二、用 time.perf_counter() 测量单次耗时
在 Python 中测量耗时，建议使用 time.perf_counter()，它比 time.time() 更精准：
import time
from openai import OpenAI
client = OpenAI(
api_key="your-api-key",
base_url="https://your-api-domain.com/v1",
)
start_time = time.perf_counter()
response = client.chat.completions.create(
model="your-model-name",
messages=[{"role": "user", "content": "你好"}],
)
elapsed = time.perf_counter() – start_time
print(f"请求耗时：{elapsed:.2f} 秒")
print(response.choices[0].message.content)
这段代码可以帮你获取每次调用的总耗时，并记录在日志中。
三、区分首字延迟与总生成时间
对于流式输出（stream=True），我们可以分别测量接收到第一个片段的时间（Time to First Token, TTFT）和完整接收的时间：
import time
from openai import OpenAI
client = OpenAI(
api_key="your-api-key",
base_url="https://your-api-domain.com/v1",
)
start_time = time.perf_counter()
first_token_time = None
stream = client.chat.completions.create(
model="your-model-name",
messages=[{"role": "user", "content": "写一篇简短说明"}],
stream=True,
)
for chunk in stream:
if first_token_time is None:
first_token_time = time.perf_counter()
content = chunk.choices[0].delta.content
if content:
print(content, end="", flush=True)
end_time = time.perf_counter()
ttft = first_token_time – start_time
total_time = end_time – start_time
print(f"\\n首字延迟 (TTFT): {ttft:.2f} 秒")
print(f"总耗时: {total_time:.2f} 秒")
为什么区分 TTFT 很重要？
- TTFT 大：通常说明模型在排队、服务器负载高、或者提示词过长导致预填充（Prefill）变慢。
- TTFT 小，但总耗时大：说明模型已经开始输出，但生成速度较慢，或者要求的输出长度（max_tokens）设置得过大。
通过这一指标，你可以更准确地判断延迟原因。
四、常见的性能瓶颈与优化方向
1. 提示词过长
如果每次请求都携带数千字的冗余历史或全局文档，预填充阶段就会消耗大量时间。
- 优化方法：精简系统提示词，对长文本做分段摘要，或只传递相关上下文。
2. 输出长度限制不合理
如果任务只需要简短结论，但 max_tokens 设得很大，模型可能会生成不必要的冗长内容。
- 优化方法：根据业务需求合理限制输出长度。
3. 本地并发过高导致排队
客户端同时发起大量请求，超出了本地连接池或服务端的并发承受能力，导致请求在队列中等待。
- 优化方法：使用前文提到的 Semaphore 控制并发，避免无效压测。
4. 模型选择不当
对简单分类、文本清洗等任务直接使用高规格模型，不仅成本高，响应速度也慢。
- 优化方法：按任务复杂度选择合适的模型。
五、在日志中加入耗时指标
建议在统一的请求封装中自动记录耗时：
import time
import logging
logging.basicConfig(level=logging.INFO, format="%(asctime)s | %(levelname)s | %(message)s")
def measure_call(func, *args, **kwargs):
start = time.perf_counter()
try:
result = func(*args, **kwargs)
cost = time.perf_counter() – start
logging.info(f"API success | cost={cost:.2f}s")
return result
except Exception as exc:
cost = time.perf_counter() – start
logging.error(f"API failed | cost={cost:.2f}s | error={exc}")
raise
这样每次调用都会留下耗时数据，方便后续按天或按模型统计平均延迟。
六、批量任务中的耗时统计
在处理批量数据时，可以统计总耗时、平均耗时和失败率：
import time
def run_batch_with_stats(items, handler):
start_total = time.perf_counter()
success_count = 0
fail_count = 0
for item in items:
try:
handler(item)
success_count += 1
except Exception:
fail_count += 1
total_cost = time.perf_counter() – start_total
avg_cost = total_cost / len(items) if items else 0
print(f"总耗时：{total_cost:.2f}s | 平均耗时：{avg_cost:.2f}s | 成功：{success_count} | 失败：{fail_count}")
通过这些基础统计，你可以直观看到批量任务的效率表现。
七、优化时的一般步骤
如果你发现程序变慢，建议按这个顺序排查：
不要一上来就去改架构，先用数据确认瓶颈在哪里。
八、结语
API 性能优化的核心在于测量与定位：
- 用 time.perf_counter() 替代粗略估计
- 区分首字延迟（TTFT）与总耗时
- 检查提示词长度与输出限制
- 在日志中持续记录耗时指标
对于 Python AI 项目来说，建立稳定的耗时监控，不仅能帮你在出现卡顿时快速找到原因，也能为后续的模型选择和架构调整提供数据支撑。
免责声明
本文内容仅用于技术交流与经验分享，具体实现请结合项目实际情况调整。
