1. 五路数据源#

训练语料统称 Qwen2.5-Coder-Data，总共约 5.5T tokens，分五类：

这里有个细节很见功力：通用文本里特意把代码片段移除，避免跟源代码语料重复计数；数学数据则是整个 Qwen2.5-Math 的语料库直接并入。这就是”代码模型不变成偏科生”的关键操作。

2. 过滤和配比：脏活出真功夫#

数据清洗走的是”粗到细”路线：规则过滤打底，再用小模型分类器/打分器（比如 fastText）做分层过滤。报告里给了一个很实在的数字：光是对文本-代码数据做四级过滤，Qwen2.5-Coder-1.5B 的 HumanEval+MBPP 平均分就从 41.6% 提到 46.8%——五个多点，全靠洗数据洗出来的，一分钱模型结构没改。

合成数据这块也值得说：用上一代 CodeQwen1.5 生成代码，然后真的拿去执行，跑不通的直接扔掉。“用执行器验证”这五个字，是合成代码数据和”纯 LLM 编出来的代码”的分水岭。

最后是数据配比实验，比较了 Code/Text/Math 不同比例，定下来 70% 代码、20% 文本、10% 数学，最终训练集约 5.2T token（六个模型的总训练量标 5.5T）。这个配比透露了一个判断：代码模型想不偏科，三成非代码数据是下限。

1. 文件级预训练：next-token + FIM 双目标#

第一阶段最大序列长度 8,192，吃下约 5.2T 数据。训练目标有两个：常规的下一 token 预测，加上 FIM（Fill-in-the-Middle，中间填充）。

FIM 是什么？简单说就是把一个文件切成三段：前缀、后缀、中间待填的部分，训练时打乱顺序让模型”看着前后文补中间”。这就是 IDE 里代码补全的真实场景——你的光标永远在文件中间，没人只从第一行往下写。模型为此专门留了四个特殊 token（FIM prefix/middle/suffix/pad，ID 151659-151662）。

2. 仓库级预训练：8K → 32K → 128K#

第二阶段把上下文从 8,192 拉到 32,768，用约 300B 长上下文代码数据继续训。RoPE 基频从 10,000 调到 1,000,000，再叠上 YARN（Yet Another RoPE extensioN）外推，推理时能撑到 131,072 token，也就是 128K。

这一步配套了两个设计：

• 仓库级 FIM（repo-level FIM）：待补全的洞不再只在单个文件里，而是跨文件、跨整个仓库。模型要学会从别的文件里找线索来补当前文件。
• 特殊 token 里那个”仓库名”和”文件分隔符”就是为这个阶段准备的，用来把多个文件打包成一个训练序列。

报告里做了个朴素但硬核的验证：往长代码库里插入一个自定义函数，看模型能不能在 128K 范围内把它检索/复述出来。能。这说明 128K 不是纸面数字。

3. 后训练：粗到细 SFT + 拒绝采样 + DPO#

指令微调走”粗到细（coarse-to-fine）“路线：先喂数千万条低质量但多样的指令样本铺广度，再用数百万条高质量样本提精度。数据生产上有几个亮点：

• 用 CodeBERT 微调出编程语言识别器，覆盖近 100 种语言，先把指令数据按语言分桶；
• 从 GitHub 代码片段反向合成指令：LLM 出题、代码模型作答、再用 LLM 打分过滤，打分用一套 checklist（问答一致性、代码正确性、代码规范、注释质量……）；
• 用 tree-sitter 解析代码 AST，随机抽逻辑块当”待填中间”，造出 FIM 格式的指令样本——也就是说 SFT 阶段也没丢补全能力，大部分标准 SFT 数据加少量 FIM 指令数据混训（mixed tuning）；
• 最后上 DPO（直接偏好优化）：同一个 query 生成多个候选，能跑的代码用多语言沙箱执行验证，跑不动的复杂代码用 LLM-as-a-judge 打分。

去污染也做了：对预训练和后训练数据做 10-gram 重叠过滤，把 HumanEval、MBPP、GSM8K、MATH 这些测试集都剔掉。敢公开说做了去污染的代码报告，可信度高一截。

1. Base 模型：同尺寸全面碾压#

先看 Base 模型在 HumanEval/MBPP 上的表现：

对比很直白：32B-Base 对 DeepSeek-Coder-33B-Base，HumanEval 高出 11 个点（65.9 vs 54.9）；对 StarCoder2-15B，高出快 20 个点。7B 对自家前代 CodeQwen1.5，HumanEval 从 51.8 拉到 61.6，一代涨 10 个点，这就是 5.5T 数据堆出来的效果。

