模型调用超时应共享同一截止时间

一个接口只给请求留了 1.5 秒，新增的免费模型调用却自带 10 秒超时。作者在审查一个小型服务时发现，这个改动没有引发崩溃，却让 p99 延迟翻倍，并耗尽工作池容量。文章讨论的重点是：模型调用、排队和重试，怎样才能共同遵守接口的总时间预算。

目前能确认什么

p99 是请求耗时的第 99 百分位，用来观察慢请求。局部调用各自设置超时，并不能保证整个接口按时结束：串行步骤会累加耗时，重试还可能进一步拉长等待。

作者提出，由请求入口生成一次绝对截止时间，后续各层只计算剩余预算，重试也不能重新领一份时间。节选中的 Python 实现使用单调时钟，避免系统时间调整干扰耗时计算；剩余时间过少时，直接拒绝发起调用，让上层执行降级。

并发也要受控。作者用信号量限制同时调用的数量，并要求分别记录排队时间和调用时间。文章同时披露，这是 MonkeyCode 的产品推广内容，作者没有测量其中提及的模型、配额或可用性。

我的判断

最该检查的，是排队和重试有没有绕过请求总预算。

节选里的适配器还有一个具体缺口：它先等待信号量，拿到名额后才进入超时控制。队列等待因此没有被这段超时机制约束。仅传递截止时间对象还不够，等待并发名额本身也必须能在预算耗尽时退出。

另外，异步等待超时，不代表底层网络请求已经停止。客户端能否响应取消、连接能否及时释放，需要结合具体 SDK 确认。

跨服务传递也尚未讲完整：示例使用的单调时钟时间戳不能直接假定在不同机器间通用。原文在后续改进处截断，跨服务预算如何换算、如何验证排队超时，目前都还不能确认。