爆料：ChatGPT/Codex长对话性能将提速16倍，27秒缩至1.6秒！
内容提要
OpenAI内部优化了ChatGPT/Codex长对话性能，加载时间从27.62秒降至1.66秒，请求数从894减至16。此前全量加载策略导致卡顿，用户抱怨多，第三方插件曾缓解。优化虽显著，但暴露了此前代码质量问题，且尚未上线，引发对工程文化和优先级的争议。
延伸解读
性能提升背后的工程文化争议
此次优化将加载时间从27.62秒降至1.66秒，请求数从894减至16，提升显著。但文章指出，这恰恰暴露了此前代码质量问题：98.2%的请求和99.6%的渲染内容被证明是多余的。这引发了关于OpenAI工程文化的讨论——优先新功能而忽视性能优化，导致用户长期受困于卡顿，甚至需要第三方插件缓解。
“94% faster”的表述陷阱
官方称“94% faster”，但实际提速约16.6倍。文章指出，这是营销语言与工程语言的差异：“94%”听起来更精确，但容易让普通人误解为“快一倍”。真正的优化幅度应看请求数从894到16、加载条目从15529到64等数据。这种表述方式可能误导用户对性能提升程度的认知。
优化方案的未解问题
新方案采用按需加载，仅加载64条条目，但文章提醒：滚动加载的体验（如位置保持、闪烁）未在基准测试中体现；优化尚未上线，用户无法立即使用；对于更长对话（如2000轮），按需加载能否持续有效仍是未知。这些未公开的细节可能影响实际用户体验。
用户情绪与信任危机
帖子获得57个点赞和70个点踩，反映出用户对“修复自身问题却作为突破宣传”的不满。文章强调，用户更关心“现在为什么慢”以及问题存在多久，而非“即将变快”。这种情绪可能加剧对OpenAI产品可靠性的质疑，尤其是在其宣称“coding is largely solved”的背景下。
Q&A
OpenAI 内部优化 ChatGPT/Codex 长对话性能，具体数据提升是多少？
根据内部基准测试，一个 741 轮对话、体积 231MB 的超大聊天记录，加载时间从 27.62 秒降至 1.66 秒，网络请求从 894 个减至 16 个，前端加载的对话条目从 15,529 条降至 64 条，内存增长降低 41.2%，渲染引擎堆内存增长降低 87.8%。
为什么 ChatGPT/Codex 长对话之前加载很慢？
因为 ChatGPT 和 Codex 的桌面应用采用“全量加载”策略，打开对话时会将整个对话历史全部拉取并渲染，导致大量网络请求和 DOM 渲染，造成卡顿。
OpenAI 是如何优化长对话加载速度的？
优化方案是从“全量加载”改为“按需加载”，只加载最近 64 条对话条目，滚动时再按需加载更早内容，从而大幅减少请求数和渲染量。
这次性能优化暴露了 OpenAI 的什么问题？
暴露了 OpenAI 工程文化中优先级的问题，即重新功能轻性能优化，导致客户端代码质量低下，长期存在性能问题，直到用户抱怨才修复。
第三方开发者是如何解决 ChatGPT 长对话卡顿问题的？
第三方开发者编写了浏览器扩展，如“Unfreeze-for-ChatGPT”能让冻结的对话在 2 秒内加载，“ChatGPT Performance Optimizer”自动卸载旧对话只保留最近 40 条，“GPT Cleaner”只保留最后 N 条消息可见。
为什么说“94% faster”的说法有误导性？
因为从 27.62 秒降至 1.66 秒，耗时减少了 94%，但速度提升是 16.6 倍，而不是“快了将近一倍”。用“94%”更精确但容易让人误解，这是营销语言与工程语言的差异。
这次优化是否已经上线？
没有。Ambrosino 公布的是内部 benchmark 数据，并非已上线的产品更新，用户询问何时能用到，没有得到回答。
长对话性能问题对用户造成了什么影响？
用户打开长对话需要等待 27 秒，界面卡死、内存暴涨，甚至无法访问旧对话，严重影响工作效率，因为超过 70% 的 Codex 用户执行的任务需要超过一小时，长对话是常态。
