Why does post-training ignore parallel and aggregative reasoning?

Scaling inference compute is not a single lever. SPIRAL names three distinct primitives: sequential reasoning inside one trace, independently sampled parallel traces, and aggregation of multiple traces into a final answer. The mismatch it identifies is that during post-training a model is optimized only for the first — sequential CoT within a single trace — even though deployment routinely uses all three. This means the model never learns to produce traces that are collectively useful for an aggregator, nor to aggregate well; those behaviors are bolted on at inference by scaffolds the model was never trained against.

Since How should we balance parallel versus sequential compute at test time?, the usual framing pits parallel against sequential as competing budgets. SPIRAL reframes the two as complementary primitives that, plus aggregation, form one pipeline — and argues the real bottleneck is the train/inference gap, not the choice between them. The fix is set reinforcement learning to make a batch of traces jointly informative, plus standard RL on the aggregation step, with all components optimized end-to-end against the final aggregated reward.

This matters because it explains a class of test-time failures where more compute stops helping: the model misallocates a budget it was never trained to spend across primitives. Where Can parallel architectures solve inherently sequential problems? says some problems demand serial depth, SPIRAL says even when parallelism helps, an untrained aggregator wastes it.