贝壳研究院32B模型突破：用开源数据打造推理能力媲美超大模型的"小巧强兵"

这项由贝壳找房（Ke.com）内部a-m团队的纪运杰、田晓雨、赵思彤、王浩天、陈帅庭、彭一平、赵涵、李现刚等研究者完成的研究，于2025年5月发表在计算机科学预印本网站arXiv上（论文编号：arXiv:2505.08311v2），有兴趣深入了解的读者可以通过https://huggingface.co/a-m-team/AM-Thinking-v1访问完整模型。

近年来，大型语言模型在推理能力上取得了令人瞩目的进步，特别是在数学问题解决和代码生成这些需要复杂逻辑推理的任务上。然而，目前的顶尖推理模型往往依赖于庞大的混合专家（MoE）架构，这些"巨无霸"模型虽然能力强大，但部署和微调都极为复杂，对硬件资源的要求也相当苛刻。

面对这种情况，研究团队提出了一个关键问题：能否在不依赖私有数据和大规模MoE架构的情况下，通过精心设计的训练流程来释放32B规模密集模型的推理潜力？这就像在问，能否用一台精心调教的家用汽车跑出超跑的速度。

为了回答这个问题，研究团队开发了AM-Thinking-v1，这是一个基于开源Qwen2.5-32B基础模型构建的推理优化语言模型。这个模型在多个推理基准测试中取得了令人印象深刻的成绩：在AIME2024数学竞赛中得分85.3，AIME2025中得分74.4，在LiveCodeBench编程测试中得分70.3。更令人惊讶的是，这个仅有320亿参数的"小"模型竟然超越了DeepSeek-R1这样的671B MoE模型，甚至接近了Qwen3-235B-A22B和Seed1.5-Thinking等顶级大模型的性能。

研究的核心创新在于一套精心设计的后训练框架。这个框架就像一个精密的烹饪流程，包含两个主要阶段：监督微调（SFT）和强化学习（RL）。研究团队从Qwen2.5-32B基础模型开始，首先使用冷启动数据集进行监督微调，培养模型的"先思考再回答"模式，建立初步的推理能力。接着在强化学习阶段，他们采用了难度感知的查询选择和两阶段训练程序，确保训练的稳定性和性能的逐步提升。

更重要的是，整个训练过程完全基于公开可获得的数据集。研究团队对各种开源查询和指令进行了严格的预处理，包括去重、去除低质量或多模态查询，以及对评估基准进行彻底的污染检测。特别是对于数学查询，由于发现其中存在大量噪声项，他们构建了一个全面的数据处理流程，涵盖查询过滤和标准答案验证。

在数据收集方面，研究团队从多个公开数据集中收集训练数据，涵盖数学推理、代码生成、科学推理、指令遵循和通用对话等任务。对于数学推理数据，他们确保每个数据点都包含可验证的标准答案，并整合了OpenR1-Math-220k、Big-Math-RL-Verified、NuminaMath、MetaMathQA等多个数据集。代码生成数据则确保所有收集的代码数据都包含可验证的测试用例，涵盖PRIME、DeepCoder、KodCode等数据集。

在数据清洗过程中，研究团队首先去除重复项，然后应用两个清洗步骤：移除包含URL的查询（因为模型无法在训练过程中访问外部链接）和移除引用图像的查询（因为这是一个纯文本模型）。最后，他们使用精确匹配和语义去重技术，从训练集中移除与评估集相似的查询。

对于数学查询的特殊处理更加细致。研究团队发现数学数据中存在描述不清楚或不完整的查询以及错误的标准答案问题。为了解决前者，他们使用大语言模型分析并过滤掉缺乏清晰完整描述的查询。对于后者，他们实施了严格的标准答案验证流程：对每个查询，提示DeepSeek-R1生成多个回答，并使用math_verify工具比较最常见答案与原始标准答案。当发现不一致时，他们会咨询o4-mini获得替代答案，如果math_verify确定o4-mini答案和DeepSeek-R1常见答案产生等效结果，就认为原始标准答案可能错误并将其修订。

在合成回答过滤方面，研究团队应用了三种方法来过滤低质量的合成回答：基于困惑度的过滤（使用之前训练的32B模型计算每个模型生成回答的困惑度）、基于N-gram的过滤（丢弃包含连续出现的重复短语的回答）、基于结构的过滤（确保多轮对话的最后一轮是助手回答，并要求每个模型生成的回复都包含完整的思考和回答组件）。

奖励机制的设计也颇为巧妙。对于有客观验证标准的查询（数学、代码、指令遵循），研究团队采用基于规则的验证或代码执行来评估模型回答的正确性。对于数学查询，奖励通过验证模型的最终答案确定，过程是从模型答案内容的最后一个框内容中提取答案，然后使用math_verify工具与参考答案验证。对于代码查询，验证过程在安全的代码沙盒环境中执行，目前支持Python和C++等多种编程语言的评估。

