Title: SPRINT: Enabling Interleaved Planning and Parallelized Execution in Reasoning Models
Venue: NeurIPS 2025
Accepted: yes
Keywords: Large Reasoning Models

Parallel inference

Planning and parallel execution

Post-training
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.


Peer reviews:
{"IS_META_REVIEW": false, "comments": "SUMMARY:\nThis 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).\n\nSTRENGTHS AND WEAKNESSES:\nStrengths:\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?\n\nQUESTIONS:\nPlease 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.\n\nLIMITATIONS:\nyes", "TITLE": "Official Review", "RECOMMENDATION": 4, "REVIEWER_CONFIDENCE": 3, "CLARITY": 3, "IMPACT": 3, "ORIGINALITY": 3, "DATE": "2025-06-22"}

{"IS_META_REVIEW": false, "comments": "SUMMARY:\nThis 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.\n\nSTRENGTHS AND WEAKNESSES:\nStrengths:\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)\n\nQUESTIONS:\n1. 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.\n\nLIMITATIONS:\nYes", "TITLE": "Official Review", "RECOMMENDATION": 5, "REVIEWER_CONFIDENCE": 3, "CLARITY": 3, "IMPACT": 3, "ORIGINALITY": 3, "DATE": "2025-06-29"}

{"IS_META_REVIEW": false, "comments": "SUMMARY:\nThis 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.\n\nSTRENGTHS AND WEAKNESSES:\nStrengths:\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.\n\nQUESTIONS:\n1. 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?\n\nLIMITATIONS:\nYes.", "TITLE": "Official Review", "RECOMMENDATION": 4, "REVIEWER_CONFIDENCE": 3, "CLARITY": 3, "IMPACT": 2, "ORIGINALITY": 3, "DATE": "2025-07-02"}

{"IS_META_REVIEW": false, "comments": "SUMMARY:\nThis 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.\n\nSTRENGTHS AND WEAKNESSES:\n### **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.\n\nQUESTIONS:\n- 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?\n\nLIMITATIONS:\nyes", "TITLE": "Official Review", "RECOMMENDATION": 5, "REVIEWER_CONFIDENCE": 4, "CLARITY": 3, "IMPACT": 3, "ORIGINALITY": 3, "DATE": "2025-07-02"}