← 返回 2026-03-27

IQuest-Coder-V1 技术报告:面向代码智能的多阶段进化训练范式 IQuest-Coder-V1 Technical Report

Jian Yang, Wei Zhang, Shawn Guo, Zhengmao Ye, Lin Jing, Shark Liu, Yizhi Li, Jiajun Wu, Cening Liu, X. Ma, Yuyang Song, Siwei Wu, Yuwen Li, L. Liao, T. Zheng, Ziling Huang, Zelong Huang, Che Liu, Yan Xing, Renyuan Li, Qingsong Cai, Hanxu Yan, Siyue Wang, Shikai Li, Jason Klein Liu, An Huang, Yongsheng Kang, Jinxing Zhang, Chuan Hao, Haowen Wang, Weicheng Gu, Ran Tao, Mingjie Tang, Peihao Wu, Jianzhou Wang, Xianglong Liu, Weifeng Lv, Bryan Dai 📅 2026-03-17 👍 18 2026-07-13 08:36
代码大模型 代码智能 多阶段训练 强化学习 循环架构 智能体编程

提出代码流多阶段训练范式与循环Transformer架构,在代码智能基准上达到开源SOTA。

前置知识

代码大语言模型(Code LLM)

代码大语言模型是在大规模代码语料上预训练的神经网络模型,能够理解和生成多种编程语言的代码。与通用LLM不同,Code LLM在代码补全、调试、重构等任务上有专门优化。代表模型包括DeepSeek-Coder、Qwen-Coder、CodeLlama等。这些模型通常在数十亿到数百亿token的代码语料上训练,涵盖Python、Java、TypeScript等多种语言。代码LLM的核心挑战在于如何从静态代码文本中学习动态的程序逻辑和软件工程知识,而不仅仅是模式匹配。

本文的核心目标是构建高性能的代码LLM家族,理解代码LLM的基本概念和发展现状是读懂本文的基础。

Fill-In-the-Middle(FIM)

FIM是一种代码补全训练范式,将代码文档分为前缀(prefix)、中间(middle)、后缀(suffix)三部分,训练目标是根据前缀和后缀预测中间被遮蔽的代码。本文在文件级和仓库级两个层面使用FIM,仓库级FIM还会从同一仓库中检索语义相似的代码片段作为额外上下文,从而提升跨文件补全能力。FIM技术是代码LLM预训练阶段的核心数据构建方法之一。

FIM是本文预训练数据构建的关键技术,论文详细描述了启发式和语法级两种FIM构造策略,理解FIM有助于理解预训练阶段的技术细节。

Group Relative Policy Optimization(GRPO)

GRPO是一种强化学习算法,属于策略梯度方法的变体。与PPO不同,GRPO不使用价值网络(critic),而是通过在同一批次内对多个采样输出进行相对排序来估计优势函数。具体来说,对于每个prompt生成一组响应,计算每个响应的奖励,然后用组内均值和标准差进行归一化得到相对优势。本文在后训练阶段使用GRPO进行推理和指令遵循的强化学习优化。

GRPO是本文后训练阶段的核心优化算法,理解其工作原理对于理解Thinking路径和Instruct路径的强化学习训练至关重要。

循环Transformer(Loop Transformer)

循环Transformer是一种参数共享的架构设计,其中同一组Transformer块以固定迭代次数(本文为两次)重复执行。第一次迭代处理输入嵌入并生成隐藏状态,第二次迭代同时执行全局注意力(可访问第一次迭代的所有KV对)和局部注意力(仅访问第二次迭代中的因果前序token),然后通过学习的门控机制混合两种注意力输出。这种设计在不增加参数量的情况下增加了计算深度,类似于在推理时对同一输入进行多次"思考"。

LoopCoder是本文的架构创新核心,理解循环Transformer的工作机制是理解本文40B-Loop模型为何能在保持参数量不变的前提下提升性能的关键。

智能体编程(Agentic Coding)