2. Instruct 模型：贴着 GPT-4o 打#

Instruct 版本才是真正的战场：

划重点：

• HumanEval 92.7，全场最高，比 GPT-4o 还高 0.6；MBPP 90.2，同样压过 GPT-4o 的 86.8；
• BigCodeBench Hard 27.0，开源第一，这个基准考的是工具调用和复杂指令跟随，接近真实 Agent 场景；
• 最狠的是跟 CodeLlama 的对比：CodeLlama-70B-Instruct 参数量是 Qwen2.5-Coder-32B 的两倍多，HumanEval 却只有 72.0，差出 20 个点。这就是”一代数据红利”的直观体现——CodeLlama 是 2023 年的产物，吃的还是 1T 量级的代码数据。

3B-Instruct 也值得单拎出来：HumanEval 84.1，比 StarCoder2-15B-Instruct（67.7）高 16 个点，参数量却只有五分之一。小模型做到这个份上，本地部署的门槛已经低到没什么借口了。

还有一个容易被忽略的数字：32B-Instruct 的 HumanEval+（更严格的测试用例版本）拿到 87.2，跟 GPT-4o、Claude-3.5-Sonnet 完全并列。HumanEval+ 的题面没变但用例更刁钻，专门抓”侥幸过测”的代码，能在上面拿 87+ 说明生成的代码不是背题库背出来的，是真的理解了边界条件。

1. 代码编辑：Aider 基准#

Aider 是模拟真实 IDE 里”给需求、改现有代码”的基准，测的是编辑能力而非从零生成：

32B-Instruct 的 Pass@1 60.9，开源第一，甚至超过 GPT-4o 的 56.8；只有 Claude-3.5-Sonnet 明显领先。CodeLlama-70B 在这里只有 12.8，再次证明老一代模型在”改代码”上基本不可用。CodeEditorBench 上 32B-Instruct 跟 DeepSeek-Coder-V2 打平（86.2% win rate 附近）。

2. Agent 与工具使用#

报告没有单独开 Agent 章节，但三块内容都在给 Agent 铺路：BigCodeBench 考工具调用（32B 开源第一）；仓库级 FIM + 128K 上下文是”读懂整个项目再动手”的前提；IFEval 79.9 保证指令跟随不掉链子。报告自己就把应用场景点名到了”代码助手和 Artifacts”。换句话说，32B-Instruct 就是奔着当 Coding Agent 底座去的——后来它在 SWE-bench 这类真实 issue 修复基准上的表现也印证了这条路线。

3. 代码推理：CRUXEval#

CRUXEval 考的是”读代码推执行结果”，32B-Instruct 拿 Input-CoT 75.2 / Output-CoT 83.4，开源第一；但 GPT-4o（78.6/89.2）和 o1-mini（91.6/96.2）还是拉开了身位。这是报告里少数”没打赢”的地方，也说明纯推理这条线上，靠堆数据是有天花板的。

模型与训练一览#

旗舰模型关键战绩（32B-Instruct）#

概念清单#

• FIM（Fill-in-the-Middle，中间填充）：把文件切成前缀/后缀/待填中段，训练模型看前后文补中间，是 IDE 补全能力的来源。
• Repo-level FIM（仓库级中间填充）：待填的洞跨文件、跨仓库，逼模型学会从项目全局找上下文。
• YARN：RoPE 外推技术，配合调高的基频把上下文从 32K 拉到 128K。
• GQA（Grouped Query Attention，分组查询注意力）：继承自 Qwen2.5 的注意力结构，省显存、提推理速度。
• Coarse-to-fine SFT（粗到细微调）：先用数千万条多样但粗糙的指令铺广度，再用数百万条高质量样本提精度。
• DPO（Direct Preference Optimization，直接偏好优化）：离线偏好对齐；代码用多语言沙箱执行验证，复杂样本用 LLM-as-a-judge。
• MultiPL-E：多语言代码生成基准，覆盖 Python/C++/Java/JS/TS 等主流语言。
• BigCodeBench：考工具调用与复杂指令跟随的基准，接近 Agent 实战。
• LiveCodeBench：滚动更新的竞赛题基准，防数据污染，考真实泛化。
• CRUXEval：代码执行推理基准，给代码推输入/输出。
• Aider：模拟”在现有代码库上按需求编辑”的基准，测改代码而非写代码。
• McEval / MdEval：大规模多语言基准（40 种语言 16,000 用例）与 18 语言调试基准（1.2K 样本）。