Do Larger Reasoning Models Actually Use Tokens More Efficiently?

September 2026 update. No new inference was run for this update. We re-analyzed the existing 97,024 rollouts in three ways: per-problem compute accounting, a quality–compute frontier, and output-length comparisons grouped by problem difficulty. One conclusion changes. In both families the larger model writes less, but at the 32K budget, only GPT-OSS also uses less compute per problem under a config-based estimate. Qwen3.5 27B uses 2.5–2.9× the compute of Qwen3.5 9B. The new material is in the four sections from "Compute accounting" to "Why the two families differ"; the takeaways and sources were revised to match.

The question became more practical in September. OpenAI released GPT-6 Astra on September 3, and its system card reports shorter reasoning traces and stronger performance on hard tasks without verbalized reasoning. OpenAI chief scientist Jakub Pachocki then stated that the computation-graph depth of OpenAI's current frontier models, Astra included, is within a factor of two of GPT-4. On September 23, Redwood Research reported that Astra's accuracy on AIME-level problems rises sharply when it answers without reasoning but with filler tokens appended to the prompt. Visible reasoning keeps getting shorter. How much compute that actually saves has to be counted separately.

The project began with a Yann Dubois interview

This project started from an interview. Yann Dubois, who co-leads OpenAI's post-training frontiers team, linked pretrained model scale to reasoning-token efficiency on The MAD Podcast with Matt Turck:

“If you have larger models, the amount of thinking time—so the amount of tokens they will think for—will usually decrease. […] The model already thinks through its weights when it generates a certain token. So you can decrease the number of tokens that you need to generate for thinking by increasing the size of the model […] if you basically pre-train larger models, you will get better efficiency.”
—Yann Dubois, excerpt from 24:34–25:23 in the original interview.

The passage ties together three things: a larger pretrained model, thinking that already happens in the weights, and fewer explicit thinking tokens. If more capability sits in the parameters, the model may not need an equally long visible trace to find the answer.

This is an interview remark, not an OpenAI technical report, and Dubois said "usually." A test cannot rely on leaderboard scores, and a shorter output is not automatically a more efficient one: the model may have been cut off or never produced a final answer. The question we tested is:

Within one model family, with the same tasks, output budgets, decoding rules, and repeated sampling, does the larger model reach equal or better quality with fewer visible thinking tokens?

At the time I was trying out Auto Research: having frontier models propose hypotheses, design experiments, schedule remote runs, audit outputs, diagnose failures, and assemble a report that others can check. Yann's claim made a good concrete question.

Public remarks by Noam Brown and Josh McGrath filled in two more pieces. Brown argued that extra test-time compute helps only when the model is capable enough to use it. McGrath suggested plotting progress on a quality–token plane and asking whether a model moves up and to the left. The design followed from these: compare two sizes within each family, fix the task and generation settings, sweep several output budgets, sample each problem repeatedly, and compare token efficiency only when final-answer validity, token partitioning, and truncation meet preset thresholds.

GPT-5.5 and GPT-5.6 worked as research assistants throughout. They challenged the hypothesis, designed the experiment matrix, audited remote runs, diagnosed measurement problems, analyzed accepted results, and helped draft the report, a paper, and this post. They are not evidence. Numbers from our own experiments come from job logs, validated result files, and subsequent analyses of those records.

Figure 1 shows eight decisions that changed the direction of the study. Orange side branches are routes we diagnosed and downgraded to supporting evidence; they are not failed runs.

From five candidate families to two

We did not start with GPT-OSS and Qwen3.5. The candidate pool also included Ministral-3, Qwen3, and GLM-4.5. We ran small pilots and then asked whether each family could support an interpretable within-family size comparison. A family entered the main matrix only if it met four conditions:

1. at least two comparable sizes in one family, with architecture and post-training differences small enough that size remains the main difference;
2. the same tokenizer, chat template, reasoning parser, and generation settings;
3. enough task, budget, and sampling coverage to draw a quality–token frontier rather than one benchmark slice;
4. final-answer validity, token partitioning, and truncation good enough to measure tokens without rewarding responses that never finished.

GPT-OSS also came with an external reference. OpenAI's model card provides a 20B/120B pair, the Harmony format, and low/medium/high reasoning-effort results on AIME and GPQA-Diamond. Its Figure 3 plots the three effort levels on an accuracy versus average-CoT+Answer-tokens plane, and 120B often reaches similar or higher accuracy with shorter output. Those results are not part of our experiment and are not counted below. They made GPT-OSS a good candidate for a controlled re-test.

GPT-OSS and Qwen3.5 Dense gave the cleanest two comparisons and entered the main matrix. Ministral-3, Qwen3, and GLM-4.5 stayed out because measurement validity was too low, size was entangled with architecture or training recipe, or results depended heavily on the inference budget. These pilots also produced genuine quality reversals, which are retained and analyzed below.

Admission depended on comparability and measurement validity, not on whether a family supported the hypothesis. The families outside the main matrix are part of the result.

Experimental setup

Each family contributes two sizes:

The protocol uses K=8: four models, four tasks (MATH500, GPQA-Diamond, AIME 2024, AIME 2025), and four maximum output budgets (4K, 8K, 16K, 32K), with eight independent rollouts for every model–problem–budget combination.

The problem is the unit of inference; eight rollouts of one problem are not eight problems. The 95% intervals come from a paired problem bootstrap with 2,000 resamples. Each sampled problem keeps all eight rollouts for both sizes, and we then compute larger minus smaller. AIME therefore has 30 effective samples, not 240. K=8 makes each per-problem estimate steadier; the number of problems stays the same.

GPT-OSS high effort is an auxiliary analysis and does not gate the main conclusion.

Quality is the mean accuracy over eight rollouts (avg@8), with pass@8 as a secondary view. We count thinking tokens, answer tokens, and total generated tokens separately.

Token-efficiency comparisons pass through a measurement gate. Strict accuracy always scores a missing or unparsable final answer as wrong. A comparison is used only when:

• at least 95% of responses have a valid final answer;
• at least 95% have a valid thinking/answer token split;
• a 32K cell truncates no more than 5% of the time.

A cell that fails keeps its strict accuracy, but its token length is not used to argue about efficiency.

Aggregate results: both families point the same way, under different conditions

The next table gives the paired 32K avg@8 difference, larger minus smaller. An interval that excludes zero supports the direction of the accuracy change on these benchmark problems. "Failed" limits only the token-efficiency claim; strict accuracy and its interval are kept.

Comparison with the official model card. The card's Figure 3 plots 20B/120B quality against CoT+Answer tokens on AIME 2025 and GPQA-Diamond. Its points match the with tools rows of Table 3 and illustrate test-time scaling across effort levels. The closest match to our setting (no tools, fixed medium effort, four hard caps) is the medium / no tools column. On GPQA-Diamond the card reports 66.0%→73.1% and we measure 66.9%→73.1%. On AIME 2025 the card reports 72.1%→80.0% and we measure 74.2%→83.3%, the same direction. MATH500 is not in the card.

