给 DeepSeek 的推理输出留够时间：一把 key 上的超时与预算怎么设

为什么 DeepSeek 需要不同的超时策略

DeepSeek 这类模型在输出前会进行多步推理，生成更长的思维链，导致首个 token 的返回时间（TTFT）明显长于快速对话模型。如果你沿用为快速对话模型设置的短超时（如 5-10 秒），很容易在模型刚开始输出时就断开连接，造成请求失败和重试浪费。

理解推理链路对超时的影响

推理模型的响应过程通常分为两个阶段：

• 推理阶段：模型内部进行思考，不产生可见输出。这个阶段可能持续数秒到数十秒，取决于问题复杂度和生成长度。
• 输出阶段：模型逐步生成最终答案，速度相对稳定。

因此，客户端超时必须覆盖推理阶段的最长可能时间，而不仅仅是输出阶段的耗时。此外，流式响应下，超时应基于首个 token 到达时间来设置，而不是整个请求的总时长。

交互场景：平衡响应速度与可靠性

在交互式应用（如聊天界面）中，用户期望快速反馈，但也要避免因超时导致对话中断。建议：

• 连接超时：保持较短（如 5-10 秒），用于快速发现网络问题。
• 读取超时（TTFT）：设置为 30-60 秒，给推理阶段留足时间。如果模型在 60 秒内仍未输出首个 token，重试可能是合理的。
• 总超时：根据最大生成长度设置，通常为 2-5 分钟。
• 重试策略：仅对超时和 5xx 错误进行有限重试（如最多 2 次），避免在模型正常推理时重复提交。

使用流式请求时，确保客户端能正确处理长时间无数据的心跳或保持连接。

后台场景：优先保证完整性

后台任务（如批处理、异步生成）对延迟不敏感，但要求高成功率。建议：

• 连接超时：可适当放宽至 10-20 秒。
• 读取超时（TTFT）：设置为 2-5 分钟，以适应复杂推理。
• 总超时：根据任务允许的最长执行时间设置，例如 10-30 分钟。
• 重试策略：采用指数退避重试，最多 3-5 次，并记录每次重试的原因。对于超时重试，可考虑先检查任务是否已在服务端完成（如果 API 支持幂等或查询）。

成本与重试预算的权衡

每次重试都会产生额外的 token 消耗，按官方价 ×1.3 扣费。因此，重试预算需要平衡可靠性和成本：

• 避免对推理超时进行频繁重试，优先通过调整超时参数来减少不必要的重试。
• 在后台场景中，可为重试设置独立的预算上限（如最多重试 3 次），防止异常情况下成本失控。
• 监控重试率，如果某类请求频繁超时，应考虑优化提示词或拆分任务，而不是一味增加重试。

实践建议

• 区分模型：在客户端代码中为 DeepSeek 等推理模型单独配置超时和重试参数，不要与快速对话模型共用同一套配置。
• 动态调整：根据实际观测到的 TTFT 分布调整超时阈值，初期可设置保守值，后续逐步优化。
• 流式优先：使用流式响应可以更早获得反馈，并基于首个 token 时间判断是否超时。
• 日志与监控：记录每次请求的 TTFT、总耗时和重试次数，便于持续优化。

通过合理设置超时和重试预算，你可以在享受 DeepSeek 强大推理能力的同时，保持应用的稳定性和成本可控。