兼顾推理效率和代码效果的Ling-Coder-Lite解读

代码大模型在类似 Cursor 等 AI-IDE 环境有着广泛的应用基础。在诸如代码补全这类需要极致响应（不超过 500ms 响应时间）的场景中，最先进的开源模型如 Qwen2.5-Coder、StarCoder、OpenCoder 等密集架构（dense）模型面对着效率和效果更好平衡的挑战。如果为了极致效率，把模型大小推进到比如 7B 以下的尺寸，效果就会大打折扣，反之亦然。

为此，我们采用 Ling-MoE 混合专家架构提升计算效率，结合基于程序分析技术的代码数据治理体系，探索代码大模型在效率与效果之间的更优平衡。基于上述技术理念，CodeFuse & Ling 团队开发并且开源 Ling-Coder-Lite 代码大模型。

本次发布关键总结如下：

• 模型和数据集开源：2 个轻量级代码大模型 Ling-Coder-Lite 和 Ling-Coder-Lite-Base 已在 Hugging Face 与 ModelScope 开源 。同时，开源了用于退火训练的 SyntheticQA、用于后训练 SFT（Supervised Fine-tuning）和 DPO（Direct Preference Optimization）共计约 3000 万条数据（图 1(a)），支持社区进一步研究和开发。

• 技术细节公开：本次开源同步发布技术报告，公开更多关于高质量训练代码数据集构建方法，以及训练中数据分阶段混合配比策略的细节，助力行业共同推进代码大模型研究。

• 效率与效果平衡升级：基于 Ling-MoE 架构，Ling-Coder-Lite 总参数量为 16.8B，推理时激活参数仅为 2.75B ，同时兼顾了更高效率和更好效果。在 12 个代码基准测试中，Ling-Coder 的表现和类似尺寸最佳模型（Qwen2.5-Coder-7B）不相上下（12 个中 7 个胜出），领先于 OpenCoder-8B 和 DeepSeek-Coder-V2-lite，具体参见图 1(b)； 推理效率比 Qwen2.5-Coder-7B 快 1.5X~2X（图 1(c)），特别适合需要低延迟响应的场景，如 AI-IDE 中的代码补全。实际内部使用中，Ling-Coder-Lite 在相同延迟设定下，比此前基于 dense 架构的类似尺寸模型节省一半部署资源。

• 多语言和多任务支持：Ling-Coder-Lite 支持 Python、Java、C++、JavaScript 等数十种常用编程语言，在 MultiPL-E 和 MBXP 等多语言基准测试中表现优秀；除简单的和多语言的代码生成之外，还支持竞赛类和应用类高级代码生成、代码理解和输入输出推理、数据科学和 SQL 类数据分析、代码修复等多个任务场景。

图 1: Ling-Coder-Lite 开源数据、模型代码能力及理论推理效率

首先，我们评估了 Ling-Coder-Lite-Base 在 HumanEval、MBPP、EvalPlus 及 BigCodeBench（Completion 分区）上的代码生成能力，并与 DeepSeek-Coder-V2-Lite-Base、Qwen2.5-Coder-7B-Base、OpenCoder-8B-Base 等表现优秀的相似参数规模的代码大模型进行了比较，结果如表 1 所示。各个模型各有所长，Ling-Coder-Lite-Base 在整体均值上略高于其他模型。

表 1: 各 Base 模型在 HumanEval、MBPP 和 BigCodeBench 上的代码生成能力

其次，我们使用 CRUXEval 评测集评估了 Ling-Coder-Lite-Base 的代码理解与推理能力，采用 CoT 评测模式，结果如表 2 所示。Ling-Coder-Lite-Base 在输入推理（Crux-I-CoT）、输出推理（Crux-O-CoT）及整体维度均高于另外 2 个模型。

表 2: Base 模型在 CRUXEval（贪婪模式）上的代码理解与推理能力

此外，我们也评估了 Ling-Coder-Lite-Base 的数学与 NLP 能力，结果如表 3 所示。Ling-Coder-Lite-Base 整体与 Qwen2.5-Coder-7B-Base 基本持平，高于代码加训的起点 checkpoint（即 Ling-Lite-Base* (7T)），证明模型在预训练代码数据为主体的加训阶段也增强了模型的数学和 NLP 能力。

表 3: Base 模型在数学和部分 NLP 评测集上的表现

对于 Instruct 模型，我们使用 12 个代码评测集更全面地评测 Ling-Coder-Lite 模型的代码能力，包括：

• 基础代码生成能力：HumanEval、MBPP 与 EvalPlus；

• 高阶代码生成能力：LiveCodeBench（2024.08-2024.11 区间）和 BigCodeBench（Instruct 分区）；

• 多语言代码生成能力：MultiPL-E HumanEval（10 种语言）、MultiPL-E MBPP（10 种语言）、MBXP_EN（6 种语言，筛选 100 道题）及其中文语言版本 MBXP_CN；

• 代码理解与推理能力：CruxEval；