The two-dimensional view and the basic GPT-OSS direction are therefore not our discoveries. This part of the work is a controlled re-test of the official result with fixed effort, K=8, and measurement gates, extended with a thinking-only token count, MATH500, and the Qwen3.5 family. The official numbers serve as an outside check and are not pooled with our data, intervals, or acceptance statistics.

GPT-OSS: the clearest result

GPT-OSS gives the strongest support for the hypothesis. In all five gate-passing fixed-budget comparisons, 120B uses fewer thinking tokens than 20B, and in four of them it is also more accurate. At all four quality-matched frontier points, 120B reaches the target accuracy with fewer thinking tokens.

At 32K:

• MATH500 rises from 95.8% to 97.2%: +1.35 pp, 95% CI [+0.60, +2.18]. Mean thinking tokens drop by 849, 95% CI [−1,028, −685].
• GPQA-Diamond rises from 66.9% to 73.1%: +6.25 pp, 95% CI [+3.41, +9.34]. Mean thinking tokens drop by 2,804, 95% CI [−3,289, −2,323].
• AIME 2025 rises from 74.2% to 83.3%: +9.17 pp, 95% CI [+3.75, +15.00]. This cell fails the token-efficiency gate, so only the accuracy result is kept.

On AIME 2024 the point estimate reverses: accuracy falls from 84.6% to 81.7%, a −2.92 pp difference with a 95% CI of [−8.33, +2.50]. An exact paired sign-flip test gives two-sided p=0.383. We read this as an unresolved deviation rather than a counterexample. The token reduction is stable: −4,252 thinking tokens on average, 95% CI [−6,071, −2,663].

Qwen3.5: same direction, less usable evidence

Qwen3.5 points the same way in its gate-passing evidence. On MATH500 at 32K, 27B rises from 93.3% to 98.0%: +4.68 pp, 95% CI [+3.65, +5.73]. Mean thinking tokens drop by 1,949, 95% CI [−2,155, −1,752], an 18.7% point estimate.

GPQA-Diamond strict accuracy rises from 74.1% to 82.2%: +8.14 pp, 95% CI [+5.49, +10.98]. AIME 2024 and AIME 2025 show +8.33 pp (95% CI [+3.33, +14.17]) and +15.83 pp (95% CI [+8.75, +23.75]). These cells fail the final-validity or truncation gate. Their accuracy results stand; they are not used for token-efficiency claims.

Compute accounting: GPT-OSS saves compute, Qwen3.5 uses over 2.5× as much

So far we compared token counts. A larger model pays more for every token it generates, so fewer tokens need not mean less compute. Think of it as price times quantity:

• T is the average number of tokens generated per problem, thinking plus answer;
• c is the number of floating-point operations needed to generate one token. Roughly, c ≈ 2 × the parameters used per token; only active experts count in the MoE expert component, while shared layers still count;
• compute per problem ≈ T × c.

In this simplified model, the larger model saves compute when T_large × c_large < T_small × c_small. With r = c_large / c_small, it must reduce token count by more than 1 − 1/r. r is the larger-to-smaller per-token compute ratio, and 1 − 1/r is the break-even line.

Estimated per-token compute for the four models, from their official configs (not hardware measurements):

Take GPQA-Diamond at 32K. GPT-OSS 20B generates 4,613 tokens per problem and 120B generates 1,809, a 61% reduction, well past the 30% line. Compute per problem falls from 41.5 to 23.1 TFLOP, or 0.56× the 20B. Qwen3.5 9B generates 16,295 tokens and 27B generates 12,926, a 21% reduction against a 69% line. Compute per problem rises from 290 to 733 TFLOP, or 2.53× the 9B.

All 32K results (compute ratio is larger over smaller; brackets are paired problem-bootstrap 95% intervals):

For GPT-OSS, the compute ratio is 0.56–0.72 on all four tasks, with every interval below 1. For Qwen3.5 it is 2.53–2.90, with every interval above 1. Qwen3.5 27B is more accurate, and it pays for that accuracy with extra compute.

Method: for every rollout we use the recorded prompt and generated lengths and sum config-based theoretical FLOPs for prefill and per-token decoding, including attention, which grows with context. These are analytical estimates, not measured GPU operations; the intervals reflect problem-sampling uncertainty, not error in the cost model. 671 Qwen3.5-27B MATH500 rollouts were recovered from logs without a recorded input length (some seeds of the 24 problems math500_476–499). We filled them with the input length recorded for the same problem in other Qwen rows: all 24 problems have recorded 27B and 9B values, and across all 758 problems every Qwen row of a given problem carries the same recorded value. Recorded values are the runner's count of the templated input, not engine-observed counts. Setting these inputs to 0, setting them to 903 tokens (the longest MATH500 prompt), or dropping the 24 problems from both models keeps the MATH500 compute ratio at 2.59–2.61 and the quality-matched ratio at 2.46–2.48, with interval endpoints moving by at most 0.015 relative to the same-problem imputation baseline; their prefill accounts for 0.09% of the 27B's MATH500 compute. The GPT-OSS break-even line is lower on AIME (24%) because the 20B's long traces pay more attention cost per token, which narrows the per-token price gap. Token counts here are total generated tokens, which include the answer; on GPQA the saving is 60.8% by this count and 60.9% by thinking tokens alone.

Two checks. Parameter counts computed from the configs approximately agree with the published figures (for GPT-OSS 120B we get 116.78B total and 5.12B active; OpenAI reports 116.8B and 5.13B). On an earlier single-GPU, single-request run of Qwen3.5-27B on AIME 2024, a memory-bandwidth estimate gives 330 seconds against 325 seconds measured.

Deployment cost also depends on concurrency. Under the same bandwidth model, the estimated single-request GPU-time ratio for GPT-OSS 120B versus 20B is 0.51–0.68 per problem. At 64 concurrent requests, a batch touches many more distinct experts, 120B reads far more weights per step, and the ratio rises to 1.06–1.45. The concurrency estimate assumes uniformly selected experts, a high-weight-traffic scenario. These GPU-time ratios are theoretical estimates, not matched measurements.

Quality against compute

Replace the token axis of Figures 2 and 3 with compute per problem, and plot all four tasks and all four budgets:

Truncated rollouts are included at their estimated compute based on recorded lengths and scored wrong if they gave no answer. Cells that failed finalization or truncation gates can therefore describe strict accuracy versus estimated compute under that budget. This does not make them pass the token-efficiency gate or establish their efficiency without truncation.

The four-budget quality frontier lets us estimate how much compute corresponds to matching the smaller model's 32K accuracy. We take the upper envelope of the four settings and interpolate linearly between accuracy and log compute. The ratios below describe that estimated frontier, not a global minimum over arbitrary inference settings.

