Log number of retries at INFO level

快速结论：这不是运行时报错，而是 OpenAI Python SDK 的重试日志可观测性改进请求。当请求因限流或连接问题触发重试时，日志只在 INFO 级别提示发生了重试，而 “retries_taken / max_retries” 具体次数只在 DEBUG 级别输出，导致生产环境无法判断第几次重试。可优先升级到包含该改动的 SDK 版本。

适用环境：OpenAI Python SDK（sync / async 客户端）；Issue 涉及 _base_client.py 中的 _sleep_for_retry 相关逻辑。Issue 未提供具体 Python、CUDA、显卡或操作系统版本信息。

最快修复方案：暂无确认的一步修复方案。维护者表示 #3867（pending merge）会把重试次数和上限加入现有 INFO 日志，覆盖同步与异步客户端；在对应版本发布后升级 SDK 即可。

注意事项：该改动属于日志格式增强，不改变重试策略本身；#3867 在 Issue 关闭时仍处于待合并状态，实际可用版本请以发布记录为准。自行临时调整日志级别（如把重试相关 logger 设为 DEBUG）会同时引入其他调试日志，属于可优先尝试但不等于官方方案的绕过手段。

问题场景

使用 OpenAI Python SDK 调用接口时，请求遇到限流（429）或服务端 / 连接错误会进入自动重试流程。用户希望在生产环境日志中直接看到当前是第几次重试、总共允许重试几次，但 SDK 只在 INFO 级别记录了“发生重试”，重试计数信息被放在 DEBUG 级别，默认日志级别下不可见。

报错原文

In the _sleep_for_retry methods in _base_client.py, the fact that a retry is happening is logged at the INFO level, but the retries_taken and max_retries are only logged at DEBUG level.

原因分析

这是 SDK 日志级别设计导致的可观测性缺口，不是异常。在 _base_client.py 的 _sleep_for_retry 逻辑中，重试发生的事实使用 INFO 级别输出，而 retries_taken 与 max_retries 只在 DEBUG 级别输出。由于生产环境通常不开启 DEBUG，重试次数与重试上限信息被隐藏，用户无法从 INFO 日志判断重试进度。维护者的回应也印证了这一点：#3867 会把重试次数和上限合并进已有的 INFO 消息。

环境排查

确认所安装的 openai Python SDK 版本，判断是否已包含 #3867 的改动。
确认当前日志级别配置：logging 的 root logger 或 openai logger 是否为 INFO，DEBUG 是否被关闭。
确认触发重试的请求类型：是限流（429）、服务端错误（5xx）还是连接错误（APIConnectionError），不同错误对应的重试路径不同。
确认使用的是同步客户端还是异步客户端，两者在 _base_client.py 中分别有对应的 _sleep_for_retry 实现。
Issue 未提供 Python、CUDA、PyTorch、显卡等版本，无需额外核对。

解决步骤

记录当前 openai 包版本，便于升级后对比日志输出是否变化。
关注并升级到包含 #3867 改动的 SDK 版本；该 PR 会把 retry attempt 与 limit 加入同步和异步客户端已有的 INFO 重试日志，无需再依赖 DEBUG 日志。
若暂时无法升级，可优先尝试临时降低日志级别：将 openai 相关 logger 调至 DEBUG，从而看到 retries_taken 与 max_retries；但会同时输出大量其他调试信息。
在自定义重试逻辑场景下（例如多模型链路自建退避），参考 Issue 评论中的分层策略：429 用指数退避加抖动、5xx 退避重试、400 直接记录并快速失败，避免对不可重试错误做无效重试。
重试日志确认可见后，把日志级别恢复为 INFO，避免长期开启 DEBUG 影响性能与日志体积。

验证方法

在 INFO 级别下触发一次可重试错误（例如限流），观察日志中除“正在重试”外，是否同时出现 retry {retries_taken} of {max_retries} 形式的重试次数与上限信息；同步与异步客户端都应各自验证一次。如果仍只有重试发生、没有计数，说明当前 SDK 版本尚未包含该改动。