代码验证分为两种形式：方法调用测试用例（要求实现特定方法或函数，测试用例由特定函数名、输入值和对应的预期输出定义）和标准输入输出测试用例（代码从标准输入读取并写入标准输出）。为了确保安全的代码执行和高并发下的稳定性能，研究团队将沙盒部署为利用多台机器的分布式云服务，通过负载均衡和队列管理确保安全隔离和高容量执行的可靠性。

对于缺乏客观验证标准的查询，研究团队采用基于奖励模型的方法。他们使用奖励模型为每个生成的回答提供三个不同的分数，分别衡量有用性、正确性和连贯性，最终奖励分数计算为这三个分数的平均值。

在监督微调阶段，研究团队使用约284万个样本进行训练，涵盖数学、代码、科学、指令遵循和通用对话五大类别。从实例层面看，数学占35.5%，通用对话占38.3%，代码占16.4%，科学占4.3%，指令遵循占5.5%。从token层面看，数学占41.8%，代码占30.9%，通用对话占22.5%，指令遵循占2.6%，科学占2.2%。

有趣的是，研究团队发现在长形式推理任务上进行监督微调会导致模式转换。与传统SFT不同，这个阶段需要更大的学习率和批量大小才能实现稳定收敛，否则模型难以有效拟合数据。传统SFT可能使用约8×10^-6的学习率和约0.5M token的批量大小，而长形式推理的监督微调通常需要高达8×10^-5的学习率和约2M token的批量大小。

强化学习阶段更加精细。研究团队观察到，选择适当难度的训练查询对确保强化学习阶段稳定的性能改进起着关键作用。因此，在RL之前，他们基于SFT模型获得的通过率过滤数学和代码查询，只保留通过率严格在0和1之间的查询，确保训练数据保持足够的挑战性以推动学习，同时避免过于简单或过于困难的实例。

RL流程包含两个阶段。当模型在第一阶段的性能达到平台期时，他们转入第二阶段。在第二阶段，他们移除所有在第一阶段模型100%正确回答的数学和代码查询，并补充15k通用对话和5k指令遵循数据以改善更广泛的泛化能力。

研究团队采用群体相对政策优化（GRPO）作为训练算法。尽管这是近端政策优化（PPO）的简化轻量变体，但他们发现GRPO提供了强大的训练稳定性和有效的性能增益。训练配置包括：移除KL约束以允许更实质性的政策更新；对于在推出过程中超过特定长度阈值的回答，将其优势设为零以防止其影响参数更新；严格的在策略训练，每个训练批次包含256个查询，对每个查询采样16个推出，政策模型在每个探索阶段后只更新一次；两阶段生成和学习率调度，第一阶段限制最大回答长度为24K token并使用相对较高的4×10^-6学习率，第二阶段将最大回答长度增加到32K并将学习率降低到1×10^-6。

技术框架方面，研究团队的训练流程基于verl框架构建，使用GRPO进行强化学习。verl是一个开源RL框架，集成了vLLM、FSDP和MegatronLM，能够在1000+GPU上实现可扩展的RL训练。他们进一步扩展了verl，增加了最适合其训练策略的修改。

在推出速度优化方面，研究团队发现在线样本生成的RL往往受到训练周期长的困扰，每个训练步骤需要几分钟到几十分钟。与SFT或DPO不同，在线GRPO需要在每个步骤中进行政策模型样本生成，增加了每步延迟。这个推出阶段占据了一个训练步骤总时间的70%以上，因此需要优化。

他们识别出两个主要问题：首先，训练是同步的，整个生成批次必须全部完成才能继续下一阶段，必须等待批次中最长的序列完成，造成长尾效应。其次，不同提示和随机样本之间的生成长度差异进一步加剧了推理实例间的负载不均衡。

为了解决这些问题，研究团队采用了两种方法。第一种方法使用静态负载均衡，将一个提示的随机采样分散到多个实例上。通过将重复采样移出推出工作器到训练器中，并增加额外的混洗，放松了同一提示绑定到同一推理实例的约束。这种改变缓解了不均衡负载，解放了拥挤的实例免于运行许多低单序列吞吐量的长序列。

第二种方法是将推出工作器从推理引擎分离，通过知晓实时系统指标的自定义负载均衡器实现动态实例分配。系统现在具有为每个生成样本动态分配推理实例的灵活性。为了实现这一点，他们在推出工作器内的离线vLLM引擎中添加前端服务器，暴露API端点，将所有实例的端点附加到自定义负载均衡器，然后从每个推出工作器调用这个聚合端点。通过实现感知每个实例当前负载和速度指标的负载均衡器，他们可以将拥挤工作器上的长序列重新路由到不那么拥挤的副本。

在评估方面，研究团队在多个具有挑战性的基准上评估模型。AIME2024是一个具有挑战性的数学推理竞赛数据集，包含30个整数答案问题，旨在评估精确的数学推理。AIME2025包含2025年AIME竞赛的30个问题，来自2025年AIME第一部分和第二部分。LiveCodeBench是一个全面的、无污染的编程基准，持续聚合来自LeetCode、AtCoder和Codeforces等平台的新编程挑战。Arena-Hard是一个从Chatbot Arena中的实时数据构建高质量基准的数据流程，其中模型回答通过使用GPT-4-Turbo作为仲裁者的成对比较进行评判。

