Show HN: Fly Language Model这个标题在技术社区里其实已经算是一个相当清晰的信号——作者是真把东西做出来了而不是又放一个包装精美的PPT。最近这半年关于从零开始构建大语言模型的讨论热度一直很高前阵子还有人传《Build a Large Language Model from Scratch》的PDF资源再加上RegMix那类数据混合配比的论文开始被频繁引用实际动手训练一个自己模型的门槛确实在肉眼可见地降低。我自己的Fly项目就是从这两种情绪里长出来的一方面想验证从零训练这条路到底有多长另一方面想用一个小规模的模型把预训练技术栈完整跑通一遍。严格来说Fly不是一个追求刷榜的模型参数规模堆到今天只能算玩具级别但整个项目踩过的坑、总结出的经验在工程上和教学上的价值远高于它本身的指标。这篇文章想把Fly从立项到跑通全过程的关键决策和实际数据做个复盘给同样想动手训练一个属于自己模型的人一份参照。1. Fly的项目定义1B参数到底能做什么Fly这个名字是随手起的没有太多玄学含义。我给它定义的核心气质就一个字——快。训练要快迭代要快推理也得快快到你不需要专门的推理服务器就能在家里跑起来。很多人在做自己的模型时容易陷入一个误区既然算力有限那就把参数压到最小结果模型训练完成之后除了能生成一些语无伦次的句子什么都干不了。Fly的定位从一开始就得说清楚这不是一个面向通用场景的助手而是一个验证语言模型训练技术路径的实验平台顺便能在若干个特定任务上达到可用水平。1.1 为什么选1B这个规模这个规模的决策受制于两个因素显卡数量和训练时间成本。我当时手上能稳定占用的是4张A100 40G偶尔能挤到8张。如果参考业界比较公认的Chinchilla法则来算1B参数的模型对应的数据量应该在20B到30B token左右在4卡环境下跑这个量级的训练大概需要十几天到二十天的连续时间这个窗口完全在可接受范围内。1B这个体量还有一个很实际的好处模型可以直接fp16推理不需要量化不需要蒸馏不需要vLLM那套复杂优化。在单张3090或者4090上就能跑得动token生成速度在推理框架加持下足够应付demo和交互。这对于一个想持续迭代、频繁调整数据的项目来说是巨大的效率优势。另外从工程角度说1B模型的显存占用大概在2GB到3GB左右你有大量的空间去塞长上下文、批量推理和beam search。而如果换成7B模型单卡推理就要瞬间逼近显存红线很多实验你就没法做了。1.2 目标能力不追求全知全能但求把基础打牢我给Fly划了一个能力边界覆盖四个方向上手先跑跑通再谈优化。这个顺序在语言模型项目里极其重要因为训练一次的时间成本很高你不能指望所有问题都在第一次大规模训练时就发现最好的策略就是用最短时间把整条流水线从数据到模型到推理打通然后再回来反复打磨每个环节。2. 数据底座语料混合不是玄学是可以回归的问题如果说架构决定模型的天花板那数据决定模型能不能够到这块天花板。Fly在技术选型上没太多纠结如今的Transformer架构和训练框架已经高度标准化真正花掉我最多精力的环节就是数据。模型训练的数据问题本质上是个食谱问题。你把不同来源、不同语言、不同质量的语料按一定比例混在一起放进训练流程最后模型的语言能力和知识结构完全取决于这份食谱的好坏。Fly的数据处理流程几乎是我翻遍所有开源数据集之后拼出来的中间踩了不少坑。2.1 语料来源与过滤管线Fly的初始语料主要由五部分构成每一份原始数据进来之后都需要经过一套统一的清洗流水线。我在实践中验证过一个结论清洗数据的优先级远高于增加数据量。脏数据喂进去不仅浪费算力还会反向教坏模型。我的过滤规则按顺序执行这个流程走完之后最终的有效数据量大约占原始语料的三成到四成。你可能会觉得这个损耗太大但我做过对照组实验用未过滤的语料训出来的模型生成质量明显偏差尤其是会频繁出现乱序标点、无意义重复片段等问题这种问题在模型参数上去之后几乎无法通过后处理纠正。2.2 RegMix思路把数据配比变成回归问题早期做数据混合基本都是拍脑袋去看别人开源模型用的什么配比就照着抄。Fly真正开始系统化解决这个问题是在读到RegMix论文之后——它把数据配比选择定义为一个回归问题用一个小模型去预测不同数据比例在目标任务上的效果从而避免对完整训练的大规模探索。RegMix的核心逻辑可以理解为在采样配比和模型性能之间存在一种可学习的映射关系。你不需要每个配比都完整训练一个大模型只需要用一系列小规模实验获得性能指标然后训练一个回归模型去预测任意配比下模型会有什么表现最后在回归模型上搜索最优配比。我在Fly项目里验证了这套思路的可行性。具体操作是这样选定代码、维基百科、通用文本、数学、书籍作为五个语料类别在总数占比固定的前提下生成了一批不同的混合比例每个比例用200M参数的小模型、跑5B token来评估。最后把配比作为输入特征、四个下游benchmark的平均分数作为输出训练了一个简单的随机森林回归模型用来搜索更优的配比空间。这个方法的性价比极高。原本完整搜索需要每个配比都花几十天现在一次小规模实验可能只要环境正常两天以内就能完成。而且回归模型的预测精度在小规模到中等规模的迁移上比较可靠至少它能告诉你搜索的方向而不是让你在黑暗中瞎撞。2.3 Fly实际采用的数据配比通过RegMix思路做了一些实验之后我最终敲定的Fly训练数据配比如下这是全套训练数据的配比。但模型不是从头到尾都用这一套配比实际训练过程里我还做了一处调整在最后大约10%的训练进度时把中文百科和书籍的比例上调了代码和通用英文的比例相应下调。这样做是为了让模型在中后期集中学习更稠密的知识内容降低前面的训练噪声对最终能力的影响。必须明确的一个经验是数据配比高度依赖于语料质量和目标能力设定不存在放之四海而皆准的黄金比例。RegMix给你的是一个优化的方法论而不是一份抄作业的答案。3. 架构选型与训练管线从零搭建的每一步语言模型的架构现在已经高度收敛在标准Transformer基础上做微调是主流做法。Fly在架构层面没有做什么颠覆性设计但在好几处细节上做了基于当下主流实践的取舍这些取舍对训练稳定性和推理性能的影响比想象中大得多。3.1 模型架构的具体参数Fly的整体结构是一个标准的decoder-only transformer具体参数如下这些参数并不是拍脑袋定的。隐藏维度和层数、注意力头数之间的比例关系大致遵循了同规模模型的主流设计范式。更关键的一个选择是FFN层维度从标准的4倍隐藏维度压缩到了约2.7倍这直接减少了约20%的参数量而对困惑度的影响很小。在显存受限的环境下这是一个我觉得性价比挺高的取舍。3.2 位置编码、归一化与激活函数的选型逻辑在Fly里我直接采用了目前1B级别模型里比较常见的技术栈旋转位置编码RoPE相比原始的绝对位置编码RoPE对长文本外推能力更强也能更好地配合注意力计算中的相对位置信息。Fly支持的上下文长度是4096 token在小规模模型上算是一个比较实用的长度。RMSNorm它去掉了LayerNorm中的均值计算只保留方差归一化参数更少训练更稳定在目前的主流开源模型架构里已经成为事实标准。SwiGLU激活函数相对更传统的ReLU和GELUSwiGLU的开关门控结构能让模型在前馈过程中保留更丰富的信息流对训练效率和下游任务表现都有正向帮助。很多初学者容易忽略这些组件带来的累积作用。单看每个选择似乎都只带来零点几的提升但三者叠加对训练曲线的平滑程度和最终效果的帮助非常可观。3.3 Tokenizer训练一个容易被低估的工作Tokenizer的质量直接影响模型对文本的建模粒度。我直接用SentencePiece训练了一个BPE分词器词表大小定在32K。在选择词表大小时做过权衡——更大的词表能减少每句话切分出的token数量但会增加embedding矩阵的参数量对小模型来说32K是一个兼顾表示能力与参数量效率的选择。训练数据覆盖中文和英文所以我在分词器训练时特意控制了两者的比例。实践下来如果中英文比例失衡分词器会出现一种很明显的现象某个语言里的词被切得特别碎另一个语言的长词则被整体保留。这种情况会在后续的训练中持续造成跨语言的表示偏差。SentencePiece训练完成之后还必须要做的一件事是检查特殊token和数字的切分。默认情况下分词器可能会把2024切成两个token这种分法在某些场景下没有问题但在需要模型精确理解年份、价格的场景下整块保留会更合理。我手动调整了一批数字类token的合并规则。3.4 训练超参数与分布式的配置参考Fly的训练配置是用了一套相当标准的recipe序列长度全程固定为4096意味着每个batch包含的token数为512 × 4096约2M tokens。从Chinchilla法则出发20B到30B token的总数据量在这个配置下一个epoch就能覆盖全部数据所以我没有设置epoch的概念而是直接按总步数来安排数据顺序。分布式方面我用了PyTorch原生FSDP它对比DeepSpeed的优势在于和PyTorch本身的功能兼容性更好。4卡环境下把transformer层做分片Adam优化器状态也一并分片单卡显存峰值大约在32G上下还有余量做梯度检查点。一个比较实用的理解是在4卡或8卡这个规模下分布式训练带来的技术挑战其实不大真正的瓶颈在数据加载和存储IO。我的数据以二进制mmap格式存储配合预取和打乱缓冲能把GPU空闲率压到非常低。4. 训练实测loss曲线、震荡和灾难性遗忘理论上再完美的配置放到真实训练环境里都会被现实教育一遍。Fly的训练过程谈不上顺利但每一次问题都是对架构理解的加深。这里把最有代表性的几个问题、定位过程和解决办法记录下来。4.1 loss曲线的整体形态与异常诊断Fly的预训练loss曲线整体趋势符合预期快速下降之后进入平台期然后缓慢下降。但如果放大看局部训练前期的曲线震荡幅度一度偏大loss波峰和波谷之间可以有0.1以上的差距这在1B规模模型上不太正常。定位过程是按排除法来的。先怀疑学习率过高但调低之后震荡虽有缓解却没有消失。随后检查了数据batch之间的相关性——问题出在打乱逻辑上。我最初做数据打乱时窗口设得太小导致同一个连续段落被反复切进邻近batch模型在这些局部重复数据上出现过拟合表现为周期性loss尖峰。修复方案有两个一个是加大全局打乱范围确保同一个文档的不同部分不会被连续访问另一个是引入了数据混叠策略把不同来源的数据流交叉混合。这个操作的影响是立竿见影的loss曲线瞬间平滑了一大截。4.2 梯度累积步数不当引发的隐性灾难Fly采用梯度累积来模拟更大的batch size。我最初的配置是累积8步结果训练到中期发现loss下降明显变缓而且对学习率调整的响应变得迟钝。排查之后把累积步数降回4步只保留一个合适的梯度更新频率问题立刻缓解。这个问题的本质是梯度累积意味着参数每多少步才更新一次累积步数过多会延迟反馈。In大batch、高学习率的recipe下延迟反馈可能被放大导致模型在最优解附近来回振荡。类似这种问题如果你只看最终曲线而不对比更新前后的局部变化很难意识到累积步数才是元凶。4.3 后期数据比例调整带来的任务遗忘问题我在前面提到训练最后阶段上调了中文百科和书籍比例。这个操作带来了一个让我有点措手不及的现象模型在中文能力增强的同时代码生成和数学推理的能力明显回退。这就是灾难性遗忘在小规模预训练中的具体体现。解决思路不是简单地让数据配比保持不变而是把比例切换变得更平滑。我重新设计了数据调度方案将比例变化从最后一阶段直接切换改为最后20%的训练进度内线性渐变。这个操作相当于给模型一个过渡期去吸收新数据分布同时保留旧分布的能力。最终效果是理想的中文能力上升的同时代码质量的回退幅度只有原先的三成左右。数据调度策略和大模型训练本身的动态关系在Fly的实践里体现得相当充分。4.4 训练中断与checkpoint的教训预训练过程里一定会有各种各样的中断机器掉卡、机房网络抖动、有人误操作kill了进程。Fly项目在早期因此吃过一次大亏——我没有设置足够频繁的checkpoint保存导致一次意外中断直接回退了两天的训练进度。从那之后我固定每500步保存一个完整checkpoint每2000步保存一个带优化器状态的checkpoint用于断点续训。两者的区别在于完整checkpoint可以通过合并参数制作推理模型而带优化器状态的checkpoint则能让你在训练的任意节点恢复虽然单文件动辄几十GB但从恢复训练回滚成本来看非常划算。5. 评测与效果不靠感觉数字说话Fly训练完成后我没有直接靠人工去评估对话感受而是先跑了一轮系统性的benchmark。这个环节帮我筛掉了好几个感觉挺好但实际不行的问题点。5.1 评测集与结果汇总我选了七个指标覆盖通用知识、推理、代码、中文能力和安全倾向五个维度其中MMLU的5-shot相对模型大小来说是符合预期的。C-Eval在中文模型里算中等偏上说明中文语料占比和后期调度策略确实起了作用。比较意外的是HellaSwag的分数相当不错这说明通用文本语料带来的常识理解增益比预期更明显。5.2 人工评测暴露出的问题Benchmark数字并不能完全代表真实体验。我组织了一轮人工对话评测邀请了大概十来个人从不同角度跟Fly交互。结果暴露出来的问题很集中第一个问题是回复长度偏向过长。模型似乎被训练数据里某些长文风格带偏了在简单问题上也会输出大段冗余的内容。这个问题通过采样参数调节能缓解但根子还是数据层面的风格平衡不够。这就引出开篇提到的数据配比问题——如果你希望模型输出简洁训练数据里就必须有足量的简洁示例。第二个问题是数学能力仍旧拉胯。虽然GSM8K分数看起来不算太难看但一到多步推理或者应用题模型经常一本正经地列出错误算式。这说明对小模型而言数学推理能力的提升光靠数据量和模型容量是不够的可能需要配合CoT数据微调或者更结构化的训练策略。5.3 与基准模型的对比观察我把Fly和几个同规模开源的模型做了快速对比结论是Fly在通用知识和中文能力上基本持平在代码上偏弱在安全避免生成有害内容上略好。代码偏弱的原因我能定位到——代码语料在总配比中占比15%这个比例在1B级别模型上是偏少的。代码生成需要模型捕捉很长的语法依赖关系数据量不足时这种能力很难无中生有。如果要做一个偏代码的模型数据配比里代码语料至少得占到25%以上这算是Fly测试后得出的直接经验。与同规模模型对比中还有一个值得关注的现象Fly在训练数据中英文混杂的情况下跨语言的代码注释理解能力出现了明显折损。这一现象对多语言语料混合的训练是一个很有参考价值的样本。6. 从Fly到下一版经验沉淀与迭代方向Fly第一版的完整流程走完之后我对从零构建语言模型的复杂度有了非常具体的认知。接下来如果要做Fly-2有几个方向是确定的。第一数据管线升级。目前的数据清洗流程虽然跑通了但大量规则是手工维护的扩展性很差。下一步会引入更细粒度的质量打分模型用一个小型的分类器给每个文档打分然后按分数做加权采样而不是简单的过不过滤。这样能更精细地控制语料的质量分布。第二增加SFT和RLHF阶段。当前Fly严格来说只是完成了预训练它生成的内容在格式合规和有用性上距离真正的助手模型还很远。下一版会在预训练完成后接上指令微调和基于偏好优化的对齐环节。这部分的工程量其实不亚于预训练。第三尝试MoE化架构。1B级别的dense模型在推理上确实快可如果在同样的算力预算下做成MoE总参数量可以堆到3B甚至5B每个token只激活一部分专家推理速度几乎不变知识容量却能大不少。这个是接下来最想验证的事情。对我个人而言做Fly最大的收获不是跑通了一个模型而是把训练一个语言模型从神秘黑盒变成了一套可解释、可调参、可复现的工程流程。这套流程带来的掌控感跟直接调API完全是两种体验。如果你也有算力资源、也好奇自己从头训一个模型会是什么结果Fly的整套数据管线和训练配置都可以作为一份参照。语言模型训练这条路已经没有太多秘密了剩下的就是用量和细节去换质量。