2.7 API成本控制与性能优化：Token计费与重试机制
一、成本控制
1.1 Token计费
OpenAI按输入+输出Token计费，不同模型单价不同。优化建议：
- 精简system与user提示，删除冗余内容
- 控制max_tokens，避免过长输出
- 长对话考虑上下文截断或摘要
《大模型应用开发极简入门》第2章「考虑因素」将成本控制（Token 计费、批量请求、缓存策略）与性能优化（延迟、吞吐量、错误处理、重试机制）并列。本节与之对应，并提供可直接落地的代码与检查清单。
1.2 批量与缓存
- 批量请求可降低单次成本
- 使用Prompt Caching缓存重复系统提示（部分模型支持）
二、性能优化
2.1 延迟
- 选择gpt-3.5-turbo或gpt-4o-mini可降低延迟
- 流式输出（stream=True）可提升首字响应时间
2.2 重试机制
from tenacity import retry, stop_after_attempt, wait_exponential
@retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=2, max=10))
def call_api(prompt):
return client.chat.completions.create(model="gpt-3.5-turbo", messages=[{"role":"user","content":prompt}])
三、重试机制详解
3.1 指数退避
失败后等待时间逐渐增加：第1次等1秒，第2次等2秒，第3次等4秒...避免在服务恢复前持续轰炸。
3.2 tenacity示例
from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type
@retry(
stop=stop_after_attempt(3),
wait=wait_exponential(multiplier=1, min=2, max=60),
retry=retry_if_exception_type((ConnectionError, TimeoutError))
)
def call_api(messages):
return client.chat.completions.create(model="gpt-3.5-turbo", messages=messages)
3.3 不重试的场景
AuthenticationError、InvalidRequestError等客户端错误不应重试，直接返回用户。仅对网络超时、RateLimitError、5xx等可恢复错误重试。
四、流式输出优化
流式输出可提升首字响应时间，用户感知更快。实现时注意：
- 边收边渲染，不要等完整响应
- 错误可能在流中发生，需处理不完整流
- 流式模式下
usage可能最后才返回，需在流结束后获取
五、批量与异步
对大批量请求，可使用异步客户端并发调用，注意控制并发数避免触发限流。OpenAI支持批量API（Batch API），适合非实时任务，成本更低。
六、与《大模型应用开发极简入门》第2.7节的对应
本书第2章「考虑因素」专门讲成本控制（Token 计费、批量请求、缓存策略）与性能优化（延迟、吞吐量、错误处理、重试机制）。本节与之对应：Token 计费与精简提示、批量与缓存对应「成本控制」；延迟、流式输出、重试机制对应「性能优化」；不重试的客户端错误对应「错误处理」的区分。书中强调的「考虑因素」是上线前必须过一遍的清单，本节给出可直接落地的代码与策略。
七、Token 估算与用量监控
7.1 估算工具
可使用 tiktoken 库（OpenAI 推荐）在发送前估算 Token 数，避免超限或成本失控：
import tiktoken
enc = tiktoken.encoding_for_model("gpt-3.5-turbo")
tokens = enc.encode("你的文本")
print(len(tokens)) # 约等于本次文本的 Token 数
7.2 用量统计
每次调用的 response.usage 包含 prompt_tokens、completion_tokens、total_tokens。可在中间件或封装函数中累加，按日/周统计，结合单价估算成本，便于做预算与优化。
7.3 成本告警
当累计 Token 或估算费用超过阈值时，可发送告警（邮件、钉钉等），避免因异常流量或逻辑错误导致高额账单。
八、限流与并发控制
8.1 OpenAI 限流
不同账户与模型有不同 RPM（每分钟请求数）与 TPM（每分钟 Token 数）限制。触发限流时会返回 RateLimitError，需配合重试与退避。
8.2 客户端并发控制
在应用层限制并发请求数（如信号量、队列），避免瞬时大量请求触发限流。对非实时任务可排队串行或限制并发数（如 5–10）。
十、与书中第2.7节「考虑因素」的完整对应
本书第 2 章「考虑因素」将成本控制（Token 计费、批量请求、缓存策略）与性能优化（延迟、吞吐量、错误处理、重试机制）并列。本节结构与之对应：第一至三节对应成本与重试；第四至五节对应流式与批量；第六节对应书中考虑因素的整体定位；第七至八节对应 Token 估算、用量监控、成本告警与限流。开发上线前可按本节逐项检查，确保成本与稳定性在可控范围内。书中未展开的「批量 API（Batch API）」适合非实时、大批量任务，可在 OpenAI 文档中查阅 Batch 接口，与本节的重试、并发控制配合使用。
十二、成本与稳定性检查清单（对应书 2.7）
上线前建议逐项确认：（1）Token：是否用 tiktoken 或 response.usage 做了用量统计与预算告警；（2）重试：是否对可恢复错误（限流、超时、5xx）做了指数退避重试，且对客户端错误（4xx、参数错误）不重试；（3）流式：对需要首字延迟体验的场景是否启用 stream=True，并正确将完整回复追加到 messages；（4）并发与限流：是否限制了并发数、是否处理了 RateLimitError；（5）缓存：对重复或相似请求是否有缓存策略。书中「考虑因素」在本节已转化为可执行的检查项，便于团队在发布前做成本与稳定性评审。
十一、小结
成本控制与性能优化是生产级应用的关键。通过 Token 优化、重试与流式输出，可显著提升稳定性与用户体验。下一节将介绍 Embeddings 与 Moderation API。将本节与第 2.1 节的 Token、温度等参数结合，即可形成从单次调优到整体成本与稳定性管理的完整实践。
十三、与 2.2 模型选型、2.5 多轮对话的衔接
2.2 节模型选型：不同模型单价差异大（如 gpt-4 远高于 gpt-3.5-turbo），成本控制需与选型结合。在 2.2 节选定模型后，在本节用 tiktoken 与 usage 统计该模型的 Token 消耗，设定预算与告警。2.5 节多轮对话：多轮会导致单次请求的 prompt_tokens 随轮次增长，成本线性上升。需在 2.5 节的上下文截断策略与本节成本监控间取得平衡：例如只保留最近 N 轮，或对早期轮次做摘要后再送入，既保证对话连贯又控制 Token。
十四、错误码与重试策略速查
| 错误类型 | 是否重试 | 说明 |
|---|---|---|
| RateLimitError | 是 | 限流，指数退避后重试 |
| Timeout / ConnectionError | 是 | 网络或服务暂时不可用 |
| APIError (5xx) | 是 | 服务端错误，可短暂重试 |
| AuthenticationError | 否 | 密钥错误，需修正配置 |
| InvalidRequestError | 否 | 参数或内容违规，需修正请求 |
仅对「可恢复」的错误重试，避免对永久性错误无限重试导致延迟与资源浪费。书中「错误处理、重试机制」在本节已细化为错误码分类与 tenacity 示例。与 2.1 节 Token 的关系：单次请求的 Token 消耗由 prompt 与 completion 共同决定，2.1 中的上下文、max_tokens 直接影响成本；在网关或封装层累加 response.usage 即可实现按用户、按模型的用量统计，与本节成本告警衔接。
下一节预告：2.8 Embeddings API与Moderation API实战应用详解