• GPT-OSS 120B needs 0.67× the 20B's compute on MATH500 (95% CI [0.61, 0.74]), 0.50× on GPQA-Diamond ([0.46, 0.55]), and 0.53× on AIME 2025 ([0.44, 0.62]). On GPQA, the cheapest 120B setting (4K, 20.9 TFLOP per problem, 68.1%) already beats the most expensive 20B setting (32K, 41.5 TFLOP, 66.9%).
• AIME 2024 is the exception: by point estimate, 120B does not reach the 20B's 84.6% at any of the four tested budgets. This does not change the earlier conclusion that the accuracy difference is statistically unresolved.
• Qwen3.5 27B needs 2.47× the 9B's compute on MATH500 ([2.42, 2.53]), 2.24× on GPQA-Diamond ([2.11, 2.38]), 2.65× on AIME 2024 ([2.49, 2.79]), and 2.51× on AIME 2025 ([2.32, 2.70]).

On MATH500, 9B at 32K spends 181 TFLOP per problem and scores 93.3%. The cheapest 27B setting (4K) already spends 186 TFLOP and scores 44.1% because many responses are cut off. 27B does reach 98.0%, which 9B cannot reach within 32K. Within Qwen3.5 Dense, size raises the accuracy ceiling; over the accuracy range the 9B can reach, the 27B is the more expensive route.

On the same problem, GPT-OSS 120B still writes about half as much

A natural objection: maybe the larger model is shorter on average only because it solves more problems, and failed attempts tend to be long. We grouped problems by how many of the smaller model's eight attempts were correct, then compared the two models on the same problem:

• Problems both models solve 8/8: GPT-OSS 120B writes 0.47–0.63× as much as 20B (0.57 on the 423 MATH500 problems). Across all four tasks there are 542 such problems; 120B is shorter on 99% of them, with a median per-problem ratio of 0.64.
• Problems the 20B solves only sometimes (1–7 of 8): the ratio falls to 0.37–0.50. The 20B writes especially long traces here, while 120B produces substantially shorter outputs.
• Qwen3.5 27B: the "both solve" and "sometimes solve" groups sit between 0.76 and 0.90 with little dependence on difficulty. On problems the 9B never solves, the ratio is close to 1, because both models run up to the cap. On the 526 problems both solve 8/8, 27B is shorter on 86%, with a median of 0.80.

GPT-OSS 120B's shorter outputs cannot be explained only by which problems it solves. On the same set of problems that both sizes always solve, it writes about half as much; savings are larger in the group the 20B solves only sometimes. This is a descriptive analysis of outcome-defined groups, not an isolated causal effect of difficulty or scale.

Why the two families differ (hypothesis)

The supplementary analysis also reports different length-scaling patterns. These ranges span estimates from three subsets—all problems, both models correct 8/8, and non-truncated problems—not confidence intervals. Regressing each problem's larger-model log length on its smaller-model log length, with a sampling-noise correction, gives estimated slopes of 1.02–1.03 for Qwen3.5: the 27B's lengths look like the 9B's multiplied by about 0.8. For GPT-OSS the estimate is 0.89–0.92: on problems where the 20B writes longer, the 120B tends to cut more. Estimated noise-corrected length correlations within both families are 0.97–0.98, consistent with stable differences between problems; length correlation alone does not identify difficulty as the cause.

The two pairs also differ in architecture:

Qwen3.5 doubles its depth while GPT-OSS adds only half again, yet Qwen3.5 saves far fewer tokens. Depth alone does not explain the gap. GPT-OSS has four times as many experts, increasing parameter capacity, while per-token compute is only about 1.4× that of the smaller model.

Our working hypothesis: whether each size learns its own reasoning length through reinforcement learning, or inherits it from a shared teacher, may help explain whether scale translates into token efficiency. OpenAI's model card states that both GPT-OSS sizes were post-trained with "similar CoT RL techniques as OpenAI o3," so each could settle on its own length. The Qwen3 technical report states that its smaller models were distilled from larger ones; the public Qwen3.5 model cards mention reinforcement learning but give no per-size detail. If the Qwen3.5 sizes inherited their lengths from one teacher, lengths would scale as a whole, which matches the slope above. This does not establish that Qwen3.5 actually used that training route.

An outside evaluation also suggests that output caps may affect the observed length ratio. On the full Artificial Analysis Intelligence Index, Qwen3.5 9B used about 260M output tokens and 27B about 98M, a ratio near 0.38, far below the 0.8 we measure. Users have also reported the 9B getting stuck in reasoning loops on simple prompts. In our data, the 32K truncation rate on AIME is 29%–38% for 9B and 20%–23% for 27B. One possible explanation is that long 9B outputs on difficult problems are disproportionately cut off by the 32K cap, which may bias our AIME and GPQA ratios upward. The evaluations use different tasks and settings, so this does not determine the uncapped ratio. The MATH500 ratio of 0.81, where truncation is only 1%–4%, is less affected by this issue.

This remains a hypothesis; the experiments in “Next steps” would test it.

The parser question

Qwen3.5's AIME gate failures at first looked like a parser problem. An audit of the outputs showed that the thinking/answer split was fine. The failure happens at the switch from reasoning to answering: long reasoning uses up the budget and the model never writes a final answer.

More samples under the same settings would not fix this systematic finishing problem. We kept strict accuracy, excluded the affected cells from token-efficiency analysis as the gate requires, and did not "repair" the data by keeping only well-finished traces.

What the three excluded families showed

The screening summary above gives only the outcome. Here the problems are split into four layers: whether the parser worked, whether the model finished its reasoning and answered, whether the size difference produced a real quality difference, and whether budget or architecture settings made the comparison uninterpretable.

Ministral-3: a real quality reversal beyond the parser

The official parser handles complete outputs correctly. The main AIME problem comes earlier: the model spends its reasoning budget and still writes no final answer. On MATH500 at 32K, 14B scores 7.0% and 8B scores 31.6%, so fixing the parser would not rescue the hypothesis. The technical report describes a 14B→8B→3B pruning-and-distillation cascade and an RL generation limit raised from 32K to 80K after truncation was observed. The distillation path and sensitivity to long reasoning are plausible leads, not established causes. Classification: measurement failure plus a genuine smaller-model win.

Qwen3: the runs worked, but the difference is not about size

The Qwen3 pilot had no parser problem, but the direction depends on the task. On AIME, 235B-A22B leads. On MATH500, 30B-A3B is both more accurate (94.2% vs. 89.8%) and shorter (3.34K vs. 4.04K total tokens). The technical report shows the two also differ in active parameters (3B vs. 22B), depth, distillation, and post-training; the official AIME setup also uses a stop-thinking-then-answer step and a 38,912-token limit, while we used a hard 32K cap. The pilot is valid, but the difference cannot be pinned on size. Future MoE comparisons should control active size, training recipe, and the finishing protocol together.

GLM-4.5: a real counterexample that is sensitive to settings

At 32K on AIME, GLM-4.5-Air scores 64.4% avg@8 against 55.0% for the full model. Both have valid token splits, so the parser is not the cause. GPQA goes the other way and final validity is low, which shows the counterexample interacts strongly with the budget and with how the model exits reasoning. The report uses hybrid expert distillation and runs reasoning RL directly at 64K. Our 32K cap may amplify the problem, but a seed-0 diagnostic at 64K still did not restore the larger model's lead. Classification: a real AIME counterexample plus sensitivity to settings. Small ablations over budget, template, stop conditions, and forced finishing are the natural next step.

