在AI-IDE开发环境中，代码大模型的应用已相当广泛，尤其是代码补全这类对响应速度要求极高的场景——必须在500毫秒内给出结果。面对如此苛刻的限制，即便是Qwen2.5-Coder、StarCoder等顶尖密集架构开源模型，也难以兼顾效率与效果：若追求极致速度，将模型压缩至7B以下，性能会明显下降；若为了提升效果而增加参数，推理效率又跟不上。效率和效果真的无法兼得吗？

Ling团队给出的答案是：基于Ling-MoE混合专家架构，结合一套由程序分析技术驱动的代码数据治理体系，打造出名为Ling-Coder-Lite的轻量级代码大模型。该模型总参数16.8B，但推理时仅激活2.75B，理论计算量不到同级别密集模型的一半。近日，该模型及其相关技术细节和数据集已在Hugging Face和ModelScope上开源。

此次发布的核心信息可以归纳为以下几点：

• 模型与数据集开源：两款轻量级代码大模型Ling-Coder-Lite和Ling-Coder-Lite-Base已在Hugging Face与ModelScope上开源。同时，用于退火训练的SyntheticQA、用于后训练SFT和DPO的共计约3000万条数据（图1(a)）也一并开放，供社区进一步研究。
• 技术细节公开：随模型发布的还有技术报告，详细介绍了高质量训练代码数据集的构建方法，以及训练中数据分阶段混合配比的策略细节，为行业共同推进代码大模型研究提供了参考。
• 效率与效果双重提升：基于Ling-MoE架构，模型总参数量16.8B，推理时仅激活2.75B，兼顾了更高效率和更优效果。在12个代码基准测试中，其表现与同尺寸最佳模型Qwen2.5-Coder-7B不相上下（12个中7个胜出），领先于OpenCoder-8B和DeepSeek-Coder-V2-lite（图1(b)）；推理效率比Qwen2.5-Coder-7B快1.5倍至2倍（图1(c)），非常适合对低延迟要求高的AI-IDE代码补全场景。实际内部部署中，在相同延迟设定下，相比此前基于密集架构的同类尺寸模型，资源消耗节省了近50%。
• 多语言与多任务支持：支持Python、Java、C++、JavaScript等数十种常用编程语言，在MultiPL-E和MBXP等多语言基准测试中表现优异。除简单代码生成外，还覆盖竞赛类和应用类高级代码生成、代码理解与输入输出推理、数据科学和SQL数据分析、代码修复等多个任务场景。

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

01 模型效果

Base模型

首先看Base模型的表现。在HumanEval、MBPP、EvalPlus及BigCodeBench（Completion分区）上，Ling-Coder-Lite-Base与DeepSeek-Coder-V2-Lite-Base、Qwen2.5-Coder-7B-Base、OpenCoder-8B-Base等相同参数规模的优秀模型进行了对比，结果见表1。各模型各有优势，但Ling-Coder-Lite-Base在整体均值上略胜一筹。

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

在代码理解与推理能力方面，使用CRUXEval评测集，采用CoT模式，结果见表2。Ling-Coder-Lite-Base在输入推理（Crux-I-CoT）、输出推理（Crux-O-CoT）及整体维度上均高于另外两个模型。

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

此外，在数学与NLP能力方面，Ling-Coder-Lite-Base整体与Qwen2.5-Coder-7B-Base基本持平，高于代码加训的起点checkpoint（即Ling-Lite-Base* (7T)）。这表明预训练阶段以代码数据为主体的加训，也同时增强了模型的数学和NLP能力。

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

Instruct模型

对于Instruct模型，评测更加全面，覆盖了12个代码评测集，包括：

• 基础代码生成：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-Instruct不相上下，在12个评测集中有7个表现出优于同类参数模型。

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

这里重点展开多语言代码生成能力，见表5。Ling-Coder-Lite在MultiPL-E HumanEval分区上略低于Qwen2.5-Coder-Instruct（均值低0.58），但在MultiPL-E MBPP、MBXP_EN和MBXP_CN三个分区上均超出其他模型。更多评测细节可参考技术报告。

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

02 技术细节

代码数据

整个训练共构建了1.4T代码数据，包括源代码、代码相关文本以及QA三类数据，如图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份训练数据：约24M条合成代码QA样本（Ling-Coder-SyntheticQA）、5M+ SFT代码样本（Ling-Coder-SFT，覆盖20多种编程语言，涉及代码生成、代码推理、数据分析等），以及250K+ DPO偏好对齐代码样本（Ling-Coder-DPO）。

