超时请求本身不计费，但被服务端接收的重试请求独立计费；需通过禁用自动重试、合理设置timeout、启用退避策略及核验request_id来规避重复计费。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
如果您调用通义千问API时发生响应超时，请求未成功返回结果，则该次调用不产生计费；但若超时后触发重试且重试请求被服务端接收并处理，无论是否成功返回内容，每次被服务端确认接收的请求均独立计费。以下是针对该问题的具体说明与应对方式：
一、超时请求本身不计费
通义千问API采用“服务端确认计费”机制：仅当请求完整抵达服务端、被成功解析并进入排队/执行流程后，才计入有效调用次数或token消耗。网络层超时（如TCP连接失败、DNS解析超时、客户端主动中断）或网关层拦截（如鉴权失败、参数校验不通过）均不会触发计费。
1、检查客户端日志中错误类型是否为connect timeout、read timeout或ClientClosedRequest；
2、确认HTTP状态码未出现在2xx或3xx范围内，且无response body中含"request_id"字段；
3、若dashscope SDK抛出TimeoutError且未返回任何result对象，则该次调用无费用产生。
二、重试请求独立计费
每次重试发起的新HTTP请求，只要完成三次握手、携带合法Authorization头及完整payload，并被百炼网关接收，即视为一次独立API调用，按实际输入输出token或请求次数计费。重试行为本身不减免费用，也不合并计费。
1、查看SDK配置中retry.enabled是否设为true，避免无意识开启自动重试；
2、在dashscope.init()中显式设置max_retries=0以禁用内置重试逻辑；
3、若需自定义重试，应在业务代码中捕获异常后手动构造新请求，并确保仅对幂等性明确的场景（如只读摘要）启用。
三、通过超时参数控制无效重试
合理设置timeout值可减少因模型长尾响应导致的非必要重试，从而规避重复计费风险。建议将timeout设为预期平均响应时间的3–5倍，而非固定保守值。
1、使用dashscope.TextGeneration.call()时传入timeout=60000（单位毫秒）；
2、对于Qwen-Long等长文档模型，根据历史P95延迟设定timeout，例如实测P95为8.2秒，则设timeout=45000；
3、避免将timeout设为过短值（如5000），否则大量请求会在服务端尚未开始推理时即被客户端中断并触发重试。
四、启用服务端熔断与退避策略
在高并发调用场景下，可通过配置客户端退避逻辑降低重试密度，防止雪崩式重复计费。vLLM或Triton部署的私有服务支持后端限流，但百炼公有云API需依赖客户端协同控制。
1、使用exponential backoff算法实现重试间隔，首重试延时≥1000ms，逐次翻倍；
2、在重试前检查上一次响应header中x-ratelimit-remaining值，低于阈值时暂停调用；
3、对HTTP 429错误统一降级处理，直接返回缓存结果或静态兜底文案，不发起重试。
五、通过Request ID核验计费明细
每个成功抵达服务端的请求都会返回唯一request_id，该ID同步记录于账单明细与用量统计后台，可用于精准定位是否发生重复计费。
1、从response.headers中提取x-request-id字段并持久化存储；
2、登录百炼控制台→用量中心→API调用明细，筛选对应request_id查看状态与计费标记；
3、若发现同一语义请求多次出现不同request_id且均标记为success，说明业务层存在未去重的重复提交逻辑，需检查前端防抖或后端幂等设计。