Three suggestions for future studies

1. Check that the result is measurable first. Full coverage does not guarantee valid final answers, valid token splits, or acceptable truncation. A missing answer counts as wrong, but its length should stay out of efficiency comparisons.
2. Establish comparability before talking about size. Sweep several output caps and report active MoE parameters, routing, and post-training differences so configuration effects are not mistaken for size effects.
3. Keep real counterexamples. If the smaller model is better under valid measurement, that result should limit the conclusion rather than be filed as dirty data.

Staying out of the main matrix does not mean the experiment failed. It can mean invalid measurement, an unidentifiable comparison, or a real counterexample.

Takeaways

In some controlled model families, the larger model reaches equal or better quality with fewer visible reasoning tokens. At the 32K budget, only GPT-OSS also saves per-problem compute under a config-based estimate. Qwen3.5 27B is more accurate but uses 2.5–2.9× the compute of 9B per problem.

• This is a conditional within-family pattern, not a law of parameter scale. The statistically supported 32K accuracy gains are +1.35 pp for GPT-OSS MATH500, +6.25 pp for GPT-OSS GPQA, and +4.68 pp for Qwen3.5 MATH500, each with fewer thinking tokens. They say nothing general about other architectures or training recipes.
• Fewer tokens save compute only past the break-even line. If each token costs r times as much, the larger model must reduce token count by more than 1 − 1/r. For GPT-OSS, r is about 1.4 and the 120B writes about half as much. For Qwen3.5, r is about 3.2 and the 27B writes only 10%–20% less.
• GPT-OSS 120B is shorter on the same problems. On the 542 problems both sizes always solve, 120B is shorter on 99%; savings are larger in the group the 20B solves only sometimes. Qwen3.5's reduction is similar in the both-always-correct and sometimes-correct groups.
• Reasoning efficiency combines quality, tokens, and measurement validity. A short response with no final answer is not efficient. Final validity, token splits, and truncation are part of the metric, not after-the-fact cleanup.
• The excluded families show measurement failure, confounded comparisons, and real counterexamples. Size is a meaningful factor only when architecture, post-training, active MoE size, and tokenizer are comparable. Counterexamples should be kept.
• Small benchmarks need uncertainty estimates. AIME has 30 problems; K=8 steadies each per-problem estimate but does not create 240 independent samples. The GPT-OSS drop on AIME 2024 is therefore an unresolved deviation.

Next steps

All three need inference only, no training:

1. Raise the Qwen3.5 output cap. Following the official recommendation, rerun 9B and 27B on AIME and GPQA with an 81,920-token cap. This reduces truncation and allows a more reliable length-ratio estimate, with residual truncation checked, and tests whether the 9B runs away on problems it cannot solve.
2. Force early answers and add a filler-token control. At several budgets from 0 to 4K, compare three conditions: reason up to the budget and then answer; answer without reasoning after the same number of filler tokens; answer with neither. The comparison splits what thinking tokens contribute into two parts: the written content, and the extra computation positions they provide. The first part is the reasoning that actually needs to be written down.
3. Compare distilled-only and distilled-then-RL models from the same base. Measure how length changes with size in each group using this protocol, to test whether the source of reasoning length determines token efficiency.

Research effort

Across two Codex tasks, the original study took about 126.2 hours of effective Codex work, or five days and six hours. This counts active execution, tool calls, and remote monitoring, and excludes long idle gaps between sessions.

The final auditable artifacts processed about 874 million tokens, including prompts and model outputs. This is a conservative lower bound: some early exploration and failed runs never made it into the unified ledger, and the count excludes tokens used by the GPT-5.5/GPT-5.6 research assistants.

The September update ran no new inference. It re-analyzed the existing 97,024 rollouts; Claude assisted with the analysis, figures, and revision.

Sources

• Noam Brown, Scaling Test Time Compute to Multi-Agent Civilizations, Latent Space, June 20, 2025: https://www.latent.space/p/noam-brown
• Yann Dubois, OpenAI's Yann Dubois: Why AI Progress Suddenly Feels Real, The MAD Podcast with Matt Turck, May 21, 2026; scale, weights, and thinking tokens at 24:34–25:23: https://www.youtube.com/watch?v=DhD1zZ8w8Mw&t=1474s
• Josh McGrath, [State of Post-Training] From GPT-4.1 to 5.1: RLVR, Agent & Token Efficiency, December 31, 2025; token-efficiency chapter at 13:12: https://www.youtube.com/watch?v=botHQ7u6-Jk
• OpenAI, gpt-oss-120b & gpt-oss-20b Model Card: https://cdn.openai.com/pdf/419b6906-9da6-406c-a19d-1bb078ac7637/oai_gpt-oss_model_card.pdf
• Liu et al., Ministral 3, arXiv:2601.08584, 2026: https://arxiv.org/abs/2601.08584
• Yang et al., Qwen3 Technical Report, arXiv:2505.09388, 2025: https://arxiv.org/abs/2505.09388
• Zeng et al., GLM-4.5: Agentic, Reasoning, and Coding (ARC) Foundation Models, arXiv:2508.06471, 2025: https://arxiv.org/abs/2508.06471
• Qwen, Qwen3.5-9B and Qwen3.5-27B model cards: https://huggingface.co/Qwen/Qwen3.5-9B, https://huggingface.co/Qwen/Qwen3.5-27B
• Artificial Analysis, Qwen3.5 small models: Everything you need to know: https://artificialanalysis.ai/articles/qwen3-5-small-models
• OpenAI, GPT-6 Astra System Card, September 3, 2026: https://deploymentsafety.openai.com/gpt-6-astra/vision
• Jakub Pachocki on the computation-graph depth of frontier models, X, September 2026: https://x.com/merettm/status/2095023204993490967
• Dylan Xu, Sebastian Prasanna, and Alek Westover, Astra is much better at reasoning with filler tokens than previous models, Redwood Research, September 23, 2026: https://blog.redwoodresearch.org/p/astra-is-much-better-at-reasoning

2026 年 9 月更新。 这次没有新增推理实验，只用原有的 97,024 条 rollout 补做了三项分析：按计算量核算、按计算量画质量前沿、按题目难度分层比较输出长度。结论有一处实质变化：两个家族的大模型都写得更短，但在 32K 预算下，按模型配置估算每题总计算量，只有 GPT-OSS 同时省了计算；Qwen3.5 27B 的计算量是 9B 的 2.5–2.9 倍。新增内容在「按计算量核算」到「两个家族为什么不同」四节，Takeaways 和来源也做了相应修改。

补这次更新，是因为这个问题在 9 月变得更实际了。OpenAI 9 月 3 日发布 GPT-6 Astra，system card 报告它的思考轨迹更短，不写思考时也能完成更难的任务。首席科学家 Jakub Pachocki 随后公开表示，包括 Astra 在内的前沿模型，每个 token 的计算图深度在 GPT-4 的两倍以内。Redwood Research 9 月 23 日的实验显示，Astra 在不写思考、只在题目后加填充 token 的条件下，AIME 类题目的准确率明显提高。模型的可见思考越来越短，写得短到底省了多少计算，需要单独算一遍。

