OpenAI 实测大型 ChatGPT 和 Codex 线程加载时间提升 16 倍

RuntimeWire 2026-08-16T12:28:40.688235

Andrew Ambrosino(@ajambrosino)负责 OpenAI 的 Codex 桌面应用。他最近测试了一种加载超大型 ChatGPT 与 Codex 对话的新方式,把测试会话的加载时间从 27.62 秒降到了 1.66 秒。测试用的是一段 741 轮、231 MB 的对话。根据 Ambrosino 在 X 上的帖子,新实现还让对话渲染器的 JavaScript 堆内存增长减少了 87.8%,整个应用的内存增长减少了 41.2%。基准测试里标注的“快 94%”,指的是耗时大约下降了 94%;如果按速度倍数来算,这段对话的加载速度快了约 16.6 倍。8 月 15 日,Dan(@DanDr1s)把这个结果转发了出来,作为长对话体验升级的依据。这些数据衡量的是客户端加载和渲染对话的性能,不涉及模型推理速度、回答质量,也不代表 Codex 完成某项任务所需的时间。

测试中记录了一次 231 MB 对话的加载时间、内存增长、网络请求数量以及对话记录条目数。另外两组数据揭示了性能提升最可能的来源:网络请求从 894 次降到 16 次,减少了 98.2%;初始加载的对话记录条目数从 15,529 条降到 64 条,减少了 99.6%。这两组数字说明,新版客户端不再像以前那样,把一条庞大的对话一次性全部拉进应用。它只先加载一个有界的记录片段,这样一来,在用户能开始交互之前,网络层、JavaScript 运行时和渲染器要做的工作都少了很多。

不过,这份基准测试并没有说明用户向上翻看旧消息时是如何取回更早内容的。因此,平滑的分页加载和稳定的滚动位置,依然是长对话体验的核心。

为什么要区分这些层面?因为一段很长的对话,可能在好几个不同的环节出问题。模型也许还有足够的上下文能继续干活,但桌面界面却可能因为要渲染存储的完整记录而卡死。减少客户端初始加载的条目数,正好针对的是这个界面瓶颈,不需要改动模型,也不需要对底层对话做删减。

长会话已经成为产品的瓶颈。这项基准测试针对的是 OpenAI 桌面软件中一个有据可查的痛点。今年 7 月,有用户在 OpenAI 的 Codex 仓库中反馈:一次更新之后,较早的对话轮次变得无法访问,尽管完整历史记录仍保存在本地,应用服务器也照常返回会话记录页面。问题出在分页历史记录无法与界面中采用虚拟列表渲染的会话内容正确合并。另一个汇总长会话故障的 Codex issue 则描述了冻结、内存持续增长,以及对话状态不断累积后失去对当前轮次控制等表现。

这些虽然是用户提交的报告,但它们说明了一个核心问题:为什么会话加载已经成为智能体软件的关键产品问题,而不是一项可有可无的体验优化。OpenAI 自家的使用数据让这个问题更加突出。在 2026 年 6 月发布的一篇研究文章中,OpenAI 表示,5 月有超过 70% 的 Codex 用户让智能体执行需要人类花一小时以上才能完成的工作。更长的任务会带来更多工具输出、中间推理记录、文件变更和反复的后续交互,产生的会话历史远比普通聊天对话要庞大。Ambrosino 的基准测试正是针对这种使用模式累积下来的开销。

查看原文