经常有人私信我AI工程到底怎么从零开始问的人里不少已经看了一堆公开课、收藏了好几个“路线图”但真到动手时还是懵。我自己也有过同样的阶段直到把一个推理模型的训练、评估、部署完整跑通再一路把规模扩到大语言模型预训练才算想明白一件事——“ai-engineering-from-scratch”的关键不在“from scratch”那几个字而在“engineering”。换句话说难点不是你从零写一个Transformer而是你写完以后能系统地推进它数据怎么造、训练怎么稳、效果怎么评、下一版怎么迭代。这篇文章没有按“从基础概念到高级专题”的路线来写而是把我个人实操中验证过的完整链路拆开从轻量推理模型一直聊到中小规模大语言模型。适合两类人一类是刚入门、想找一个能真正跑通的项目练手的开发另一类是已经在调开源模型、但心里没底想知道底层到底发生什么的人。整个过程我会尽量说人话把参数、步骤、踩坑点都交代清楚方便你直接照着复现。1. 先想清楚你要从哪个“零”开始1.1 AI工程和你想的不一样很多人以为AI工程等于训练模型我过去也这么想直到自己做了一轮才发现训练环节可能只占整个项目20%的时间。真正的工程时间花在数据版本管理、实验追踪、评估集构造、训练稳定性调试、推理性能优化以及一次次的回归对比。这个比例在从零起步时尤其明显因为每一步都没有现成的模板可抄。为什么先说这个因为如果你一开始就奔着“我要训练一个大模型”去大概率会在第三步就放弃。更现实的做法是把一个很小的任务从头到尾跑通让系统的每一环都变成肌肉记忆再逐步放大。这也是本文反复强调的路线先小后大先通后优。项目标题虽然看起来宏大但真正的落地路径是“从一个很小的闭环开始”。1.2 三种起步路线的对比把圈子里的常见做法归纳一下基本是三种路线A找开源大模型微调。见效最快适合做产品和业务验证但很难理解底层机制一旦模型效果不对你不知道问题出在底座还是出在数据。路线B从零复现一个中小规模模型百万到亿级参数。学习价值最高也是本文的主角。你会亲手碰到数据、训练、评估每一个环节。路线C从集群开始训练超大模型。学习意义不大成本极高多数人不需要也不是“from scratch”的合理姿势。路线成本学习价值适合谁开源模型微调低中产品工程师、业务验证中小模型从零复现中高想深入理解AI工程的开发超大模型从头训练极高低对少数研究员高机构/大厂团队我自己走的是路线B先复现一个小学数学推理模型再扩展到1B左右的decoder模型。接下来几节就是这条路的完整拆解。你不需要一开始就决定“我要做个几十亿参数的大模型”只要先把这个小闭环跑通后续扩大规模只是资源问题不再是认知问题。2. 从零构建一个能跑起来的推理模型2.1 选任务把“推理”落到可衡量的问题上“推理模型”这个词最近很火但如果你去看各种各样的宣传会觉得必须做成大规模强化学习训练才叫推理。实操中的第一步其实是把任务选小。我用的切入点是小学数学应用题选它有三个理由推理步骤明确可以检查中间推导过程数据可以程序化合成不需要人工标注正确率可以精确计算评估无歧义不会出现“生成结果好像对又好像不对”的模糊局面。我设计的数据长这样输入“一个班有28个学生其中男生比女生少4人请问女生有几人” 标准输出不是简单数字“16”而是完整推导“设女生人数为x则男生人数为x-4方程为x(x-4)28解得x16所以女生有16人。”为什么这样设计因为如果只输出答案模型很容易背数据分布无法体现推理过程。把中间步骤也放进目标序列里模型必须学会“设方程、列方程、求解、总结”这个完整的思考链。这一步对后续做真正的大模型reasoning调优非常重要因为RL训练里给奖励信号的往往是“中间步骤是否合理”而不是只看最终答案。数据合成代码可以参考import random def synthetic_data(n): samples [] for _ in range(n): girls random.randint(5, 50) gap random.randint(1, 8) boys girls - gap total girls boys q f一个班有{total}个学生其中男生比女生少{gap}人请问女生有几人 a (f设女生为x男生为x-{gap} f方程x(x-{gap}){total}解得x{girls} f所以女生有{girls}人。) samples.append((q, a)) return samples这里有几个非常重要的细节。第一个是变化模板你不能只停留在“班级人数”这一个场景要扩展到买水果付钱、两人年龄差、工程合作效率等场景否则模型只会记住固定模板里的数字替换根本不算推理。第二个是答案的可检验性程序合成时答案一定正确但你需要去检查生成逻辑本身比如年龄差模板里如果允许小孩比大人大合成出来的题就是错的。我最初偷懒没做一致性检查结果模型在测试集上学会了“题干矛盾时也硬解”这反而暴露了数据质量比模型规模更关键。2.2 模型实现最小闭环的Transformer解码器任务和数据准备好了模型不用往大里做。我从零实现了一个极轻量的Transformer解码器配置如下参数取值词表大小1024按字切分序列长度128d_model128层数4注意力头数4参数量约300万为什么不用现成库里的GPT-2因为“from scratch”的意义就是亲手写一遍把每个张量shape、掩码、位置编码的作用看清楚。之后换库、换规模心里才有底。实际上很多人在这个阶段连为什么需要mask都不知道decoder模型在生成第k个token时不能看到未来的token所以要构造一个上三角掩码矩阵强制注意力只面向过去。这些细节不亲手实现一遍看十遍文档也记不牢。模型训练时使用交叉熵损失teacher forcing每个位置的目标是下一个token。优化器用AdamW加上200步warmup和余弦退火学习率峰值1e-3batch size 64。这套配置在单张显卡上几十个epoch就能收敛甚至高端CPU也能做演示性训练非常适合入门阶段反复试错。2.3 训练到推理把“工程闭环”第一次跑通训练循环本身不复杂但这里我建议把三样东西从第一天就做好评估集与训练集完全分离用不同模板生成避免模板记忆每训练一定步数就做一次贪心解码人工看输出而不是只看loss保存每个epoch的checkpoint后续做中间推理错误分析时需要回看。推理时用贪心解码逐个token生成。实测这种小模型的确能学会完整解题步骤但错误也很有代表性有时候方程列对了、最终答案计算错有时前几步对最后“所以女生有...”的结论部分乱套。这些错误恰恰是评估模型推理能力的绝佳素材。我举一个真实输出例子“设女生为x男生为x-4方程x(x-4)28解得x18所以男生有14人。” 你看它前一半完全正确但最后被训练数据里“男生有14人”的常见句式带偏了把结论主语换掉了。这就是典型的“过程推理正确、最终表述跑偏”如果只统计最终答案正确率这种错误会被归为“计算错误”实际上它是语言建模层面的问题修复思路完全不同。3. 从零构建大语言模型的现实路线3.1 先把算力的账算清楚很多人被“大模型”三个字吓住以为必须几百张卡。实际上你要“从零”走通大语言模型完全可以从0.1B到1B的参数规模起步。先算一笔账1B参数全精度fp32训练单是参数、梯度、优化器状态就得约4GB、4GB、8GB合计16GB显存加上激活值一张24GB的显卡勉强可以跑。如果转成bf16混合精度并用ZeRO等策略单卡压力会小不少但数据量仍是大头。数据量按经典的Chinchilla法则1B参数大约需要20B token。个人开发者单卡很难吃下这个量。所以我的建议很务实学习复现时可以把数据量降到2B token接受模型效果不如理论最优但把训练、评估、迭代的完整流程跑通。毕竟你的目标是学会“怎么从零构建”而不是真的和一个千亿模型竞争。参数量建议token量最小显存估算个人单机是否可行0.1B2B约8-12GB可行0.5B10B约20GB需要好显卡长时间1B20B约32GB基本不推荐单机7B140B多卡集群不建议自己做3.2 数据工程是真正的“从零”核心如果你自己跑过预训练就会发现模型效果差多数时候不是架构问题是数据问题。从零构建LLM的教科书路线是先收集大规模文本、清洗去重、按比例混合再做tokenizer和训练集切分。这里给几个实用原则质量优先。宁取1B清洗干净、领域均衡的数据不要20B直接网上爬的脏数据。脏数据里重复文本、乱码、广告和口水话会让模型的生成质量断崖式下降。去重很重要。重复文本会让模型背诵而不是学会推理。用MinHash或简单的哈希去重都能见效关键是去重前后做个对比实验你会看到指标明显变化。混合比例要靠实验调。代码、数学、通用文本、多语种不同比例效果完全不同。我试过把代码比例从5%提到15%模型的逻辑任务表现有明显提升但闲聊流畅度会受损这就回到你的目标上做取舍。数据管道建议以“可复现”为第一目标每个版本的数据集要有ID、有记录、有统计报告。这样后续换数据版本时能定位效果变化来自哪一批数据。这里不需要一开始就上多复杂的平台一个文件夹加一个JSON配置就能跑起来但必须有人能说清楚某条数据来自哪里。3.3 三个阶段怎么规划预训练、指令微调、偏好优化从零走完一个能对话的大模型大致三步预训练在纯文本上学语言统计规律这一步成本最高指令微调SFT用问答对教会模型按指令输出偏好优化DPO/RLHF让输出更符合人类偏好。很多人一上来就做SFT效果看起来“聪明”但一测基础能力就露馅因为底座没预训练好。顺序不要乱。我自己也是踩过这个坑先做SFT再回来补预训练白白浪费了两周。预训练欠账不是SFT能补的就像盖房子没打地基就装修表面再好看也没用。如果想系统了解每一步的底层实现我会推荐Sebastian Raschka的《Build a Large Language Model (From Scratch)》。它把GPT类模型的实现、预训练到微调讲得比较完整最好配合作者开源仓库一起读动手把代码跑起来比单纯看书有用得多。购买正版渠道或官方电子平台都很方便不建议去网上找不明来源的资源既涉及版权问题内容也未必完整。3.4 算力有限时的“轻量从零”方案如果显卡一般我的建议是分两步走先在1B以下把机制跑通再换更大的卡或云环境。具体做法用一个已有tokenizer不要自己从头训省掉一个工程复杂度。自己训tokenizer要处理uniicode合并、特殊token、截断策略等一堆细节很容易把有效训练时间挤掉。用普通文本完成一个极短周期的预训练哪怕只有几百M token目的是验证数据管道、训练稳定性和评估基线。做好checkpoint和实验记录迁移到更大算力时无缝续跑。我见过不少人换机器后加载不了checkpoint就是因为路径写死、硬件配置变了这些细节应该在第一次保存checkpoint时就规范好。4. 实操中我反复踩的工程坑4.1 可复现性随机种子与数据版本从零训练的第一个大坑就是你昨天跑出0.82今天重跑变成0.75。原因通常是数据shuffle随机性、dropout、并行采样的顺序不一致。解决不复杂但容易忘在训练入口固定所有随机种子同时把数据集的版本号写进实验配置。另外一个坑是时间戳当标识的checkpoint随手存最后根本不知道哪个对应哪个。我现在的习惯是每个实验有一个config文件包含数据集ID、模型配置、种子、超参checkpoint和日志全部挂在这个config下。宁可多写几行样板代码也不要在三天后对着十几个文件夹发呆。4.2 训练不稳定loss突刺与梯度爆炸模型从零预训练时我最常见的问题不是loss不降而是loss突然冲高再回来有时直接爆掉。原因往往是学习率过大、warmup太短、或batch size和lr不匹配。解决办法增加warmup步数前1%到5%的步数里线性升温开启梯度裁剪max_grad_norm设1.0如果反复出突刺把峰值lr减半再试。为什么warmup有效因为训练初期参数离最优解很远梯度方向噪声大一上来用大学习率容易冲过头。类比一下就是刚上冰面的人要先小步适应再放开速度不然大概率摔。这个道理几乎所有框架文档都会提但只有你亲眼看到loss爆到NaN之后才会真正记住。4.3 评估指标会骗人只说“accuracy 80%”对于推理任务远远不够。我实际用下来最典型的情况模型能输出格式正确的方程但数值算错或者中间步骤是对的最后结论抄错。如果只看最终答案正确率你根本不知道模型卡在哪一环。所以从第一天就要做分步评估把生成结果按步骤拆开分别统计“列方程正确率”“求解正确率”“最终答案正确率”。这个分析虽然麻烦但每次都能直接指出下一轮迭代该改数据还是改模型。比如列方程正确率低说明模型没有理解题目语义需要增加题型变体如果列方程正确而求解错误可能是数值范围训练分布覆盖不够需要扩充分布范围。4.4 实验管理没有记录等于白跑我早期做过一个愚蠢的对比同一份数据跑了两遍一次用A框架、一次用B框架最后想复盘差异发现两个实验的超参、数据版本、步数全对不上。从那以后我强制自己用实验跟踪工具比如wandb或者本地存JSON每次启动训练前先打印config训练结束后自动归档loss曲线、评测结果、样本输出。我在实际项目里的配置记录长这样{ experiment: math_reasoning_v3, dataset_id: math_template_20250112, model_config: {d_model: 128, n_layers: 4, n_heads: 4}, seed: 42, optimizer: {name: adamw, lr: 0.001, warmup_steps: 200}, batch_size: 64, notes: 增加年龄差模板验证分步准确率 }你看这个记录本身不复杂但当你一个月后想对比“为什么v4效果比v3好”时它能直接告诉你差异在哪而不需要靠回忆。5. 一份六个月的从零到落地路线5.1 分阶段目标与检验标准如果照着“从零构建推理模型轻量大模型”的思路走我建议按六到十二个月来规划。时间太短会焦虑太长则容易放弃。给一份我验证过的节奏月份目标检验标准第1个月Python/PyTorch基础手写一个小Transformer能训练到loss下降生成通顺文本第2个月数据合成和评估管线生成2万条数学推理数据完成训练/评估脚本第3个月推理模型闭环数学应用题分步正确率达到70%以上第4个月扩展到1B以下参数预训练完成一个短周期预训练第5个月SFT与偏好优化模型能按指令回答人工评测通过第6个月工程化落地推理接口、评测报告、Demo展示每月的“检验标准”比“目标”更重要。因为目标容易写得虚“检验标准”逼着你想清楚什么证据能证明这个月没有白过比如第3个月的70%分步正确率写到周报里和“我学完了Transformer”是完全不同的说服力。5.2 最终交付物别只交模型很多人学完一轮手里只有一个训练脚本面试或者写简历时很难落地。我的建议是做一个完整的仓库至少包含数据生成代码与数据集说明训练配置与复现步骤评测脚本与分步准确率报告一个最简单的Web Demo实操中我推荐Streamlit或Flask别贪复杂。这个仓库本身就是“ai-engineering-from-scratch”最好的证明。以后不管换模型、换任务所有环节都能挪过来复用。数据生成的代码可以换模板复用训练配置可以改参数复用评测脚本可以接新任务复用Demo框架可以直接套到下一个项目上。这才是工程复利。最后说一点我的真实感受。所谓“from scratch”最珍贵的不是亲手写出了一个多大的模型而是你把每个环节都打开看过一遍之后建立起来的控制感。以后再拿到新的任务遇到效果不好的情况你不会只会束手无策而是能沿着数据、训练、评估、迭代这条链路一步一步定位问题。这篇文章里的很多坑我都是花了一两周才爬出来的希望你读完之后能少走几步。