这个项目从 Yann Dubois 的一段访谈开始

这个项目的起点是一段访谈。共同领导 OpenAI post-training frontiers 团队的 Yann Dubois 在 The MAD Podcast with Matt Turck 中谈到预训练规模与推理效率，原话是：

“If you have larger models, the amount of thinking time—so the amount of tokens they will think for—will usually decrease. […] The model already thinks through its weights when it generates a certain token. So you can decrease the number of tokens that you need to generate for thinking by increasing the size of the model […] if you basically pre-train larger models, you will get better efficiency.”
——Yann Dubois，访谈原文节选，24:34–25:23

他的意思是：模型越大，思考用的 token 通常越少，因为模型生成每个 token 时，已经靠权重完成了一部分思考。所以预训练更大的模型，推理效率会更高。

这段话把三件事连在了一起：更大的预训练模型、发生在权重里的思考、更少的显式思考 token。如果能力更多地存进了参数，推理时也许就用不着再写一条同样长的轨迹去重新搜索。

这是访谈里的判断，不是 OpenAI 的技术报告；Dubois 说的也是“通常会减少”。检验它不能只比排行榜分数，也不能把输出更短直接算作更高效，因为模型可能只是提前截断，或者根本没给出最终答案。所以实验要回答的是：

在同一模型家族内，任务、输出预算、解码规则和重复采样方式都保持一致时，较大模型能否用更少的可见思考 token，达到相同或更高的质量？

当时我在试 Auto Research：让前沿模型参与提出假设、设计实验、调度远端任务、审计产物、诊断失败，最后整理成可以复核的报告。Yann 的判断正好可以变成一个具体的研究问题。

Noam Brown 和 Josh McGrath 的公开讨论补上了另外两点。Brown 认为，额外的测试时计算只有在模型能力足够时才有用。McGrath 建议把模型进步画在“质量–token”平面上，看它是否向左上方移动。于是实验这样设计：每个家族比较两个规模，固定任务和生成方式，扫描多档输出预算，每道题重复采样；最终答案有效率、token 分区和截断率都达标，才拿来比较 token 效率。

GPT-5.5 和 GPT-5.6 作为研究助手参与了全过程：质疑原始假设、设计实验矩阵、审计远端任务、诊断测量问题、分析验收后的结果，并协助写报告、论文初稿和这篇文章。它们不是结论的证据。本文自有实验的数字来自任务日志、通过验收的结果文件及其后续分析。

图 1 画出了研究过程中八个改变方向的决策。橙色侧枝是经过诊断、降为补充证据的路线，不是跑失败的实验。

从五个候选家族筛到两个

GPT-OSS 和 Qwen3.5 不是一开始就挑好的。最初的候选还有 Ministral-3、Qwen3 和 GLM-4.5。我们先做小规模试跑，再看每个家族能否组成可解释的同家族规模对照。进入正式矩阵要同时满足四个条件：

1. 同一家族至少有两个可比较的规模，架构和后训练差异不会盖过规模本身；
2. tokenizer、对话模板、推理解析器和生成方式能保持一致；
3. 任务、预算和重复采样的覆盖足够画出质量–token 前沿，而不只是一个基准上的切片；
4. 最终答案有效率、token 分区和截断率足以支撑 token 测量，不会让“没写完”的短回答显得高效。

GPT-OSS 还有一个现成的对照。OpenAI 的 官方 model card 给出了 20B/120B 两个规模、官方 Harmony 格式，以及 AIME 和 GPQA-Diamond 上 low、medium、high 三档推理强度的评测。其中的图 3 把三档画在“准确率–平均 CoT+Answer token”平面上，120B 往往用更短的输出到达相近或更高的准确率。这组官方结果不属于我们的实验，也不计入下文统计，但它说明 GPT-OSS 规模可比、token 通道可靠，适合拿来做受控复验。

筛选之后，GPT-OSS 和 Qwen3.5 Dense 组成了最干净的两组对照，进入正式矩阵。Ministral-3、Qwen3 和 GLM-4.5 因测量有效性不足、规模和架构或训练配方混在一起，或者和推理预算强烈交互，没有进入正式矩阵。其中也观察到真实的质量反转，后文保留并分析。

入选标准看的是可比性和测量是否有效，而不是某个家族是否支持原假设。没进正式矩阵的家族，结果同样是研究的一部分。

实验设置

每个家族选两个规模：

实验统一采用 K=8：4 个模型，4 个任务（MATH500、GPQA-Diamond、AIME 2024、AIME 2025），4 档最大输出预算（4K、8K、16K、32K）；每个“模型–题目–预算”组合独立采样 8 次。

统计以题目为独立单位，同一道题的 8 次 rollout 不当作 8 道题。95% 置信区间来自按题配对的 bootstrap（2,000 次重采样）：每抽到一道题，就把这道题在大小两个模型上的全部 8 次 rollout 一起保留，再算“大模型减小模型”的差。所以 AIME 的有效样本量是 30 而不是 240；K=8 让每道题的估计更稳，题目数量本身不变。

GPT-OSS 的 high effort 只作辅助分析，不参与主结论的门禁。

质量主要看 8 次 rollout 的平均准确率 avg@8，pass@8 作参考。token 分成思考 token、答案 token 和总生成 token 分别统计。

比较 token 效率之前，还要过一道测量门禁。严格准确率始终把缺失或无法解析的最终答案算错。一组 token 效率比较要满足三个条件才会采用：

• 最终答案有效率至少 95%；
• 思考/答案 token 分区有效率至少 95%；
• 32K 的单元截断率不超过 5%。

没过门禁的单元保留严格准确率，但不用它的 token 长度去论证效率。

汇总结果：两个家族的方向都对，但条件不同

下表是 32K 预算下“大模型减小模型”的 avg@8 配对差。置信区间不跨 0，说明在这批基准题目上，准确率的方向有统计支持。“未通过”只限制 token 效率的推断，严格准确率和它的置信区间照常保留。

和官方 model card 的对照。 官方图 3 在 AIME 2025 和 GPQA-Diamond 上画过 20B/120B 的质量–CoT+Answer 曲线，点位对应表 3 的 with tools 结果，用来展示推理强度提高带来的测试时扩展。和我们“不用工具、固定 medium、四档硬预算”最接近的是表 3 的 medium / no tools：GPQA-Diamond 为 66.0%→73.1%，我们测到 66.9%→73.1%；AIME 2025 为 72.1%→80.0%，我们测到 74.2%→83.3%，方向一致。model card 里没有 MATH500。

所以二维画法和 GPT-OSS 上的基本方向都不是我们首先发现的。这部分工作是对官方结果做一次受控复验：固定推理强度、K=8、加测量门禁；同时补上只算思考 token 的口径、MATH500 和 Qwen3.5 这个家族。官方数字只作外部对照，不和我们的数据、置信区间或验收统计合并。

