SPRINT: Enabling Interleaved Planning and Parallelized Execution in Reasoning Models
Authors: Emil Biju
Shayan Talaei
Zhemin Huang
Mohammadreza Pourreza
Azalia Mirhoseini
Amin Saberi
Venue: NeurIPS 2025 poster ()
Keywords: Large Reasoning Models
Parallel inference
Planning and parallel execution
Post-training
Primary area: deep_learning
TL;DR: SPRINT trains large reasoning models to dynamically spot and run independent subtasks in parallel, reducing sequential tokens by up to 40% on complex tasks like math without sacrificing accuracy compared to sequential reasoning baselines.

Abstract: Large reasoning models (LRMs) excel at complex reasoning tasks but typically generate lengthy sequential chains-of-thought, resulting in long inference times before arriving at the final answer. To address this challenge, we introduce SPRINT, a novel post-training and inference-time framework designed to enable LRMs to dynamically identify and exploit opportunities for parallelization during their reasoning process. SPRINT incorporates an innovative data curation pipeline that reorganizes natural language reasoning trajectories into structured rounds of long-horizon planning and parallel execution. By fine-tuning LRMs on a small amount of such curated data, the models learn to dynamically identify independent subtasks within extended reasoning processes and effectively execute them in parallel. Through extensive evaluations, we demonstrate that models fine-tuned with the SPRINT framework match the performance of reasoning models on complex domains such as mathematics while generating up to 39% fewer sequential tokens on problems requiring more than 8,000 output tokens. Finally, we observe consistent results transferred to two out-of-distribution tasks, namely GPQA and Countdown, with up to 45% and 65% reduction in average sequential tokens respectively for longer reasoning trajectories, while matching the performance of the fine-tuned reasoning model.