评估方法保持标准化条件，最大生成长度设为49,152 token。对于需要随机采样的基准，统一采用0.6的温度和0.95的top-p值。具体而言，对于AIME2024和AIME2025，每个查询生成64个回答来计算pass@1精度；对于LiveCodeBench，每个查询生成16个回答来估计pass@1；对于Arena-Hard，每个查询生成一个回答并使用GPT-4 Turbo进行评估。

在提示策略方面，所有评估都使用一致的系统提示来指导模型的回答格式，告诉模型它是一个有用的助手，在回答用户问题时，首先思考推理过程，然后为用户提供答案，推理过程和答案分别包含在和标签内。

实验结果显示，AM-Thinking-v1在多个推理基准上的表现令人印象深刻。在数学任务上，该模型在AIME2024和AIME2025上分别获得85.3和74.4的分数，超越或紧密匹配DeepSeek-R1和Qwen3-235B-A22B等更大模型。在专注于代码推理的LiveCodeBench基准上，AM-Thinking-v1达到70.3的分数，大幅超越DeepSeek-R1（64.3）、Qwen3-32B（65.7）和Nemotron-Ultra-253B（68.1），展现了强大的代码理解和生成能力。在通用对话基准Arena-Hard上，AM-Thinking-v1获得92.5的分数，与OpenAI-o1（92.1）和o3-mini（89.0）等几个专有模型竞争激烈，不过其性能仍落后于Qwen3-235B-A22B（95.6），表明在通用对话能力方面仍有改进空间。

性能与模型大小的关系图表明，AM-Thinking-v1在相似规模的密集模型中实现了最强性能，并接近了更大MoE模型的性能，在效率和性能之间取得了有效平衡。

在训练过程中，研究团队还观察到一些有趣的现象。在SFT的早期阶段，模型倾向于生成过长的输出，停止比率较低。这主要是由于基础模型的预训练语料主要由纯文本组成，以及数据集中的推理示例比标准指令数据长得多。随着训练的进行，平均生成长度持续下降，停止比率稳步上升，表明模型正逐渐学习长形式推理提示中固有的结构和语义模式。

这项研究最重要的贡献在于证明了即使没有大规模MoE架构，32B规模的密集模型也能实现与最佳可用模型相当的推理能力。研究团队希望这项工作能为社区提供实用参考，突出精心的后训练设计如何在保持中等规模模型部署优势的同时弥补性能差距。

然而，研究团队也坦诚地指出了AM-Thinking-v1的局限性。虽然该模型在推理和开放域对话方面表现良好，但它缺乏对结构化函数调用、工具使用和多模态输入的支持，限制了其在基于代理或跨模态场景中的适用性。安全对齐仍然是初步的，需要进一步的红队测试。此外，其在低资源语言和特定领域任务上的性能可能有所不同。

说到底，这项研究为我们展示了一个令人振奋的可能性：通过巧妙的设计和精心的训练，相对较小的模型也能在特定任务上达到甚至超越巨型模型的表现。这就像一个技艺精湛的工匠，用普通的工具也能创造出超越昂贵设备的作品。对于那些资源有限但又希望在推理任务上获得出色性能的研究者和开发者来说，这无疑是一个重要的启示。

归根结底，AM-Thinking-v1证明了在AI发展的道路上，创新的方法往往比单纯的规模扩张更有价值。这项研究不仅为32B规模模型的潜力提供了有力证明，也为整个开源社区指出了一条可行的发展路径。有兴趣的读者可以通过https://huggingface.co/a-m-team/AM-Thinking-v1下载并体验这个模型，亲自感受其在推理任务上的表现。

Q&A

Q1：AM-Thinking-v1是什么？它有什么特别之处？ A：AM-Thinking-v1是贝壳找房开发的32B参数推理优化语言模型。它的特别之处在于用相对较小的规模（320亿参数）实现了媲美甚至超越千亿级大模型的推理能力，在数学竞赛AIME2024上得分85.3，超越了671B的DeepSeek-R1模型。

Q2：这个模型是怎么训练出来的？普通人能用吗？ A：该模型完全基于开源数据和Qwen2.5-32B基础模型训练，采用监督微调加强化学习的两阶段流程。普通人可以通过https://huggingface.co/a-m-team/AM-Thinking-v1免费下载使用，但需要一定的技术背景来部署运行。

Q3：32B模型相比更大的模型有什么优势？ A：32B模型的主要优势是部署简单、资源需求低、微调容易。相比动辄几千亿参数的MoE模型，32B模型可以在普通硬件上运行，维护成本更低，同时在特定推理任务上仍能达到顶级性能，是效率和能力的最佳平衡点。