1. 从零开始前先把成本账算清楚先说结论所谓 ai-engineering-from-scratch在大多数人的预期里不应该是复现ChatGPT而是亲手把一条管线的每一个环节都踩一遍——数据怎么洗、token怎么分、模型怎么搭、梯度怎么流动、loss怎么掉、推理怎么部署。我见过太多人开局就立志训练一个千亿参数模型结果卡在环境配置三个月最后连有效的数据样本都没凑够。这条路走不长。我给自己定的边界很明确不做研究型创新不做超大模型只做一条小但完整的工程链路以手写一个GPT风格的decoder-only语言模型为核心参数量控制在1亿以内在单张消费级显卡上完成训练、评估、部署闭环。目标不是刷榜而是让每个模块都能讲清楚为什么这样做。1.1 为什么我不建议一上来就复现ChatGPT很多人忽略了一个事实大型语言模型的效果背后是超出个人承受范围的工程系统而不只是模型架构。数据管道每天吞吐几十TB训练集群的稳定性、断点续训、日志告警、评估回灌、RLHF偏好数据管理每一项都是单独的工程方向。个人项目如果一上来就奔着大模型去大概率会陷入资源黑洞。更合理的方式是用一个小模型把全链路真实地走通。模型缩小的代价只是某些表面上不那么惊艳但该用的技术一样都不少——tokenizer要自己训、注意力要自己写、loss要自己盯着掉、推理要自己优化。我在做完第一版9千万参数模型后再回头去看相关论文里关于分布式训练、混合精度、长上下文的部分理解速度完全不一样了。1.2 我用一台消费级GPU就能跑通的资源方案我这里给出一份非常务实的硬件账单供参考资源项我的配置备注GPU单张RTX 4060 Ti 16GB显存16GB训练和推理都能兼顾CPU8核数据tokenize阶段比较吃CPU内存32GB数据预处理阶段会短暂吃紧存储1TB NVMe SSD数据集原始文件约200GB清洗后约80GB预算约1.5万元人民币含整机个人项目足够如果只有8GB显存的显卡也并非完全不行后面会专门讲梯度累积和offload策略。前期最容易被低估的是数据预处理对CPU和内存的要求我第一版连个像样的分词模型都没训完内存就崩了一次。建议先把数据规模切成小份一步步放大。2. 数据管线文本清洗、分词与上下文窗口的取舍2.1 从原始语料到高质量训练样本的清洗规则我的数据来源是公开爬取的网页和多份开源文本总原始量约200GB。很多人拿到语料的第一反应是直接扔进tokenizer这是最大的坑。原始网页里藏着大量重复导航栏、cookie弹窗、页面模板噪音训练出来的模型会在生成时突然冒出点击此处了解更多之类的片段。我的清洗规则按照优先级排序如下删除HTML标签、脚本块、样式块、不可见字符。按行去重再按段落指纹去重simhash的简化实现。过滤所有长度小于20个字符的段落过滤纯数字、纯标点。删除包含成人内容、暴力、赌博类关键词的文档。语言识别过滤只保留中文和英文语料。对剩下的文本做段落级别的shuffle避免同一个源站内容过度集中。清洗之后体积会缩水到40%左右。这一步不要用正则硬扛正则只处理HTML和特定模式其余用规则加权的方式做。我写了一个十层规则管道每一层都记录过滤掉的样本数量和原因方便后续复查。2.2 BPE分词把词拆成我们真正能控制的单位后续所有参数都会落在token数量上因此分词是第一个真正影响模型能力的技术决策。我选用Byte-Pair EncodingBPE直接用了HuggingFace的tokenizers库来训练一个中文英文混合的tokenizer。词汇表定在32k因为对于一个小模型超过这个规模只会让embedding矩阵吃掉太多参数量。训练BPE时有一点值得注意要在UTF-8字节级别做基础切分而不是直接按空格或字符。这样既能覆盖中文又不浪费词表容量。我的配比如下from tokenizers import Tokenizer, models, trainers, pre_tokenizers, decoders tokenizer Tokenizer(models.BPE()) tokenizer.pre_tokenizer pre_tokenizers.ByteLevel(add_prefix_spaceTrue) trainer trainers.BpeTrainer(vocab_size32000, min_frequency2) files [data/clean_zh.txt, data/clean_en.txt] tokenizer.train(files, trainer) tokenizer.save(tokenizer.json)实际训练过程中我建议开一个分词后语料长度的统计脚本看看每条样本平均token规模。这个数字直接决定你训练时的最大序列长度也决定一个batch的显存占用。2.3 上下文窗口与批次组成的联调我最初的上下文窗口设为512后来发现数据里很多长文段被硬生生截断导致模型学不到跨段的依赖。之后调整为768位置编码的表示能力有所增强但训练时间也上涨了约20%。上下文窗口不是越大越好它是一个工程权衡。在组batch时我会按序列长度做bucket分组避免一条长样本拖慢整个batch。具体做法是先把语料按token数粗略分桶每个batch尽量由长度相近的样本组成padding比例因此大幅下降。实测下来吞吐量提升了30%以上。padding浪费的不仅是算力更浪费了注意力矩阵里的无效计算。3. 从Attention到参数计数手写一个decoder-only骨干3.1 GPT风格模型的整体数据流我选用decoder-only架构也就是常说的GPT风格。它的核心思路是把语言建模当成给定前文预测下一个token的自回归任务。输入一个token序列模型通过多层Transformer计算每步的隐状态最后一层输出一个在词表上的分布训练时用交叉熵损失对比真实下一个token。实例骨干结构超参数数值词表大小32,000最大序列长度768隐藏层维度 d_model512层数8注意力头数8Feedforward隐藏层2048Dropout0.1总参数约86M这套配置下参数主要分布在三块token embedding output head32000×512×2但通常共享权重、8层Transformer的注意力和FFN层、LayerNorm与位置编码。算出来之后我对参数分布有了直觉embedding头在超小词表下依然占比很大所以后来我参考常见做法让输入embedding和输出映射共享同一套权重参数立即省了约一半。3.2 LayerNorm、因果注意力与位置编码的实现要点因果注意力是decoder-only区别于BERT的关键。实现上最优雅的方式是先构造一个上三角掩码矩阵把未来位置置为负无穷再在softmax之前加到注意力分数上。我第一次手写时先在attention分数里用masked_fill生成了上三角的极大负数走了不少弯路。核心工整的写法是import torch import torch.nn.functional as F def causal_attention(q, k, v, mask): scores torch.matmul(q, k.transpose(-2, -1)) / (q.shape[-1] ** 0.5) scores scores.masked_fill(mask 0, float(-inf)) return torch.matmul(F.softmax(scores, dim-1), v)位置编码我第一版用的是可学习的绝对位置编码简单直接小模型下完全够用。如果你打算做长上下文扩展后续可以考虑旋转位置编码RoPE它在外推性上明显更好但当时的复杂度对第一版并不友好。LayerNorm的位置也要注意Transformer里放在Attention和FFN之前pre-norm比放在之后训练更稳定。我在实验日志里对比过post-norm在同样的学习率下更快发散原因在于残差结构和梯度范数的相互作用。这个细节很多入门资料不提但实战影响极大。3.3 参数清单每个数字都该花在哪儿理解参数去向是工程调优的基础。我把自己第一版模型的参数分布记录如下模块参数量占比Token Embedding共享head32000×512 16.4M约19%位置编码768×512 0.4M约0.5%8层Attention层约40M约46%8层FFN层约25M约29%LayerNorm及其他约4M约5%从表中能看出Transformer层占了大头而其中Attention的参数量在d_model远小于词表时并不是绝对主导。如果以后要压缩模型优先减层数比减隐藏维度更见效。这些认知只有在亲手计算后才会形成。4. 训练策略学习率调度、梯度累积与显存极限实测4.1 学习率为什么小模型也需要warmup训练刚开始时模型权重接近随机如果直接用比较大的学习率梯度中的噪声会被放大导致loss陡增甚至发散。warmup阶段的本质是让模型先在小步长下适应数据的梯度分布再逐步过渡到目标学习率。我观察到warmup从零线性升到目标值步数占总训练步数的5%到10%之后采用余弦退火到最高学习率的十分之一。实测下来不给warmup的对照组在初期loss曲线上会出现一个明显尖峰。我的具体配置如下from torch.optim import AdamW from torch.optim.lr_scheduler import LambdaLR def lr_lambda(step): warmup_steps 2000 total_steps 50000 if step warmup_steps: return step / warmup_steps progress (step - warmup_steps) / (total_steps - warmup_steps) return 0.5 * (1 math.cos(math.pi * progress)) optimizer AdamW(model.parameters(), lr3e-4, betas(0.9, 0.95), weight_decay0.1) scheduler LambdaLR(optimizer, lr_lambda)对于一个9千万参数的小模型3e-4是我试下来较稳的最高学习率。如果batch size改大一倍学习率通常也可以适当上浮但幅度不要超过1.5倍否则容易触发损失震荡。4.2 梯度累积与显存极限拿8GB显存训练9千万参数我身边有朋友只有8GB显存也想跑类似规模的模型。梯度的做法是梯度累积——把多个mini-batch的梯度累加后再更新一次等效于扩大batch size。它的原理并不复杂PyTorch默认每次backward都会把梯度累加到Parameter.grad中我们只需要控制每隔多少个step执行一次optimizer.step()和zero_grad()。我使用的等效总batch是768实际每个batch为12条序列梯度累积64步12×64768。这个数字让显存占用稳定在13GB左右单纯堆batch size是办不到的。还配合了混合精度训练用torch.autocast把大部分计算降为FP16显存进一步缩减。注意loss scaling自动处理我基本没有手动介入。scaler torch.cuda.amp.GradScaler() accum_steps 64 for step, batch in enumerate(dataloader): with torch.autocast(device_typecuda, dtypetorch.float16): loss model(batch[input_ids], batch[labels]) / accum_steps scaler.scale(loss).backward() if (step 1) % accum_steps 0: scaler.step(optimizer) scaler.update() optimizer.zero_grad() scheduler.step()第一次训练时我漏掉了除accum_steps这个操作导致loss计算被放大了64倍学习率的有效步长也变得极大模型在几百步之内loss就飙升到十几。后来加上这个除法训练曲线才恢复正常。4.3 Loss曲线诊断过拟合、欠拟合与数据重复训练过程中我发现一个有意思的现象验证集loss在3.2附近开始缓慢上升训练集loss还在继续下降。很多人第一反应是过拟合但我的训练集规模足够大模型容量很小过拟合不太可能这么早出现。逐一排查后问题出在验证集和训练集存在相似文档。原始语料里同一篇文章经常出现在多个镜像站清洗阶段我只按精确指纹去重没有做近似指纹导致训练集里被学过的文章又出现在验证集造成了一个假象。把验证集严格按simhash去重后验证曲线恢复平稳。这个教训给我一个提醒loss曲线的拐点本身只是现象归因时要回到数据分布上模型只负责忠实地反映数据。5. 不只看Loss评估指标、早期停止与失败样本分析5.1 从perplexity到下游任务评估体系的搭建Loss在下降不代表模型具备实用能力我需要更贴近任务的指标。常用的perplexity等于交叉熵损失的指数形式它反映模型对下一个token的置信度但过于宏观。我为这个项目建了三层评估token级别验证集perplexity、重复率、生成多样性。句子级别完形填空准确率、句子接龙的自然度打分。任务级别简单的中文摘要测试集、英文冒犯性语言检测、基础常识问答。任务级别测试我并没有额外训练只是以zero-shot条件概率来度量。例如给模型一个不完整句子太阳从___升起看它选东和西的概率谁高。这类测试可以直接用模型的logprob获取实现成本很低但能明显反映预训练数据的质量和模型的基础世界知识。5.2 评估集上的诡异行为与我对失败样本的归因典型槽点模型就是把你的提问接龙下去而不是在回应。例如我输入中国的首都是模型更可能续写中国而并非北京。查明原因后发现我的训练语料大量来自百科和新闻的完整段落单纯的前缀继续概率统计模型会把高频共现当成目标更高频的关键词反而获得关注。这不是严重的错误但它意味着模型没有在问答意图下被微调纯粹是基座模型的正常状态。随后我做了第二次小规模数据进行监督微调准备了一批问题-答案对用普通回答的前缀作为输入目标输出放在下一段。几百个样例就能让模型在简单问答测试上的准确率从21%提升到47%。这让我意识到基座模型的常识已经有一个底部但有效的工程微调可以释放它。6. 推理部署量化精度、缓存策略与API封装细节6.1 把训练权重变成可对外服务的推理接口模型训练完后下一步就是让它能以一个合理的延迟对外服务。我用TorchServe写了一个封装服务对外暴露的API只有两个/generate和/score。generate用于自回归生成score用于计算某段文本的logprob。其中最容易被忽视的是自回归生成的KV Cache。第一次实现时我每次生成一个token都重新算一遍完整输入的注意力在768长度下生成100个token要跑几十秒。加上KV Cache后只缓存已有token的Key和Value矩阵每个新token只计算新位置的结果生成端到端速度提升大约4倍。KV Cache的核心代码思路大致如下def generate(model, tokenizer, prompt, max_new_tokens128): input_ids tokenizer.encode(prompt) past_key_values None model.eval() with torch.no_grad(): for _ in range(max_new_tokens): outputs model(input_idstorch.tensor([input_ids]), past_key_valuespast_key_values) logits, past_key_values outputs next_token logits[0, -1].argmax().item() input_ids [next_token] if tokenizer.decode([next_token]).strip() [EOS]: break return tokenizer.decode(origin_ids generated)这里要强调如果没有给模型实现padded past_key_values则无法把每步序列长度压缩为1。工程上做推理优化第一步永远是缓存这一步收益最大。6.2 量化方案的取舍INT8足够吗我最初用FP16部署显存占用约1.7GB延迟也还行但多路并发时GPU显存会迅速吃紧。而后尝试了INT8量化参数量从86M降到实际存储约86MB内存占用大约减少30%。注意这里的减少30%并不是80%因为embedding表仍然按纯FP16保存了一部分权重以及量化带来的额外结构。我用的是动态量化quantized_model torch.quantization.quantize_dynamic( model, {torch.nn.Linear}, dtypetorch.qint8 )实际操作中LayerNorm和Embedding没有被量化但Linear层大幅瘦身。跑了几百条生成结果对比发现量化后在短句生成质量上基本持平但长文本的重复率略有上升。如果你的应用是对话场景这点差异可以忽略如果用于高质量长文写作建议保留FP16。6.3 推理缓存与批处理吞吐量翻倍的简单技巧服务上线后单实例的并发能力很快就成了瓶颈。我做了两件事请求缓存和连续批处理。请求缓存适合重复性的简单问题。对于完全相同的输入直接把生成的输出缓存到内存里命中后在毫秒级返回。考虑到这个模型本身就是低资源、低并发的个人项目缓存能减少实际压力。连续批处理相对更技术一些把多个请求拼成一个batch但各请求的长度不同。最简单的方法是padding到batch最大长度缺点是越长越浪费。后来我在batch内按长度由大到小排列然后用动态padding让最长样本单独捕获最长时间其他样本可以提前结束GPU利用率明显上升。小模型在低并发下一次处理16个请求吞吐量相比逐条处理大约提升了2倍。更进阶的Continuous Batching我没有完全实现核心思路是在一个大batch里动态插入新请求同时允许完成的序列随时退出。以后如果我要部署更大一点的模型这会是一个重要优化方向。7. 从语言模型到reasoning model下一阶段的延伸思路7.1 为什么会说话不等于会推理整个预训练阶段只学习了一个能力根据前文续写下一个最可能的token。模型对我来说像一把基础武器它知道人没吃饭会饿但它不会主动把多个这样的事实链式组合起来。如果你问它一个简单数学题它照样会生成一大段貌似推理但事实完全混乱的内容。这是没有推理监督信号导致的仍然只学会了下一词的分布。近两年大家都开始讨论reasoning model本质上是把链式推理过程显式加入训练目标。在模型更弱、数据更少的规模下我能做的最直接一件事是收集一批带详细推理解释的数据进行短链路的监督微调然后再用RL风格的方法优化。不追求大型系统但不能望而却步。7.2 我在下一代项目里准备做的四件事第一把上面的9千万参数模型扩展成一个3亿参数的版本采用RoPE位置编码序列长度提升到2048。这个体量在单卡16GB显存下仍可训练只是需要更多的耐心和更长的运行时间。第二构建一套推理轨迹数据标注管线针对数学、逻辑、常识问答三类任务收集包含中间步骤的问题-解析-答案三元组。在现有模型的输出基础上进行人工修正效率比完全从零写要快很多。第三引入一个简单的过程监督信号不光奖励最终答案正确还要求中间步骤的每一步都能在语言逻辑上自洽。我会用一个小分类器去判断每一步是否与上一步和最终答案一致。这种方法需要的工作量大但对reasoning能力的提升是直接有效的。第四在推理端搭建一套真正的连续批处理服务加入FLOPs监控、延迟统计、错误回退机制。我希望下一版服务不止是能跑而是能稳定的跑。从零开始做一个AI工程项目的价值恰恰在于它逼你去面对所有技术选择。你不再有现成的完整系统可用每个细节都必须自己决策和负责。我在这条路上踩过数据清洗的坑被梯度累积的除法和注意力掩码卡过很久也曾经在一个没有问题的验证集上浪费过一周时间。正是这些看起来琐碎的东西构成了AI工程中不可回避的实体。下一轮扩展中我依然会保留从零开始的习惯先跑通一条最小但完整的链路然后逐段放大。