2026年7月5日 · 深度技术分析

导语

2026 年 6 月底，OpenAI Codex 社区报告了一个令人困惑的现象：当使用 gpt-5.5 模型（尤其是 xhigh reasoning 档位）时，模型的 reasoning_output_tokens 异常地、高频地聚集在三个固定数值上：516、1034、1552。更关键的是，当 token 数恰好为 516 时，模型往往跳过中间的思考阶段，直接输出最终答案——而这些答案的错误率显著升高。

这不是一个孤立的 bug 报告。基于 390,195 条响应记录的统计分析显示，GPT-5.5 的 exact-516 比例在 5 月份飙升至 53.30%，是 2 月份的 484 倍。OpenAI 官方至今未给出技术解释。本文将从现象、数据、根因假说三个层面，拆解这场正在发生的"推理退化"事件。

一、现象：三个魔法数字

1.1 核心症状

在 OpenAI Codex 环境中使用 gpt-5.5 时，开发者观察到以下异常模式：

  • 推理 token 聚类：reasoning_output_tokens 高频出现在 516、1034、1552 三个数值
  • 思考中断：当 token 为 516 时，模型通常跳过 commentary 中间思考阶段，直接输出 final_answer
  • 错误率飙升：516 运行的答案错误率远高于正常推理（3,000-8,000+ token）的运行
  • 时间异常：正常推理运行耗时数十至上百秒；516 运行通常在 15 秒左右结束

1.2 恶化时间线

月份 exact-516 / >=516 比例
2026-02 0.11%
2026-03 0.15%
2026-04 0.48%
2026-05 53.30%
2026-06 35.84%

5 月份的激增尤为突然——从 4 月的 0.48% 跳到 53.30%，增幅超过 100 倍。

二、数据：390,195 条记录的统计真相

2.1 大规模聚合统计

基于 GitHub issue #30364（2026-06-27 发布）的统计，覆盖 390,195 条 response-level token 记录、865 个 session（2026-02-01 至 2026-06-27）：

指标 数值
exact-516 事件总数 3,363
GPT-5.5 占总响应比例 19.3%
GPT-5.5 占 exact-516 事件比例 82.0%
GPT-5.5 exact-516 / >=516 比例 44.0%
非 GPT-5.5 exact-516 / >=516 比例 1.3%

GPT-5.5 的 clustering ratio 是其它模型基线的 33.6 倍。

2.2 跨模型对比

Model Response records Exact 516 / >=516
gpt-5.5 75,401 44.0%
gpt-5.4 25,214 19.8%
gpt-5.2 247,575 0.34%
gpt-5.3-codex 13,333 0.0%
gpt-5.3-codex-spark 26,179 0.0%

数据清晰地显示：这是一个 GPT-5.5 独有的问题。

2.3 推理强度退化趋势

同期整体推理 token 强度不升反降：

月份 Mean reasoning tokens P90 reasoning tokens
Feb 2026 268.1 772
Mar 2026 256.8 723
Apr 2026 228.7 669
May 2026 106.9 344
Jun 2026 168.5 515

5 月份的 mean reasoning tokens 从 4 月的 228.7 骤降至 106.9——降幅 53%。这与 exact-516 激增的时间点高度吻合。

2.4 任务级复现

社区开发者使用 haowang02/codex-candy-eval 进行 5 次独立运行：

结果 reasoning_output_tokens
正确 (2/5) 6,732 / 3,624
错误 (3/5) 516 / 516 / 516

Token 数与正确率呈现强相关性——这是最关键的发现。

三、根因假说：batching、截断，还是调度器问题？

OpenAI 官方至今未给出技术解释。社区基于数据模式提出了三种高可信度的工程层假说：

3.1 假说一：512 整数倍 Batching / KV Cache 复用

核心观察：516、1034、1552 的步长接近 512（516 ≈ 512+4，1034 ≈ 512×2+10，1552 ≈ 512×3+16）。

假说内容：OpenAI 可能在推理栈中引入了基于 512 token 边界的吞吐量优化（batching 或 KV cache 分块复用），导致 reasoning 过程在 batch 边界处被截断或提前终止。

支持证据：

  • 数值的 512 整数倍模式过于规律，不可能是随机巧合
  • 推理 token 数恰好落在 batch 边界时，模型可能收到"停止生成"的信号

