我一直觉得ai-engineering-from-scratch这种项目名是技术社区里最容易被低估的一类。很多人看到“from scratch”第一反应是“又一位硬核大佬在造轮子”第二轮反应是“看看就好我肯定跑不起来”。但如果你真的动手走一遍这个流程会发现它恰恰是当前把 AI 工程基础打得最扎实的一条路线。这个领域里的大部分工作其实不是“建模”而是把数据、训练、评估、部署、监控这些工程环节串起来。这篇内容我会从环境搭建讲到推理部署把可复现的步骤和我踩过的坑都摊开来说适合已经能写 Python、也跑过几次开源模型但始终觉得“哪里没吃透”的开发者。1. 先拆词AI 工程不是“跑通模型”from scratch 也不是“不用框架”1.1 AI 工程到底在解决什么问题AI 工程AI Engineering这个词最近两年被用得有点滥。有人把它等同于“用 HuggingFace 加载一个模型”也有人觉得它就是“写 Prompt 调 API”。但真正的 AI 工程解决的是从业务问题到稳定系统的完整链路数据从哪里来、怎么清洗、模型怎么选、训练怎么收敛、效果怎么评估、服务怎么部署、上线之后怎么监控。任何一个环节掉链子最后交付的东西都跑不远。举一个最典型的例子你从 GitHub 上找到一个开源推理模型下载权重写几行transformers代码它能回答你的问题。这看上去“成功”了。但等你要把这套东西放进实际项目你会发现训练数据里的脏样本会让模型输出一堆重复句子推理速度慢到用户等不了几秒就关掉页面甚至模型在测试集上表现正常一上线面对真实分布就崩盘。这些才是 AI 工程的核心挑战也是大多数人真正缺失的经验。1.2 “from scratch”的价值自己造一次轮子才知道轮子为什么这么设计“from scratch”最容易被误读成“不依赖任何现成库从矩阵乘法开始写”。真没必要这样。就像你“从零组装一台电脑”不等于自己要熔硅炼芯片而是要把 CPU、内存、显卡、电源这些部件的搭配原理搞清楚。AI 工程里的“from scratch”是指不直接套用最高层的一体化平台而是亲手把数据预处理、模型训练、权重保存、推理脚本这些环节写一遍理解每一步在做什么。这样做的好处很实际。第一你不会因为在某个框架里换了个参数导致整个结果崩掉而束手无策第二你能在出现问题时快速定位是数据问题、模型问题还是训练策略问题第三当你需要从一个开源预训练模型出发做垂直领域微调时你知道改哪里、不该改哪里。我见过的工程师里凡是能把一个 100M 参数的小模型从零训练到可用状态的人上手复杂项目时通常都更稳。这不是玄学而是因为他脑子里有一条完整的“因果链”。2. 从零起手的三个地基环境、数据和模型选型2.1 开发环境与硬件显存不够也有办法先说硬件。很多人一开始就担心“我要训练大模型没有 A100 怎么办”。其实从零做 AI 工程完全可以用消费级显卡起步。我自己早期用一张 RTX 3060 12GB 训练 0.5B 参数的小模型配合梯度累积和混合精度单卡就能跑。如果你只有 8GB 显存就把模型压到 100M~300M也一样能走通全流程。重点在于你要理解训练大模型不是目的理解工程链路才是。软件环境方面我建议使用 Python 3.10配合 PyTorch 2.x。CUDA 版本要跟显卡驱动匹配这一步最浪费时间不要凭感觉装。最省事的方法是先创建一个干净的 conda 环境然后安装torch官方推荐的版本再通过torch.cuda.is_available()验证一下是否真的能用上 GPU。如果你没有本地 GPU用云平台的免费 GPU 实例也可以只是要注意环境隔离开避免销毁实例后把训练日志也一起删掉。2.2 数据管线的三个关键动作清洗、去重、打包很多人训练小模型随便拉一个文本文件就开始train然后发现 loss 降不下去。这往往不是模型的问题是数据太脏。我在实际项目中总结了三个必做的动作。第一是清洗把 HTML 标签、乱码、重复标点、无意义 URL 全部过滤掉。别小看这一步文本质量直接决定模型输出质量训练数据里的噪声会变成模型生成的坏习惯。第二是去重如果数据里很多重复段落模型会把“背数据”当成“学语言”导致泛化能力很差。可以用 MinHash 或简单哈希对文本做相似度去重几百兆的数据量用 Python 脚本就能处理。第三是打包模型训练一般按照固定长度切段比如每个样本 1024 个 token。短文本需要用eos分隔后拼接成长样本同时注意不要把一个段落的上下文割裂得太厉害。2.3 模型选型基座模型和推理模型怎么定从零开始走一次工程最推荐先选一个小规模的自回归语言模型比如 GPT-2 风格架构参数规模在 100M~500M 之间。这个量级在单卡上能训练完推理也快适合 debug。当你对训练流程有把握之后再考虑“推理模型”reasoning model这条路。推理模型最近很火本质是在生成过程中先产出长的思维链再给出最终答案。想自己从头训练一个不是换架构而是改训练目标先在高质量数据上做监督微调让模型学会“思考后回答”然后再用强化学习算法比如 GRPO优化最终答案的正确率。从工程角度看最大的变化在于数据构造和训练策略而不是模型结构本身。先把基座语言模型训出来再在这个基础上做推理增强是一条可复现的路径。3. 亲手训练一个语言模型从 Tokenizer 到强化学习3.1 Tokenizer它决定模型“看到”什么开始训练之前你要先有一个 tokenizer。它把文本切成一个个 token再映射成数字 ID。常见的 BPE tokenizer 会把常见词保留成整体把生僻词拆成子词这样可以平衡词表大小和表达灵活度。我建议用tokenizers库训练一个 BPE 模型vocab size 设置在 8k~32k 之间。为什么不是越大越好词表越大embedding 矩阵越大参数和显存都会上涨。8k 词表适合中文或英文小体量实验32k 已经是大多数开源小语言模型的选择。这里有个小技巧训练完 tokenizer 之后一定要打印几个示例看看常见句子是不是被切得合理比如“人工智能”应该尽量被切成一个或两个 token而不是被拆得七零八落。Tokenizer 一旦训练完就不要轻易换否则后面所有数据都要重新编码。3.2 训练循环AdamW、动态学习率和混合精度训练一个自回归语言模型目标是预测下一个 token。核心训练循环里你会用到交叉熵损失优化器我首推 AdamW。学习率不要一开始就给很大我在小模型上通常用3e-4先让学习率从接近零 warm up 到目标值再用 cosine 调度慢慢衰减。为什么需要 warm up因为训练刚开始时参数和优化器的状态都是随机初始化过大的学习率容易让模型一步走到极端区域后面很难拉回来。如果你用的是 PyTorch 2.x可以很轻松地开启自动混合精度AMP使用torch.autocast把一部分计算切到半精度减少显存占用并加速训练。损失缩放需要配合GradScaler来防止精度溢出。这些小技巧单看起来都不复杂但组合起来能让你的训练时长直接缩短 40% 以上。我见过不少新手一上来就直接用float32训练显存跑满不说速度还慢得让人失去耐心。3.3 梯度累积与有效批次小显存训练大模型的偷心术单卡显存 12GB 想要训练一个 500M 模型一次性给入batch_size32几乎不可能。解决办法是梯度累积每次只算一个小的 micro batch比如 4 个样本得到梯度后先不更新权重把梯度累积到缓存里重复 8 次等效于一个batch_size32的更新。这里一定要记得有效学习率与总批次大小相关如果你把累积步数翻倍最好把学习率也微调一下否则可能出现收敛变慢。具体操作上PyTorch 里只需要在反向传播之后判断“当前累计步数是否达到目标”只在该更新的时候调用optimizer.step()和optimizer.zero_grad()。还有一个容易踩的坑使用混合精度时梯度累积期间也要保持 GradScaler 的上下文一致否则会出现数值不稳定的情况。我早期在这里卡了整整一个下午后来发现是 AMP 和梯度累积的配合出了问题。3.4 从普通语言模型到推理模型强化学习入门如果你不想止步于一个“只会续写文本”的模型可以尝试把它升级成带推理能力的模型。这里说的推理能力不是调用外部知识而是让模型学会在输出答案之前生成中间推导步骤。我比较推荐的做法是先收集一小批带有思维链示例的数据做监督微调SFT然后让模型对同一个问题生成多个候选答案用规则自动判断哪些答案正确再用强化学习算法拉高正确答案的生成概率。最容易入手的算法是 GRPO它不需要训练一个庞大的价值模型而是通过组内比较来估计优势。你只需要定义奖励函数回答格式对不对、最终答案是否正确、推理步骤是否过长且混乱。这些规则可以用字符串匹配或简单分类器实现。做完之后你会发现比起单纯扩展模型参数让模型学会“在生成时思考”往往更立竿见影。不过它也有代价推理时生成的 token 数量变长延迟更高你必须开始认真考虑推理优化。4. 评估、优化与部署让模型从“能跑”变成“能用”4.1 评估体系不要只盯着 Loss训练日志里的 loss 一直在下降会让你产生一种“马上就能上线”的错觉。真实情况是训练 loss 下降只能说明模型记住了训练数据的分布不代表它拿到了真实任务上可用的效果。我在项目里至少会做三层评估。第一层是留存集上的 perplexity用来判断模型有没有过拟合第二层是若干下游任务的 zero-shot 表现比如常用的 GSM8K 或 MMLU但对于小模型来说这些榜单分数可能很低你更需要关注趋势变化第三层是业务相关的人工评估抽 100 条测试输入逐个看模型输出是否合理并把错误分成“明显胡说”“重复啰嗦”“漏掉关键点”三类。只有三层评估都过关我才会谈部署。4.2 推理优化KV Cache、量化和动态批处理训练完成后部署又是另一场战斗。Transformer 模型在生成时每生成一个新 token 都要扫描一遍历史上所有 token 的键值向量如果不做缓存重复计算会多耗很多时间。KV Cache 就是把已经算好的键值缓存起来让后续生成只算增量部分。绝大多数推理框架都默认开启但你要知道它本质上是拿显存换时间。量化是另一个常用手段把权重从float16压到int8或int4可以在牺牲少量精度的情况下把显存占用压到原来的四分之一甚至更低。如果你只做推理不需要训练用bitsandbytes或 GGUF 格式都能轻松完成。还有动态批处理多个用户并发请求时不要一个一个处理而是把能合并的请求拼成一个 batch 推理。延迟会显著下降吞吐量可以翻倍。这些优化手段结合起来一个 7B 模型也能在普通显卡上流畅跑 Demo。4.3 部署一个最小可用的模型服务部署方案我推荐用 vLLM 这类专门为 LLM 优化的推理服务。它支持连续批处理、KV Cache 管理还能提供 OpenAI 兼容 API方便你快速对接业务。启动一个服务只需要写个配置文件把你训练好的 HuggingFace 权重路径填进去选一个合适的 GPU就能跑起来。真正要注意的是服务上线后的监控指标请求延迟、GPU 显存占用、每秒钟生成的 token 数以及模型输出的平均长度。输出长度一旦异常增长通常意味着模型进入重复循环这时候需要检查解码参数或训练数据。日志里还要记录每次请求的 prompt 和 response方便后续做错误复盘。别等到用户反馈“模型傻了”才去查主动监控能帮你避免很多尴尬。5. 常见问题与避坑手册5.1 模型不收敛先查这五件事如果你训练了很久loss 始终在一个高位震荡我建议按顺序排查第一数据是否真的打乱了有些框架默认不打乱数据会让模型学偏第二tokenizer 是否正常工作你可以先解码一个训练样本看看里面是不是有大量未知 token第三学习率是否过大或过小可以从1e-4到1e-3之间快速做一个粗调第四是否存在数据泄漏验证集的文本是不是混进了训练集第五模型的初始化或前向传播是否有数值溢出打印中间层数值分布看看。5.2 显存不够用这几招都有效显存 OOM 大概是训练中最常见的问题。第一招是把 micro batch size 降到 1第二招是开启梯度累积第三招是使用混合精度显存占用直接减半第四招是检查是否存在显存碎片尤其是在反复加载数据时可以通过torch.cuda.empty_cache()手动清理缓存第五招是使用gradient_checkpointing它对某些层不保存激活值而是反向传播时重新计算虽然变慢一点但能省出大量显存。5.3 数据质量比模型大小更影响结果这一点我强调多少次都不为过。我在小模型实验中发现把训练数据从 1GB 粗糙网页文本换成 500MB 经过清洗的高质量文本最终下游任务分数反而提升了近 10%。数据清洗不是可有可无的“洁癖”而是 AI 工程中投入产出比最高的一步。如果你想训练推理模型思维链数据的质量更关键如果示例里带着错误推理模型会学得很难看。宁可数量少一点也要保证每一条都是对的。5.4 实验记录要从第一天开始做最后分享一个心态层面的建议训练过程中一定要用 WandB 或 MLflow 记录每次实验的配置和曲线。不要嫌麻烦每个超参数、每份数据版本、每个 tokenizer 配置都要记录下来。很多失败实验其实在设计上没问题只是你没有比较基线导致重复调参浪费几天时间。有条理地记录比天赋更重要。我个人在实际操作中最深的体会是从零做 AI 工程核心不是追求模型的绝对性能而是获得一套属于自己的 debug 方法论。当你亲手把一个小模型从数据清洗训练到部署上线再回头看那些开源项目和框架的文档会突然发现原来的很多“黑盒”变得透明了。这也正是from scratch最珍贵的回报。