GPT-OSS：结果最清楚

GPT-OSS 对原假设的支持最强。5 个过门禁的固定预算比较里，120B 的思考 token 全部少于 20B，其中 4 个的准确率也更高。4 个等质量前沿点上，120B 都用更少的思考 token 达到了同样的准确率。

32K 下：

• MATH500 准确率从 95.8% 升到 97.2%，配对差 +1.35 个百分点，95% CI [+0.60, +2.18]；思考 token 平均少 849，95% CI [−1,028, −685]。
• GPQA-Diamond 从 66.9% 升到 73.1%，配对差 +6.25 个百分点，95% CI [+3.41, +9.34]；思考 token 平均少 2,804，95% CI [−3,289, −2,323]。
• AIME 2025 从 74.2% 升到 83.3%，配对差 +9.17 个百分点，95% CI [+3.75, +15.00]。这个单元没过 token 效率门禁，只保留准确率结论。

AIME 2024 的点估计反了过来：准确率从 84.6% 降到 81.7%，配对差 −2.92 个百分点。它的 95% CI 为 [−8.33, +2.50]，精确配对 sign-flip 检验的双侧 p=0.383，统计上无法确定，只能算一次偏离，不算反例。思考 token 的减少倒是稳定的：平均少 4,252，95% CI [−6,071, −2,663]。

Qwen3.5：方向相同，可用的证据更少

Qwen3.5 在过门禁的证据上也是同一方向。MATH500 32K 下，27B 的准确率从 93.3% 升到 98.0%，配对差 +4.68 个百分点，95% CI [+3.65, +5.73]；思考 token 平均少 1,949，95% CI [−2,155, −1,752]，点估计下降 18.7%。

GPQA-Diamond 的严格准确率从 74.1% 升到 82.2%，配对差 +8.14 个百分点，95% CI [+5.49, +10.98]。AIME 2024 和 AIME 2025 分别为 +8.33（95% CI [+3.33, +14.17]）和 +15.83 个百分点（95% CI [+8.75, +23.75]）。这几个单元没过最终答案有效率或截断率门禁，准确率结果有效，但不用于 token 效率结论。

按计算量核算：GPT-OSS 省了，Qwen3.5 是小模型的 2.5 倍以上

前面比的是 token 数。大模型每生成一个 token 本身就更贵，所以 token 少了，总计算不一定少。按“单价 × 数量”来算：

• T：一道题平均生成多少 token，含思考和答案；
• c：生成一个 token 要多少次浮点运算。粗略地说，c ≈ 2 × 每个 token 用到的参数量；MoE 的专家部分只计这次激活的专家，共享层仍计入；
• 一道题的总计算 ≈ T × c。

在这个简化模型中，大模型要省计算，需要 T大 × c大 < T小 × c小。记 r = c大 / c小，这个条件等价于大模型少写的 token 比例超过 1 − 1/r。r 是大小模型每 token 计算量之比，1 − 1/r 就是盈亏平衡线。

四个模型每生成一个 token 的计算量，按官方 config 估算（不是硬件实测）：

以 GPQA-Diamond 32K 为例。GPT-OSS 20B 每题平均生成 4,613 个 token，120B 生成 1,809 个，少写了 61%，远超 30% 的平衡线；每题计算从 41.5 TFLOP 降到 23.1 TFLOP，是 20B 的 0.56 倍。Qwen3.5 9B 每题生成 16,295 个 token，27B 生成 12,926 个，只少写了 21%，离 69% 差得远；每题计算从 290 TFLOP 升到 733 TFLOP，是 9B 的 2.53 倍。

32K 下的全部结果（计算量之比为大模型除以小模型，括号内为按题配对 bootstrap 95% CI）：

GPT-OSS 四个任务的计算量之比都在 0.56–0.72，置信区间全部低于 1；Qwen3.5 在 2.53–2.90，全部高于 1。Qwen3.5 27B 的准确率确实更高，但那是多花计算换来的。

计算方法：每条 rollout 用记录中的 prompt 长度和生成长度，按模型配置累加 prefill 和逐 token 解码的理论 FLOPs，包括随上下文变长而增加的注意力计算。这是解析估算，不是实测 GPU 运算量；置信区间反映题目采样的不确定性，不涵盖成本模型误差。有 671 条 Qwen3.5-27B 的 MATH500 记录来自日志恢复，没有记录输入长度（math500_476–499 共 24 道题的部分 seed）。我们用同一道题在其他 Qwen 记录中的输入长度补齐：这 24 道题都有 27B 和 9B 的已记录值，而且 758 道题里，同一道题的所有 Qwen 记录值完全相同。这些记录值是运行脚本按官方模板算出的输入长度，不是推理引擎的实测值。把这些记录的输入长度按 0 算、按 MATH500 最长的 903 个 token 算，或把这 24 道题从两个模型中一并剔除，MATH500 的计算量之比都在 2.59–2.61 之间，等准确率计算量之比在 2.46–2.48 之间，相对同题补齐方案，置信区间端点的移动不超过 0.015；这些记录的 prefill 只占 27B 在 MATH500 上总计算的 0.09%。GPT-OSS 在 AIME 上的平衡线较低，只有 24%，是因为 20B 的长轨迹要付更多注意力开销，拉低了两个模型的单价之比。这里的 token 数是总生成 token，比思考 token 多出答案部分，两者在 GPQA 上的节省比例分别是 60.8% 和 60.9%。

两个校验：按 config 算出的参数量与官方公布值接近（例如 GPT-OSS 120B 算得 116.78B 总参数、5.12B 激活参数，官方为 116.8B 和 5.13B）；在一组单卡、单请求的 Qwen3.5-27B AIME 2024 历史运行上，按显存带宽估算的耗时为 330 秒，实测 325 秒。

FLOPs 之外，实际部署的开销还取决于并发。按同一带宽模型估算，单请求时，GPT-OSS 120B 每题的 GPU 时间约为 20B 的 0.51–0.68 倍；并发 64 时，一批请求会用到更多不同的专家，120B 要读的权重大增，这个比例升到 1.06–1.45。并发估算假设专家被均匀选中，属于较高权重读取量的情形；这些 GPU 时间比值均为理论估算，没有对应实测。

按计算量画质量前沿

把图 2、图 3 的横轴从 token 换成每题计算量，四个任务、四档预算都画出来：

这张图里，被截断的 rollout 也按记录长度估算其计算量，没给出答案就算错。因此，前面未通过收尾或截断门禁的单元，可以用于描述该预算下的严格准确率与估算计算开销；这不代表它们通过了 token 效率门禁，也不能外推无截断时的效率。

用四档预算构成的质量前沿可以估计：大模型要追平小模型在 32K 下的准确率，需要多少计算？我们取四档结果的上包络，并在准确率与对数计算量之间做线性插值。下面是该前沿上的估计，不是任意推理配置下的全局最小值。