智能体编程是指LLM作为自主代理,能够通过多步工具调用与开发环境交互来完成复杂的软件工程任务。典型任务包括根据issue描述自动修复bug(如SWE-bench)、在终端中执行命令构建和调试软件(如Terminal-Bench)、进行多轮函数调用(如BFCL)。智能体编程要求模型具备长程规划、错误恢复、工具使用等能力,是代码LLM的前沿应用方向。

智能体编程是本文模型的核心应用场景,论文在SWE-bench、Terminal-Bench等多个智能体基准上进行了广泛评估。

研究动机

当前代码LLM领域存在一个显著的性能鸿沟:开源模型与闭源领先模型(如Claude 4.5 Sonnet)之间在长程推理和复杂多文件代码库导航方面差距明显。具体来说,现有开源代码模型(如Qwen2.5-Coder-32B、DeepSeek-Coder系列)在SWE-bench Verified基准上的得分通常在45-73分区间,而Claude 4.5 Sonnet达到77.2分。这种差距的根本原因在于:(1)现有模型主要基于静态代码快照训练,缺乏对代码仓库动态演化过程的理解;(2)训练范式通常是单一阶段的预训练加微调,缺少中间过渡阶段来桥接静态知识与动态行动能力;(3)后训练阶段没有针对推理和指令遵循两条不同路径分别优化,导致模型在复杂推理和通用助手两个方向上无法同时达到最优。

本文的目标是本文的目标是构建IQuest-Coder-V1系列模型(7B/14B/40B/40B-Loop),通过系统性的多阶段进化训练范式来弥合开源与闭源代码模型之间的差距。具体目标包括:在SWE-bench Verified上达到76分以上的成绩,在LiveCodeBench v6上超过80分,在多个智能体编程和代码推理基准上全面超越现有的开源代码模型;同时提供从预训练基础模型到最终Thinking和Instruct模型的完整白盒检查点链,支持社区研究代码智能的涌现机制。

与已有工作不同的是,本文的独特切入角度是"代码流"(Code-Flow)训练范式,即将代码仓库的开发演化过程(而非静态代码快照)作为核心训练信号。传统代码LLM训练将代码视为静态文本,而本文认识到软件开发本质上是一个动态的演化过程——从初始提交到功能迭代、bug修复、重构,形成了一条完整的逻辑链条。通过在训练中捕捉这种动态演化(以仓库过渡数据commit flow的形式),模型能够学习到比静态文件更丰富的任务规划和逻辑推理能力。此外,本文提出双路径后训练(Thinking路径和Instruct路径),认识到不同使用场景需要不同的优化策略,这与以往一刀切的后训练方法形成鲜明对比。

核心方法

本文提出IQuest-Coder-V1的"代码流"(Code-Flow)训练范式,这是一个四支柱的多阶段进化管线。整体思路是:先通过大规模预训练建立基础语言理解和代码生成能力,再通过中训练阶段注入推理和智能体能力作为逻辑支架,最后通过两条独立的后训练路径分别优化推理能力和指令遵循能力。训练管线从通用数据开始,逐步过渡到代码数据、高质量代码、32k上下文推理数据、128k仓库级数据,最终分化为Thinking模型和Instruct模型。这种渐进式的"锻造"过程模拟了人类程序员从学习基础语法到掌握复杂软件工程的进化路径。

本文的核心创新在于三个关键发现:(1)仓库过渡数据(commit flow,即代码仓库的提交序列)相比静态快照文件提供了更优越的任务规划信号。传统方法将代码视为静态快照,而本文构建了三元组(R_old, P, R_new)来捕捉代码的动态演化,其中R_old是旧代码状态,P是补丁信息,R_new是新代码状态。(2)在高质量代码退火之后、后训练之前注入32k推理和智能体轨迹,作为"逻辑支架"稳定模型在分布偏移下的性能。(3)Thinking路径(使用推理驱动的RL)能够触发自主错误恢复的涌现能力,这是标准Instruct SFT后训练路径所缺乏的。这三个发现挑战了代码LLM开发中的几个传统假设。

