最近 Codex 执行速度变慢？聊聊并发调优与踩坑经验

最近在搞开发调优的时候，不知道大家有没有同感：之前一直稳如老狗的 gpt-5.4-mini low 模型，在调用 Codex 执行环境时，速度好像突然“降智”了一样，明显变慢了。本来用来处理一些实时任务非常顺手，但这几天的卡顿感属实让人头疼。

为什么突然变慢了？

云端服务器负载波动导致的请求排队示意图

首先，咱们得排查一下是不是环境问题。如果之前一直很顺滑，最近才变慢，通常逃不出这几种情况：

1. 云端服务器负载波动：大模型服务商的后端资源并不是无限的。在特定时段（比如工作时间或者全球开发高峰期），算力资源吃紧，排队现象就会加剧。你觉得自己在等，其实是在等服务器腾出空隙。

2. 速率限制 (Rate Limits) 的暗雷：很多时候我们以为并发拉高了就能起飞，但往往忽略了 Token 生成速度的限制。如果你的账号等级或者 API 等级受到了限流，即便你把并发拉到 40，服务器依然会按它的节奏给你吐数据，甚至因为请求过多触发 429 (Too Many Requests) 错误，导致后续请求被强行延后。

3. “假”并发与模型自身延迟：gpt-5.4-mini low 作为轻量版模型，虽然生成速度快，但如果上下文太长或者代码逻辑复杂，首次响应时间（TTFT）依然会增加。如果你在代码里用的是同步阻塞式调用，所谓的“高并发”其实只是把请求堆满了线程池，并没有真正利用好异步 I/O。

实用的调优与解决方案

既然遇到了问题，总不能干瞪眼。针对这种“突然变慢”的情况，我有几个比较实操的调优思路，大家可以参考一下：

同步阻塞与异步 I/O 的执行流程对比

1. 调整并发策略：别盲目拉满

原文提到已经把并发拉到了 40。说实话，对于普通账号或者非企业级 API 调用，长期维持 40 并发非常容易触发风控或限流。建议逐步调整：

• 阶梯式降级：尝试先砍到 20 甚至 10，观察速度是否回升。有时候请求少了，服务器处理反而更从容，整体吞吐量反而上升。
• 观察 TPS 和 Latency：不要只看并发数，要看实际每秒处理的任务数和平均延迟。如果并发高了延迟暴涨，那就是得不偿失。

2. 优化请求代码：善用异步与超时

检查一下你的调用逻辑。

• 使用异步客户端：如果你的语言支持（比如 Python 的 aiohttp 或 asyncio，Node.js 的原生 Promise），务必改用异步请求。这能让你在等待第一个请求返回时，发出第二个请求，最大化利用网络带宽。

• 设置合理的超时：不要让请求无限期挂起。设置一个较短的 Connect Timeout 和 Read Timeout（比如 10秒），一旦超时立刻重试或降级，避免任务堆积。

3. 引入“退避重试”机制

遇到变慢或偶尔报错时，直接重试可能会让情况更糟。建议引入 Exponential Backoff（指数退避） 算法：

• 第一次失败等待 1 秒重试；
• 第二次失败等待 2 秒；
• 第三次等待 4 秒……

这样做可以给服务器一点喘息的时间，也能有效避开瞬时的高峰拥堵。

4. 备选方案切换

如果 gpt-5.4-mini low 在近期持续不稳定，不妨短暂切换到其他档位的模型试试看：

• 尝试更高一档的模型：有时候低配版模型会被优先降级保障高配版用户的体验（虽然听起来很残酷，但资源调度通常如此）。如果预算允许，切到标准版测一下速度是否恢复正常。

• 代码生成专用模型：如果你的任务主要是写代码，看看是否有专为代码生成优化的 Endpoint，通常这类通道的针对性优化会做得更好。

总结

Codex 执行变慢这事儿，大概率不是你一个人的错觉，可能是近期的服务器负载策略调整了。在做技术调优时，切忌“大力出奇迹”地硬拉并发。合理的策略是：先降并发测水位，再看代码查阻塞，最后上机制做重试。

如果实在慢得离谱，不妨换个时间段再跑，或者临时切一下模型。大家在最近的开发中有没有遇到类似的瓶颈？欢迎在评论区分享你的应对招数！