• GPT-OSS 120B 需要 20B 的 0.67 倍（MATH500，95% CI [0.61, 0.74]）、0.50 倍（GPQA-Diamond，[0.46, 0.55]）和 0.53 倍（AIME 2025，[0.44, 0.62]）。在 GPQA 上，120B 最便宜的 4K 配置每题 20.9 TFLOP、准确率 68.1%，已经超过 20B 最贵的 32K 配置（41.5 TFLOP、66.9%）。
• AIME 2024 是例外：按点估计，120B 在四档已测预算下都达不到 20B 的 84.6%；这并不改变前文对准确率差异尚不确定的判断。
• Qwen3.5 27B 需要 9B 的 2.47 倍（MATH500，[2.42, 2.53]）、2.24 倍（GPQA-Diamond，[2.11, 2.38]）、2.65 倍（AIME 2024，[2.49, 2.79]）和 2.51 倍（AIME 2025，[2.32, 2.70]）。

在 MATH500 上，9B 用 32K 预算每题花 181 TFLOP，准确率 93.3%；27B 最便宜的 4K 配置每题就要 186 TFLOP，因为大量截断，准确率只有 44.1%。27B 能到 98.0%，这是 9B 在 32K 内达不到的。在 Qwen3.5 Dense 里，规模带来的是更高的准确率上限；在 9B 能达到的准确率范围内，它不是更省的选择。

同一道题，GPT-OSS 120B 也只写一半

有人会问：大模型平均写得短，会不会只是因为它做对了更多题，而做错的题往往写得长？按小模型每道题 8 次里做对几次分组，再比较两个模型在同一道题上的生成长度：

• 两个模型都 8/8 做对的题：GPT-OSS 120B 的长度是 20B 的 0.47–0.63 倍（MATH500 423 题为 0.57）。把四个任务合起来共 542 道题，120B 在 99% 的题上更短，每题比值的中位数是 0.64。
• 20B 只能偶尔做对的题（8 次中对 1–7 次）：比值降到 0.37–0.50。20B 在这些题上写得特别长，120B 的平均输出明显更短。
• Qwen3.5 27B：“都做对”和“偶尔做对”两组都在 0.76–0.90 之间，和难度基本无关；9B 全错的题上接近 1，两个模型都写到了上限附近。两个模型都 8/8 做对的 526 道题里，27B 在 86% 的题上更短，中位数 0.80。

所以 GPT-OSS 120B 的“短”不能仅用答对题目的构成解释：在两者都稳定做对的同一组题上，它也只写一半左右；在 20B 部分做对的题组中，缩短比例更大。这是按结果分组的描述性分析，不能单独识别难度或规模的因果效应。

两个家族为什么不同（推测）

补充分析还给出了两个家族不同的长度缩放模式。这些范围来自全样本、两模型均 8/8 做对、无截断三个子集的估计，不是置信区间。把每道题“大模型的对数长度”对“小模型的对数长度”做回归，并校正采样噪声后，Qwen3.5 的斜率估计为 1.02–1.03，27B 相当于把 9B 的长度整体乘了约 0.8；GPT-OSS 为 0.89–0.92，20B 写得越长的题，120B 往往缩得越多。两个家族内部，大小模型输出长度的噪声校正相关系数估计均为 0.97–0.98，与题目本身存在稳定差异的解释相容，但不能仅凭长度相关性归因于难度。

再看架构。两组模型的差异并不相同：

Qwen3.5 的层数加倍，GPT-OSS 只加了一半，但 Qwen3.5 省下的 token 反而少得多。单看深度解释不了这个差别。GPT-OSS 的专家数同时增至 4 倍，增加了可用参数容量，而每个 token 的计算量约为小模型的 1.4 倍。

我们目前的推测是：思考长度是每个尺寸自己通过强化学习学出来的，还是从同一个 teacher 继承来的，可能影响规模能否转化为 token 效率。OpenAI 的 model card 写明 GPT-OSS 两个尺寸都做了 CoT 强化学习，可以各自学出适合自己的长度。Qwen3 技术报告写明小模型通过从大模型蒸馏得到；Qwen3.5 的公开 model card 提到做了强化学习，但没有分尺寸说明。如果 Qwen3.5 各尺寸的长度来自同一个 teacher，长度被整体继承、按比例缩放，就和上面的斜率一致；但这不能证明 Qwen3.5 实际采用了该训练路线。

外部评测还提示，输出上限可能影响观察到的长度比。Artificial Analysis 跑完整套 Intelligence Index 时，Qwen3.5 9B 用了约 2.6 亿输出 token，27B 约 9,800 万，比值约 0.38，比我们测到的 0.8 小得多。社区也有 9B 在简单指令上陷入思考循环的反馈。我们的数据里，Qwen3.5 在 32K 下的截断率是 9B 在 AIME 上 29%–38%、27B 为 20%–23%。一种可能解释是：9B 超出能力范围时产生的长输出更多地被 32K 上限截掉，因此 AIME 和 GPQA 上的比值可能偏高。两个评测的任务和配置不同，不能据此确定无截断时的比值；截断率只有 1%–4% 的 MATH500 上，0.81 受这一问题影响较小。

以上是推测，需要后文「下一步」列出的实验来检验。

到底是不是解析器的问题？

Qwen3.5 在 AIME 上没过门禁，一开始容易被当成解析器出错。审计产物后发现，思考和答案的 token 分区是正常的；问题出在从思考转到作答这一步：长推理耗光了预算，模型没能写出最终答案。

在同一配置下多采样，也消除不了这种系统性的收尾问题。我们保留严格准确率，按门禁把相关单元排除在 token 效率分析之外，也没有只挑“收尾良好”的样本来修补数据。

三个未入选家族的诊断

前面只概括了筛选结果。这里把问题拆成四层：解析器是否正常；模型能否完成从思考到作答的收尾；大小模型之间是否真有质量差；推理预算或架构配置是否让比较无法解释。

Ministral-3：解析器之外还有真实的质量反转

官方解析器能正确处理完整输出。AIME 的主要问题出现在更早：模型耗光推理预算，仍没写出最终答案。MATH500 32K 上，14B 只有 7.0%，8B 是 31.6%，修好解析器也救不回原假设。技术报告显示这个家族按 14B→8B→3B 逐级剪枝和蒸馏，而且曾因截断把强化学习的生成上限从 32K 提到 80K。蒸馏路径和对长推理的敏感都是合理的线索，但还不足以确定原因。结论：测量不合格，同时小模型真实胜出。

Qwen3：结果跑出来了，但差异归不到规模上

Qwen3 试跑没有明显的解析器问题，结果却因任务而异：AIME 上 235B-A22B 占优；MATH500 上 30B-A3B 的准确率（94.2% 对 89.8%）和总 token（3.34K 对 4.04K）都更好。技术报告显示，两者除了总参数，激活参数（3B 对 22B）、层数、蒸馏和后训练路线也都不同；官方 AIME 评测还用“停止思考再作答”的收尾方式和 38,912 token 上限，我们用的是硬性 32K。这组试跑有效，但差异归不到“规模”这一个因素上。以后做 MoE 对照，需要同时控制激活规模、训练配方和收尾方式。

