Codex 首字秒回但转圈两分钟？这恐怕不是 DNS 的锅

最近在使用 Codex 的时候，大家有没有遇到一种特别让人抓狂的情况：首字出来得飞快，几百毫秒就蹦出来了，让你感觉这波稳了，结果后面的输出像是陷入了沉思，转圈转到了天荒地老，总耗时甚至能干到 2 分钟？

Codex 界面显示首字生成极快，但后续输出陷入长时间的等待状态。

一开始我以为是自己网络抽风，或者像圈子里有人说的是 DNS 污染导致握手慢。但仔细想想，不对啊，要是 DNS 或者握手有问题，那应该是最开始连接的时候卡住才对，怎么可能首字秒回呢？这种“起步即冲刺，中途就熄火”的表现，显然另有隐情。

作为一个经常折腾各种 AI 工具的博主，今天咱们就来深度拆解一下这个奇怪的性能瓶颈，顺便聊聊遇到这种情况该怎么排查和应对。

1. 排除“假想敌”：这不完全是网络的锅

很多人的第一反应是“网络不好”或者“DNS 解析慢”。这很好理解，毕竟以前用国外服务时，DNS 污染确实是首字节（TTFB）变慢的罪魁祸首。

但在 Codex 这个场景里，逻辑有点反了：

大模型推理中 KV Cache 的工作原理示意图。

• TTFB 极快：说明你的客户端到服务器之间的建连、DNS 解析、SSL 握手以及模型的“预填充”阶段都非常顺畅。模型已经准备好吐出第一个 token 了。
• 后续卡顿：说明模型已经开始工作，但在生成后续内容时遇到了瓶颈。

所以，如果你的首字能秒回，基本可以拍着胸脯说，你的网络底座没问题，不用急着去改什么hosts或者换代理节点。

2. 真正的嫌疑人：推理阶段的“深思考”

既然网络没问题，那问题大概率出在模型自身或者服务端的处理机制上。目前来看，有几种可能性比较大：

A. 模型架构导致的“计算密集型”卡顿

如果你的提示词比较复杂，或者触发了模型内部的“思维链”或深层次的推理逻辑，模型在生成第一个 token 后，可能需要进行大量的矩阵运算来规划后续内容。

• 首字快：可能只是模型把缓存里最明显的概率最高的词吐出来了。
• 思考慢：到了生成后续长文本或需要逻辑连贯的内容时，计算量瞬间爆炸，GPU 显存带宽或者算力跟不上，导致生成速度断崖式下跌。

B. 服务端的负载均衡与排队机制

这是很多公用 AI 平台的通病。当你请求进来时，可能正好赶上一个空闲的 GPU 实例，所以秒分配、秒出首字。但是，当模型开始进入长时间的推理流生成时，后台的调度系统可能突然把资源切给了别的优先级更高的任务，或者当前实例的显存被占满需要频繁交换，导致你的请求被“限流”或挂起，只能龟速输出。

C. KV Cache 的缺失或失效

对于大模型推理，KV Cache 是提速的关键。如果服务端的某些优化没做好，或者你的请求触发了某种机制导致缓存失效，模型每生成一个新词都要重新计算 Attention，那速度肯定会慢得像蜗牛。

3. 这种情况该怎么救？

遇到这种问题，除了干等，有没有什么实际的解决办法？这里给大家提供几个思路：

① 简化 Prompt，避免“过度思考”

有时候我们的指令写得太长、逻辑太绕，逼得模型不得不“深思考”。试着把 Prompt 写得直接一点，明确告诉它“不需要中间过程，直接给结果”，看看速度能不能提上来。

② 切换模型或参数

如果你使用的是支持参数调节的平台，试着把 max_tokens 调小一点，或者换一个参数量更小的模型版本。有时候，小模型在简单任务上的推理速度会快非常多。

③ 避开高峰期

如果是服务端整体负载高的问题，那只能错峰使用了。比如在国内的上午或者凌晨时段试试，那时候并发少，速度通常会稳定不少。

④ 检查是否有“冷启动”迹象

如果你是长时间没用后的第一次请求，可能会遇到服务实例冷启动的问题（虽然通常这会影响首字，但有时候也会影响后续流）。如果第一次慢，第二次请求变快了，那就是这个问题，无解，保持活跃度即可。

总结

Codex 最近这种“首字快、思考慢”的现象，大概率不是你客户端网络的问题，更多是服务端推理资源调度或者模型计算特性导致的。

既然连上了，首字也出来了，就说明路是通的。如果遇到长时间的卡顿，不妨先放一放，或者检查一下是不是自己下达的任务太复杂，把模型“难住”了。希望官方后续能优化一下推理引擎的调度策略，别让这种“虎头蛇尾”的体验浪费大家的时间。

大家最近用得怎么样？有没有发现什么特定的 prompt 会让它变慢？欢迎在评论区分享你的观察！