SPRINT: Enabling Interleaved Planning and Parallelized Execution in Reasoning Models
Emil Biju 12+
Shayan Talaei
Zhemin Huang!
Mohammadreza Pourreza*
Azalia Mirhoseini Amin Saberi't
Stanford University Microsoot Google
{emilbiju, stalaei, zheminh)@stanfford edu pourreza@google. com, (azalia, (aberi)@stanford.. edu
Abstract
Large reasoning models (LRMs) excel at complex reasoning tasks but typically generate lengthy sequential chains-of-thought, resulting long inference times before arriving the final answer. To address this challenge, introduce SPRINI, a novel post-tran post-training and inference- time framework designed to enable LRMs dynamically identify and exploit opportunities for parallelization during their reasoning process. SPRINT incorporates an innovative data curation pipeline that reorganizes natural language reasoning trajectories into structured rounds of long- horizon planning and parallel execution. By fine-tuning LRMs on a small amount of such curated data, the models learn dynamically identify independent sub- tasks within extended reasoning processes and effectively execute them in parallel. Through extensive evaluations, SPRINT framework match the performance of reasoning models on complex do- mains such as mathematies while generating up 39% fewer sequential tokens on problems requiring more than 8,000 output tokens. Finally, we observe consistent results transferred to two out-of-distribution tasks, namely GPQA and Countdown, with up to 45% and 65% reduction in average sequential tokens respectively for longer reasoning trajectories, while matching the performance of the fine-ture fine-tuned reasoning model.
demonstrate that models fine-tuned with the
Introduction
Scaling inference-time compute in large language models (LLMs) has consistently been shown to enhance reasoning accuracy. Existing methods broadly fall into categories: sequential [1] and parallel 22. Sequential approaches, notably large reasoning models (LRMs) such as Deepseek-R1 (
and OpenAl ol 4 have demonstrated remarkable successes in solving complex reasoning tasks, e.g., math and coding, but at the cost of generating very lengthy sequences of tokens. On the other hand, parallel methods, such as repeated sampling with self-consistency (5) or best-of-N [6] 7 leverage multiple response generations to improve accuracy. However, these methods typically lack effective coordination and shared information across inference paths, leading redundant computations and limited performance gains. Furthermore, structured parallel methods like Tree-of- Thoughtsss (8) and Graph-of-Tie Thooughsss [9] require predefined, heuristic--driven search structures, inherently restricting flexibility and scalability across diverse tasks.
"Equal contribution.
Equal senior authorship.
39th Conference on Neural Information Processing Systems (NcurIPS 2025).

---

We propose SPRINT a framework for post-training and inference of reasoning models that combines the advantages of sequential reasoning and parallel inference, while maintaining the flexibility required for general tasks. Instead of relying on manual structures, SPRINT trains reasoning language models to dynamically identify and exploit parallelization opportunities during inference. This enables SPRINT to achieve the high accuracy of reasoning models while significantly reducing the number of sequential tokens needed for solving complex reasoning tasks such as mathematics.
For the inference, SPRINT introduces an orchestration of LRMs through two distinct roles: planner and a pool of executors. At each step, the planner that has access to the cumulative context of the reasoning trajectory generates a set of independent plans, each explained via natural language <prompt>. Subsequently, multiple executors concurrently carry out these plans. This interleaved planning-executinn strategy accelerates the reasoning process by enabling simultaneous execution of lengthy tasks.
Although many off-the-shelf LRMs achieve high performance via sequential reasoning trajectories, they are not trained for effectively proposing parallelizable tasks. Recognizing that LRMs' reasoning trajectories for a given query include steps such as reflection on their previous steps, decomposing tasks to subtasks, and trial-and-error exploration of alternative strategies, we question the necessity of strictly sequential reasoning. In practice, many reasoning steps are independent and thus can be executed in parallel; for instance, by simultaneously exploring multiple strategies or independently computing separate components of a complex problem. Building on these insights, we designed data curation pipeline that carefully reorganizes natural language reasoning trajectories into structured plans and parallel executions, closely preserving the original data distribution. Finally, through supervised fine-tuning of the reasoning model on only 1700 such demonstrations, we unlock the model's 's capability to dynamically recognize and exploit opportunities for parallel reasoning.
To evaluate the accuracy and efficacy of SPRINT, we conducted experiments on MATH-500 (7 for lesting in-distribution. and two out-of-domain distribution benchmarks: GPQA-diamon Countdown (Game of 24) [8] On MATH-500, SPRINT improved the accuracy of the base reasoning model Deepseek-R - -distill-77B 7B B from 89.1% to 92.5%, outperforming the reasoning fine-tuned model (RFT) at 91%, while generating 440 fewer sequential tokens on average. On the problems requiring longer reasoning trajectories (more than 8000 tokens under the RFT model), SPRINT achieves even greater savings, reducing sequential tokens by up to 39%. We also show that SPRINT generalizes well to out-of-domaii tasks, matching the performance of the reasoning fine-tuned model while significantly reducing token usage- - by 53% on Countdown.
[10] and
In summary, our work makes the following key contribution +
We propose SPRINT, an innovative framework for accelerating the reasoning process of large reasoning models through rolling horizon parallel planning and execution.
We develop novel data curation pipeline that carefully converts complex natural language reasoning trajectories into structured datasets for fine-tuning LRMs, featuring a multi-step process that includes step extraction, Directed Acyelic Graph (DAG) creation, packing, filtering, and reformatting.
We analyze the accuracy and the efficiency of SPRINT on complex reasoning tasks in comparison to strong reasoning baselines. Our results show that SPRINT can achieve higher accuracy compared the reasoning distilled model, while generating up to 39% fewer sequential tokens on long reasoning trajectories.
We show consistent generalization performance of SPRINT on two out-of-domain benchmarks, saving sequential tokens by about 45% on GPQA and 65% Countdown respectively, while matching the performance of the reasoning finetuned model. These results highlight SPRINT'S ability to effectively parallelize reasoning trajectories across diverse domains.
'The name SPRINT is inspired by agile development methodology, where a sprint involves a planning phase followed by parallel, incremental execution.
We open-source our code and datasets this repository

---

Table Comparison inference- time scaling approaches. Methods are evaluated based on support for inference-tine parallelism, adaptive search, model optimization, and the capability to handle multi-step sequential reasoning. SPRINT uniquely addresses all criteria, enabling dynamic parallelism in general reasoning tasks that require interdependent sequential steps.
Inference-Time
Adaptive Search
Model Optimization
Multi-Step Reasoning
Method
Parallelism
Sree-of-Thought (To'T) 8
X
Graph-of-Thoughe (GoT)
9
XX
AXX
X
Skeleton-of-Theee Thought (SoT)
X
Repeated Sampling 2.5.6
X
Reasoning Models 3
V
PASTA [26
V
X
Hogwild! Inference
/
X
SPRINT (Ours)
/
/
2
Related Work
Long Chains-of-Thought for Improved Reasoning, Recent advancements have shown that gen- erating extensive chains-of-thought [ significantly enhances the reasoning capabilities of large language models, particularly in tasks such as mathematical problem-solving and logical inference 4 3. Despite their effectiveness, these methods inherently produce long sequential outputs, increasing latency and slowing inference speed. SPRINT addresses this limitation by enabling models dynamically parallelize independent reasoning steps, significantly reducing sequential generation and enhancing inference efficiency.
Structured Search and Multi-Agent Frameworks. Approaches like Tree-of-Thougee [8). Graph-of- Thought [9] Forest-of- Thouhhth [13], and Atom-of-Thought [14], along with multi-agent interaction methods [15 16 17 18). structure reasoning processes through fixed search patterns predefined interaction protocols, often at the full-solution level. SPRINT generalizes these frameworks by training models autonomously allocate inference-time computation between serial and parallel tasks to solve sub-parts one solution trajectory or explore alternative solutions.
Planning and Execution with Language Models. Integrating planning capabilities into language models has been explored through upfront decomposition of tasks into subtasks [19 20 21 (2 or
iterative refinement based on intermediate feedback 23 24
These approaches primarily rely on
sequential execution without explicitly considering dynamic parallel planning. SPRINT addresses this gap by enabling models autonomously perform dynamic parallel planning, enhancing inference efficiency through concurrent execution.
Parallelization in language model reasoning. Methods that leverage parallel inference paths, such as best-of-N sampling 6 or self-consistency 5 have shown performance improvements through generating multiple independent reasoning trajectories. However, these techniques typically lack effective coordination among parallel threads, resulting redundancy and inefficient computation. To mitigate this issue, Skeleton-of-TT ofhoough Thought (25 and 28) parallelize decoding by assuming semantic independence among subtasks, thus enabling separate processing of different response segments. Although these methods achieve faster inference, they exhibit suboptimal performance on tasks that inherently require sequential reasoning, such as mathematical mroblem-solving where later steps depend earlier computations.
Recently, three works, PASTA 26). Hogwild! Inference 27 and APR 29 have investigated parallelization within shared reasoning trajectory. PASTA teaches models to decompose task into parallel subtasks and subsequently merges their full context back into single main thread, but it does not optimize for reasoning tasks that require multi-step planning. Hogwild! Inference relies on parallel prompting for collaborative reasoning among multiple workers, without tuning the models to distribute tasks effectively. APR trains models to delegate subtasks to parallel child threads for synthetic countdown tasks, but its training data curation relies on specialized symbolic solver, limiting its applicability to general reasoning tasks. SPRINT extends this line of research by

---

Query
(1) Planning
Planner
(2) Parallel execution
<Plan
Terminating the reasoning process
Thinking
sprompt..12... sprompt
Executor
<execution 1> <lexecution
Thinking
Sprompt 1.2 Sprompt
Executor
<execution <lexecution 2>
Final Answer
Thinking
sprompt p.
Executor
xexecution 3> <lexecution 3>
</Plan_i>
Starting next round
Running Context
(3) Syncing
Figure 1: Overview of SPRINT's inference process: 1) The planner receives the cumulative context, including previous plans and execution results, and either proposes new of independent tasks terminates the process by producing the final answer. 2) A pool of executors concurrently performs each task according their prompts. 3) The execution outcomes appended back into the cumulative context with corresponding tags, returning to step for the next iteration.
introducing a generalizable post-training framework that enables reasoning models to dynamically structure inference for general reasoning tasks.
In general, an effective reasoning system should support logical multi-step interdependencies (multi- step reasoning) accurately handle tasks where later steps depend earlier outcomes. It should dynamically adapt its search strategy (adaptive search) to address diverse problem structures. Opti- mizing model performance specifically for downstream tasks (model optimization) is often necessary to achieve efficient results. Finally, leveraging parallel execution finfrencc-tine time parallelism) is crucial reducing latency by concurrently processing independent reasoning subtasks. Table compares our method and existing inference-time scaling methods against these criteria.
Methodology
In this section, outline the design and components of SPRINT, which at high level consists of an inference framework for reasoning models and a training protocol to teach them how to effectively identify and exploit parallelizable planning and execution during their reasoning processes.
3.1 Interleaved Planning and Parallel Execution at Inference Time
SPRINT'S inference comprises two main modules: a planner and a pool of executors, all powered by fine-tuned reasoning models. Inference begins when the planner receives the input query, followed by iterative rounds of planning and execution, called stages, until the planner decides to terminate the process by producing the final answer. As shown in Figure each inference stage includes the following three phases:
1. Planning. At stage the planner receives the cumulative context of the reasoning trajectory, which includes the input query, previous plans, and the execution outputs from all the preceding stages (1 through i 1). The planner then generates a plan for the current stage, enclosed within <Plan_is tags. During this stage, the planner may generate intermediate reasoning tokens, benefiting from its reasoning capabilities. When the planner identifies subtask suitable for delegation to executor, specifies this task within tags <prompt_ij _ij>..jij..........eeee.. Upon closing each </prompt_i, pijpppt_iii>ir tag, an executor initiates the corresponding task given the current cumulative context snapshot.
Parallel executions. Fach executor independently and concurrently performs its assigned subtask by generating a chain-of chain-of-thought reasoning trajectory accomplish the specific task. Executing these

---

Query
Query
Query
Query
Packed stages
<Reasoning> line 1: Let's calculate the line 2:
Step 1-3
Step
Step 1
Execution: line 4-10
fiter
Step Plan: line 11-14
Step
Step
Formatted
Iine 11: Let's verfly our calculation
prompt: Veriy Execution: 15-30
Step
Step
Step
Step
Step
Step Plan: 200-203
<iRessoning>
prompt: Concluding the final answer which is
Step
Step 7
SPRINT finetuned LRM
Answer
Final Answer
Final Answer
Final
0) Thinking trajectories
Extracting the prompt. and executions
2) Creating the DAG execution dependencies
Packing the
SFT LRM filtered, reformatted data
model
Figure 2: Overview of the SPRINT training pipeline: (0) Starting from raw reasoning trajectories,
(I) we first extract individual reasoning steps, identifying their planning and execution phases. Next, (2) we construct a DAG representing dependencies among these steps, and then (3) group steps into compact stages that be executed in parallel. Finally, (4) after filtering and reformatting these structured stages into training samples, we perform supervised fine-tuning of a reasoning model to dynamically propose and execute parallelizable tasks.
subtasks in parallel significantly reduces the total number of sequential tokens generated compared to processing them sequentially, greatly improving inference efficiency.
Syncing. Once all parallel executions are complete, the results from each executor are enclosed within tags <execution_i_) _ij'j, clearly indicating their corresponding tasks. These results are synced back into the cumulative context in the same order as their original prompt definitions. The updated context is then fed back to the planner, which either initiates the next stage concludes the inference by outputting the final answer.
3.2 Training Reasoning Models for SPRINT Framework
To effectively train reasoning models to identify and exploit parallelization opportunities during inference, we developed data curation pipeline that transforms complete natural language reasoning trajectories into structured rounds of rolling-horin extracts individual planning and execution steps, organizes them into dependency- based stages, and generates training examples that capture both sequential planning and parallel execution aspects. An overview of this pipeline is shown in Figure Detailed prompts for each step in the pipeline are provided in Appendix A
planning and parallel execution. The pipeline
in response to query Q, we decompose it into distinct steps S = [S1. S2..... S by prompting an LLM (in this case, GPT-4o) with specific instructions; refer to Appendix A.2 Each step S is further decomposed into planning phase (P:), where R1 identifies tasks and strategies, and an execution phase (Ez), where these planned tasks are performed. Note that some steps may only involve planning without explicit execution; these are termed plan-only steps, and no executor instructions are generated for them.
Step extraction. Given a reasoning trajectory т, generated by DeepSeck-RI
To discourage trivial executor calls, we merge very short executions back into their planning phase, making them plan-only steps and encouraging the planner to handle simpler tasks independently.
2. DAG creation. Next, we identify dependencies among steps by prompting a smaller LLM (GPT- 4o-mini) to determine which steps depend on others; for the instructions see A.2 These dependencies are represented formally as:
D (S,, Sy depends on S,, S. e S).
This set of dependencies forms a Directed Acyelic Graph (DAG), denoted by G = (S, D), where nodes represent individual steps and edges represent dependencies among them.
5

---

Sequential tokens decoded during the reasoning process
Reasoning
Bequential
Query Plan
Exec
Plan
Exec
Plan
Exec
Plan
Exec
... Final Answer
Indepandent
dependent
Independent
Fine
SPRINTS
Query Plan
Plan Exec
Exec
Plan Plan Exec
Exec
Final Answer
Query
Plan
Final
Exec
Exec
Exec
Exec 4
Synd
Sync:
Figure 3: Comparison of sequential tokens decoded during reasoning. Sequential reasoning models generate all the steps serially, resulting long token sequences. SPRINT's fine-tuning data restructures these steps into stages, grouping parallelizable plans followed by their respective executions. This organization enables SPRINT'S inference framework to execute these grouped steps in parallel, significantly reducing the number of sequential tokens.
3. Packing. We group the steps into stages, each containing plans that can be generated simulta- neously by the planner and executions that can be carried out concurrently by executors. While naive approach would group steps solely based on their depth the DAG, we further optimize the stage arrangement by observing that if the parent Sp of node S; plan-only step, S; can safely be included in the same stage as Sp- This optimization ensures both context availability and enhanced parallelization efficiency. Further details this adjustment are provided in Appendix A.2
Formally, the stage number (S,) for each step S = (P,, E.) is defined as:
if St has parents
(S.))
max (o(Sp)+ + 0)), otherwise (SP
The set of steps at a given stage consists of all steps with stage number o(S)) = represented as:
( St (S.)) k.
Within each stage k the combined plan is created by concatenating the plans all steps S; in L(k), ordered according to their original sequence. The execution phase for stage k includes execution components from steps, excluding those that are plan-only:
p concat(P, S. E ((M), g(h) (E E #0.
where E, indicates that S; is plan-only step.
Training the LRM. To ensure that the model learns from trajectories with significant parallelization potential, we introduce parallelization ratio, defined as (#steps)/ (#sstggss) and discard trajectories with ratios below 1.5. The selected trajectories are reformatted into sequences of stage-wise plans and executions, enclosed within explicit tags (<Plan_i> and <execution_ipp (ipitiiooniii)))))) in the order illustrated Figure 3 Finally, we fine-tune the LRM on the reformatted thinking patterns. Through this process, the model learns to dynamically propose independent, parallelizable tasks based on previous sequences of plans and executions, and to execute each task following its corresponding prompt effectively.
Methodology Overview. Overall, as detailed in Section 3.2 SPRINT trains reasoning models to propose parallelizable subtasks rather than generating their entire reasoning trajectories serially. During inference, as described in Section 33.1] the trained model effectively manages long-term interdependencies while significantly reducing the number of sequential tokens generated. Figure illustrates this workflow, highlighting how SPRINT reorganizes sequential reasoning traces into parallelizable stages during training and subsequently leverages this learned parallel structure for efficient, concurrent execution inference time. For examples of SPRINT'S reasoning versus serial reasoning trajectories, please refer to Appendix B

---

Experiments
4.1 Experimental Setup
Datasets, To train our models, we begin with 6,000 reasoning trajectories from DeepSeek-RI 3
generated on the training set of the MATH dataset [3], released by (3I). After filtering these trajectories for correctness of the final answers and processing them through our data curation pipeline
(Section 3.2
obtain curated of approximately 1,700 samples for training.
For evaluation, we primarily use the MATH-500 benchmark [32], a widely recognized test set consisting of 500 mathematical reasoning problems. To further examine the generalization capabilities of SPRINT to more challenging and cittof-ddistibbttion scenarios, we evaluate its performance against strong baseline models
additional benchmarks. First, we evaluate GPQA-diamond [TO), a dataset from entirely different scientific domains, including biology, physics, and chemistry, thus assessing cross-domain reasoning robustness. Moreover, following (29) g we test SPRINT subset of 1000 samples from Countdown [8] a synthetic numerical reasoning task in which models must derive a target number from four provided numbers using arithmetic operations (+: X, +).
Baselines. We compare SPRINT against several reasoning baselines employing both serial and parallel sampling strategies:
3 This model is distillation of the main RI reasoning model into Qwen-2.5-7B [3] released by DeepSeek. We use this reasoning model both as baseline for direct comparison and as the base model for our fine-tuning experiments.
Base reasoning model (DeepSee--RL-DDstill--eeee
2. Reasoning fine-tuned model (RFT): To control for the effect of the training data and compare against conventional distillation methods, we perform supervised fine-tuning of the DeepSeek-RI: Distill-Qwen-7B model using the same 1,700 RI reasoning trajectories from MATH used to train SPRINT. This model represents standard continued distillation of Qwen-2.5-7B on RI trajectories from the MATH dataset.
Given query, SoT decomposes it into subtasks and executes them through parallel LLM calls within a single stage. Both the subtask generation and execution processes rely on out-of-the-bon LLMs without any task- fine-tuning. We evaluate SoT using both the chat-instruct Qwen-2.5-7B model (referred to as SoT-chat) and the reasoning-focused DeepSeek-RI DeepSeck-R1-Distill- 1-Distilll---e--T7 model (referred to SolV-reasoning).
3. SoaeettnnoofThouglhe (SoT) 25
We include repeated sampling combined with self-consistency aggregation baseline to evaluate whether purely parallel sampling approach can achieve similar accuracy and efficiency compared to the interleaved planning and execution framework of SPRINT.
Repeated Sampling + Self-consistency 2 5]
We consider two metrics evaluate the performance and efficiency different approaches. First, we measure the accuracy of the final answer reached for the downstream task, computed as the percentage the correctly answered queries by each method (see A..4 for details). Second, to evaluate the efficiency improvements in terms of the latency, we measure the number of sequential tokens generated by each method. In particular, for sequential reasoning baselines, is exactly the number of output tokens. For SPRINT, calculate the sequential tokens follows:
Evaluation Metrics.
stagos
# prompts at stage & max
number of sequential tokens
(Pr. + Ei.)).
where P.,k and Eg,x represent the number of sequential tokens generated by the planner until the end of 1tth prompt and by exccutor for the 4hhh execution step i respectively. Note that the ideal wall-clock time correlates with the number of sequential tokens generated by each method; however, accurately measuring this metric would require higher computational resources, which we discuss further in Section
4.2 Results
Comparison to conventional distillation. Figure shows the accuracy and average number of sequential tokens generated by different methods on the MATH-500 benchmark. We observe that fine-tuning our base model (RI (RI-Distill-7B) trajectories generated by DeepSeck-RR improves
7

---

93.0
SPRINT
500
Parallelized
Level
Level
92.0
R1-Distil-32B
Number problems
Level
91.5
Level
Accuracy
91.0
RFT
SoT
300
Level
90.5
200
90.0
89.5
R1-Distil-7B
100
5
4
8
9 10
Average Number of Sequential Tokens
Stage number
Figure 4: Pareto plot comparing accuracy (%) and sequential token counts generated by dif- ferent methods on MATH-500. While SPRINT achieves slightly higher accuracy compared the RFT model, generates 440 (~~ 15%)
Figure 5: Number of problems at each difficulty level in MATH-500 that pass each stage of in- terleaved planning before arriving the final answer. The dashed line indicates the number of problems each stage that exhibit parallelism (more than one plan).
fewer tokens on average.
the accuracy of both SPRINT and RFT, albeit with an increase in their average sequential token counts. The accuracy gains are substantial, bringing both models close to the performance of the much larger RI-Distill-32B reasoning model. Notably, SPRINT achieves a higher accuracy of 92.5%, which can be attributed to independent executions within each stage that prevent one result from influencing the others. Despite being fine- tune- on the same trajectories plan-executtin format, SPRINT requires 440 (~ 15%) fewer sequential tokens due to parallelized executions. These results demonstrate that SPRINT achieves the same level of reasoning accuracy as conventional distillation used in RFT while substantially reducing the sequential token count.
RFT, reorganized in
Effectiveness of interleaved planning. The SoT-reasgn baseline underperforms SPRINT in both accuracy and the number of sequential tokens. Since SoT only allows single round of planning and uses model without task-specific fine-tuning, it often generates mutually dependent subtasks. When the model executes them independently in parallel, it cannot use the result of one execution to inform another, resulting in redundant computations across subtasks and total token count that is almost three times higher than SPRINT (see Table 2). Similarly, repeated sampling with self-consistenge generates multiple independent responses the same query, leading to a high total token count. In contrast, SPRINT uses interleaved planning and execution over multiple stages where the plan in each stage is generated based on the results of previous executions, allowing better coordination. Figure
In-domain
Out-of-domain
MATH-500
Countdown
GPQA-Diamont Diamond
Method
Accf
# Seql
Total
Acc
Seql
Acct
# Seql
Self-consistency
80.5
590
11645
78.5
2845
45.4
4735
SoT-chat
47.3
256
1290
80.0
2367
49.4
3526
SoT-reasoning
90.8
3836
11538
82.4
5823
48.0
7560
RFT
91.0
2880
2880
84.9
4917
50.5
7103
SPRINT
92.5
2440
3622
85.9
2284
51.0
6336
Table 2: Comparison of pass accuracy and sequential token count across MATH-500, GPQA-
Diamond, and Countdown tasks. While SPRINT is only fine-tuned on math reasoning, SPRINT demonstrates strong generalization capabilities on the oft-of-domain tasks, Countdown and GPQA- Diamond, SPRINT also reduces sequential token count through parallelized executions without large increase in total token count.

---

MATH500
Countdown
GPQA-Diamona
Sequential Token Reduction
39%
5000
4000
3000
2000
5.%
19%
2000
by
1000
1%%
1000
9%
-42%
-1000
0-4k 6k-8k
8k-10k
0.2k
26-4k
0.6k
6k-9k
91-12k
12k-15k
Number of Takens generated by RFT model
Figure 6: Sequential token reduction achieved by SPRINT. The x-axis shows the number of sequential tokens generated by the RFT baseline model, and the y-axis indicates the average reduction in sequential tokens achieved by SPRINT. As the baseline's sequential requirements increase, SPRINT finds greater opportunities for parallelization, yielding larger sequential token reductions.
illustrates patterns in SPRINT'S interleaved planning. As expected, harder problems require more stages before reaching the final answer. Additionally, SPRINT generates more plans in the earlier stages, the model explores multiple strategies and identifies relevant subtasks, while later stages are more deterministic.
Reduction in sequential token count. We further examine the sequential token reduction achieved by SPRINT relative to RFT Figure For problems with short reasoning trajectories, the additional prompts and plan/exccution tags introduce small overhead, resulting in 5% increase in sequential tokens. However, as problem difficulty increases and reasoning trajectories become longer, SPRINT consistently reduces the sequential token count relative to the length of the RFT trajectory due to parallel executions. In particular, on problems where RFT requires more than 8,000 tokens on average, SPRINT achieves 39% reduction in sequential tokens.
Reduction in runtime. The savings sequential tokens translate directly to lower latency. We estimate per-problem runtime by adding the time-to-first-tokn (TTFT) overhead incurred at the start of each plan/cxecution to the subsequent decoding time. In practice, decoding dominates; the prefilling (TTFT) cost is comparatively small. Under this estimate, SPRINT outperforms RFT by 9% on MATH-500 (36.92s vs. 40.57s per problem) and by 38% on the subset with longer reasoning chains (74.47s vs. 120.54s). Because runtime scales primarily with the number of decoded tokens, SPRINT'S advantage increases with trajectory length, yielding larger absolute and relative latency reductions harder instances.
Generalization. To assess SPRINT'S generalization capabilities to out-of-domain tasks, we report performance on Countdown and GPQA-Diamond in Table SPRINT leverages the highly paralleliz- able nature Countdown task solve problems with much fewer sequential tokens (2284 tokens compared to 4917 tokens by RFT), demonstrating 53.5% reduction. Notably, these parallelization opportunities are identified despite not being trained on trajectories from this task. Due to the benefits of independent exploration and interleaved planning, SPRINT also beats all baseline methods to achieve an accuracy of 85.9%. Similarly, on the GPQA-Diamond dataset, SPRINT achieves the highest accuracy (51.0%) while reducing sequential token count by 10.8% relative to RFT. Similar to MATH-500, we observe from Figure that SPRINT provides higher efficiency gains on problems with longer reasoning chains.
5 Limitations and Future work
Hardware optimization for realized wall-clock time speed-up. SPRINT delivers clear efficiency gains, reducing sequential tokens and lowering our end-to-end runtime approximation, but fully realizing these benefits in wall-clock time requires hardware-aware optimizations. Previous works [26]
27 29
have indicated that sequential token counts are closely correlated with wall-clock latency. However, achieving the ideal latency improvements in practice requires optimized key-value caching mechanisms and baghhbhndwidth GPU interconnects, especially for long reasoning trajectories

---

encountered in general tasks. Additionally, executing large number of parallel tasks simultaneously necessitates a corresponding number GPUs. Due limited resources, we were unable to implement the optimal
decoding for SPRINT. Future work could explore implementing SPRINT within optimized caching frameworks and scalable GPU architectures to fully realize practical wall-clock time efficiency gains offered by parallel decoding strategies.
Parallelizing tool-use in reasoning models. In our current work, we primarily treat executions as sequences of tokens that models decode to accomplish tasks. However, from a planning perspective, these executions can alternatively be viewed as black-box modules that receive specific tasks and return corresponding execution results. Several prior works, such as ReAct [23], Self-Ask [34], Swirl [35] and others [36] 37 38), have introduced mechanisms enabling language models to in- tegrate tool-use into their reasoning loops, iteratively planning, invoking external tools or APIs, and then continuing their reasoning based on the obtained results. Such reasoning-tool interaction trajectories could significantly benefit from parallelization, especially in scenarios where tool invo- cations dominate the decoding latency. Future work could extend SPRINT'S data curation pipeline to accommodate these trajectories, training models to effectively invoke multiple tools APIs concurrently within their reasoning processes.
Beyond Supervised Training. Through supervised fine-tuning (SFT) on curated data, our model learned how to define parallelizable plans, effectively reducing sequential token generation. However, the achievable parallelism is inherently limited by the quality of training data. Future work could explore latency-aware reinforcement learning (RL), using reward signals based on inference efficiency. allowing models to autonomously discover strategies that further enhance parallel reasoning beyond the constraints of demonstration data.
Conclusion
In this work, we presented SPRINT, framework for post-training reasoning language models that reorganizes their reasoning trajectories into a series of plans and parallelized exccutions. Additionally, SPRINT introduces an inference mechanism that leverages the trained reasoning model to identify independent subtasks and execute them in parallel. This approach significantly reduces the number of sequential tokens while achieving comparable state-of-the-ar performance to the reasoning fine-tuned (RFT) model. Notably, problems requiring extensive reasoning trajectories, SPRINT uncovers even greater parallelization potential, achieving sequential token reductions of 39%. Furthermore, we evaluated our model's generalization on multiple out-of-domain tasks and consistently found that SPRINT generates substantially fewer sequential tokens while maintaining performance on par with RFT. These results suggest that the SPRINT training unlocks parallelized reasoning capabilities in the model across diverse domains with longer reasoning trajectories.
7
Acknowledgment
This work was supported in part by the Air Force Office of Scientific Research (AFOSR) under Grant TA9550-23-1-0255 and in part by the Office of Naval Research under Grant N00014-24-1-2164 We also thank Yuhao Ge at the University Illinois Urbana-Champaign for his guidance on the model training process and computing requirements.
References
[1] Jason Wei, Xuezhi Wang. Dale Schuurmans. Maarten Bosma, Brian Ichter. Fei Xia, Ed Chi, Quoc Le, and Denny Zhou. Chain-of off-hhougtt prompting elicits reasoning in large language models, 2023.
[2] Bradley Brown, Jordan Juravsky, Ryan Ehrlich, Ronald Clark, Quoc Le, Christopher Ré, and Azalia Mirhoseini. Large language monkeys: Scaling inference compute with repeated sampling. arXiv preprint arXiv:2407.217877 2024.
[3] Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, Ruoyu Zhang, Runxin Xu, Qihao Zhu, Shirong Ma, Peiyi Wang, Xiao Bi, et al. Deepseek-rl: Incentivizing reasoning capability in Ilms via reinforcement learning, arXiv preprint arXiv:2501.12948 2025.
10

---

[4] OpenAl. Learning to reason with 1lms, 2024.
[5] Xuezhi Wang, Jason Wei, Dale Schuurmans, Quoe Le, Ed H Chi, Sharan Narang, Aakanksha Chowdhery, and Denny Zhou. Self-consistency improves chain of thought reasoning in language models. In The Eleventh International Conference on Learning Representations.
[6] Karl Cobbe, Vineet Kosaraju, Mohammad Bavarian, Mark Chen, Heewoo Jun, Lukasz Kaiser, Matthias Plappert, Jerry Tworek, Jacob Hilton, Reiichiro Nakano, et al. Training verifiers to solve math word problems. arXiv preprint arXiv:21 10. /4/68, 2021.
[7] Hunter Lightman, Vineet Kosaraju, Yura Burda, Harri Edwards, Bowen Baker, Teddy Lee, Jan Leike, John Schulman, Ilya Sutskever, and Karl Cobbe. Let's verify step by step, 2023.
[8] Shunyu Yao, Dian Yu, Jeffrey Zhao, Izhak Shafran, Tom Griffiths, Yuan Cao, and Karthik Narasimhan. Tree of thoughts: Deliberate problem solving with large language models. Ad- vances in neural information processing systems, 36:11809-11822, 2023.
[9] Maciej Besta, Nils Blach, Ales Kubicek, Robert Gerstenberger, Michal Podstawski, Lukas Gianinazzi, Joanna Gajda, Tomasz Lehmann, Hubert Niewiadomski, Piotr Nyczyk, et al. Graph of thoughts: Solving elaborate problems with large language models. In Proceedings of the AAAI Conference on Artificial Intelligence, volume 38, pages 17682-17690, 2024.
[10] David Rein, Betty Li Hou, Asa Cooper Stickland, Jackson Petty, Richard Yuanzhe Pang, Julien Dirani, Julian Michael, and Samuel R. Bowman. Gpqa: A graduate-level google-proof q&a benchmark, 2023.
[11] Banghua Zhu, Hiteshi Sharma, Felipe Vieira Frujeri, Shi Dong, Chenguang Zhu, Michael I Jordan, and Jiantao Jiao. Fine-tuning language models with advantage-induced policy alignment. arXiv preprint 20X.02230..0221,, 2023.
[12] Eric Zelikman, Yuhuai Wu, Jesse Mu, and Noah Goodman. Star: Bootstrapping reasoning with reasoning. Advances in Neural Information Processing Systems, 35:15476-1548, 2022.
[13] Zhenni Bi, Kai Han, Chuanjian Liu, Yehui Tang, and Yunhe Wang. Forest-of:thought: Scaling test-time compute for enhancing Ilm reasoning, 2025.
[14] Fengwei Teng, Zhaoyang Yu, Quan Shi, Jiayi Zhang, Chenglin Wu, and Yuyu Luo. Atom of thoughts for markov IIm test-time scaling. arXiv preprint arXiv:2502. 12018, 2025.
[15] Yilun Du, Shuang Li, Antonio Torralba, Joshua B Tenenbaum, and Igor Mordatch. Improv- ing factuality and reasoning in language models through multiagent debate. In Forty-first International Conference on Machine Learning, 2023.
[16] Sehoon Kim, Suhong Moon, Ryan Tabrizi, Nicholas Lee, Michael W Mahoney, Kurt Keutzer, and Amir Gholami. An Ilm compiler for parallel function calling. In Forty-first International Conference on Machine Learning, 2024.
[17] Mingehen Zhuge, Wenyi Wang, Louis Kirsch, Francesco Faccio, Dmitrii Khizbullin, and Jürgen Schmidhuber. GPTSwarm: Language agents optimizable graphs. In Proceedings of the 41 International Conference on Machine Learning. 2024.
[18] Jon Saad-Falcon, Adrian Gamarra Lafuente, Shlok Natarajan, Nahum Maru, Hristo Todorov, Etash Guha, E. Kelly Buchanan, Mayee Chen, Neel Guha, Christopher Ré, and Azalia Mirho- seini. Archon: An architecture search framework for inference-time techniques, 2024.
[19] Denny Zhou, Nathanael Schärli, Le Hou, Jason Wei, Nathan Scales, Xuezhi Wang. Dale Schuurmans, Claire Cui, Olivier Bousquet, Quoe Le, et al. Least-to-most prompting enables complex reasoning in large language models. arXiv preprint arXiv:2205. 10625, 2022.
[20] Karthik Valmeekam, Sarath Sreedharan, Matthew Marquez, Alberto Olmo, and Subbarao Kambhampati. On the planning abilities of large language models (a critical investigation with proposed benchmark), 2023.

---

[21] Gurusha Juneja, Subhabrata Dutta, Soumen Chakrabarti, Sunny Manchanda, and Tanmoy Chakraborty. Small language models fine-tuned to coordinate larger language models improve complex reasoning, 2024.
[22] Archiki Prasad, Alexander Koller, Mareike Hartmann, Peter Clark, Ashish Sabharwal, Mohit Bansal, and Tushar Khot, Adapt: As-needed decomposition and planning with language models, 2024.
[23] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. React: Synergizing reasoning and acting in language models. In International Conference on Learning Representations (ICL.), 2023.
[24] Noah Shinn, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. Reflexion: Language agents with verbal reinforcement learning, 2023.
[25] Xuefei Ning, Ziman Lin, Zixuan Zhou, Zifu Wang, Huazhong Yang, and Yu Wang. Skeleton- of thouhhtth Prompting iims for efficient parallel generation. arXiv preprint 1rX1v 2023.
[26] Tian Jin, Ellie Y. Cheng, Zack Ankner, Nikunj Saunshi, Blake M. Elias, Amir Yazdanbakhsh, Jonathan Ragan-Kelley, Suvinay Subramanian, and Michael Carbin. Learning to keep promise: Scaling language model decoding parallelism with learned asynchronous decoding, 2025.
[27] Gleb Rodionov, Roman Garipov, Alina Shutova, George Yakushev, Vage Egiazarian, Anton Sinitsin, Denis Kuznedelev, and Dan Alistarh. Hogwild! inference: Parallel Ilm generation via concurrent attention, 2025.
[28] Mingdao Liu, Aohan Zeng, Bowen Wang, Peng Zhang. Jie Tang, and Yuxiao Dong. Apar: Llms can do auto-parallel auto-regressive decoding, 2024.
[29] Jiayi Pan, Xiuyu Li, Long Lian, Charlie Snell, Yifei Zhou, Adam Yala, Trevor Darrell, Kurt Keutzer, and Alane Suhr. Learning adaptive parallel reasoning with language models, 2025.
[30] Dan Hendrycks, Collin Burns, Saurav Kadavath, Akul Arora, Steven Basart, Eric Tang, Dawn Song, and Jacob Steinhardt. Measuring mathematical problem solving with the math dataset, 2021.
[31] open rl. Openthoughts-11 114kggttt--114aatthhh 2025.
[32] Hunter Lightman, Vineet Kosaraju, Yura Burda, Harri Edwards, Bowen Baker, Teddy Lee, Jan Leike, John Schulman, Ilya Sutskever, and Karl Cobbe. Let's verify step by step. arXiv preprint arXiv:2305.20008 2023.
[33] An Yang. Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chengyuan Li, Dayiheng Liu, Fei Huang, Haoran Wei, et al. Qwen2. 5 technical report. arXiv preprint arXiv:2412.15115, 2024.
[34] Ofir Press, Muru Zhang, Sewon Min, Ludwig Schmidt, Noah A. Smith, and Mike Lewis. Measuring and narrowing the compositionality gap in language models, 2023.
[35] Anna Goldie, Azalia Mirhoseini, Hao Zhou, Irene Cai, and Christopher D. Manning, Synthetic data generation multi-step for reasoning tool use, 2025.
[36] Zhengliang Shi, Shen Gao, Lingyong Yan, Yue Feng, Xiuyi Chen, Zhumin Chen, Dawei Yin, Suzan Verberne, and Zhaochun Ren. Tool learning in the wild: Empowering language models as automatic tool agents, 2025.
[37] Yongliang Shen, Kaitao Song. Xu Tan, Dongsheng Li, Weiming Lu, and Yueting Zhuang. Hugginggpt: Solving ai tasks with chatgpt and its friends in hugging face, 2023.
[38] Bhargavi Paranjape, Scott Lundberg, Sameer Singh, Hannaneh Hajishirzi, Luke Zettlemoyer, and Marco Tulio Ribeiro. Art: Automatic multi-step reasoning and tool-use for large language models, 2023.
12

---

[39] Edward Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li. Shean Wang. Lu Wang. Weizhu Chen, et al. Lora: Low-rank adaptation of large language models. ICLR. 12):3, 2022.
[40] Tim Dettmers, Artidoro Pagnoni, Ari Holtzman, and Luke Zettlemoer. Qlora: Efficient finetuning of quantized llms. Advances in neural information processing systems, 36:10088- 10115, 2023.
[41] Yuze Zhao, Jintao Huang, Jinghan Hu, Xingjun Wang, Yunlin Mao, Daoze Zhang, Zeyinzi Jiang, Zhikai Wu, Baole Ai, Ang Wang, Wenmeng Zhou, and Yingda Chen. Swiftra scalable lightweight infrastructure for fine-tuning, 2024.
[42] Jeff Rasley, Samyam Rajbhandari, Olatunji Ruwase, and Yuxiong He. Deepspeed: System optimizations enable training deep learning models with over 100 billion parameters. In Proceedings of the 26th ACM SIGKDD international conference on knowledge discovery & data mining, pages -500--306, 2020.
[43] Samyam Rajbhandari, Jeff Rasley, Olatunji Ruwase, and Yuxiong He. Zero: Memory optimiza- tions toward training trillion parameter models. In SC20: International Conference for High Performance Computing, Networking, Storage and Analysis, pages 1-16. IEEE, 2020.
[44] Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph Gonzalez, Hao Zhang, and Ion Stoica. Efficient memory management for large language model serving with pagedattention. In Proceedings of the 29th Symposium on Operating Systems Principles, pages 61 1-626, 2023.
13

---

NeurIPS Paper Checklist
1. Claims
Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?
Answer: [Yes]
Justification: All the claims made in the paper backed by the experimental results provided section 4.2
Guidelines:
The answer NA means that the abstract and introduction do not include the claims made the paper.
The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No or
NA answer to this question will not be perceived well by the reviewers.
The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize to other settings.
is fine to include aspirational goals as motivation as long as is clear that these goals not attained by the paper.
2. Limitations
Question:
Does the paper discuss the limitations the work performed by the authors?
Answer:
[Yes]
Justification:
We discussed the limitations of work in section 5
Guidelines:
The answer NA means that the paper has no limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.
The authors are encouraged to create a separate "Limitations" section their paper.
The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g., independence assumptions, noiseless settings, model well-specification, asymptotic approximations only holding locally). The authors should reflect how these assumptions might be violated in practice and what the implications would be.
The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on few datasets or with few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.
The authors should reflect on the factors that influence the performance of the approach. For example, facial recognition algorithm may perform poorly when image resolution is low images are taken in low lighting. Or speech-to-text system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.
The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size.
If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairness.
While the authors might fear that complete honesty about limitations might used by reviewers as grounds for rejection, worse outcome might be that reviewers discover limitations that aren't 't acknowledged judgment and recognize that individual actions in favor of transparency play impor- tant role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations.
the paper. The authors should use their best
3. Theory assumptions and proofs
Question: For each theoretical result, does the paper provide the full set of assumptions and complete (and correct) proof?
Answer: [NA].
14

---

Justification:
The paper does not include theoretical results.
Guidelines:
The answer NA means that the paper does not include theoretical results.
All the theorems, formulas, and proofs in the paper should be numbered and cross- referenced.
All assumptions should be clearly stated referenced in the statement of any theorems.
The proof' can either appear the main paper or the supplemental material, but they appear in the supplemental material, the authors are encouraged to provide short proof sketch to provide intuition.
Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.
Theorems and Lemmas that the proof relies upon should properly referenced.
4. Experimental result reproducibility
Question: Does the paper fully disclose all the information needed to reproduce the main ex- perimental results of the paper to the extent that affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided or not)?
Answer: [Yes]
Justification: We have provided steps for dataset preparation, model training, and evaluation in the paper and with the details explained in Appendix. We also provided a repository link containing our code and datasets for complete reproducibility.
Guidelines:
The answer NA means that the paper does not include experiments.
If the paper includes experiments, a No answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.
If the contribution is dataset and/or model, the authors should describe the steps taken make their results reproducible or verifiable.
Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is novel architecture, describing the architecture fully might suffice, or if the contribution a specific model and empirical evaluation, it may be necessary either make it possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data is often one good way accomplish this, but reproducibility can also be provided via detailed instructions for how to replicate the results, access to a hosted model (e.g., in the case of large language model), releasing of a model checkpoint, or other means that appropriate to the research performed.
While NeurlPS does not require releasing code, the conference does require all submis- sions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example
(a) the contribution is primarily a new algorithm, the paper should make clear how reproduce that algorithm. (b) If the contribution is primarily new model architecture, the paper should describe the architecture clearly and fully.
(c) the contribution is a new model (e.g., a large language model), then there should either be way to access this model for reproducing the results or way to reproduce the model (e.g., with an open-source dataset instructions for how to construct the dataset).
(d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome deseribe the particular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (e.g., to registered users), but it should possible for other researchers to have some path to reproducing or verifying the results.
5. Open access to data and code
15

---

Question: Does the paper provide open access to the data and code, with sufficient instruc- tions faithfully reproduce the main experimental results, as described in supplemental material?
Answer: [Yes]
Justification: We provide open access to our repository containing code, and datasets, along with the detailed instructions how reproduce the main experimental results.
Guidelines:
The answer NA means that paper does not include experiments requiring code.
Please see the NeurIPS code and data submission guidelines (https://nips... cc/
for more details.
While encourage the release of code and data, we understand that this might not be possible, so "No" is an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for new open-source benchmark).
The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurIPS code and data submission guidelines (https
for more details.
The authors should provide instructions on data access and preparation, including how to access the raw data, preprocessed data, intermediate data, and generated data, etc.
The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. only subset of experiments are reproducible, they should state which ones are omitted from the script and why.
At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).
Providing much information possible in supplemental material (appended to the paper) is recommended, but including URLs to data and code permitted.
6. Experimental setting/details
Does the paper specify all the training and test details (c.g., data splits, hyper- parameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?
Question:
Answer: [Yes]
Justification: We specify necessary training and testing details, clearly described in the Appendix.
Guidelines:
The answer NA means that the paper does not include experiments.
The experimental setting should be presented in the core of the paper to level of detail that is necessary to appreciate the results and make sense of them.
The full details can be provided either with the code, in appendix, as supplemental material.
7. Experiment statistical significance
Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?
Question:
Answer: [No]
Justification: Due to the cost of resources (GPUs), and the size of the experiments, we only reported the average metries on each benchmark. However, described in the paper, we ran our experiments on multiple benchmarks and the results were consistent across the datasets.
Guidelines:
The answer NA means that the paper does not include experiments.
The authors should answer "Yes" if the results are accompanied by emror bars, confi- dence intervals, or statistical significance tests, least for the experiments that support the main claims of the paper.
16

---

The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall run with given experimental conditions).
The method for calculating the error bars should be explained (closed form formula, call to a library function, bootstrap, etc.)
The assumptions made should be given (e.g., Normally distributed errors).
It should be clear whether the error bar is the standard deviation the standard error of the mean.
It is OK to report 1-sigma error bars, but one should state it. The authors should preferably report a 2-sigma error bar than state that they have 96% CI, if the hypothesis of Normality of errors is not verified.
For asymmetric distributions, the authors should be careful not to show in tables figures symmetric error bars that would yield results that are out range (e.g. negative error rates).
If error bars are reported in tables or plots, The authors should explain in the text how they were calculated and reference the corresponding figures or tables in the text.
8. Experiments compute resources
Question:
For each experiment, does the paper provide sufficient information on the com- puter resources (type of compute workers, memory, time of execution) needed reproduce the experiments?
Answer: [Yes]
Justification: We reported the details of the computational resources used for the experiments in the Appendix.
Guidelines:
The answer NA means that the paper does not include experiments.
The paper should indicate the type of compute workers CPU GPU, internal cluster, or cloud provider, including relevant memory and storage.
The paper should provide the amount of compute required for each of the individual experimental runs as well estimate the total compute.
The paper should disclose whether the full research project required more compute than the experiments reported in the paper (e.g.. preliminary or failed experiments that didn't make into the paper).
9. Code of ethics
Question: Does the research conducted the paper conform, in every respect, with the NeurlPS Code of Ethics htttp:://euurppt http://pww....p..oooo//o/aacaaaa
Answer: [Yes]
Justification: Our research fully complies with the NeurlPS Code of Ethics; it involves no ethical issues, and respects all relevant guidelines outlined by NeurlPS.
Guidelines:
The answer NA
that the authors have reviewed the NeurIPS Code of Ethics.
If the authors answer No, they should explain the special circumstances that require deviation from the Code of Ethics.
The authors should make to preserve anonymity (e.g.. if there is special consid- eration due to laws or regulations in their jurisdiction).
10. Broader impacts
Question: Does the paper discuss both potential positive socictal impacts and negative socictal impacts of the work performed?
Answer: [NA]
Justification: Our research is foundational and aimed at reducing latency in reasoning language models without being tied any specific application; hence, it does not directly entail identifiable societal impacts.
17

---

Guidelines:
The answer NA means that there is no societal impact of the work performed.
If the authors answer NA or No, they should explain why their work has no societal impact or why the paper does not address societal impact.
Examples of negative societal impacts include potential malicious or unintended uses (e.g.. disinformation, generating fake profiles, surveillance), fairesss considerations (e.g., dep.oymmly of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.
The conference expects that many papers will be foundational research and tied to particular applications, let alone deployments. However, if there is direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that an improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, is not needed to point out that a generic algorithm for optimizing neural networks could enable people to train models that generate Deepfakes faster.
The authors should consider possible harms that could arise when the technology is being used intended and functioning correctly, harms that could arise when the technology is being used as intended but gives incorrect results, and harms following from (intentional unintentional) misuse of the technology.
If there are negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition to attacks, mechanisms for monitoring misuse, mechanisms to monitor how a system learns from feedback over time, improving the efficiency and accessibility of MI).
11. Safeguards
Does the paper describe safeguards that have been put in place for responsible release of data models that have high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?
Question:
Answer: [NA]
Justification: Our work does not introduce safety risks, as involves lne-ttnnig pretrained language models specifically on mathematical data, which poses no additional risks of misuse.
Guidelines:
The answer NA means that the paper poses such risks.
Released models that have high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere usage guidelines or restrictions to access the model or implementing safety filters.
Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.
We recognize that providing effective safeguards is challenging, and many papers do require this, but we encourage authors to take this into account and make best faith effort.
12. Licenses for existing assets
Question: Are the creators or original owners of assets (e.g.. code, data, models), used in the paper, properly credited and are the license and terms of use explicitly mentioned and properly respected?
Answer: [Yes]
Justification: All datasets, models, and other assets used in this work properly cited, with original creators clearly credited. We explicitly adhere to the licenses and terms of use associated with these assets.
Guidelines:
The answer NA means that the paper does not use existing assets.
The authors should cite the original paper that produced the code package dataset.
18

---

The authors should state which version of the asset is used and, if possible, include URL.
The name of the license (e.g., CC-BY 4.0) should be included for each asset. For scraped data from a particular source (e.g.. website), the copyright and terms of service of that source should be provided.
If assets are released, the license, copyright information, and terms of use in the package should be provided. For popular datasets, paperswi thcode com/ datasets has curated licenses for some datasets. Their licensing guide can help determine the license of dataset.
For existing datasets that re-packaged, both the original license and the license of the derived asset (if it has changed) should provided.
If this information is not available online, the authors are encouraged to reach out to the asset's creators.
13. New assets
Question: Are new assets introduced in the paper well documented and is the documentation provided alongside the assets?
Answer: [Yes]
Justification: All new assets, including datasets and code, are well documented, with clear instructions provided alongside them.
Guidelines:
The answer NA means that the paper does not release new assets.
Researchers should communicate the details of the dataset/code/moodl part of their submissions via structured templates. This includes details about training, license, limitations, etc.
The paper should discuss whether and how consent was obtained from people whose asset is used.
At submission time, remember to anonymize your assets (if applicable). You can either create an anonymized URL or include an anonymized zip file.
14. Crowdsoureing and research with human subjects
Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and screenshots, if applicable, as well details about compensation (if any)?
Answer: [NA]
Justification: Our work does not involve crowdsourcing or research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsoureing nor research with human subjects.
Including this information in the supplemental material is fine, but if the main contribu- tion of the paper involves human subjects, then as much detail as possible should be included in the main paper.
According the NeurIPS Code of Ethics, workers involved in data collection, curation, or other labor should be paid at least the minimum wage in the country of the data collector.
15. Institutional review board (IRB) approvals equivalent for research with human subjects
Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or an equivalent approval/review based on the requirements of your country or institution) were obtained?
Answer: [NA]
Justification: Our research does not involve human subjects, so IRB approval is not applica- ble.
19

---

Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with
human subjects.
Depending on the country in which research is conducted, IRB approval (or equivalent)
may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.
We recognize that the procedures for this may vary significantly between institutions and locations, and expect authors to adhere to the NeurIPS Code of Ethics and the guidelines for their institution.
For initial submissions, do not include any information that would break anonymity (if applicable), such as the institution conducting the review.
16. Declaration of LLM usage
Question:
Does the paper describe the usage of LLMs if it is important, original, or non-standard component of the core methods this research? Note that the LLM used only for writing, editing, or formatting purposes and does not impact the core methodology. scientific rigorousness, or originality of the research, declaration is not required.
Answer: [NA].
Justification: This work is the original work of the authors and does not involve the use of LLMs as an important, original, or non-standard component of the core methods.
Guidelines:
The answer NA means that the core method development in this research does involve LLMs as any important, original, or non standardd components.
Please refer to our LLM policy for what should or should not be described.
20

---

A Implementation Details
A.1 Inference
Inference from sequential reasoning model. To generate responses from sequential reasoning models, such as PeepSeck-RI-Distill-7 and the RFT model, we use the prompt provided below. to derive the RFT model. During
The same prompt was used for fine-tuning DeepSeck-RI-Distill inference, the question appended to the prompt and the model called in the completions format. Following guidelines suggested by DeepSeek [3], we set the generation temperature to 0.6 to mitigate repetitive outputs. Additionally, we enforce maximum token limit of 36,000 per response, truncating any outputs exceeding this threshold.
Sequential Reasoning Prompt
Your role an assistant involves thoroughly exploring questions through systematic long thinking process before providing the final precise and accurate solutions. This requires engaging in a comprehensive cycle of analysis, summarizing, exploration, reassessment, reflection, backtracking, and iteration to develop well-considered thinking process.
Please structure your response into two main sections: Thought and Solution.
In the Thought section, detail your reasoning process using the specified format: <think> (thought with steps separated with "In \n") </think> Each step should include detailed considerations such as analyzing questions, summarizing relevant findings, brainstorming new ideas, verifying the accuracy of the current steps, refining any errors, and revisiting previous steps.
In the Solution section, based various attempts, explorations, and reflections from the Thought section, systematically present the final solution that you deem correct. The solution should remain logical, accurate, concise expression style and detail necessary step needed to reach the conclusion.
Now, try to solve the following question through the above guidelines. Return your final response within \boxed().
SPRINT Inference. During inference, we use the following prompt to guide the generation of plans and executions from the SPRINT model. Although the model is fine-tuned to produce entire trajectory-incluse all plans and executions-in single generation, we manage model invocations and output token handling to alternate between planner and executor roles effectively.
To restrict the model's 's outputs to either single plan or execution per invocation, we employ specific stop tokens. Generation is terminated once the model produces any of the following strings, indicating the completion of a plan or execution segment: (</Execution_, </Plan_, answerr </ </execution_).
When generating plan for stage we feed the prompt along with the input query and the cumulative context, which includes all preceding plans and executions, to the SPRINT model. Conversely, to generate the execution corresponding prompt, the input query, all previously generated plans and executions up to stage i 1, and the text from plan until the end prompt_i., j. This structured context management allows to reuse the same prompt for both planning and execution tasks seamlessly.
particular prompt_i-3 we provide the model with the
The model is permitted maximum of 12 stages produce final answer. To enforce this constraint, we append "<Final, answer>\n' "FFinal_nnsver\e at the end of the prompt when invoking the model at the 12th stage. Generated responses for each plan execution limited 8,000 tokens, with any excess tokens truncated accordingly. This prompt is identical to that used during model fine-tuning.
21

---

SPRINT Prompt
You Al system that follows systematic long thinking process arrive the precise and accurate answer to the below math question specified within <Question> and </Question> tags. The solution is generated over multiple phases, where each phase consists of a plan and an execution.
Planning. At phase you must first create plan within <Plan_p> and </Plan_pt tags by thinking out loud and planning the tasks that need to be executed next.
Your plan may involve detailed considerations such as analyzing the question, summarizing relevant findings, brainstorming new/alterattive approaches, verifying the accuracy of the current steps, refining any errors, or revisiting previous steps.
Since you may think about multiple aspects of the problem within the same plan, you must insert a line break using ----- before you transition from one train of thought to another.
While generating the plan, if you identify a task that needs to be executed, you must create prompt that clearly specifies the task within <prompt_ k> and </prompt_p k> tags where k starts from 1.
When planning within each phase, you must create prompts that can be run independent of the results from the other prompts, to achieve speedup through parallelization. You must also try minimize the number of phases required further arrive at the accurate final answer.
Execution. After creating the plan, you must carry out the tasks identified in the plan sequentially within <Execution_p> and </Execution_p tags. For the prompt labeled as prompt_p k..,, k. the corresponding execution must be generated within <execution_p and wttxeceuiionnp...........
tags.
If the plans and execution results you receive are sufficient generate the accurate final answer, you must respond with the final answer within <Final_answer> and _anae_rsswer>>>> tags. The numerical answer must be within \boxed()
A.2 Dataset Curation
Step Extraction. For step extraction, we use the GPT-4o model with the temperature set to 0. The following prompt is used to extract steps from reasoning trajectory generated by DeepSeek R1. In the prompt, we use the term "Component" confusing it with the traditional use of the term "step" in math solution which could be single operation as opposed to logical part the solution. Components, as defined here, may involve tasks such identifying subsequent actions, validating previous results, proposing alternative methods, comparing solutions derived through different strategies. For each component, the model starts by thinking out loud about what needs to be done and then carries out the identified task. We refer the first part as the plan and the second as the execution and extract them separately using this prompt.
refer to the extracted steps to prevent the model from
The reasoning trajectory passed to the model as input is formatted by labeling each line/sentence with a unique line number and the model provides the range of line numbers for each plan and execution within component. This minimizes the number of output tokens that have to be generated by the model, consequently reducing costs. The line numbers are later parsed from the response to infer the block of text that is relevant to each plan execution.
Step Extraction Prompt
Given below is a math problem and well-thought out solution the problem generated by an Al model. The solution contains multiple components (progressing with next steps, verifying past steps, proposing alternative methods, comparing solutions across different methods, etc.). Within each component, there are three phases:
Planning: Here, the model first thinks out loud and plans what it needs to do.
22

---

Execution: Here, the model follows the plan and executes it.
Commenting: Here, the model comments the execution results with phrases such as "Yes, that seems right", "Both methods lead to the same answer, etc.
Note that the verification of an execution should be considered as separate component and as the commenting phase of the same component.
I am building a new system to solve such math problems. This system will consist two separate Al models planner and an executor.
The planner will receive all the components of the solution completed so far and will need think aloud and generate a plan for the next component. Then, needs to provide a prompt to the executor model to execute a specific task.
Planner:
The executor will receive the components the solution completed so far, the plan for the component generated the planner, and the prompt generated by the planner. It will need to execute the specified task.
Executor:
To train these two Al models, must generate training data by breaking down the solution pro- vided below into individual components. For each component, clearly provide the following details:
Required Response Format:
### Component X (Line Number Range)
Description: Brief explanation of what this component achieves.
Plan: Lines (minimal number of lines describe the plan clearly).
Prompt: A precise, actionable instruction for the exccutor based explicitly the above plan.
Execution: Lines (specific line numbers performing the planned task).
Comment: Lines (reflective comments Lines not found if missing).
Important Notes:
The planning phase should only include minimal number of lines required to specify what needs to be done. The remaining lines from the component where the model carries out the plan should be included in the execution phase.
There MUST be NO overlap between the line numbers of different components.
There MUST be NO overlap between the line numbers of the planning and execution phases of the same component.
All the lines the solution should covered by the components.
Use the line number mentioned the start and end of each line identify the line when specifying the line number range.
The prompt to the executor model must be a very specific instruction that the executor can follow complete the required task. The executor must not perform more tasks than required. The prompt can refer to the plan for that component by saying "the above plan".
If the model does not comment on the execution results within a component, the corre- sponding bullet point can be written as Comment: Lines not found
23

---

DAG Creation. For DAG creation, we use the GPT-4o-mini model with the temperature set to The following prompt used infer the DAG in the form of parent dictionary, where each key refers to a step extracted above and the corresponding values refer to the steps on which the key depends.
DAG Creation Prompt
Given below is a well-thought out solution to math problem generated by an Al system. The system consists of planner and an executor. The planner model thinks out loud and plans the next component of the problem solution. Then, provides prompt along with the plan to an executor model. The exccutor then follows the instructions in the prompt and uses context from the plan to carry out the given task.
The solution consists of multiple components, each containing the following:
Description: A brief description of what the component does.
Plan: The plan generated by the planner.
Prompt: Instructions generated by the planner enclosed within <prompt> tags.
Execution: Output provided by the executor.
Though the executions are sequentially in this solution, of the executions may be parallelized to improve speed. Identify and explain which components can run in parallel and determine the best way to parallelize them maximize speed. Note that parallel runs should not have co-dependency.
The parallelization schedule can be represented directed acyelic graph (DAG) where the nodes are the component numbers. You need represent the DAG parent dictionary where each node is a key and its value is list of nodes that point to it, i.e., the nodes that must be executed immediately before For a key node, do not include any nodes its value that can be run in parallel with it.
Format of parent dictionary:
Let us consider a simple example. Suppose that the following constraints hold:
Component needs be run before any other component
Components 2, 3, 4 can be run in parallel after
Component which depends the results of 2 and 3 can be run after and 3
Component which depends on the results of 4 and 5 can be run after and
The parent dictionary for this example "MUST* be represented as a python dictionary as follows:
parent dictionary
1: [,
2: [1],
3: [1],
4: [1],
5: [2, 3]
6: [4, 5]
}
Using the resulting DAG, reorganize the components into interleaved plans and executions to obtain a parallelizable reasoning trajectory. A simple strategy involves assigning components at the same DAG depth to the same planning-exest execution stage. However, further optimization reduce the total number of stages required to reach the final answer.
The objective of packing to optimally assign stage numbers each component. To achieve this, we apply the following greedy heuristics:
Packing.

---

If a component's 's execution consists of fewer than three lines, it is merged directly with its corresponding plan. This approach reduces overhead from additional prompt writing and executor invocation. Through fine-tuning trajectories with merged short executions, the planner learns to earry out short or trivial executions on its own.
If component C' depends execution results from P's stage. When of C's parent components satisfy this condition, C' is merged into the same planning stage as P by combining their respective plans.
plan-only component P. then C's plan is independent of the
As a result, we obtain optimal stage numbers for each component which can then used for generating the fine-tuning trajectory.
A.3 Fine-tuning
We conducted supervised fine-tuning (SFT) of models by training the reasoning trajecto- ries. Initially, we experimented with more efficient fine-tuning techniques such as LoRA (39] and qLoRA 40) However, since LoRA did adequately enable the models to adhere to the desired response format, we proceed with full fine-tuning instead.
primarily executed single machine with eight NVIDIA A100 GPUs with 40 GB memory per GPU, We use the ms-swift framework [4I], a fine-tuning toolkit provided by the Modelscope community.
Fine-tuning
Each model fine-tuned for epochs. Due to the long-context required for reasoning traces and the memory constraints, we use batch size of during the training. We use bfloat16 precision, an initial learning rate of x 10-5, and weight decay factor of x 10-4, The learning rate scheduling consists of a linear warm-up phase during the first 5% of training steps, subsequently followed by linear decay to zero over the remaining training iterations. Model evaluation is conducted every 100 steps, and the best-performing model based on evaluation loss is retained.
To optimize memory usage during training, we integrate several efficiency strategies, notably the DeepSpeed ZeRO Redundancy Optimizer [42) 43 and 4-bit quantization. DeepSpeed's ZeRO optimizer offers a set of memory-partinn -eattoy--artitioningg strategies that trade off memory savings against communication overhead. In many workloads, ZeRO Stage or 2 strikes the best balance between memory efficiency and communication cost; however, since we need train on long sequences, our per-GPU memory demands exceed what those stages can support. Therefore, we adopted ZeRO Stage 3 to train with extended context lengths without OOM errors.
A.4 Evaluation
For model evaluation, we leverage vL..M 44 to serve our models. Specifically, each 7B-scale model (SPRINT, RFT, and DeepSeek-RI-Distil--1 is deployed a single NVIDIA A100 GPU with 40 GB of memory.
To enhance evaluation accuracy, we instruct the models to encapsulate their final answers within \boxed{]) For evaluations on the MATH-500 and Countdown tasks, we leverage the Math-Verify library alongside SymPy for equivalence checking, ensuring robustness against mathematically equiv- alent but differently expressed solutions. In the GPQA task, accuracy is determined by comparing explicitly generated option labels (c.g., A, B, C, D) directly with the corresponding ground-trui options.
Despite providing explicit formatting instructions, we occasional observe deviations by the models from the specified output format. For instance, during the Countdown task evaluation, the models occasionally produce outputs in unexpected formats (e.g.. Atimes, x), complicating the parsing procedure. To mitigate these issues, we incorporate the GPT-4o-mini model as an auxiliary evaluator to judge the generated answer against the ground truth.
A.5 Baselines
Below present the implementation details for the baselines used in study:
SoT (Skeleton of Thought): For SoT-chat, we use the Owen2.5--BBInnttree model with the temperature set to O.I. For SoT-reasoning, use the DeepSeck-RR RI--RRtilll-OO Distn
25

---

model with the temperature set to 0.6. We use the same prompts reported in the original paper (25] After the full solution generated, we send GPT-4o-mini extract the final answer for evaluation.
RFT (Reasoning Fine-tuned Model): This baseline was created by fine-tuning the DeepSeek model on sequential RI trajectories. During inference,
the temperature 0.6 and employed the sequential reasoning prompt provided in Appendix[A.]
Parallel Sampling Self-consistency: The Qwen2.5-77 1 model was used with temperature of 0.3, generating 20 independent samples per problem. The majority answer is considered as the predicted answer for the evaluation this baseline.
26

---

B Sample Demonstrations
B.1 Demonstration of the Data Curation Pipeline
To illustrate our data curation pipeline, we examine a representative example from the MATH training
dataset. Consider the following question:
Question: The vertex of the parabola described by the equation y -3x 30xr 81 (m, n). What is n??
Next, we provide the response generated by DeepSeek-R RI for this question with each logical
component in separate box. Note that the original response does not provide any separation among its logical components and the full text generated as single long trajectory.
Outline of DeepSeek-RI response
Okay, so need to find the vertex of the parabola given by the equation -3x2 30r 81, and specifically determine the n-coordinate of the vertex, which is (m, n). Hmm, let's start by recalling how to find the vertex of quadratic equation. remember that quadratic equations in the form y az + bz + c. and their graphs are parabolas. The vertex of parabola can be found using the formula for the ur-coordinate, which is (2/( Then once have the a-coordinate, can plug that back into the original equation to find the corresponding y-coordinate, which would be in this case.
So let's identify a, b, and from the given equation. Comparing y -xx 30.r 81 with the standard form y = ax² +bx++o it looks like a = -3, b = 30, and -81.
Wait, is that right? Let me check again. The coefficient of x2 -3, 50 -3 The coefficient of is -30, so = -30. The constant term is -81, so = -81. Okay, that seems correct.
Now, using the formula for the u--cordinate of the vertex: -b((a)), Plugging the values and we get m ---30)/(2 32))/(2 (-3)). Let's compute that step by step. The numerator is - (0)).. which is positive 30. The denominator is 2 times which 2 (-3) = 6. So m = 30/(-6) 55 Therefore, the z-coordinate of the vertex is -5. That seems straightforward.
Now, to find the g-coordinate need to substitute -5 into the original equation. Let's do that. The original equation is y = -3z 30.r 81. Plugging in -5:
-3 (-5) 30 (-5) 81. Let's compute each term step by step. First,
( (-5) 25, so -3 25 - 75. Then, 30 (-5) is positive 150. And the last term
-1. So adding them up: -75 + 150 81. Let's calculate this.
First,
75. Then, 75 81 -6. So -6. Therefore, the vertex is
(-5, 6). s0 is -6.
27

---

Wait, let double-check my calculations make sure I didn't make any arithmetic errors. Let's redo the substitution.
Calculating y when x -5:
First term: -3 (-5)². 2 The exponent first: (-5)² = 23. Then multiply by -3: -3 25 -75. Second term: 30 (-5). Multiply those: -30 times -5 is 150.
Third term is 81. So adding them: -55 + 150 75; 75 81 = -6. Yep, that's correct.
Alternatively, maybe I can use another method to confirm. Sometimes, completing the square can be good way find the vertex. Let me try that. The given equation is 3x 30x 81. To complete the square, first factor out the coefficient of x² from the first two terms. So:
y/ - 33x 10x) - 81. Wait, let's check: -3x² 30w becomes -3(x² + 10x). Yes, that's correct because -3 times x² is -3x² and -3 times 10x is 300r. Then, we have the remaining constant term as -11
Now, to complete the square inside the parentheses, we need to take half of the coefficient of x, which is 10, half of 10 is 5, and then square it: 5² = 25. So add and subtract 25 inside the parentheses to maintain equality. However, since we adding 25 inside the parentheses that's multiplied by -3, have to balance that by actually adding and subtracting -3 * 25 to the entire equation. Wait, maybe need to write it out more carefully.
So:
y 3(2 + 10x + 25 25) 81
Wait, that equivalent to: - + 10r + 25) 25] 81
Which simplifies to: y 3( + 5)² + 75
Because (x²2 + 10r + 25) is (x + 5)2, and then we have -3 times -25 which +75.
Then, subtract 81. So:
= -3x + 5)2 +
Then, combining the constants: 75 -6. So the equation becomes: - 5)
Which is in vertex form: y a(x h22 k. where the vertex is (h, k). Wait, in this case, it's (x + 5) which is the same as (x - (-5)). so is -5 and & is -6. Therefore, the vertex is at (-5, 6). is -6. That confirms the previous result.
Alternatively, maybe can use calculus, taking the derivative and setting it to zero, but since this is a simple quadratic, that might be overkill. But for thoroughness, let's try The derivative of y with respect to z dy/ dr ( (-3) x (-30)
- 6a 30. Setting this equal to zero for critical points: -6r 30 = 0. Solving for
2: 30 = x 5. Then substitute
into original equation, as before,
gives = -6. So again, same result.
28

---

Therefore, all three methods (vertex formula, completing the square, calculus) lead to the same answer: = -
there any chance made mistake in the signs? Let me check again. The original
equation is -3 3x 30r 81. So a = -3, = -30. Then the zzcoordinate of
vertex (2/(2a) - (-300 (2 (-3)) -30/ - -6 -- That's correct. Then
substituting x -5 into the equation: y = -3 (-5)² -330 (-5) 81. Compute each term:
First term: -3 (25) = -75
Second term: -30 * (-5) = +150
Third term: 81
Total: -75 + 150 75; 75 - 81 = 66 Correct.
Completing the square also confirmed the same. Calculus as well. So multiple methods confirm that -6
Therefore, I'm confident that the answer is 66
Next, demonstrate the output of step extraction. As explained in A.2 the output from step extraction contains line numbers corresponding to each plan and execution within a component. In the sample below, we replace line numbers with the corresponding block of text from the reasoning trajectory for ease of understanding. For the sake of brevity, we only show the full details for a few components.
Formatted output of Step Extraction
### Component 1
Description: Planning how to find the vertex of the parabola. Plan: Okay, so need find the vertex ... Then once we have the z-coordinate, we can plug that back into the original equation to find the corresponding y-coordinate, which would be in this case.
Prompt: Identify the values of b, and from the given quadratic equation. Execution: So let's identify a, and c c... looks like -3, -30, and -81.
Comment: No lines found
### Component 2
Description: Verifying the identified values a, b, and
### Component 3 Description: Calculating the z-coordinate of the vertex using the vertex formula.
### Component 4 Description: Calculating the y-coordinate of the vertex by substituting the v-coordinate.
29

---

### Component 5
Description: Verifying the calculation of the y-coordinate.
### Component 6
Description: Using the method of completing the square to find the vertex.
Plan: Alternatively, maybe can use another method to confirm. Sometimes, completing the square can good way to find the vertex. Let me try that.
Prompt: Use the method of completing the square on the given equation to find the vertex.
The given equation is = -3x² 30x 81. To complete the square, first factor out the coefficient of x² So the equation becomes: y -3(x + 5)2 which is in vertex form: = a( æ h)² + k, where the vertex is (h, k) Therefore, the vertex is at (-5, -6),
Execution:
is -6
Comment: That confirms the previous result.
### Component 7 Description: Using calculus to find the vertex by taking the derivative and setting it to zero.
### Component 8
Description: Comparing results from different methods.
### Component 9
Description: Final verification of the solution and confirming results.
In Figure 7 we demonstrate the dependencies that are inferred from running DAG creation over the steps (a.k.a components) extracted above. The model has identified that Components 2, 3, 6, and 7 can run in parallel. This is because once the values of a, b, and c are identified in Component the verification of that calculation (Component 2) and the computation of the z-coordinate (Component 3) are mutually independent. Besides, alternative approaches such as completing the square (Component 6) and using calculus (Component 7) not dependent components other than Component 1. Component depends on Component 3 as the computation of the y-coordinate depends on the value of the z-coordinate identified in Component 3. Comparing the results of the three approaches (Component 8) depends on the results from Components 4, 6, and 7 while the final verification (Component 9) depends Component 8. Hence, the DAG effectively models the dependencies among the components and identifies parallelization opportunities.
As explained in Appendix A.2 for components with short executions, merge the executions with their plans. Hence, for the above problem, the executions of Components 2, 3, and 8 are merged with their plans. The trajectory containing plans and executions generated for the above problem following this modification given below. Note that the plans are ordered based on the dependencies modeled in the DAG.
The sequential token count for the original response from RI measured the total number of tokens in the response which is 1645. The trajectory sample below has a smaller sequential token count of 1445 due to the parallelized executions.
30

---

2
3
7
9
Figure Dependencies inferred from running DAG creation over the steps extracted from the example reasoning trajectory in Appendix B.
Trajectory sample for fine-tuning
<Plan_1> 1>
Okay, need to find the vertex it looks like -, b 330, and -1.
Wait, that right? Let me check again ... The constant term is -8,, so -8.. Now, using the formula and plugging in the values of and b... Let's compute that step by step.
<prompt_1 1. 1> Calculate the x-coordinate of the vertex </prompt_1... 1.1>
Alternatively, maybe I can use another method to confirm. Sometimes, completing the square can be good way to find the vertex. <prompt_ 1 2> Use the method of completing the square the given equation to find the vertex. </prompt_1.2
Alternatively, maybe can use calculus, taking the derivative let's try it. <prompt_ 1.3> Use calculus to find the r-coordinate </prompt_1.3 _133>
</Plan_1>
<Execution_1>
31

---

cexecution_i.11
The numerator is (-30.... So m =30(--6) -5. Therefore, the r-coordinate of the vertex is -5. </execution_1.1
<execution__..
The given equation is 3x² 30x
81. To complete the square, first factor out the coefficient of x² So equation becomes: y/ = -3(x + 5)2 6 which is in vertex form: y a(x h)² + k, where the vertex is (h, k) Therefore, the
vertex is at (-5, -6). so n is
</execution_1.2 1.23
<execution_ 1..>>
The derivative with respect to x dy/dz = 2 (-3)x + (-30) = -6r 30. Setting this equal zero for critical points before, gives y -6. </execution_1.3 1.3>>
</Execution_1 1>
<Plan_2>
Now, to find the y-coordinate need to substitute = =5... <prompt_22 2. Substitute
-5 find the y-coordinate of the vertex.
</prompt_2.f 2.1>
</Plan_2>
<Execution_2> 2>
<execution_2.. 2>1> Plugging =
...
Son 6. </execution_2 2.1> </Execution_
<Plan_3>
Based execution 2:cut
Wait, let me double-check my calculations
<prompt_3, 3. 1> Redo the substitution of - into the original equation to verify. htppmpttt3.1111
Based on execution 2,1, execution 1.2, execution 1.3:
Therefore, all three methods (vertex formula, completing the square, calculus) lead to the same answer:
6.
Let me check again.
<prompt_33 _32>> Recheck the calculations and confirm the results </prompt_3.2>
</Plan_3>
<Execution_3>
32

---

<execution_3.. 1>
Calculating y when x -5: First term: -3 (-5)² So adding them: - + 150 = 75; 75 81 -6
</execution_3.1
<execution_3.2>
The original equation is So multiple methods confirm that -6. </execution_3.2>
</Execution_3>
<Final_answer>
Therefore, the value of n is boxed(-6).
</Final _
33

---

B.2 Demonstration of SPRINT execution versus sequential reasoning from RFT
Given below an example how SPRINT responds to question from the MATH-500 benchmark at inference time. The executions presented side-by-side are carried out in parallel using the inference strategy shown in Figure
Question: The binary number 10101001110, is equal to what number in base eight?
Planning and parallel execution trajectory generated by SPRINT
<Plan_
Okay, so need to convert binary number 10101001110; to base eight. So, the plan is probably to group the binary digits into sets of three starting from the right and then convert each group to an octal digit. Wait, but first, let me confirm: the binary number given is 10101001110 Let me count the digits.
Let's see: 10101001110. That's 11 binary digits. Since 23, each octal digit is three bits, 11 bits would need to be grouped into 4 octal digits (since 4*3=12. which is more than 11) but we need to add leading zero to make it 12 bits? Wait, no, actually, when converting from binary split into groups of three. Right, so even if the total number of bits isn't mul- tiple of three, you can add leading
octal, you start from the right and
to make it multiple of three. Let check.
<prompt_ Verify the method of converting binary octal by considering the binary number 10101001110. </prompt_1.1
But let me think again. Let me confirm with another approach. Alternatively, could convert the binary number decimal first and then octal. Maybe that's good way to cross-verify.
<prompt_ 2> Consider converting the binary number to decimal first and then octal as an alternative method. </prompt_1. 1.2>>
</Plan_1>
<Execution_1>
<execution_ 1.2>
<execution_1.7
Let's see. The binary number is 10101001110, Let me write down the positions from right left, starting at 0. Wait, actually, in computers, the rightmost bit the least significant bit, which is position O. So let's list the bits: Position: 10 9 6 4 3 Bit: O 10100 110...
The original number 10101001 100. Let's write them out: positions from right to left (since we start grouping from the right). Wait, actually, when grouping, we start from the right, so the leftmost digit might need be padded with zeros to make the total number of digits multiple of three. So the binary number has 11 digits. 11 divided by is 3 with remainder of 2. So, we need to add one lead- ing zero make 12 digits. Wait, 3*4=12, so yes, adding one zero the left. So the original binary is 00101001110, Adding a leading zero gives 010101001110. </execution_1.1
So: Bit 10: 1 (2
Bit 9: 0 (29)
Bit 8: 1 (2%)
the binary number is: 2 42 +..22
Adding them all up: 1024 + 256
1280; 1280 +
1344; 1344 8
1352; 1352 4 = 1356; 1356 + 2
= 1358. So the decimal equivalent is
1358. </ eeeecutioo_1122
34

---

</ /Execution_11
<Plan 2>
Based on execution_1.1:
Now, splitting into groups of three starting from the right:
<prompt_ 2. 1> Split the 12-digit binary number into groups of three starting from the right and convert each group to octal. e/prompt_2.1
Based on execution 1.2:
Now, converting 1358 octal. Let's divide by 8:
sprompt_2.2 Convert the decimal number 1358 to octal using division by </prompt_2.2>
</Plan_2>
<Execution_2>
<execution
01010001111
Wait, no, wait. Wait, the binary number af- ter adding a leading zero is 010101001110.
<execution_2 222>>
1358 + 169 with remainder (since 169*8 = 1352, 1358 1352 =6)
Now, group into 4 sets of three: Group (leftmost): 010, Group 2: 101, Group 3:
001, Group 110. Then convert each of these octal digits. Wait, octal digits go from 0 to 7, so each group of three bits represents 0-7. Let me recall the binary to octal mapping:
169 8 = 21 with remainder (2188 168, 169 168 = 1)
2 8 with remainder 5 (2*8
= 16, 21 16=
2 with remainder 2
000 = 0, 001
010 = 2, So:
So the remainders, from last to first, are 2, 5, 6. There- fore, 1358 in octal is 2516g. </execution_2.2
Group 1: 010 +
Group 2: 101 +
Group 3: 001 +
Group 4: 110 + 6
So putting them together: 251 6 2516g.
</execution_2> 2.1>
</Execution_2>
<Plan_3>
Based on execution_ 2.1: 2::cutioon2.1:::
Wait, but let me check again. Let's verify the grouping. <prompt_3. 3. 1> Verify the grouping the binary digits and the conversion to octal. </prompt_3.1>
Based execution_22. _22::
Therefore, the binary number 10101001110, is equal to 2516g. So both methods give the same result, which is reassuring.
<prompt_S 3.2 2> Reflect on the solution and confirm its correctness by comparing both conversion methods. </prompt_3.2
</Plan_3>
<Execution_3>
35

---

texecution_3...
think this confirms that the answer is correct. But let me just go through the steps more to thorough. Original binary: 10101001 10 Convert groups of three starting from the right. Since it's 11 digits, add a leading zero to make it 12 digits: 010101001 110.
<execution_ Original binary with leading
Group into four parts: 010 101 001 110. Convert each:
zero: 010 101 001 110.
Group I: 010 + 2
010=2, 101 = 5, 001 1, =10=6
Group 101 +
Combine: 2516. Yep.
Group 3: 001 +
Alternatively, converting to decimal via binary to decimal conversion: 10101001110; 1
Group 4: 110 +
So octal number is 2 1
2 + 0 2 +1 2 +0 +... +0 2
+ 2516.
1024 + 256 + 64
4 1358. Then 1358 divided by 8 gives 169*8=1352, remainder 6; 169 divided by is 21*8=168.
</execution_3.1
2.5 1316 6. So 2516. All checks out. There- fore, the final answer is 2516 octal. think that's solid. No mistakes detected in the process. </execution_3.2
</Execution_>>
<Final <Final_answer answer>
This step-by-step conversion shows that the binary number 10101001110; is equal to (20xed(2516g) in base eight.
s/Final_answer
The sequential token count of the above response from SPRINT is 1463, For the same question, we present the sequential trajectory generated by the RFT model below. The sequential token count of this response is 1989 since all tokens are generated sequentially. This highlights the benefit of parallelizing executions using SPRINT.
Sequential reasoning trajectory generated by the RFT model
Okay, so need to convert the binary number 101010011 1100001110, base eight. Hmm, remember that converting between binary and octal is done by grouping the binary digits into sets of three, starting from the right. Each group of three bits corresponds to single octal digit. Let me think through the steps carefully.
First, let me write down the binary number: 0 1 0 000000110000 0. Wait, let me count the digits. The original number is 10101001110, which has 11 digits. Since octal groups are in threes, need to split this into groups of three. But 11 isn' divisible by three. So, should add leading zeros to make the total number of digits multiple of three. Right, by 3 is 3 with remainder of 2. That means need to add one leading zero to make it 12 digits. So the new number becomes 010101001110,
divided
Now, let me split this into groups of three starting from the right. Let me write it out:
Group 1: 010, Group 2: 101, Group 3: 001, Group 4: 110
Wait, no. Wait, the leading zeros are added at the beginning, so the original number was 10101001110. Adding a leading zero makes it 010101001110. Now, splitting into groups of
36

---

three from the right:
Starting from the end, the last three digits 110. then moving left, the next three are 001, then 101, then 010. So the groups are 010, 101, 001, 110. Now, each of these binary groups needs to be converted their octal equivalents.
Let convert each group:
0102 is 2 in octal because 0 x 4 x x 1 =
101₂ 5 in octal because 1 + 0 + 5.
So putting those together in order from left to right, the octal digits are 2, 5. 1, 6. Therefore, the octal number should be 2516g. Wait, but let me verify this again to make sure didn't make a mistake in grouping or conversion.
Wait, when grouping from the right, the first group (rightmost) is 110, then moving left, the next is 001, then 101, then 010. So the groups are 010, 101, 001, 110. Converting each to octal:
0102 = 101₂ 5, 001, 1, 110g 6. So the octal number is 5 1 6, which is 2516g- Let me check this is correct by converting the original binary number to decimal and then converting that decimal number to octal to see if it matches.
First, converting 10101001110, decimal. Let's write out the binary number with each digit's place value:
From right to left, the positions are 0 to 10. The digits are:
Position 10: 1, Position 9: 0, Position 8: L, Position O: 0
Calculating the decimal value:
1 22 1d + (29) -1x (2a) +0 (2?) (2)) (2 +0 +2x) +1x +0
1 1x (2 +1 (2') +0 (20)
Calculating each term:
200_ 1024, 256, 26 = 64, 2
=8, 22 = 4,
Adding them up: 1024 + 256 1280; 1280 + 64 = 1344: 1344 + 1352:
1352 + 4 1356; 1356 + = 1358.
So the decimal value is 1358. Now, converting 1358 octal. repeatedly.
Let's divide 1358 by
1358 + 8 = 169 with remainder of
169 : 8 21 with remainder of 1.
21 8 = 2 with a remainder of 5.
2 with remainder of
Writing the remainders from last to first: 2 1 6. So 2516g. Which matches the previous result. Therefore, the conversion is correct.
But wait, 1et me check the grouping again. The original binary number was 00101001110 When adding a leading zero, it becomes 010101001110. Splitting into groups of three from
37

---

the right:
Starting from the right: 111 001 101 010. Wait, that's different. Wait, perhaps I made a mistake in grouping.
Wait, the original binary number is 10101001110. Let me write it as 10 101 001 110. Wait, that's correct. Wait, the original number is 11 digits. So when adding leading zero, becomes 12 digits: 010101001
1 0. Then grouping from the right:
Groupl: O 1 O (positions 11, 10, 9). Group2: 1 1 (positions 8, 7, 6). Group3: 0. 1 (positions 5, 5,4,3), Group4: 1 (positions 0)
Wait, but when grouping from the right, the rightmost group is the last three digits. So the original number is 0101010011 10. The rightmost three digits are 110, then moving left, next three are 001, then 101, then 010. So the groups are 010, 101, 001, 110. Which is the same as before. So converting each gives 2, 5, 1, 6. So 2516g. Which is correct. So the answer is 2516g.
But wait, when grouped the original number as 10101001 110, which 11 digits, adding leading zero makes it 010101001111 which is 12 digits. So grouping into three from the right: 010, 101, 001, 110. So that's correct.
Alternatively, another way to check is by converting each group as did before. So yes, the answer 2516 in octal.
But let 10101001110,.
just confirm again by converting 2516g back to binary if it's
2516 in octal:
Each digit corresponds to three binary digits:
2 + 010
101
1 + 001
110
So putting them together: 010 101 110 -> 010101001110, which is the original number.
So that's correct.
Therefore, the final answer is \boxed (2xx66 in base eight.
38

---

B.3 Demonstration of SPRINT parallelism within a single solution method
The sample in Section B.2 shows SPRINT parallelizing alternative solution methods in stages and In the below example, we show that SPRINT can also split single solution method into subtasks, execute them in parallel, and aggregate the results later. Here, the planner splits the problem into calculating the vertical asymptote and re-evaluating the horizontal asymptote, as prompts 1.1 and 1.2 parallel.
Question:
The graph of 2x
2--22-11 has vertical asymptotes I = a and x = b, and horizontal
asymptote c. Find a + +
Trajectory sample for parallelism within single solution method
<Plan_1>
Determine the vertical and horizontal asymptotes of f(x)= (x--5xx111 then compute a+b+c.
<prompt_1 1. Identify the vertical asymptotes by finding the roots of the denominator. </prompt_1.1>
<prompt_1.0 1.2mpt__1.2>> Re-evaluate the horizontal asymptote using the degrees of the numerator and denominator. "/prompt_1.25
</Plan_1>
<Execution_1>
<execution_1.11
Vertical asymptotes occur where the denominator is zero (provided the numerator isn't zero). Factoring x^2-5x-14 (x-7)(x+2) gives roots at x=7 and x=-2. Thus, a=7 and b=-2.
</execution_1.1> 1.11>
cexecution_1.22
Since the numerator's degree (1) is less than the denominator's (2), the horizontal asymptote is y=0. Hence, c=0)
</execution_1.2 1.22
/Execution_1>>
Rest of the solution continues...
B.4 Demonstration of SPRINT execution on non-STEM task
We use the below example to demonstrate that SPRINT generalizes well to non-STEM tasks like creative writing, despite being different from tasks in the MATH dataset used for fine-tuning. When tasked with generating a brief movie scene description, the planner successfully devises three independent subtasks, each executed concurrently by separate executors. After three planning and execution rounds, these independently developed results were integrated into coherent and unified narrative.
39

---

Trajectory sample for creative writing task
<Plan_1>
The user wants a 250-word scene set shortly after the Battle of King's Landing.
<prompt_ 1.1> Identify the key elements and emotions for each perspective: Bran Stark's visions, the noble's skepticism, and the urchin's admiration. </prompt_1.1 1111
</Plan_1>
<Execution_1>
<execution_1.1
Bran: He's the one who saw the vision of the White City...
Noble from the Vale: He's skeptical...
Urchin: This adds an unexpected element...
</execution_1.1>
</
</Execution_1>
<Plan_2>
Based on Execution 1.1:
Bran: His lines should include visions...
<prompt_2, 2. Develop Bran Stark's lines to describe the vision of the White City and the Iron Throne. </prompt_2.1
<prompt_ _2 2.2> Develop the noble's lines to express skepticism about Bran's leadership and his brother's choice. </prompt_2.. 2.2>
sprompt_2.0 2._3.>3.222 3> Develop the urchin's lines to show admiration for Bran and the vision, and the impact on his journey. </prompt_2.0 _.
</Plan_2 2>
<Execution_2>
<execution_2..0 2.1>
The urchin's lines should be simple full of wonder... </execution_2.11 2211>
<execution 2.2>
The urchin in the Red Keep adds a layer of innocence, contrasting with... </execution,2.2 2..2
<execution 2.3>
The streets below are in ruins, but the urchin's eyes... 3/execution,2.3> 2.33>
< E/Executio_22>
<Plan_3>
40

---

Based Executions 2.1-2.3:
<prompt_3. 1> Ensure each character's perspective is distinct and contributes to the overall mood. The scene should capture the transition from battle chaos to the realm of possibility of a new order. 3/prompt_3.. 1>
</Plan_3>
<Execution_3>
<execution_3.1 3.
The urchin's s admiration is genuine... </execution_3.1
</Execution_3>
Final_answer
The air was thick with the scent of incense and the faint hum of machinery. The throne loomed before Bran...
The council chambers were quiet, save for the faint murmur of leather on wood...
The Red Keep was alive with the promise of change ... The White City was his home, and the Iron Throne was his throne.
</Final answer> >
41


Reviews:
[{"review_id": "b1i4DfnR7m", "reviewer": "Reviewer_5uvg", "summary": "This paper uses SFT training LRMs to automatically combine traditional sequential reasoning with parallel task decomposition and execution, aiming at improvement of both accuracy and efficiency.", "questions": "- Q1: The examples in the appendix seem to show the tendency of LRMs using parallelism for different reasoning and soltion paths. Are there other cases that the model set plans for parallelizable sub-tasks of one single solution?\n- Q2: What the recovery behavior of LRMs in SPRINT is like? Take the appendix figure as an example, what the LRM would usually do if an error was detected in the rechecking execution?", "limitations": "yes", "rating": 5, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 2, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "### **Strengths**\n\n#### **S1: Reasonable Motivation**\n\nThe idea to parallelize reasoning and execution process makes a lot sense to me. The concept of combining sequential and parallel actions brings a novel aspect of investigating LRMs.\n\n#### **S2: Potentially Very Useful on Certain Tasks**\n\nOn tasks with clear sub-task splits or natural parallelism properties, the proposed techniques can be very useful in terms of both accuracy and efficiency.\n\n### **Weaknesses**\n\n#### **W1: Issues about Efficiency Evaluation**\n\nFirstly, I think the \"number of sequencial tokens\" defined in Section 4.1 underestimates the cost of SPRINT. Since all the plannings are sequencially generated by the head agent, to calculate the token consumption related to time cost estimation, it should be defined as:\n\n$ \\sum_{i=1}^{stages} \\max_k^{prompts} [(\\sum_{j=1}^k P_{i, j}) +E_{i,k}]. $\n\nIf defined this way, it is possible that SPRINT turns out decreasing the efficiency rather than increasing it.\n\nSecondly, other than sequencial tokens, it may help report other two types of token statistics:\n- Number of memorized tokens, defined as all the tokens whoses kv caches need to be stored in the head agent, useful for comparing memory use;\n- Number of all tokens, defined as all the tokens generated by both the head and the works, useful for comparing computation consumption or API cost.\n\n#### **W2: Generalizability Concerns**\n\nThe experiments are conducted on STEM tasks which are easier to be splitted in to sub-goals. However, for other tasks such as common sense reasoning and creative writing, the proposed technique might be less useful.", "was_revised": true, "final_justification": "Raising rating for new experiments on creative tasks and the clarified notions.", "rebuttal": "We thank the reviewer 5uvg for your thoughtful review! We appreciate the reviewer’s recognition of the novelty of SPRINT in bringing parallelism in large reasoning models and its high utility in terms of accuracy and efficiency.\n\nIn response to your comments, we provided the numerical analysis, discussions, and illustrative examples on the SPRINT’s generalization, sub-task decomposition, and error recovery behaviour. We plan to incorporate these additions into the final version of the paper and hope you will consider updating your score in light of these improvements.\n\n**W1.1: Efficiency Evaluation**\n\nWe wish to clarify a potential misunderstanding about our notations and evaluation metric for the “number of sequential tokens” as defined in Section 4.1.\n\nIn our paper, **\\\\(P_{i,j}\\\\)** is the **cumulative** token count generated by the planner from the start of stage i up to and including prompt j. As soon as the planner streams the final token of prompt j, its corresponding execution can begin, without waiting for later prompts.\n\nAccordingly, the sequential‐token cost at stage i is correctly given by\n\\\\[\n\\max_{k}\\bigl[P_{i,k} + E_{i,k}\\bigr],\n\\\\]\nand the total cost sums over stages:\n\\\\[\n\\sum_{i=1}^{\\text{stages}} \\max_{k}\\bigl[P_{i,k} + E_{i,k}\\bigr].\n\\\\]\n\nThe reviewer’s suggested formula assumes \\\\(P_{i,j}\\\\) is **per-prompt** rather than cumulative. Since our \\\\(P_{i,j}\\\\) already accumulates all prior tokens, \\\\(\\sum_{j=1}^{k}P_{i,j}=P_{i,k}\\\\). Thus, both expressions coincide under our definitions.\n\n**W1.2: Total and memorized tokens**\n\nFollowing your suggestion, we measured and report two additional token statistics:  \n\n**Memorized Tokens**\n\nDuring the execution of a given stage, the KV cache contains tokens from all plans (up to and including the current stage) and all executions (up to the current stage). Hence, the number of memorized tokens increases as the stages progress in SPRINT’s solution. The peak usage of the KV cache occurs when the final answer is being generated. We found this peak usage to be 3475 tokens on average over MATH500. \n\n**Total Tokens**\n\nWe present these values along with accuracy and sequential token counts in the table below, averaged over the MATH500 dataset:\n\n| Method                  | Accuracy (%) | Sequential Tokens | Total Tokens |\n|-------------------------|--------------|-------------------|--------------|\n| Self-consistency        | 80.6         | 590               | 11,645       |\n| SoT-chat                | 47.3         | 256               | 1,290        |\n| SoT-reasoning           | 90.8         | 3,836             | 11,538       |\n| Reasoning Fine-tuned (RFT) | 91.0     | 2,880             | 2,880        |\n| **SPRINT**              | **92.5**     | **2,440**         | **3,622**    |\n\nAmong the high-performing methods (accuracy > 90%), SoT-reasoning exhibits a high total token cost due to redundant work by multiple independent threads, which individually replicate similar computations without coordination. In contrast, SPRINT achieves better efficiency by enabling coordination between parallel executors and the planner, resulting in reduced redundant computation. Although SPRINT introduces some planning and synchronization overhead, it substantially reduces **sequential tokens**, the key bottleneck for latency, relative to RFT, while improving accuracy and keeping total tokens low.\n\n**W2: Generalization of SPRINT beyond the STEM tasks**\n\nWe acknowledge the reviewer’s observation that STEM tasks likely benefit more readily from decomposition into subgoals. Indeed, one of our primary motivations in designing SPRINT was to identify and leverage parallelization opportunities to efficiently reduce lengthy sequential CoTs generated for *complex tasks*.\n\nTo address the reviewer’s concern, we also evaluated SPRINT on a creative writing task. Interestingly, we observed that even though the model had only been trained on mathematical data, a domain completely different from creative writing, it effectively proposed parallelizable plans when tasked with generating a brief movie scene description.\n\nIn the example provided below, at Stage 2, the planner successfully devised three independent subtasks, each executed concurrently by separate executors. After three planning and execution rounds, these independently developed subtasks were integrated into a coherent and unified narrative.\n\n---\n\n**Query**  \n*Write a 250‑word scene set shortly after the Battle of King's Landing, describing the mood in the throne room from different perspectives: Bran Stark, now seated on the Iron Throne, observing the aftermath with his visions. A skeptical noble from the Vale, questioning the new king's rule. A street urchin who snuck into the Red Keep, marveling at the scene.*\n\n---\n\n**Stage 1: Initial Planning**\n\n- **Plan 1**: The user wants a 250-word scene set shortly after the Battle of King's Landing.\n  - **Prompt 1.1**: Identify the key elements and emotions for each perspective: Bran Stark's visions, the noble's skepticism, and the urchin's admiration.\n\n**Stage 1: Execution**\n\n- **Execution 1.1**:\n  - Bran: He’s the one who saw the vision of the White City...\n  - Noble from the Vale: He's skeptical...\n  - Urchin: This adds an unexpected element...\n\n---\n\n**Stage 2: Refined Planning**\n\n- Based on Execution 1.1:\n  - Bran: His lines should include visions...\n    - **Prompt 2.1**: Develop Bran Stark's lines to describe the vision of the White City and the Iron Throne.\n    - **Prompt 2.2**: Develop the noble's lines to express skepticism about Bran's leadership and his brother's choice.\n    - **Prompt 2.3**: Develop the urchin's lines to show admiration for Bran and the vision, and the impact on his journey.\n\n**Stage 2: Execution**\n\n- **Exec 2.1**: The urchin's lines should be simple but full of wonder…\n- **Exec 2.2**: The urchin in the Red Keep adds a layer of innocence, contrasting with…\n- **Exec 2.3**: The streets below are in ruins, but the urchin's eyes…\n\n---\n\n**Stage 3: Final Planning**\n\n- Based on Executions 2.1–2.3:\n  - **Prompt 3.1**: Ensure each character's perspective is distinct and contributes to the overall mood. The scene should capture the transition from battle chaos to the realm of possibility of a new order.\n\n**Stage 3: Execution**\n\n- **Execution 3.1**: The urchin's admiration is genuine…\n\n---\n\n**Final Answer: The Iron Throne Room**\n\nThe air was thick with the scent of incense and the faint hum of machinery. The throne loomed before Bran …\n\nThe council chambers were quiet, save for the faint murmur of leather on wood …\n\nThe Red Keep was alive with the promise of change … The White City was his home, and the Iron Throne was his throne.\n\n---\n\nThis example illustrates that SPRINT can generalize to creative domains and leverage parallel planning, even outside its training domain. We believe this demonstrates the broader applicability of our method beyond STEM reasoning.\n\n**Q1: Does SPRINT parallelize across sub-tasks?**\n\nYes, according to the task at hand, the planner might propose plans for trying alternative solution paths, or decomposing a solution into its subtasks to be processed in parallel. The following is an example taken from SPRINT execution, where the planner splits the problem into calculating the vertical asymptote and re-evaluating the horizontal asymptote, as prompts 1 and 2 in parallel.\n\n---\n\n**Question (algebra_305, MATH500)**  \n*The graph of* \\\\(f(x) = \\frac{2x}{x^2 - 5x - 14}\\\\) *has vertical asymptotes* x=a *and* x=b, *and horizontal asymptote* \\\\(y=c\\\\). *Find* \\\\(a+b+c\\\\).\n\n---\n\n**Stage 1: Initial Planning**\n\n- **Plan 1**: Determine the vertical and horizontal asymptotes of \\(f(x)=\\frac{2x}{x^2-5x-14}\\), then compute \\(a+b+c\\).  \n  - **Prompt 1.1**: Identify the vertical asymptotes by finding the roots of the denominator.  \n  - **Prompt 1.2**: Re-evaluate the horizontal asymptote using the degrees of the numerator and denominator.\n\n**Stage 1: Execution**\n\n- **Execution 1.1**:  \n  Vertical asymptotes occur where the denominator is zero (provided the numerator isn’t zero). Factoring \\(x^2-5x-14 = (x-7)(x+2)\\) gives roots at \\(x=7\\) and \\(x=-2\\). Thus, \\(a=7\\) and \\(b=-2\\).\n\n- **Execution 1.2**:  \n  Since the numerator’s degree (1) is less than the denominator’s (2), the horizontal asymptote is \\(y=0\\). Hence, \\(c=0\\).\n\n---\n\n*The next planning and execution stages would be followed.* \n\n**Q2: What is the error recovery behavior of SPRINT like?**\n\nWe appreciate the reviewer’s insightful question! When an error is detected during execution, **SPRINT** typically follows a structured recovery process:\n1. **Error Detected** – Identify the mistake during execution.  \n2. **Replanning** – Generate targeted prompts to correct the error.  \n3. **Re-execution** – Run corrected subtasks (often in parallel).  \n4. **Verification** – Validate the final solution against the original problem.\n\nWe illustrate SPRINT’s error recovery behavior through a representative thinking trajectory example:\n\n---\n\n**Question**  \n*Convert the quadratic* \\\\(x^2 + 2.6x + 3.6\\\\) *into the form* \\\\((x+b)^2 + c\\\\), *then find* \\\\(b + c\\\\).\n\n---\n\n**Error in execution**  \n- **Execution 2.2 (Initial Error):**  \n  An arithmetic mistake led to \\\\(c = 0.05\\\\), producing an incorrect sum \\\\(b + c = 1.74\\\\).\n\n---\n\n**Error Detection & Replanning**  \n- **Plan 3 (Error Detection):**  \n  Issue targeted prompts to explicitly recheck the arithmetic and re-evaluate prior steps.\n\n---\n\n**Recovery Execution**  \n- **Execution 3.1 & 3.2 (Recovery):**  \n  Correct arithmetic recalculation finds \\\\(c = 1.91\\\\), updating the sum to \\\\(b + c = 3.21\\\\).\n\n---\n\n**Final Verification**  \n- **Plan 4 (Verification):**  \n  Expand \\\\((x+b)^2 + c\\\\) and compare it to the original quadratic to confirm accuracy.\n\n---\n\n**Final Answer**  \n\\\\[\nb + c = \\boxed{3.21}\n\\\\]\n\n---\n\nThe full log can be found in our repository at “logs_full_trajectory/SPRINT/MATH-500_default/planner_trajectory_test_algebra_621.txt”."}, {"review_id": "W9ON5rMZ4d", "reviewer": "Reviewer_tuC4", "summary": "This paper introduces SPRINT, a method that enables models to parallelize reasoning and execution processes through post-training and inference-time techniques. SPRINT incorporates a multi-stage data curation pipeline that transforms sequential reasoning processes into structured multi-step formats. Using the curated data, the authors conduct experiments on the MATH dataset and OOD datasets such as GPQA and Countdown. The results show a reduction in sequential tokens while maintaining/improving accuracy.", "questions": "1. Can you provide an analysis of the total number of tokens used, including both sequential and parallel branches?\n2. What is the impact of the number of parallel branches within a reasoning step? Does increasing the number of parallel branches consistently improve performance, or are there any trade-offs?\n3. Can you offer further insights into why parallelization works in this context? For example, do parallel steps offer diverse solution paths, or are they complementary substeps that can be merged into a final answer?", "limitations": "Yes.", "rating": 4, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 2, "originality": 3, "strengths_and_weaknesses": "Strengths:\n1. This work introduces dynamic parallelism in reasoning processes and proposes data creation strategies to enable such parallelization.\n2. The analysis is interesting, providing comparisons across problem difficulty levels and reasoning lengths.\n3. The overall writing is clear and easy to follow.\n\nWeaknesses:\n1. The evaluation of efficiency primarily relies on the count of sequential tokens, which may not fully reflect the total computational cost. A more complete analysis should include the total token usage, including tokens used in parallel branches.\n2. The paper lacks several design and implementation details, such as concrete examples of parallelization, analysis of steps versus stages, and specifics regarding decoding hyperparameters used during inference.", "was_revised": true, "final_justification": "The author responses have addressed my main concerns regarding the total token usage and implementation details, although the performance on MATH appears to be saturated. The explanation for why the parallelization helps also makes sense to me. Therefore, I have increased my score.", "rebuttal": "We thank the reviewer tuC4 for your constructive feedback! We appreciate your recognition of our contributions, particularly the introduction of dynamic parallelism in reasoning processes, our proposed data creation strategies to support such parallelization, and the analysis across problem difficulty levels and reasoning lengths.\n\nIn response to your comments, we have provided further numerical analysis, illustrative examples, and discussion to address the points you raised. These include clarifications on implementation details, token counts, and the characteristics of SPRINT’s dynamic parallelism. We plan to incorporate these improvements into the final version of the paper and hope you will consider updating your score based on these additions.\n\n\n**W1/Q1: Efficiency metrics, total token usage**\nFollowing your suggestion, we measured the total number of tokens generated by SPRINT and other baselines, along with the two other metrics of accuracy and #seq tokens averaged over the MATH500 dataset.\n\n| Method                  | Accuracy (%) | Sequential Tokens | Total Tokens |\n|-------------------------|--------------|-------------------|--------------|\n| Self-consistency        | 80.6         | 590               | 11,645       |\n| SoT-chat                | 47.3         | 256               | 1,290        |\n| SoT-reasoning           | 90.8         | 3,836             | 11,538       |\n| Reasoning Fine-tuned (RFT) | 91.0     | 2,880             | 2,880        |\n| **SPRINT**              | **92.5**     | **2,440**         | **3,622**    |\n\nAmong the high-performing methods (accuracy > 90%), SoT-reasoning exhibits a high total token cost due to redundant work by multiple independent threads, which individually replicate similar computations without coordination. In contrast, SPRINT achieves better efficiency by enabling coordination between parallel executors and the planner, resulting in reduced redundant computation. Although SPRINT introduces some planning and synchronization overhead, it substantially reduces **sequential tokens**, the key bottleneck for latency, relative to RFT, while improving accuracy and keeping total tokens low.\n\n\n**W2: Clarification on the Design and Implementation Details**\n\nWe have provided the design and implementation details in the file **Appendix-SPRINT.pdf**, submitted as part of our **supplementary materials**. In particular, inference-time hyperparameters, such as temperature (0.6), maximum tokens (36,000), and others, are described in Appendix A.1 (Implementation Details).\nThe analysis of the number of parallel plans generated per stage is presented in **Figure 5** and discussed at the end of **Section 4.2**. We show that SPRINT dynamically adjusts the number of parallel plans per stage: in the early stages, the planner proposes more plans to explore different pathways and tackle the subtasks, and as the solution progresses, the planner proposes fewer plans to aggregate the results.\nMoreover, we include concrete examples of parallelization in **Appendix B (Sample Demonstrations)**, and we provide additional examples of other forms of parallelization within this rebuttal (see above and below).\n\n**Q2: Impact of the Number of Parallel Branches per Reasoning Step**\n\nWe would like to clarify that the number of parallel branches at each reasoning step is **not** a manually tuned hyperparameter in our system. Instead, SPRINT’s planner is trained to **dynamically propose** the number of parallel plans to be executed at each step based on the problem context and solution state.\n\nThrough the post-training process, the planner learns to identify parallelization opportunities and assign subtasks accordingly. As a result:\n- In early stages, it proposes more plans to explore alternative reasoning pathways and tackle subtasks in parallel.\n- In later stages, it generates fewer plans, focusing on aggregating partial results and converging to a final answer.\n- For harder problems, the planner tends to propose more parallel branches compared to easier problems.\n\nBoth of these trends are evident in **Figure 5** (MATH500), where we observe stage-wise and difficulty-based adaptation in parallelization behavior.\n\n\n**Q3: Why Does Parallelization Work in SPRINT?**\nParallelization can be effective in three main ways:\n1. **Exploring alternative solutions**\n2. **Solving complementary substeps**\n3. **Verifying a previous step while another task progresses**\n\nBelow, we discuss two examples of the SPRINT’s reasoning trajectories illustrating each of these mechanisms.\n\n---\n\n**Exploring Alternative Solutions and Verification**  \nIn the trajectory presented in **Appendix B.2**, the task involves converting a binary number into its base-eight representation. SPRINT’s planner suggests two alternative approaches in parallel:\n- (a) Convert the binary number to decimal and then to octal.\n- (b) Split the 12-digit binary number into groups of three digits and convert each group directly.\n\nBoth paths proceed in parallel, and then at **Stage 3**, the planner issues a verification prompt while finalizing the answer in parallel:\n- **Prompt 3.1**: Verify the correctness of the grouping-based conversion (solution b).\n- **Prompt 3.2**: Reflect on the correctness of the final answer by comparing the outcomes of both conversion methods.\n\nThis structure helps the system reach a reliable solution through internal consistency checks, enhancing robustness in ambiguous cases.\n\n---\n\n**Decomposing into Complementary Subtasks**  \nIn another example, the planner splits the problem into two **complementary subtasks** in parallel: calculating vertical and horizontal asymptotes.\n\n**Question**  \n*The graph of* \\\\(f(x)=\\frac{2x}{x^2-5x-14}\\\\) *has vertical asymptotes* \\\\(x=a\\\\) *and* \\\\(x=b\\\\), *and horizontal asymptote* \\\\(y=c\\\\). *Find* \\\\(a+b+c\\\\).\n\n---\n\n**Plan 1**  \nTo solve the problem, we need to:\n- Identify the vertical asymptotes by finding the roots of the denominator.\n  - **Prompt 1.1**: Identify the vertical asymptotes by finding the roots of the denominator of the function.\n- Re-evaluate the horizontal asymptote based on degree comparison.\n  - **Prompt 1.2**: Re-evaluate the horizontal asymptote using the degrees of the numerator and denominator.\n\n---\n\n**Execution 1**\n\n- **Exec 1.1**  \n  Vertical asymptotes occur where the denominator is zero (as long as the numerator isn’t).  \n  Factor \\\\(x^2 - 5x - 14 = (x - 7)(x + 2)\\\\), so the vertical asymptotes are at \\\\(x = 7\\\\) and \\\\(x = -2\\\\).  \n  Therefore, \\\\(a = 7\\\\), \\\\(b = -2\\\\).\n\n- **Exec 1.2**  \n  Since the degree of the numerator is less than the denominator, the horizontal asymptote is \\\\(y = 0\\\\), so \\\\(c = 0\\\\).\n\n---\n\nThese parallel subtasks are merged to compute the final result:  \n\\\\[\na + b + c = 7 + (-2) + 0 = \\boxed{5}\n\\\\]\n\nThis example illustrates how SPRINT can decompose and parallelize logically independent subtasks that are later recombined to yield the final answer.\n\nThe full log can be found in our repository at “logs_full_trajectory/SPRINT/MATH-500_default/planner_trajectory_test_algebra_621.txt”.\n\nOnce again, we thank you for your valuable time and valuable feedback. We hope that the additional numerical analysis, illustrative examples, and clarifications we have provided address your concerns. We believe these improvements have strengthened the paper and hope you will consider reflecting this in your final score."}, {"review_id": "d1HACeuCdv", "reviewer": "Reviewer_6CkS", "summary": "This paper presents SPRINT, a post-training and inference-time framework that enables large reasoning models to dynamically identify and execute independent reasoning subtasks in parallel, reducing inference length and time. SPRINT uses a data curation pipeline to restructure reasoning trajectories into rounds of planning and parallel execution, followed by fine-tuning on a small amount of curated data. Experiments on reasoning tasks show that SPRINT reduces the number of sequential tokens on long reasoning chains, while achieving comparable performance to the reasoning fine-tuned model.", "questions": "1. Since Table 1 mentions PASTA [1] and Hogwild! Inference [2], and highlights SPRINT’s advantages over them, why not include these methods as quantitative baselines in the experimental comparisons?\n2. I agree with the authors’ point in Lines 144–147 that SPRINT could be more valuable for tool-integrated reasoning tasks. So why not directly evaluate SPRINT on such benchmarks, such as mathematical benchmarks with tool calls (those used in [3]), xLAM [4], or BrowseComp [5] with search tools? The rationale for evaluating only on MATH500, GPQA-diamond, and Countdown remains unclear.\n3. The source dataset for Figure 5 is unspecified. Does it show results from MATH500 or from the out-of-distribution tasks (GPQA-diamond, Countdown)? Also, does the same performance trend hold in the out-of-distribution scenarios?\n4. I recommend adding failure case analysis and a more detailed discussion on possible improvements. Specifically, it would help to clarify whether most errors stem from subtask planning or from execution failures during parallelization.\n5. The sole reliance on Seq. Tokens as the efficiency metric seems insufficient. Although the authors note that \"due to limited resources, we were unable to implement the optimal hardware-accelerated decoding for SPRINT,\" including other runtime metrics would significantly strengthen the paper’s efficiency claims.\n\n[1] Tian Jin, Ellie Y. Cheng, Zack Ankner, Nikunj Saunshi, Blake M. Elias, Amir Yazdanbakhsh, Jonathan Ragan-Kelley, Suvinay Subramanian, and Michael Carbin. Learning to keep a promise: Scaling language model decoding parallelism with learned asynchronous decoding, 2025.\n\n[2] Gleb Rodionov, Roman Garipov, Alina Shutova, George Yakushev, Vage Egiazarian, Anton Sinitsin, Denis Kuznedelev, and Dan Alistarh. Hogwild! inference: Parallel llm generation via concurrent attention, 2025.\n\n[3] Li, Xuefeng, Haoyang Zou, and Pengfei Liu. Torl: Scaling tool-integrated rl. arXiv preprint arXiv:2503.23383.\n\n[4] Jianguo Zhang, Tian Lan, Ming Zhu, Zuxin Liu, Thai Hoang, Shirley Kokane, Weiran Yao, Juntao Tan, Akshara Prabhakar, Haolin Chen, et al. 2024. xlam: A family of large action models to empower ai agent systems. arXiv preprint arXiv:2409.03215.\n\n[5] Wei, Jason, et al. Browsecomp: A simple yet challenging benchmark for browsing agents. arXiv preprint arXiv:2504.12516.", "limitations": "Yes", "rating": 5, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "Strengths:\n1. The motivation is clear and well-justified. The core idea—using curated data to fine-tune LLMs for dynamically identifying independent subtasks within extended reasoning processes and executing them in parallel—is simple and effective. The methodology section is well-written and easy-to-follow.\n2. The supplementary material is extensive and informative, providing details for reproduction.\n3. As discussed in the future work section, this approach has promising potential for extension to latency-aware reinforcement learning.\n\nWeaknesses:\n1. PASTA and Hogwild! Inference are mentioned but not included as baselines in experiments. (Q1)\n2. Why not directly evaluate SPRINT on tool-integrated reasoning benchmarks to better demostrate its efficiency? (Q2)\n3. The source dataset for Figure 5 is unspecified, and it’s unclear if the observed trends hold for out-of-distribution tasks. (Q3)\n4. I recommend adding failure case analysis on where SPRINT fails. (Q4)\n5. The use of only Seq. Tokens as an efficiency measure is limited. (Q5)", "was_revised": true, "final_justification": "I have carefully reviewed the authors’ detailed responses to my 5 questions. The additional experiment results and clarifications adequately resolve my earlier concerns, particularly regarding Q3, Q4, and Q5. Adding runtime as an additional efficiency metric can offer stronger evidence for the paper’s contributions. Therefore, I raise my score to 5.", "rebuttal": "Thank you for your detailed review and thoughtful suggestions! We appreciate your acknowledgement of SPRINT’s clear motivation, effective core idea, and its great potential for extension to latency-aware reinforcement learning.\n\nTo address your comments, we conducted additional experiments, clarified points of ambiguity, and provided further analysis. These include evaluating additional baselines such as Hogwild! Inference with two models, measuring runtime metrics for both SPRINT and the competing baseline, and offering a detailed analysis of failure cases along with a discussion of potential improvements.\n\n---\n\n**Q1/W1: Hogwild! Inference and PASTA as Baselines**\n\nWe have evaluated the performance of **Hogwild! Inference** on MATH500 using two types of base models: a chat-instruct model (**Qwen-2.5-7B-instruct**) and a reasoning model (**DeepSeek-R1-Distill-Qwen-7B**). As shown in the table below, both configurations result in substantially lower accuracy compared to SPRINT, which achieves **92.5%** accuracy. We attribute this to the fact that Hogwild! Inference does not involve fine-tuning for the planning-and-parallel-execution paradigm. This is consistent with the authors' own observations, as they also report subpar performance when applying Hogwild! to reasoning-focused models.\n\n| Base Model     | Accuracy (%) | Seq Tokens | Total Tokens |\n|----------------|--------------|------------|--------------|\n| Chat-Instruct  | 61.0         | 1173       | 2346         |\n| Reasoning      | 63.8         | 1797       | 3595         |\n\nRegarding **PASTA**, we have not included it as a baseline because the authors have not released their **code** or **trained model**, which prevents direct reproduction or comparison. Additionally, PASTA was not evaluated on the same benchmarks we use for SPRINT. Their experiments focus on simpler tasks that do not require complex, multi-step reasoning.\n\nPASTA decomposes a problem into subtasks that are executed in parallel **within a single stage**, and then aggregates the results to form a final answer. In contrast, **SPRINT** performs planning and execution **over multiple stages**, which enables more sophisticated, iterative decomposition and recomposition of reasoning steps. \n\nNotably, the **SoT-chat** and **SoT-reasoning** baselines help illustrate this difference, showing how chat-instruct and reasoning models, when not fine-tuned for the planning-and-parallel-execution setup, perform when only a single round of planning and execution is allowed.\n\n---\n\n**Q2/W2: Tool-integrated reasoning**\n\nWe thank the reviewer for highlighting the potential of SPRINT in tool-integrated reasoning scenarios. That said, evaluating SPRINT on tool-augmented benchmarks such as those used in xLAM, or BrowseComp presents a distinct challenge. Specifically, the open-source base models used in our work (e.g., the DeepSeek-R1-distilled series) lack native tool-calling capabilities, including the ability to produce correctly formatted tool-specific outputs. Incorporating such capabilities would require substantial additional fine-tuning, which is orthogonal to the scope of our current investigation. On the other hand, by evaluating models without tool integration, we allow a direct comparison against the baseline reasoning models that are also not tool-integrated. Otherwise, the effects on latency and accuracy resulting from parallelization and tool-use could get conflated.\nThe main objective of our work is to demonstrate that it is algorithmically feasible to train reasoning models to perform interleaved planning and parallel execution without relying on handcrafted pipelines or static decomposition strategies. Our contribution thus focuses on enabling model-driven, adaptive parallelization in complex reasoning tasks. Looking ahead, we view the integration of tool-calling capabilities with SPRINT’s parallel planning mechanism as a promising direction. Equipping models with both capabilities could enable parallel tool-use, expanding SPRINT’s applicability to tool-augmented reasoning tasks.\n\n---\n\n**Q3/W3: Clarification on Figure 5 Dataset and Parallelization Trends in Out-of-Distribution Tasks**\nThank you for bringing this to our attention. Figure 5 is based on the logs from MATH500 using the dataset’s original difficulty levels. To address your question regarding the out-of-distribution (OOD) tasks (GPQA-diamond and Countdown): yes, we observe a similar performance trend. Specifically, more parallelization opportunities arise in the earlier stages, where the model explores alternative strategies and identifies subtasks before converging to the final solution.\n\n\nThe detailed results are as follows:\n\n**GPQA**  \n- Number of problems reaching stage *i*:  \n  [198, 185, 157, 114, 81, 50, 35, 26, 18, 13, 8]  \n- Number of problems exhibiting parallelism (more than one execution) at stage *i*:  \n  [91, 100, 65, 44, 24, 7, 3, 5, 2, 0, 0]\n\n**Countdown**  \n- Number of problems reaching stage *i*:  \n  [1000, 991, 886, 732, 498, 382, 275, 202, 150, 124, 72]  \n- Number of problems exhibiting parallelism (more than one execution) at stage *i*:  \n  [585, 655, 340, 176, 102, 48, 29, 13, 8, 4, 4]\n\nDue to rebuttal constraints, we are unable to upload a separate file or figure at this stage. However, we will include the corresponding analysis figure for the OOD benchmarks in the final version of the paper.\n\n---\n\n**Q4/W4: Adding failure case analysis**\nFollowing the reviewer’s recommendation, we have analyzed failure cases and identified three categories:\nLogical Errors During Execution: These include calculation mistakes, typographical errors, or incorrect mathematical assumptions.\nImproper Conflict Resolution: These occur when two executors independently pursue different solution paths and produce conflicting results, causing the planner to fail in selecting the correct one.\nIncomplete Plan/Execution: In some complex tasks, the model repeatedly tries various approaches but fails to arrive at a final answer within the maximum number of permitted stages (12 stages). In other cases, the execution within a stage becomes too lengthy and gets truncated when it reaches the maximum token count.\nThe logical errors during execution largely stem from the limitations of the base model, rather than from parallelization or planning mechanisms. In fact, similar types of errors are also observed in the baseline Reasoning Fine-tuned (RFT) model.\nBased on the scaling trends of the reasoning models, we expect that with larger and more capable base models, both execution and planning quality will improve. We supervised fine-tuned our model on fewer than 2,000 data points, which successfully unlocked the ability to perform interleaved planning and parallel execution. Future work can enhance the model’s performance further by training on larger datasets and incorporating reinforcement learning.\nWe will include a detailed failure analysis, along with illustrative examples and proposed directions for improvement, in the revised version of the paper.\n\n---\n\n**Q5/W5: Runtime as an Efficiency Metric**\n\nWe agree that reporting only the number of generated tokens does not fully capture end‑to‑end efficiency. To strengthen our claims, we measured **SPRINT’s runtime** both **excluding** and **including** the Time‑To‑First‑Token (TTFT) overhead, which accounts for the cost of the \"prefilling\" phase, and compared these to the **Reasoning Fine-Tuned (RFT)** model's total inference latency:\n\n| Dataset                    | SPRINT (Decode Only) | SPRINT (End-to-End) | RFT (End-to-End) |\n|----------------------------|----------------------|----------------------|------------------|\n| MATH500 (all problems)     | 35.87 s              | 36.92 s              | 40.57 s          |\n| MATH500 (RFT > 8k tokens)  | 73.43 s              | 74.47 s              | 120.54 s         |\n\n**Prefill overhead is minor.** On average, each prefilling step adds only ~0.11 s, while decoding a single token takes ~0.01 s. Even across multiple stages, the bulk of runtime remains in the decoding phase.\n\n**End‑to‑end speedups.** When including TTFT, SPRINT still outperforms RFT by approximately **9%** on the full MATH500 set (36.92 s vs. 40.57 s), and by approximately **38%** on the longest sequences (74.47 s vs. 120.54 s).\n\n**Scaling benefits.** Because decoding cost dominates, **SPRINT’s advantage grows with trajectory length**: longer reasoning chains yield both larger absolute and relative latency reductions.\n\n**In summary**, even accounting for prefilling overhead, SPRINT achieves substantial end‑to‑end latency reductions compared to RFT, and these gains increase significantly for tasks that involve long reasoning trajectories.\n\n---\n\nWe appreciate the comprehensive comments and hope that our additional experiments, analysis of results, and discussion addressed your concerns. We hope you find the paper significantly improved and consider reflecting this in your final score."}, {"review_id": "CqZlBBpcc2", "reviewer": "Reviewer_76Mf", "summary": "This paper proposes SPRINT, a method to enable LRMs to parallelize reasoning and execution via planning. The proposed SPRINT framework successfully reduces sequential token generation compared to vanilla fine-tuned LLMs or inference-time parallel techniques such as the skeleton of thoughts. Moreover, the model fine-tuned with SPRINT also shows generalization capabilities in other domains (e.g., model fine-tuned on MATH generalizes on Countdown and GPQA-Diamond).", "questions": "Please see the weakness section above. On top of the weaknesses, can the authors also clarify why MATH500 test results do not seem to present integers in terms of correct cases? To my understanding, MATH500 has 500 test cases. According to Table 2, SPRINT seems to have 462.5 cases correct with an accuracy of 92.5.", "limitations": "yes", "rating": 4, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "Strengths:\n\n1. The topic is important (significance): how to make LLM/LRM inference faster so that users can enjoy better service.\n\n2. The paper is well written and easy to follow (clarity). The figures and tables are well organized and clearly presented.\n\n3. The proposed method is novel (novelty). It reduces sequential token generation without degrading model performance, and its advantage generalizes across domains.\n\nWeaknesses:\n\n1. Lack of significance test (quality): Although the authors claim that SPRINT has higher accuracy in section 4.2, it seems that the margin is quite small compared to RFT in Table 2. Can the authors present statistical significance tests and clarify whether the performance gain is significant?\n\n2. Lack of analysis about pre-filing latency analysis (quality): The main advantage of SPRINT, to my understanding, is that it reduces the wall-clock time of model inference. While the results indeed show that the sequential generation length is lower, it does not necessarily mean that the total generation time/cost is shorter/lower. Note that in every execution, the executor model has to pre-fill the plan generated by the orchestrator, then execute the plan. The pre-filling of SPRINT appears as an overhead compared to RFT in practice, while it neither appears in Figure 3 nor in other analysis parts. Can the authors clarify whether redundant pre-filing would affect SPRINT's advantage?", "was_revised": true, "final_justification": "My concerns are resolved.", "rebuttal": "Thank you for your thoughtful and technical review! We are glad you found the topic’s significance, the paper’s clarity, and SPRINT’s novelty and cross-domain generalization compelling.\nIn response to your feedback, we ran additional experiments, provided numerical analysis, and clarified points of ambiguity. In particular, we conducted a statistical significance test, measured runtime metrics, and demonstrated the scaled benefits of SPRINT, especially on longer reasoning trajectories.\n\n---\n\n**W1: Statistical Significance Analysis of the Results** \n\nWhile the difference in accuracy between SPRINT and RFT may appear small, our primary contribution lies in reducing latency through parallelism **without sacrificing** the accuracy of the underlying reasoning model. To validate that the observed accuracy gains are meaningful, we conducted a statistical significance analysis using 5 independent runs of both SPRINT and RFT on the MATH500 dataset.\n\nSPRINT achieved an average accuracy of 92.36% with a standard deviation of 0.15, while RFT averaged 90.72% with a standard deviation of 0.24. A two-sample t-test yielded a p-value of 0.00024, indicating that the performance difference is statistically significant.\n\n---\n\n**W2: Quantifying Prefilling Overhead and End-to-End Latency of SPRINT**\n\nWe appreciate the reviewer’s point on the need to quantify SPRINT’s prefilling overhead. To address this, we measured SPRINT’s runtime both **excluding** and **including** the Time‑To‑First‑Token (TTFT) overhead (which captures the cost of the “prefilling” phase), and compared these to Reasoning Fine-Tuned (RFT) model’s total inference latency:\n\n| Dataset                     | SPRINT (Decode Only) | SPRINT (End-to-End) | RFT (End-to-End) |\n|-----------------------------|----------------------|----------------------|------------------|\n| MATH500 (all problems)      | 35.87 s              | 36.92 s              | 40.57 s          |\n| MATH500 (RFT > 8k tokens)   | 73.43 s              | 74.47 s              | 120.54 s         |\n\n**Prefill overhead is minor.** On average, each prefilling step adds only ~0.11 s, while decoding a single token takes ~0.01 s. Even with multiple stages, the bulk of runtime remains in the decoding phase.\n\n**End-to-end speedups.** When including TTFT, SPRINT still outperforms RFT by approximately **9%** on the full MATH500 set (36.92 s vs. 40.57 s), and by approximately **38%** on the longest sequences (74.47 s vs. 120.54 s).\n\n**Scaling benefits.** Because decoding cost dominates, **SPRINT’s advantage increases with trace length**—longer reasoning chains yield greater absolute and relative latency reductions.\n\n**In summary**, even when accounting for prefilling overhead, **SPRINT achieves substantial end-to-end latency reductions** compared to RFT, with the gains becoming more pronounced on tasks that involve very long reasoning traces.\n\n---\n\n**Q1: Averaged over independent runs**\n\nRegarding the reviewer’s concern about the fractional number of correct cases in MATH500, we would like to clarify that the reported accuracy is the average over independent runs of SPRINT. As a result, while each individual run produces an integer count of correct answers, the average can be non-integer. \n\n---\n\nOnce again, we thank you for your valuable time and feedback. We hope that our additional experiments, analysis of results, and discussion addressed your concerns. We hope you find the paper significantly improved and consider reflecting this in your final score."}]

Author rebuttal:

Meta-review: This paper introduces SPRINT, a method that enables large reasoning models to interleave planning and parallel execution stages. The approach reduces sequential token generation by identifying and executing independent subtasks in parallel, while maintaining or improving accuracy across both in-domain and out-of-domain tasks.

During the discussion period, the authors addressed all major reviewer concerns through additional experiments and clarifications:
1. Efficiency metrics and implementation details (Reviewers 5uvg, tuC4). The authors clarified the sequential token calculation and provided more token statistics. SPRINT reduces sequential tokens by 15% with a modest increase in total tokens, while slightly improving accuracy on MATH500.
2. Runtime and prefilling overhead (Reviewer 76Mf). The authors measured actual runtime and showed that SPRINT achieves 9% end-to-end speedup on MATH500 and 38% speedup on long sequences. Prefilling adds only ~0.11s per stage, negligible compared to decoding costs.
3. Missing baselines (Reviewer 6CkS). The authors additionally included Hogwild! inference with both chat-instruct and reasoning models.
4. Generalization beyond STEM (Reviewer 5uvg). The authors demonstrated SPRINT generalizes to creative writing tasks, successfully decomposing narrative generation into parallel character perspectives despite training only on mathematical data. Similar parallelization patterns were confirmed on out-of-distribution tasks (GPQA, Countdown).
5. Why parallelization works (Reviewers 5uvg, tuC4). The authors provided concrete examples showing three mechanisms: (1) exploring alternative solution paths, (2) decomposing into complementary subtasks, and (3) verification in parallel with progression. Detailed trajectory logs illustrate these patterns.

All four reviewers converged on acceptance after the rebuttal. The consensus recognized SPRINT's technical soundness, novel approach to adaptive parallelization, and practical value for reducing LRM inference latency.

The recommendation is to accept this paper.
Decision: Accept (poster)