过去一年多AI 工程这个关键词的热度一直没怎么降。我经常在社区里看到类似的问题不想只调 API、不想把 LangChain 当黑盒想自己把一个语言模型从头搭起来到底该从哪入手项目标题ai-engineering-from-scratch恰好概括了这条路——从数据清洗、分词器、模型结构、训练脚本到推理服务每一步都自己动手不依赖现成的千亿参数大模型。这篇文章是我把这条路完整走一遍之后的总结包含选型逻辑、具体实现、踩坑记录和排查方法。适合两类人看一类是刚入门 NLP、想搞清楚 Transformer 内部到底发生了什么的学习者另一类是已经在用开源模型做应用但总觉得只会调用看不懂底层、想彻底弄明白原理的工程师。先说结论从零搭一个语言模型并没有想象中那么难难的是忍住不抄现成代码、不急着上大模型、老老实实把每个环节都验证清楚。你不需要顶级 GPU一张消费级显卡就能跑通全过程你也不需要先把深度学习数学全啃完核心就是理解 Attention 和梯度反传这两件事。1. 项目整体设计与思路拆解1.1 从零开始到底意味着什么很多人对 from scratch 有误解以为必须从矩阵乘法自己手写、不用任何深度学习框架。真这么做大概率三个月就放弃了而且学到的都是造轮子而不是做工程。我理解的 from scratch 是不直接加载现成的模型权重和 Tokenizer而是自己准备数据、自己定义模型结构、自己写训练循环、自己部署推理服务。PyTorch 这类框架可以用因为它是工具而不是成品就像你不会为了做家具先去炼钢。这个定位非常重要它决定了整个项目的边界。我见过不少人在第一步就纠结要不要手写反向传播这个纠结纯属内耗。我们的目标是理解语言模型是怎么造出来的而不是重新发明深度学习框架。框架帮你算了梯度但你必须清楚每个参数在哪一步被更新、学习率怎么影响收敛、损失函数为什么这么设计——这些东西框架帮不了你这才是 from scratch 的核心价值。1.2 为什么值得自己搭一遍直接下载一个开源模型然后写个脚本做推理这条路我走过快但空虚。你看着模型吐出一段流畅的文字却完全不知道它为什么能这样输出。自己搭一遍之后很多常识会被打破重塑你会发现所谓大模型的骨架其实只有几百行代码核心组件就是嵌入层加几十层 Transformer 块。你会发现分词器Tokenizer对效果的影响非常大同样一段文本分词方案不同模型学习难度完全不同。你会发现训练过程中的 loss 曲线会像过山车一样波动梯度范数暴涨是家常便饭调学习率比调网络结构更影响最终效果。你会发现推理阶段的 KV Cache、采样温度这些细节本质上是工程上的权衡而不是什么魔法。更重要的是自己搭一遍之后你再去看那些开源模型的论文和技术报告每一段都能对上号哦这个位置用了 RoPE这个损失用了交叉熵这个采样温度是为了控制熵。这种能对上号的感觉是单纯读论文给不了的。1.3 项目目标怎么定才算合理很多人一上来就想复现 GPT-3这跟想用自行车上月球差不多。我建议把目标定成三层每层都能独立验证第一层造一个能流畅生成短文本的模型。参数量在 1000 万到 1 亿之间在一两 G 的纯文本数据上训练能生成语法正确、语义连贯的句子。这个目标已经能覆盖大部分技术链路。第二层让模型具备一定的可控性。能通过 prompt 引导输出方向能完成简单的问答、续写、摘要任务。这时候你需要认真处理数据配比和指令微调。第三层向推理能力迈一步。模型在数学推理、多步逻辑任务上有可观察的提升。这是从语言模型到推理模型的关键一跃我会在后面的实操部分专门展开。我个人的建议是先把第一层做得非常扎实再往后走。因为第一层没做好连 loss 都不收敛的话后面所有的微调、推理优化都是空中楼阁。2. 核心细节解析与实操要点2.1 模型架构选型别急着创新语言模型的主干架构几乎已经被 Transformer 统一了这个阶段不需要你创新也不需要你优化照着经典结构实现就是最优解。我用的结构是Token Embedding 和 Position Embedding 相加作为输入经过 N 层 Decoder-Only Transformer 块每个块包含多头自注意力Multi-Head Self-Attention和前馈网络Feed-Forward Network中间夹着 LayerNorm 和残差连接最后接一个 LM Head 把隐藏状态映射回词表大小。这里有几个选型细节值得说清楚为什么用 Decoder-Only 而不是 Encoder-Decoder因为现代语言模型和推理模型基本都是 Decoder-Only 路线训练目标统一为预测下一个 Token实现简单且扩展性好。Encoder-Decoder 在翻译等任务上仍有优势但作为学习项目Decoder-Only 是主线。LayerNorm 放在哪里经典 Transformer 用的是 Post-LN先残差再归一化但训练深层模型时容易不稳定。现代主流做法是 Pre-LN先归一化再进子层配合残差连接训练更稳学习率可以开更大。我直接用了 Pre-LN省掉很多训练不稳定的头疼问题。激活函数选什么前馈网络的激活函数建议用 GELU 或 SwiGLU。SwiGLU 现在更主流但参数略多。入门阶段用 GELU 就够了它足够平滑梯度特性好。归一化用 LayerNorm 还是 RMSNormRMSNorm 去掉了 LayerNorm 中的均值中心化只做方差归一化计算量更小效果几乎没有差别。代码也就几行我直接用了 RMSNorm。2.2 分词器最容易忽略的隐形瓶颈很多入门教程把分词器当成配菜几行代码加载完事。我在实操中才发现分词器才是第一个真正影响全局的环节。外面那些开箱即用的 Tokenizer 都是在大规模语料上训练好的词表几万到几十万直接拿来做小模型训练往往不合适——词表太大嵌入层参数占比过高小模型根本学不过来。我的建议是自己训练一个迷你 BPE 分词器词表大小设置在 4000 到 8000对 100M 以内参数的小模型来说这是一个平衡点。太小则每个词被切得太碎序列变长、计算量增加太大则嵌入矩阵和输出头的参数爆炸。训练语料要用你的真实训练数据不要图省事随便找一段英文文本。中文分词尤其敏感BPE 会把常见汉字和词组拆成不同的组合词表质量直接影响模型学习效率。设置合理的特殊 Tokenunk未知、pad填充、bos/eos开始和结束、endoftext用于分隔样本。这些符号在后续做指令微调和推理时都会用到现在不设计好后面要返工。2.3 位置编码为什么必须显式告诉模型顺序Attention 机制本身是无序的它对输入序列做的是加权求和如果不加位置信息我爱你和你爱我在模型看来几乎是一样的。所以位置编码是刚需。目前主流有两种实现我推荐用 RoPE旋转位置编码绝对位置编码如 Sinusoidal把位置信息加到 Token 向量上实现简单但泛化到更长序列时效果不太好。RoPE 通过旋转矩阵把位置信息编码进 Attention 的 Q 和 K 向量的内积里好处是相对位置信息天然被建模外推能力更强。现在几乎所有主流开源模型都用 RoPE学它就等于学主流。实现 RoPE 并不复杂对 Q 和 K 按维度分组每两个维度构成一组旋转复平面位置不同旋转角度不同。有个参数叫base默认 10000 或 500000它控制旋转频率的分布直接影响模型对长距离依赖的建模能力。这些参数在我第一次实现时根本不懂全靠后面跑实验对比出来的。2.4 训练数据管道数量和质量怎么权衡小模型对数据质量极其敏感。有人觉得只要数据够多模型就能学好实测下来并非如此。我在 1 亿参数模型上做过对比用 10 亿 token 的干净数据效果比 30 亿 token 的原始爬取数据好得多。原因很简单——小模型的容量有限它只能从数据里学到最频繁、最一致的规律如果数据里到处都是噪声模型学的就是噪声。数据管道我建议这样做来源选择公开的文本数据集比如维基百科、书籍、高质量的网页文本。中文用户也可以用一些公开的语料库重点是来源可靠、编码干净。清洗规则去重MinHash 近似去重或者简单的句子级去重都行、去 HTML 标签、过滤超短行和超长行、过滤包含大量乱码的段落。清洗规则宁可保守不可激进。采样比例如果做通用模型多来源数据需要按比例混合。比例怎么定我在实践中用一个笨办法——先用小 batch 快速试训看哪个来源的困惑度Perplexity降得快降得快的说明模型学得动可以提高比例降得慢的说明数据太难或太脏要降比例或清洗。3. 实操过程与核心环节实现3.1 环境准备与基础配置我用的环境是单张 24GB 显存的卡PyTorch 2.x CUDA。很多人问显存不够怎么办我的经验是1 亿参数模型加 512 的上下文长度在 12GB 显存上也能训关键是把 batch size 调小、序列长度降下来。搭建环境时有三个节省时间的小技巧直接用 PyTorch 官方的 Docker 镜像里面 CUDA、cuDNN 都配好了比自己手动配环境省一天时间。用torch.compile加速训练代码里只需要在模型外面包一行实测训练速度提升 20% 到 40%而且不会改任何训练逻辑。全程使用 AMP自动混合精度torch.cuda.amp里封装的autocast和GradScaler在 PyTorch 2.x 中已经非常成熟。我实际用的是 bf16如果显卡支持的话因为它省显存的同时几乎不损失精度。3.2 最小 Transformer 实现要点我不打算贴完整几百行代码网上有大量开源的参考实现重点是讲清楚每个模块的写法意图嵌入层nn.Embedding(vocab_size, hidden_dim)一个是 Token 嵌入一个是位置相关的东西用 RoPE 处理所以不需要 Position Embedding 表。注意力层先做 Q/K/V 线性映射然后 reshape 成多头经过 RoPE 旋转后计算缩放点积注意力最后再接一个输出投影。关键代码就三行得分 Q 乘 K 的转置除以 sqrt(d_head)softmax再乘 V。K 和 V 为什么要单独存推理阶段每来一个新 Token都要把之前的 K、V 重新算一遍效率太低。所以推理时要启用 KV Cache把历史 K、V 存下来。这个设计不在模型结构里在推理代码里。因果掩码Causal Mask训练时要保证当前位置只能看到之前的位置。实现方式是用一个上三角矩阵把对角线以上的位置设为负无穷softmax 之后这些位置的注意力权重就是 0。这个掩码要加到每个注意力头里。输出头最后把隐藏状态过一层线性层映射到词表大小得到每个位置各 Token 的 logits。这一层的参数量等于hidden_dim * vocab_size在小模型中占比很大所以词表不能太大。3.3 训练循环与损失优化训练循环的核心是损失函数和数据迭代。损失函数直接用交叉熵但有一个细节只对非填充位置计算损失。如果你的序列里用了pad来补长度填充位置必须被 mask 掉否则模型会拼命学习预测填了多少个 pad白白浪费容量。训练超参数是很多人最头疼的部分。我分享一组实测可用的起点值参数推荐值说明序列长度256 到 512小模型不需要太长太长学不动Batch Size32 到 64配合梯度累积总 token 数维持 16K 以上每个 step学习率3e-4 到 1e-3用 AdamW先 warmup 再余弦退火AdamW 参数beta10.9, beta20.95, weight_decay0.1训练更稳泛化更好梯度裁剪max_grad_norm1.0防止梯度爆炸必开Warmup 步数总步数的 5% 到 10%一开始就大学习率容易发散这些参数不是拍脑袋定的背后有逻辑warmup 是因为 Adam 的一阶矩估计在初期不准大学习率容易导致震荡余弦退火是因为训练后期需要更精细地收敛到最优区域梯度裁剪是因为 Transformer 的梯度范数在数据出现异常时很容易暴涨不裁剪的话一个坏样本就能毁掉几千步的训练成果。训练过程中我建议每 100 步打一次日志记录 loss、学习率、梯度范数。loss 曲线的形态比绝对值更重要如果 loss 一直平缓下降说明一切正常如果突然跳高再降回来说明可能踩到了坏数据如果一直不降那就要回看数据管道和模型结构。3.4 从语言模型向推理模型迈进的实操路径项目热词里提到的 build a reasoning model from scratch 是这两年特别火的方向。很多人觉得推理模型是 OpenAI 的独门秘籍其实核心思想在学术界已经被拆解得很清楚了让模型在回答问题之前先想一会儿把推理步骤以文本形式写出来再用强化学习或监督微调让模型学会这种思维方式。我自己实践时把这条路分成了三步第一步让模型学会说出来。找一个有详细解题过程的数学数据集比如包含分步解答的数学题把答案 推理过程拼成统一的文本格式直接做监督微调。这一步之后模型虽然不一定算得对但至少会尝试分步思考了。第二步采样 筛选。让模型生成多个候选答案采样时温度调高一点比如 1.0根据最终答案对错给这些采样打标——答对的标为好答错的标为坏。这一步不需要真实的奖励模型只需要一个答案是否正确的判断器。第三步用偏好优化如简单的 DPO让模型更倾向于输出好的推理路径。DPO 的代码量很小核心就是对比好答案和坏答案的概率对数之差让两者的差距拉大。这三步走完你会清楚地感受到模型在一个特定任务上的推理能力确实提升了。注意这不是在训练一个通用推理模型只是让模型在某个领域内学会了多步思考的模式。3.5 推理服务的工程化训练完模型之后还有一半工作量在推理侧。我在做推理时踩过的坑比训练还多重要程度反而是推理侧最容易被忽视贪婪解码 vs 采样解码贪心解码每次取概率最大的 Token结果稳定但机械、重复采样解码按概率分布随机选多样性好但可能语法混乱。答案是要控制 Temperature——温度高则概率分布更平、更随机温度低则更接近贪心。做问答和代码生成推荐 0.2 到 0.7做创意写作推荐 0.8 到 1.2。这个区间是我用大量生成结果对比出来的。Top-K 和 Top-P核采样只保留概率最高的 K 个 TokenTop-K或者保留累积概率达到 P 的最小集合Top-P。两者配合使用比单用温度更稳。我常用的是 Top-P0.9 加 Top-K50。KV Cache 是性能关键没有 KV Cache生成 200 个 Token 需要 O(n²) 次计算有了 KV Cache只需要对每次新增的 Token 做计算生成速度能提升一个数量级。第一次实现时我完全没做缓存生成 50 个 Token 都能卡半天加了 KV Cache 之后流畅得跟换了台机器一样。4. 常见问题与排查技巧实录4.1 损失不下降或掉得极慢几乎所有从零实现的人都会撞到这个坑。我第一次训的时候前两千步 loss 几乎纹丝不动焦虑到怀疑人生。排查顺序很重要一层层来先检查数据标签有没有对齐。语言模型的目标是预测下一个 Token输入序列要整体左移一位当标签。如果标签错位了模型就是在瞎猜。这是最常见的低级错误但极其隐蔽。用一个可视化函数打印出输入和标签对应的文本人工看一眼比任何检查都有效。检查损失是否在随机初始化时符合预期。随机初始化的模型对每个位置应该输出均匀概率分布交叉熵应当约等于词表大小的自然对数log(vocab_size)。如果你的初始 loss 远小于这个值说明哪里偷懒了比如标签泄漏、或者模型结构里把 ground truth 漏进去了。缩小任务做冒烟测试。取几百条样本在极小的模型一两层 Transformer上过拟合。如果小模型在几百步内能把训练集 loss 降到很低说明代码链路没问题问题在数据规模或模型容量上如果小模型照样训不动问题就在代码里。4.2 训练 loss 正常下降但生成结果全是乱码这个现象特别容易让人误判为模型坏了。我排查过十几次每次几乎都是同一个原因推理时的输入格式和训练时不一致。比如训练时文本前面总是加了一个bos标记推理时你直接喂了没有任何标记的文本或者训练时序列是定长 padded 的推理时没有做对齐。模型学到的是一个条件分布条件变了输出当然崩。解决办法把训练和推理前的预处理代码完全统一。写一个encode_sample(text)函数训练和推理都调它不要写两套逻辑。哪怕多花十分钟也比后面排查两小时强。4.3 显存溢出显存溢出的直接原因好理解某一层的中间激活值太大了。常见解法按优先级排序减小 Batch Size 或序列长度这是最直接的。开梯度检查点Gradient Checkpointing用计算换显存训练速度会慢一些但显存占用能降一半以上。用 bf16/FP16 混合精度显存直接减半而且显卡利用率更高。如果是长序列导致的可以用 Flash Attention它在计算注意力的同时不会把完整的注意力矩阵存下来省显存效果显著。PyTorch 2.x 已经把scaled_dot_product_attention封装好了传一个参数就能用。我记得有一次排查显存问题排查了一个晚上最后发现是torch.compile组合某些算子时产生了额外的内存峰值。所以遇到奇怪的内存问题先把torch.compile关掉一步步加回来看是哪里引出的。4.4 训练很慢每一步都在浪费小模型训练慢的原因通常是数据加载和 GPU 计算没有并行起来。如果数据管道做的是读文件 → 预处理 → 转 tensor → 进 GPU你会发现在 GPU 真正计算之前CPU 已经忙到冒火了。解法是用DataLoader的num_workers多进程加载把预处理放到子进程里。把数据预先 tokenize 成二进制格式存下来训练时只做读数组切片不做任何在线分词。探一下瓶颈把训练循环里模型推理那行注释掉只跑数据加载看看多长时间能读完一个 epoch。如果数据加载时间快接近训练时间了那就要优化。4.5 推理模型训练时的特殊坑做 3.4 节说的推理模型时我遇到过一个很典型的问题采样生成的候选答案里好答案和坏答案分布极度不均衡。比如模型学会了只要生成长度足够长就大概率得分高于是它开始生成一堆又臭又长的废话只为了看起来在推理。这个问题的本质是奖励信号太粗——只判断最终答案对不对而没有给推理过程质量打分。我的应对是分两步先按答案对错做粗筛选再用一个通用规则比如推理步骤是否包含关键计算过程、是否得出正确中间结果做细筛选。另外采样温度不能太高否则生成的推理文本会严重偏离模型的正常输出分布后面 DPO 优化出来的模型读起来会非常怪。5. 学习资源与后续进阶方向5.1 值得精读的资料这条路走下来我认为最核心的学习材料就三类经典论文、系统实现的书籍、以及高质量的开源代码。论文Attention Is All You Need看懂 Transformer 结构、RoFormerRoPE 位置编码、Language Models are Few-Shot LearnersGPT-3 的训练和涌现、Training Compute-Optimal LLMs数据与算力配比。这四篇看完整个体系的骨架就立起来了。书籍有一本比较知名的《Build a Large Language Model (From Scratch)》适合和我的路线搭配看。它的优点是代码完整、从零开始逐步构建一个小型 GPT 模型边读边跟着实现效果比我当年踩坑摸索快很多。它讲的基础是语言模型推理模型的部分需要结合我前面 3.4 节的方法再延伸。代码找一些成功训练过的小模型开源项目重点不是读它们的完整代码而是看它们的配置文件——数据规模、学习率、batch size、训练步数这些超参数组合对比你自己的设定就能发现差距。5.2 从玩具模型到生产系统的跨度跑通全流程之后你会发现自己站在一个岔路口一边是继续往上深挖把模型做更大、更通用另一边是转向工程化把现有的小模型做成一个稳定、可用的服务系统。我的建议是先走工程化因为这是投入产出比最高的方向。你需要考虑模型量化把 FP16 的权重压到 INT8 甚至 INT4推理速度翻几倍显存占用大降。小模型量化后精度损失通常可以接受。并发服务用异步推理、请求队列、批处理Dynamic Batching来提升吞吐量。一个小的推理服务在扛住高并发时你会发现瓶颈往往不在模型计算而在内存拷贝和调度逻辑。评估体系建一个自己的评估集每次改动模型或数据之后跑一遍看哪些任务变好、哪些变差。这一步是通往认真做模型的分水岭。5.3 更多的扩展方向如果你对某个环节特别感兴趣可以沿着这些分支深入数据方向研究数据配比、去重算法、合成数据生成。对齐方向学习 RLHF 的深入实现尝试 PPO 或 DPO 之外的偏好优化算法。推理方向研究参数高效微调LoRA、模型合并、蒸馏。系统方向研究分布式训练框架、显存优化、推理加速引擎。说实话任何一个分支都足够研究好几年。但基础没打牢之前不要分散精力先把一个模型完整地建立起来再谈其他。最后分享一个我个人的体会从零搭模型这件事最大的收获反而不是模型本身。我现在看到一个开源模型第一反应不是哇好厉害而是它的训练数据大概是什么结构它的位置编码用了什么变种它的推理速度瓶颈在哪。这种拆开看的思维惯性是用 API 和现成模型永远练不出来的。如果你也正在这条路上挣扎记住一句话不要怕慢怕的是每一步都走不明白。训练一个效果一般的模型只需要几天但把每一层、每一个参数、每一个损失函数都搞清楚这份通透感能伴随你很长时间。先跑通再跑好。