
知乎:Xode
链接:https://zhuanlan.zhihu.com/p/721189499
0. 前文
1. 模型架构
2. Tokenizer
3. 预训练
3.1 数据
3.2 训练
4. Post-Training
4.1 数据
4.2 训练
5. 去除数据集污染
6. 评估
7. 总结
[!tip]
这不是技术报告的翻译,全文人工撰写
这只是个人的解读,如果有问题欢迎探讨
笔者能力有限,全文可能难以深入到特别细节的理论研究,也不会有什么公式推导
全篇会尽量按照报告的行文顺序来写解读,但中间可能会有些许变化,也不一定会提到报告中每个地方
0. 前文
这一篇 Coder 的技术报告风格不同于 Math,整体样式都不太一样:Math 的样式模板和 Qwen Technical Report、Qwen2 Technical Report 保持一致、作者名也都是按照字典序排序的,可以说是更加“正统”;Coder 的样式模板和 DeepSeek 的样式非常类似,有区分一作,并且通讯也只有 Junyang Lin 大佬一个人(只有 2.5 的两篇开始出现了通讯)。
此外,和 Math 模型类似,Code 模型的名称也出现了变动。最开始的一代(只出现在技术报告中、没开源)和 1.5 代的时候,代码模型都叫做 Code-Qwen,但到了 2.5 代就改名成了 Qwen2.5-Coder,这样做更加强调了 Math 和 Code 这类专有模型都同属于 Qwen Series。不过不同于 Math-Qwen 改名为 Qwen-Math,Code-Qwen 变成了 "Coder",据他们的说法是更加契合于 1.5 时提及的"结对编程"场景。
这次的模型开源了 1.5B、7B 和 32B(coming soon)三个尺寸,没有 Qwen 正统和 Math 模型的最大号 72B。但我个人的感觉是,Code 这样的模型在进化的过程中要么逐渐变小、便于专有化部署和高频使用;要么逐渐把能力整合入主力模型,例如 GPT、Claude 和最近的 DeepSeek,所以我觉得专门的一个更大的代码模型也确实没必要。
1. 模型架构
既然都强化了 Qwen2.5 Series 的概念,Qwen2.5-Coder 自然在模型架构上不会有什么分别。报告中只提了 1.5B 和 7B 的架构,但按理来说 32B 的模型架构应该也不会和 Qwen2.5-32B 有区别。不过 Qwen2.5-32B 和 Qwen1.5-32B 不完全一样,中间 FFN 的升维维度从 256 * 107 变成了 256 * 108、也就是向 1024 对齐取整了,不太清楚这里面具体的考量。
这里值得一提的是,Qwen 从 2 代开始加深小模型的深度、削减宽度,并且增大 FFN 升维的维度,这大概也是现在的一个 LLM 主流认识:同样参数下,窄而深的模型会比宽而浅的更好;增大 FFN 维度可以增强表征能力。例如以往 FFN 维度都是 4 倍(对于 LLaMA 这样的 GLU 来说,同参数规模要乘以 2/3,也就是 8/3 倍),但 Qwen 现在都是差不多 16/3 倍,抛开为了 128 或者 256 对齐,0.5B 的模型大概是 16/3 倍、1.5B 大概是 6 倍、7B 大概是 17/3 倍,就连 32B 也是 16/3 倍,只有最大号的 72B 大约是 11/3 倍。具体的数字应该是内部有不同的消融测试才定下来的,但整体趋势是比最开始的 LLaMA2 FFN 升维更高。
2. Tokenizer
tokenizer 也和 2 代开始的保持一致,只是 Qwen2.5-Coder 开始为了 FIM(fill-in-the-middle,根据上下文补全代码)任务引入了一些特殊 token,如下:
印象中没记错的话,这些 special tokens 和常用的 FIM 保持一致,没有特别的自定义。
也顺便提一下 FIM 大概是什么任务,其实和字面义显示的一样,就是用于代码补全,给定上下文代码填中间的空:
<< 上文代码 >>
{
{ 中间需要补全的部分 }}
<< 下文代码 >>
由于生成模型只能看到前文,没有双向的注意力,因此我们会把下文放到前面,类似于:
<< 上文代码 >>
<< 下文代码 >>
{
{ 告知模型,开始生成中间需要补全的部分 }}
具体还会有别的设计,我们后文展开讲。例如这里的 <|repo_name|> 和 <|file_sep|> 就是为了 repo 级别的代码补全而定义的。
3. 预训练
3.1 数据
数据组成
来源:主要是 Github,总共

最低0.47元/天 解锁文章
1657