训练策略

整体训练流程如图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和LR调度策略，代码数据内部不同阶段也使用了不同的源代码、代码相关文本和合成QA数据的配比。

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

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

后训练阶段先做SFT，再做DPO。先用18.8M SFT样本训练5个epoch（其中约11M+为代码SFT样本，其余为数学和自然语言SFT样本）；然后在表现最好的checkpoint上用1.4M偏好对齐样本（含代码、数学、指令遵循等）训练2个epoch，得到最终模型。更多细节可查看技术报告。

推理效率

基于Ling-MoE架构，Ling-Coder-Lite全量参数16.8B，单次推理仅激活2.75B，理论上浮点运算量不足Qwen2.5-Coder-7B-Instruct的一半。图5展示了各模型在12个代码评测集上的平均得分与单次推理所需运算量（TFLOPs）的关系，Ling-Coder-Lite在能力与效率的平衡上明显优于其他模型。

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

实际部署测试结果（图6）也印证了这一点。在tp=1配置下，Ling-Coder-Lite的速度比Qwen2.5-Coder-7B-Instruct快1.5到2倍，且序列越长优势越明显。

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

总结一下：虽然代码能力与Qwen2.5-Coder-7B-Instruct不相上下，但推理效率更高，这正是对延迟敏感的AI-IDE代码补全场景最需要的。实际内部替换也验证了这一点——同样延迟要求下，部署资源节省了近50%。

03 关键经验和教训

训练过程中积累了不少经验，也踩过一些坑，现分享给社区：

• 在相同效果下，MoE架构比密集架构推理效率更高，是对推理效率和低延迟有强需求场景的首选。
• 数据质量至关重要，必须建立完善的数据治理流程，提高准入门槛。
• 消融实验表明，通过模型打分、注释率和语法检查筛选出的高质量源代码数据，即使在代码加训多个阶段后仍然能带来平均结果的提升。而有些数据初期有用，但训练一次后很快饱和甚至带来负面影响，因此不同阶段（尤其是退火阶段）需要重新验证数据准入。
• 网页、GitHub Markdown、Jupyter Notebook等代码相关文档数据，是源代码数据的重要补充，对text2code尤其是复杂代码问题的理解和生成效果明显。
• 结构化问答数据（如Stack Overflow问答、开源模型合成的QA数据）直接与问题相关，多样性也好，放在退火阶段比较合适。
• 代码加训采用多阶段不同数据比例调整，比维持同一比例更有效（见表6）。从stage1到退火阶段，代码和数学、NLP数据的比例在变化。反直觉的是，代码占比是逐渐降低的：一开始重点学习代码续写补全，需要高源代码比例；后面为了提升复杂代码问题理解，需要增加NLP数据、代码QA和代码相关文档数据。实际配比中，代码类整体占比从70%降到60%，而代码细分类中，合成QA数据占比从1%提升到50%，纯代码数据从94%降到40%。
• 合成数据方面：（1）根据输入和代码预测输出、根据输出和问题预测输入这类推理数据，对代码理解和正确性很重要，可以大量合成；（2）不同benchmark问题格式差异大，指令跟随的丰富性和要求很高，合成一批复杂指令跟随数据对结果提升很明显；（3）CoT类数据质量参差不齐，要加强结构化控制和质量筛选，这部分目前做得还不够。
• 后训练数据合成筛选同样重要。SFT数据通过打分筛选后效果更好；DPO的筛选更为关键——如果不筛选，虽然在安全和可读性上有提升，但对benchmark得分有负面影响。实际中使用代码专用的reward model做筛选后才消除了这一问题。
• 后训练和退火目前业界有两种主流做法：一是用较少的后训练数据（几万条）激活格式指令遵循，把大量高质量QA放到退火阶段；二是用非常多的后训练数据（几百万上千万条）同时提升能力和激活格式遵循。实践中发现，对于同样一份有限的后训练数据，大模型（一般超过30B）和小模型在格式指令遵循提升上的幅度差异很大——大模型能带来较大提升，小模型提升很有限。考虑到我们的模型相对较小（16.8B激活参数2.8B），因此采用了后一种策略，用更多的后训练数据来激活能力。
• 类O1/R1的推理在代码场景分两大类型：竞赛类（如LiveCodeBench，侧重Agentless Reasoning）和软件工程类（如SWE-Bench，侧重Agentic Reasoning）。对基座模型的要求有所不同，做好一个不意味着一定能做好另一个，如何兼顾两者是后续研究的重点。