方法步骤详情

训练分为三个主要阶段。阶段一:预训练与退火。首先使用混合通用数据和代码数据进行Stage 1预训练(General Pre-training),然后进行Stage 2退火(Annealing),聚焦高质量代码语料。退火阶段使用项目成熟度原则选择训练数据:在项目生命周期的40%-80%百分位范围内选取提交,确保训练数据反映真实的软件开发模式。阶段二:中训练(Mid-Training),分两个子阶段。Phase 1在32k上下文下训练推理QA(数学、编码、逻辑)、智能体轨迹、代码提交和文件/仓库级FIM数据,产出IQuest-Coder-V1-Base-Stage1;Phase 2将上下文扩展到128k继续训练,产出最终的基座模型。阶段三:后训练,分为Thinking路径和Instruct路径。Thinking路径先在包含显式推理轨迹的Thinking数据上进行SFT,再用GRPO进行推理优化的RL训练;Instruct路径先在通用和代码指令数据上进行SFT,再用GRPO进行指令遵循优化的RL训练。

技术新颖性

本文的技术新颖性体现在多个层面。首先,LoopCoder架构采用循环Transformer设计,参数共享的Transformer块执行两次迭代:第一次处理输入嵌入,第二次同时执行全局注意力(访问第一次迭代的所有KV对)和局部注意力(仅访问第二次迭代的因果前序token),通过学习的门控机制混合两种注意力输出。这与原始Parallel Loop Transformer不同,省略了token-shifting机制和推理特定优化。其次,仓库级三元组数据构建策略(R_old, P, R_new)是全新的代码表示方法,不是简单地将代码视为文本,而是将其建模为有时间维度的演化过程。第三,双路径后训练策略认识到推理和指令遵循需要不同的优化profile,Thinking路径的RL训练能够触发自调试、跨语言传递和改进的不确定性校准等涌现能力。

IQuest-Coder-V1的代码流训练管线
Figure 2: IQuest-Coder-V1的代码流训练管线

实验结果

IQuest-Coder-V1在多个基准上取得了与闭源领先模型竞争的性能。旗舰模型IQuest-Coder-V1-40B-Loop-Instruct在SWE-bench Verified上达到76.2分,接近Claude Sonnet 4.5的77.2分;40B-Loop-Thinking模型在LiveCodeBench v6上达到81.1分,超越所有对比的开源模型。在代码生成任务上,40B-Instruct在HumanEval上达到96.3分(与Claude Opus 4.5的98.8分相当),MBPP上达到91.8分,BigCodeBench Full上达到54.2分(超越Claude Sonnet 4.5的51.4分)。在智能体编码任务上,40B-Loop-Instruct在Terminal-Bench上达到51.3分,BFCL V3上达到73.9分。值得注意的是,7B模型在Thinking路径下展现出显著的能力提升:LiveCodeBench v5从24.6分(Instruct)提升到37.7分(Thinking),增幅达53%,验证了Thinking路径的有效性。在安全性评估上,40B-Thinking模型在Tulu 3基准上总体得分85.0分,显著优于40B-Instruct的67.8分,表明推理优化也有助于提升安全性。