• 代码修复能力：HumanEvalFix；

• 基础数据分析应用能力：DS-1000 和 Spider

性能结果如图 1 (b)和表 4 所示，Ling-Coder-Lite 的整体表现与 Qwen2.5-Coder-7B-Instuct 不相上下，在单个评测集上有 7/12 个表现出优于类似参数模型。

表 4：各模型在各个代码评测集上的表现

本文仅展开介绍 Ling-Coder-Lite 在多语言代码生成能力上的表现，如表 5 所示。Ling-Coder-Lite 在MultiPL-E HumanEval 分区上的表现不如 Qwen2.5-Coder-Instruct 模型（均值低 0.58），在另外 3 个分区 MultiPL-E MBPP、MBXP_EN 和 MBXP_CN 上的表现均超出其他模型。更多评测细节可以参考技术报告。

表 5: 各模型在多语言代码生成评测集 MultiPL-E 和 MBXP 上的表现

我们共构建了 1.4T 代码数据，包括源代码、代码相关文本以及 QA（Question-Answer）三类数据，如图 2 所示：

• 源代码数据：共计 1.1T，包括 836B 文件级代码数据、182B 二次筛选的高质量代码数据和 132B 仓库级拼接代码数据。

• 代码相关文本数据：共计 119B，包括 Common Crawl 召回的代码相关网页数据、Code-Comment Pair 数据、Github Pull Request 数据、notebook 数据以及 Markdown 数据等。

• QA 数据：共计约 177B，包括通过 Magpie + 开源模型方法合成的 QA 数据（超过 1 亿条样本），以及借助类似 Evol-Instruct 与 OSS-Instruct 的方法合成的 SFT 数据中低质量的部分。

更多关于构建子类型数据的构建方法请参考技术报告。

图 2: Ling-Code-Lite-Base 预训练代码数据组成

每份代码数据都遵循严格代码准入流程，包括数据采集、数据结构化变换（包括召回）、数据清洗（包括规则清洗、去重、去毒等）、质检（包括规则质检、模型自动质检及人工抽检）、消融实验，如图 3 所示。仅当数据满足质检标准且消融实验证实对提升代码综合指标有帮助时，一份数据集才会被准许加入到训练集中，以此实现对数据质量的严格把控。

图 3: 预训练代码数据准入流程

为助力社区研究，此次开源 3 份 Ling-Coder-Lite 训练数据，包括约 24M 条合成代码 QA 样本（Ling-Coder-SyntheticQA)、5M+ SFT 代码样本（Ling-Coder-SFT，覆盖 20 多种编程语言，涉及代码生成、代码推理、数据分析等不同主题），以及 250K+ DPO 偏好对齐代码样本（Ling-Coder-DPO）。

Ling-Coder-Lite 整体训练流程如图 4 所示。在预训练阶段，我们从 Ling-Lite 的一个中间检查点（7T token 训练量，标记为 Ling-Lite-Base*）加训 3.2T Token（Next-Token-Prediction 和 Fill-In-Middle），获得 Ling-Coder-Lite-Base，随后在此基础上进行 SFT 和 DPO 后训练获得 Ling-Coder-Lite 模型，显著提升了模型在代码相关任务中的实用性和可靠性。

预训练加训共包含 3 个小阶段（阶段 1、阶段 2 和退火阶段），如表 6 所示。预训练加训每个小阶段设置了不同的代码、数学和自然语言数据配比、LR（Learning Rate）和 LR 调度策略，在代码数据内部不同阶段也使用了不同的源代码、代码相关文本和合成 QA 数据的配比。

图 4: Ling-Coder-Lite 3 阶段预训练加训及后训练阶段流程示意

表 6: 预训练加训各阶段关键超参数配置

在后训练阶段，先进行 SFT 训练，后进行 DPO 训练，以进一步使 Ling-Coder-Lite 输出与人类偏好对齐。首先使用 18.8M SFT 样本训练 5 个 epoch，其中包含约 11M+ 代码 SFT 样本，其余为数学和自然语言 SFT 样本；在完成 SFT 训练后，在其基础上选取表现最好的一个 checkpoint 并继续用 1.4M 偏好对齐样本（含代码、数学、指令遵循等数据）训练 2 个 epoch，从而获得更符合人类偏好的最终模型，即 Ling-Coder-Lite。更多细节请参考技术报告。

基于 Ling-MoE 架构，Ling-Coder-Lite 模型全量参数有 16.8B，但单次推理仅激活 2.75B，理论上推理一次的浮点运算量不足 Qwen2.5-Coder-7B-Instruct (dense) 模型的一半。我们统计了各模型在 12 个代码评测集上的平均得分与理论上单次推理所需运算量（TFLOPs）的关系，如下图 5 所示，Ling-Coder-Lite 比其他模型更好地平衡了模型代码能力与推理效率的关系。

图 5： 各模型在性能平均得分与 TFLOPs（4096 长度）之间的对比分析