GLM-4.5：真实反例，加上对推理配置敏感

32K 的 AIME 上，GLM-4.5-Air 的 avg@8 为 64.4%，完整模型为 55.0%；两者的 token 分区都正常，和解析器无关。GPQA 上方向相反，而且最终答案有效率偏低，说明这个反例和预算、退出思考的行为强烈交互。技术报告采用混合专家蒸馏，并直接在 64K 长度上做推理强化学习；我们的 32K 上限可能放大了问题，但 seed 0 的 64K 诊断仍没恢复大模型的优势。结论：AIME 上是真实反例，同时对配置敏感。下一步适合针对预算、模板、终止条件和强制收尾做小规模消融。

给后续实验的三点建议

1. 先确认结果能测。 覆盖完整不代表最终答案有效率、token 分区和截断率都合格。缺失的答案要算错，但它的长度不应进入效率比较。
2. 先控制可比性，再谈规模。 多扫几档输出上限，报告 MoE 激活参数、路由和后训练差异，避免把配置差异当成规模效应。
3. 保留真实反例。 小模型在有效测量下更好，就应该用它来限定结论，而不是归为脏数据。

没进正式矩阵不代表实验失败：原因可能是测量不合格、比较无法识别，也可能是一个真实反例。

Takeaways

在部分受控的模型家族里，较大模型能用更少的可见思考 token 达到相同或更高的质量。在 32K 预算下，按模型配置估算每题总计算量，只有 GPT-OSS 同时省下了计算；Qwen3.5 27B 的准确率更高，但计算量是 9B 的 2.5–2.9 倍。

• 这是家族内的条件性规律，不是参数规模定律。 32K 下有统计支持的准确率提升是：GPT-OSS MATH500 +1.35 pp、GPT-OSS GPQA +6.25 pp、Qwen3.5 MATH500 +4.68 pp，同时思考 token 都减少了。这些结果推不出跨架构、跨训练配方的普遍关系。
• 省 token 要越过盈亏平衡线才算省计算。 大模型每个 token 的计算量是小模型的 r 倍，就要少写超过 1 − 1/r 的 token。GPT-OSS 的 r 约 1.4，实际少写一半；Qwen3.5 的 r 约 3.2，只少写一到两成。
• GPT-OSS 120B 的短，在同一道题上也成立。 两个模型都稳定做对的 542 道题里，120B 在 99% 的题上更短；在 20B 部分做对的题组中，缩短比例更大。Qwen3.5 在「都做对」和「偶尔做对」两组的缩短比例相近。
• 推理效率要同时看质量、token 和测量有效性。 写得短但没给出答案，不算高效。最终答案有效率、token 分区和截断率是指标的一部分，不是事后清洗。
• 未入选的家族分别对应测量失效、比较混杂和真实反例。 只有架构、后训练、MoE 激活规模和 tokenizer 足够可比时，“规模”才是可以讨论的因素；反例应当保留，不能筛掉。
• 小基准要报告不确定性。 AIME 只有 30 道题，K=8 让每道题的估计更稳，但不会变成 240 个独立样本。GPT-OSS 在 AIME 2024 上的下降因此只算一次偏离。

下一步

下面三项都只需要推理，不需要训练：

1. 放宽 Qwen3.5 的输出上限。 按官方推荐，把上限放到 81,920，重跑 9B 和 27B 的 AIME 与 GPQA，减少截断并检查剩余截断率，以更可靠地估计长度比，看 9B 在做不对的题上是否写得失控。
2. 低预算强制作答，加填充 token 对照。 在 0 到 4K 的若干预算下，比较三种条件：写思考到预算后强制作答；不写思考、只加同样数量的填充 token；什么都不加。这样可以把思考 token 的作用拆成两部分：一部分靠写出的内容，一部分只是提供了额外的计算位置。前一部分对应真正需要写出来的思考。
3. 找只做蒸馏与蒸馏后再做强化学习的同底座模型组。 用本文的协议比较两组模型的长度随规模变化的方式，检验“长度来源决定 token 效率”这一推测。

这次验证的投入

原研究跨前后两个 Codex 任务，累计约 126.2 小时有效 Codex 工作时间，即 5 天 6 小时。这个口径包括实际执行、工具调用和远端监控，不含两次工作之间的长空档。

最终可审计的实验产物共处理约 8.74 亿 tokens，含 prompt 和被测模型的生成内容。这是保守下界：部分早期探索和失败任务没进统一账本，也不含 GPT-5.5/GPT-5.6 研究助手自身消耗的 token。

9 月的更新没有新增推理，只对已有的 97,024 条 rollout 做核算和分组分析；分析、作图和改稿由 Claude 协助完成。

来源

• Noam Brown，Scaling Test Time Compute to Multi-Agent Civilizations，Latent Space，2025 年 6 月 20 日：https://www.latent.space/p/noam-brown
• Yann Dubois，OpenAI's Yann Dubois: Why AI Progress Suddenly Feels Real，The MAD Podcast with Matt Turck，2026 年 5 月 21 日；规模、权重与思考 token 的原话位于 24:34–25:23：https://www.youtube.com/watch?v=DhD1zZ8w8Mw&t=1474s
• Josh McGrath，[State of Post-Training] From GPT-4.1 to 5.1: RLVR, Agent & Token Efficiency，2025 年 12 月 31 日；token 效率一节从 13:12 开始：https://www.youtube.com/watch?v=botHQ7u6-Jk
• OpenAI，gpt-oss-120b & gpt-oss-20b Model Card：https://cdn.openai.com/pdf/419b6906-9da6-406c-a19d-1bb078ac7637/oai_gpt-oss_model_card.pdf
• Liu 等，Ministral 3，arXiv:2601.08584，2026：https://arxiv.org/abs/2601.08584
• Yang 等，Qwen3 Technical Report，arXiv:2505.09388，2025：https://arxiv.org/abs/2505.09388
• Zeng 等，GLM-4.5: Agentic, Reasoning, and Coding (ARC) Foundation Models，arXiv:2508.06471，2025：https://arxiv.org/abs/2508.06471
• Qwen，Qwen3.5-9B 与 Qwen3.5-27B model card：https://huggingface.co/Qwen/Qwen3.5-9B，https://huggingface.co/Qwen/Qwen3.5-27B
• Artificial Analysis，Qwen3.5 small models: Everything you need to know：https://artificialanalysis.ai/articles/qwen3-5-small-models
• OpenAI，GPT-6 Astra System Card，2026 年 9 月 3 日：https://deploymentsafety.openai.com/gpt-6-astra/vision
• Jakub Pachocki 在 X 上关于前沿模型计算图深度的说明，2026 年 9 月：https://x.com/merettm/status/2095023204993490967
• Dylan Xu、Sebastian Prasanna、Alek Westover，Astra is much better at reasoning with filler tokens than previous models，Redwood Research，2026 年 9 月 23 日：https://blog.redwoodresearch.org/p/astra-is-much-better-at-reasoning