IQuest-Coder-V1的模型架构参数
Table 1: IQuest-Coder-V1的模型架构参数
CrossCodeEval跨文件代码补全任务性能对比
Table 2: CrossCodeEval跨文件代码补全任务性能对比
代码生成任务性能对比
Table 3: 代码生成任务性能对比
代码推理评估性能对比
Table 4: 代码推理评估性能对比
代码效率任务性能对比
Table 5: 代码效率任务性能对比
文本到SQL任务性能对比
Table 6: 文本到SQL任务性能对比
智能体编码和通用工具使用任务综合性能对比
Table 7: 智能体编码和通用工具使用任务综合性能对比
IQuest-Coder-V1在不同基准上的性能表现
Figure 1: IQuest-Coder-V1在不同基准上的性能表现
IQuest-Coder-V1各模型变体在不同基准上的性能对比
Figure 3: IQuest-Coder-V1各模型变体在不同基准上的性能对比
查看结构化数据
任务指标本文基线提升
SWE-Bench Verified(真实软件工程任务) Pass Rate (%) IQuest-Coder-V1-40B-Loop-Instruct: 76.2; IQuest-Coder-V1-40B-Thinking: 71.2 Claude Sonnet 4.5: 77.2; GPT-5.1: 76.3; Qwen3-Coder-480B: 67.0 40B-Loop-Instruct超过GPT-5.1(76.2 vs 76.3基本持平),大幅超越同量级开源模型如Qwen3-Coder-480B(+9.2)
LiveCodeBench v6(竞赛编程) Pass@1 (%) IQuest-Coder-V1-40B-Loop-Thinking: 81.1 DeepSeek-v3.2: 83.3; GLM-4.7: 84.9; Claude Sonnet 4.5: 73.0 超越Claude Sonnet 4.5达8.1分,在开源模型中处于第一梯队
BigCodeBench(库密集型代码生成) Top 1 (%) IQuest-Coder-V1-40B-Instruct: 54.2; IQuest-Coder-V1-14B-Instruct: 46.3 Claude Sonnet 4.5: 51.4; Kimi-K2: 49.8; GPT-5.1: 46.8 40B-Instruct超越Claude Sonnet 4.5达2.8分,是该基准上的开源最优
Bird-SQL(跨域文本到SQL) Execution Accuracy (%) IQuest-Coder-V1-40B-Instruct: 70.5; IQuest-Coder-V1-40B-Loop-Instruct: 69.9 Claude Sonnet 4.5: 62.5; Qwen2.5-Coder-32B: 62.1; DeepSeek-v3.2: 52.6 40B-Instruct超越Claude Sonnet 4.5达8.0分,大幅领先开源竞品
Terminal-Bench v1.0(终端工作流智能体) Top 1 (%) IQuest-Coder-V1-40B-Instruct: 52.5; IQuest-Coder-V1-40B-Loop-Instruct: 51.3 Gemini-3-Pro-preview: 46.3; Claude Sonnet 4.5: 51.0; Kimi-K2: 44.5 40B-Instruct超越所有对比模型,包括闭源的Gemini-3-Pro(+6.2)
HumanEval+(代码生成正确性) Pass@1 (%) IQuest-Coder-V1-40B-Instruct: 90.2; IQuest-Coder-V1-40B-Loop-Instruct: 91.5 Claude Opus 4.5: 93.3; Qwen3-Coder-480B: 92.7; DeepSeek-v3.2: 88.4 与闭源领先模型差距缩小到1.8分以内,超越DeepSeek-v3.2
CRUXEval Input-COT(代码推理-正向执行) Accuracy (%) IQuest-Coder-V1-40B-Instruct: 93.5; IQuest-Coder-V1-40B-Thinking: 87.4 Kimi-K2: 86.8; DeepSeek-v3.2: 82.1; Qwen2.5-Coder-32B: 78.8 40B-Instruct在该基准上大幅领先所有对比模型,领先Kimi-K2达6.7分
安全性(Tulu 3 Overall) Macro Avg Accuracy (%) IQuest-Coder-V1-40B-Thinking: 85.0; IQuest-Coder-V1-40B-Instruct: 67.8 Qwen3-Coder-480B: 84.8; Qwen2.5-Coder-32B: 67.7 40B-Thinking安全性与Qwen3-Coder-480B持平(85.0 vs 84.8),远超40B-Instruct

局限与改进