反对证据：

  • 如果是 batching 优化，为什么只在 GPT-5.5 上出现？
  • 为什么 5 月份突然激增？优化策略通常是渐进部署的

3.2 假说二：隐藏 Reasoning Budget / Throttling

核心观察：5-6 月 exact-516 激增的同时，mean/P90 reasoning tokens 大幅下降。

假说内容：gpt-5.5 可能在生产环境中被施加了隐式的推理预算上限（reasoning budget cap）或动态降级机制。当复杂任务的推理 token 接近阈值时，模型被强制截断思考过程，直接输出答案。

支持证据：

  • 推理强度下降与 clustering 激增完全同步
  • 516 的"短路"行为（跳过 commentary 直接给答案）符合"被截断"的特征
  • 5 月份可能是新机制上线的窗口

深层含义：如果此假说为真，这意味着 OpenAI 可能在未告知用户的情况下降低了模型的推理能力，以控制计算成本或提高吞吐量。

3.3 假说三：路由 / Fallback / 调度器行为

假说内容：Codex 的路由器或调度器在特定条件下（如高负载、特定任务类型）将请求 fallback 到一个低推理预算的代码路径，导致固定 token 数的"短路"输出。

支持证据：

  • GUI 路径（VS Code 插件）下 reasoning_output_tokens = 0 的异常报告率远高于 CLI 路径
  • 不同客户端可能走了不同的推理 pipeline

3.4 关键未决问题

社区强调：目前无法区分是 batching（性能优化）还是 truncation（产品 bug）。两者的修复策略、优先级和责任归属完全不同：

  • 如果是 batching 优化导致的副作用 → 需要调整推理服务的 batch 策略
  • 如果是推理预算截断 → 涉及产品决策透明度和用户信任问题

判断标准需要 OpenAI 公开 token_count 之外的 raw reasoning trace，而当前 telemetry 不暴露此数据。

四、影响与 workaround

4.1 对开发者的影响

  • 不可预测的质量：同一个 prompt，有时给出高质量答案（3,000+ token 推理），有时给出 516 的"敷衍"答案
  • 调试困难：无法区分"模型能力不足"和"推理被截断"
  • 生产力损失：需要反复重试、人工验证、或换用其他模型

4.2 社区 workaround

Prompt 缓解：

在 AGENTS.md 中加入指令：

Spend time on thinking; you do not need to use the commentary 
channel to report progress to me

据报告可部分缓解该问题——可能是通过增加 prompt 中的"思考暗示"来绕过截断机制。

模型绕行：

有用户反馈已放弃 GPT-5.5 的内部推理，改为在 Codex 中调用 gpt-5.5 但将 reasoning 步骤外包给 Claude Sonnet 5。

五、我的分析：一个更深层的问题

5.1 "黑盒推理"的信任危机

这次事件暴露了一个被忽视的问题：当我们将推理过程交给模型时，我们如何知道模型真的在"思考"？

Codex 暴露了 reasoning_output_tokens 这个指标，但这个数字本身无法告诉我们：

  • 这些 token 是"真正的思考"还是"填充物"？
  • 模型是在什么条件下决定停止思考的？
  • 是否存在外部机制（如预算限制）干预了思考过程？

5.2 516 的启示：监控指标的重要性

516 之所以被发现，是因为有开发者注意到 token 数的异常模式。这提醒我们：

  • 对于推理模型，token 分布是重要的质量指标
  • 单一数值（如 mean token 数）可能掩盖严重问题，需要关注分布形状和异常聚类
  • 建立推理质量的自动监控体系，比单纯依赖人工反馈更有前瞻性

5.3 对 OpenAI 的建议

  1. 公开 raw reasoning trace：至少在高 reasoning 档位下提供完整的 thinking 过程
  2. 区分 batching 和 truncation：如果是 batching 优化，应允许用户选择"完整推理"模式
  3. 透明化推理预算：如果存在推理预算机制，应在文档中明确说明
  4. 提供降级通知：当模型因外部限制而减少推理时，应告知用户

免责声明

本文仅供技术研究和教育目的，内容基于 OpenAI Codex 社区公开的 GitHub issue、讨论帖及开发者分享的 telemetry 数据分析。本文所有技术分析均以工程诊断和产品改进为导向，不构成对任何公司或产品的指控。读者应遵守所在国家/地区的法律法规，仅将本文内容用于合法合规的研究和学习用途。

参考资料