此外，我们也实际部署测试了 Ling-Coder-Lite 与 Qwen2.5-Coder-7B-Instruct 在接收不同输入输出长度及不同 TP 时的推理耗时差异，如图 6 所示。Ling-Coder-Lite 在推理效率方面显著优于 Qwen2.5-Coder-7B-Instruct。在 tp=1 的配置下，Ling-Coder-Lite 的表现速度比 Qwen2.5-Coder-7B-Instruct 快 1.5 到 2 倍，并且这种优势在序列长度增加时更为明显。

图 6： Ling-Coder-Lite 与 Qwen2.5-Coder-7B-Instruct 推理延迟对比

综上，尽管 Ling-Coder-Lite 与 Qwen2.5-Coder-7B-Instruct 在代码能力上表现不相上下，但 Ling-Coder-Lite 具备更高的推理效率，因此更适合时延要求高的业务场景，例如 AI-IDE 代码补全场景。实际内部部署替换此前的 dense 模型也验证了这一点，同样延迟要求下，Ling-Coder-Lite 部署的资源需求节省了近 50%。

在训练 Ling-Coder-Lite 过程中，踩了很多坑，有一些经验和教训和社区分享如下：

• 同样的效果下， MoE 架构可比 dense 架构提供更高的推理效率，是对推理效率和低延迟强需求场景的首选。

• 数据质量对于效果非常重要，为了确保数据质量需要建立完善和完整的数据治理流程，提高数据准入门槛。

• 消融实验表明，通过模型打分、注释率和语法检查等手段筛选出来的高质量的源代码数据，即便经过代码加训多个阶段几个 epoch 的训练，依然能够带来平均结果的提升。一些其他数据再初期可以准入，但是训练了一次之后很快结果就会饱和甚至带来负面影响，这样就要求代码加训的不同阶段尤其是退火阶段需要重新对数据做消融准入的验证。

• 网页、GitHub Markdown、Jupyter Notebook 等召回的代码相关文档数据，是对源代码数据的重要补充，对于提升 text2code，特别是复杂代码问题理解和生成作用明显。

• 结构化问答数据，比如 Stack Overflow 的问答数据、以及开源模型合成的 QA 数据，直接跟问题有关，同时可以构建的非常多样化，对于最终效果也比较重要。因为量比较大，放在退火阶段比较合适。

• 代码加训，实践表明多阶段不同数据混合比例调整，比维持一个阶段同一比例要有效（表 6）；从 stage1、stage2 到 Annealing stage，代码和数学、NLP 数据的比例在变化。反直觉的是，实践显示代码的占比是逐渐降低的。这主要是因为，我们一开始重点学习代码续写补全能力，需要有比较高的源代码数据比例；后面为了提升复杂代码问题的理解能力，需要增加 NLP 数据、以及代码 QA 和代码相关文档数据的占比。所以实际中配比设计是，代码类整体占比从 70%逐渐降低到 60%，而代码细分类别中，合成 QA 数据占比从 1% 提升到 50%，纯代码数据从 94%最后降低到了 40%。

• 在合成数据方面有几点经验：（1）根据输入和代码预测程序输出，和根据程序输出和问题预测输入参数，这类代码输入输出推理的数据对于提高代码理解和正确性非常重要，可以大量合成；（2）各种不同 benchmark 问题和答案格式的设计差异较大，实际业务中也有类似问题，这导致问题和答案的指令跟随有丰富的多样性且要求非常高，设计和合成一批复杂指令跟随对于结果提升非常有效；（3）CoT 类数据合成，质量差异较大，合成内容要加强结构化控制，然后质量上要加强筛选，目前这部分做的还不够。

• 后训练数据合成筛选也很重要，SFT 类数据通过打分筛选后，可以提高最终结果；DPO 的筛选更加 critical，如果不筛选，对安全和可读性有提高，但是对于 benchmark 得分有一定负面影响，实际中采用代码专用的 reward model 做了筛选才消除了这部分影响。

• 后训练和退火目前业界有两种主流做法，一个是较少的（比如几万条）后训练去激活格式指令遵循，大量高质量 QA 放到退火阶段；另外一个是使用非常多的（几百万甚至上千万条）后训练数据去同时提高能力和激活格式遵循。实践发现，对于同样一份有限的后训练数据，大模型（一般超过 30B）和小模型对于格式指令遵循的提升幅值差异很大，大模型可以带来较大提升，小模型提升很有限，业界也有大量论文指出了类似的观点。因为我们的模型相对较小（16.8B 激活参数 2.8B），因此我们采用了后者，使用更多的后训练数据去激活能力。

• 类似 O1/R1 的 Reasoning，在代码场景有两大类型，一是竞赛类如 LiveCodeBench 侧重 Agentless Reasoning，另外一种是软件工程 SWE-Bench 侧重 Agentic Reasoning ，对于基座模型的要求有一定差异，做的好其中一个并不一定做的好另外一个，如何兼顾两者是后续努力的重点。