本文存在几个值得注意的局限性。首先,论文缺乏详细的训练成本和数据规模披露——虽然提到"多百万GPU小时"的训练,但没有给出具体的GPU小时数、token数量和计算预算,这使得社区难以评估复现成本和进行公平的效率比较。其次,40B-Loop模型虽然在多个基准上表现优异,但论文中没有提供Loop架构相比标准架构的推理延迟对比,循环Transformer的两次迭代在实际部署中可能带来显著的推理开销,而论文对这一点着墨甚少。第三,7B和14B模型在多个基准上与竞品存在明显差距(如7B-Instruct在BigCodeBench上仅38.9分,而Seed-Coder-8B达到44.6分),说明模型的有效性主要体现在40B规模上,小模型的训练策略可能需要进一步优化。第四,论文中的对比模型选择存在一定的选择性——某些基准上缺少最强竞品的对比数据(如LiveCodeBench v5和v6上缺少部分模型的对比),这可能影响结论的全面性。此外,论文虽然提出了三个"Finding",但对这些发现的消融实验细节不足,例如没有给出仓库过渡数据vs静态快照数据的精确性能对比数字。

独立分析的弱点

本文的一个显著弱点是小规模模型(7B)的表现不尽如人意。7B-Instruct在HumanEval上仅79.9分(Qwen2.5-Coder-7B-Instruct为87.2分),Mercury Pass@1仅50.4分(对比DeepSeek-Coder-V2-Lite-Instruct的91.4分),说明当前的训练策略可能对小模型不够友好。改进方向包括:(1)为小模型设计专门的数据配比和课程学习策略,因为小模型的容量限制使其难以从与大模型相同的数据分布中充分学习;(2)LoopCoder架构目前仅在40B规模上验证,但其循环计算的思想理论上对小模型更有价值——通过增加计算深度而非参数量来提升小模型的能力。第二个弱点是缺乏与同等计算预算下训练的基线模型的对比。论文没有说明训练IQuest-Coder-V1消耗了多少计算资源,也没有与使用相同计算预算训练的其他模型进行对比,这使得效率方面的优势无法被量化评估。第三个弱点是论文对LoopCoder架构的推理效率分析不足,两次迭代的注意力计算在实际部署中可能带来显著延迟,需要更详细的推理吞吐量和延迟基准测试。

未来方向

论文作者提出的未来方向包括:开源完整的训练管线和模型检查点以促进代码智能研究、发展能够处理真实世界软件工程挑战的生产级智能体系统。基于本文成果可以延伸的研究方向包括:(1)将代码流范式扩展到更大的模型规模(100B+),探索在更大容量下仓库过渡数据是否能带来更显著的收益;(2)将循环Transformer架构与其他效率优化技术(如稀疏注意力、KV缓存压缩)结合,进一步优化推理效率;(3)探索Thinking路径和Instruct路径的统一训练策略,避免维护两套独立的模型变体;(4)将代码流训练范式应用到其他领域,如数据科学工作流、硬件描述语言等;(5)研究LoopCoder架构中门控机制的可解释性,理解模型在两次迭代中分别"学到"了什么。

复现评估

本文在复现方面提供了较好的支持。论文承诺开源完整的白盒检查点链,从Stage 1预训练基础模型到Stage 2中训练模型,再到最终的Thinking和Instruct模型,这使得社区可以研究每个训练阶段的贡献。模型架构参数在Table 1中详细列出(7B/14B/40B三个规模),包括层数(14/28/80)、隐藏大小(5120)、中间层大小(27648)、注意力头数(40 query heads, 8 KV heads)等。然而,复现面临的主要挑战包括:(1)训练数据的完整构建流程未完全公开,特别是仓库过渡数据的构建细节和数据量;(2)训练的计算成本未明确披露,仅提到"多百万GPU小时";(3)GRPO训练的超参数(学习率、批大小、采样数量等)未在论文中给出;(4)推理阶段的硬件需求和延迟特性未提供。总体而言,虽然模型检查点开源降低了使用门槛,但完整复现训练管线仍有一定难度。