你说你要从零开始搞AI工程但你现在大概率正躺在收藏夹里吃灰。我身边有太多人买过《Build a Large Language Model From Scratch》的中文版也有人保存了一堆“从零训练一个模型”的视频链接真正跑通一遍的凤毛麟角。问题不在资料不够而是大多数人不知道“从零开始”到底意味着什么更不知道这条路值得走的真实成本。这篇内容我想跟你聊透一件事AI工程里的“from scratch”到底是从哪个零开始以及一个从业者真正动手时该走哪几步。我把自己的路线图、参数配置、踩过的坑全摊开在这里希望能帮你少走几个月的弯路。1. 从零开始做AI工程的路线图先想清楚“为什么”1.1 所谓“从零开始”到底是从哪个零开始我见过太多人一上来就问“怎么从零训练一个大语言模型”结果聊两句就发现他就是想调一个现成的开源模型做微调。“从零”这个词在AI工程里至少有四个不同的起点从数据开始自己采数据、清洗数据、构造高质量语料库然后用别人的模型架构去训练。从架构开始自己写Transformer、写Attention、写位置编码不直接用现成的库把模型定义和训练循环全部从纯数学公式实现。从推理开始基于现有开源模型自己动手实现推理逻辑、KV Cache、采样策略理解模型从输入到输出的完整链路。从工程部署开始把训练好的模型接入实际业务解决延迟、吞吐、显存、成本这些问题。任何一个方向都值得花时间但它们产出和难度完全不同。坦白讲如果你没有训练过哪怕一个小模型直接去读那本经典书效率会很低。更合理的路径是先搞清楚自己想解决什么业务问题再选择“零”的起点。我个人的建议是第一轮“从零”选择最小闭环第二轮再扩展。也就是先基于一个开源小模型跑通全流程——数据处理、训练、评测、部署把工程感建立起来然后再动手去复现架构细节比如自己写一个单卡能跑起来的Transformer训练脚本。这样既不会因为目标过大而放弃又能真正积累底气。1.2 四条路线推理模型、大语言模型、专用模型、Agent网上现在最热的话题是“build a reasoning model from scratch”和“build a large language model from scratch”。新闻和收藏夹不会告诉你的是这两条路线差异极其巨大你的机器配置决定了你该走哪条。推理模型Reasoning Model核心任务不是学知识而是学会“多用一步思考再回答”。这类模型在数学、逻辑、代码层面的进步明显训练时需要构造大量推理链数据并配合强化学习或蒸馏技术。适合你手里预算有限但想把现有开源模型“变聪明”的场景。大语言模型LLM核心任务是把通用知识和语言能力压缩进参数里。这条路需要的数据量极大、算力门槛极高单机甚至几台机器都撑不起一次像样的全量预训练。个人开发者做这个基本是在交学费。专用模型Domain Model在通用模型基础上专攻某一个业务域比如法律、医疗、客服。这条路对数据和评测的要求远高于对机器配置的要求是目前普通团队最容易出成果的方向。Agent工程严格说不算“训练模型”而是用现成模型组装解决复杂任务的工作流配合工具调用、记忆、规划机制。它的代码编写量大但算力成本极低见效最快。这四条路线其实可以形成一个递进关系。我周围绝大多数能坚持半年的朋友都是从第四条路线的产品感受到位后开始反向补第一条路线的知识。你先搞清楚你的目标是“会调模型”还是“会造模型”这决定后面三个月你该干什么。1.3 路线选择的四个判断维度在选择具体路线的时候我建议你用四个维度来打分别凭感觉维度权重建议判断方式算力预算40%你每月能承受的GPU租赁/购买成本是多少时间投入20%每天能保证多少小时连续开发业务资源25%是否有来自真实业务的独有数据支撑团队技术栈15%团队成员对Python/深度学习框架的熟悉程度举个例子你手里只有一两张消费级显卡显存24G左右时间和代码能力都一般那么直接走“从零训练LLM”显然不合理。更现实的选择是用开源的7B或13B模型做量化推理和LoRA微调然后花时间补数据工程和评测这套方法论。理由非常朴素消费级显卡上的全量训练跑一次实验就要一周而微调一次只要几小时实验密度决定了你的学习效率。反过来如果你手里有H系列级别的算力预算那你完全可以考虑做一个“从零开始的领域推理模型”用开源底座蒸馏推理能力再配合自采数据继续训练。这条路径兼顾了“造模型”的成就感和“出交付”的现实约束。2. 数据工程很多人以为“从零”是从代码开始其实是从这里开始2.1 数据清洗与去重决定了你模型的下限我见过不少新手花了一周时间把模型代码写好然后直接把网上爬下来的语料喂进去训练出来的模型一开口就是重复的垃圾话。为什么因为数据里充斥了大量重复内容、模板化文本和隐藏的噪声标签。模型学习的是统计规律你给它的语料有多脏它输出的内容就有多脏。清洗这一步没有太多花活核心就是三板斧重复检测按文本的哈希值做精确去重再按n-gram重叠率做模糊去重。模糊去重时我用的是MinHashLSH把大规模语料的相似度计算复杂度降到一个可以接受的范围。质量过滤基于启发式规则比如文本长度、标点覆盖率、字母数字比和分类器打分用一个小模型判断文本是否为高质量内容联合过滤。安全过滤把涉及个人信息、违规内容的文本直接丢掉这一步不是形式是为了让后续工作不会招惹麻烦。清洗完之后还需要解决“缺数据”的问题。一个常见做法是合成数据。我试过用强大的商用模型做教师模型让它输出领域相关的问答对、思维链样本再用规则过滤。这里有个重要细节合成数据比例不要超过整体训练数据的30%否则模型会学到教师模型的风格偏置生成内容会越来越“同一个味儿”。2.2 Tokenization比你想的更影响训练效果很多人都会用现成的Tokenizer直接开工但如果你真想做“from scratch”我建议至少在概念层面吃透Tokenization的原理否则你会被很多诡异现象卡住。Tokenizer的本质是“字词与ID之间的映射表”。它的粒度选择直接影响序列长度、计算效率与跨语言能力。常见的三种做法Word-level直接按空格或标点切词。简单粗暴但词表巨大遇到未登录词只能丢成UNK小语种直接报废。Character-level按字符切。词表极小但序列变长模型需要花大量参数去学习字符组合规律训练成本高。SubwordBPE/Unigram介于两者之间把常用词根或词缀切成子词单元。GPT、LLaMA系列用的基本都是这类方案。如果你打算从子词单元开始训练自己的Tokenizer有个容易忽略的坑vocab_size设置得太大embedding矩阵会吃掉大量显存。比如vocab_size50kembedding维度4096光embedding层的参数量就是50k×4096≈2亿约800MB的显存只为了存词向量。这也是为什么很多小模型干脆直接复用大模型的Tokenizer因为重新训练一个更优的Tokenizer需要的数据量和调参成本实在太高。动手做的时候我建议你把vocab_size控制在模型参数总量的1/10左右然后再配一个足够大的语料来训练BPE。最终词表里不确定要留多少token可以用一个简单的经验法则跑一次小规模的训练观察不同token的出现频率分布把出现次数极少的token抛弃掉换成语料里更常见的片段。2.3 数据配比与课程学习训练数据不像炒菜不能把所有的料一股脑倒进去。不同来源的数据对模型能力的影响方向是不一样的。通用网页文本给模型常识代码数据给模型结构思维数学推理数据给模型逻辑链能力对话数据给模型交互感。我推荐的做法是先按业务目标定一个基础配比比如通用网页语料45%代码数据20%领域专业知识20%对话与指令数据10%思维链/推理样本5%然后引入“课程学习”的思想让训练过程由易到难。具体操作上前10%的训练步数只喂高质量、低难度的通用语料用来稳定loss中间80%混入业务数据和代码数据最后10%加入指令和推理数据。这样做的好处是让模型先学会语言基础再去学复杂映射收敛稳定很多。我还试过一个更激进的做法把同一份数据从粗到细过三遍第一遍用长截断的文本第二遍用中等截断第三遍用核心片段等价于让模型看数据时先看轮廓再看细节。效果上评测分数略有提升但提升最大的其实是训练稳定性——loss曲线少了很多毛刺这点在后面的章节会展开说明。3. 架构选型与训练配置不追求最前沿追求可复现3.1 架构选型Transformer是默认项但不是唯一项自己训练模型时最容易犯的错误是一上来就堆最新架构Mamba、混合专家、多查询注意力全都要。实际上模型架构没有优劣只有匹配不匹配。如果你只是单卡做微调或小规模预训练标准的Decoder-only Transformer RoPE SwiGLU Pre-Norm就够了。这四个组件的组合已经被无数模型验证过稳定可靠复现资料也多。等你把训练链路跑通再逐步替换成Grouped Query Attention省显存或者尝试Mamba之类的线性注意力心里有底得多。我踩过一个真实的坑有一版实验用了带MoE的架构但负载均衡loss权重没调好结果大量token掉进同一个专家模型后期loss完全降不下去。后来我花了三天检查数据、调学习率都没用最后定位到是MoE路由塌缩。这场事故教会我一个原则第一次做新实验时把模型规模砍半确认baseline能稳定收敛后再放回完整配置。3.2 超参数选择与缩放律训练参数不要瞎猜至少先看一下经典的Scaling Law公式再决定。简单版本是模型参数量N、训练数据token数D与最终loss之间存在幂律关系。也就是说如果你把模型参数翻倍但数据量不翻倍收益会迅速边际递减。实际操作上我通常按照这个顺序定参数根据可用的总GPU显存反推模型参数量的上限。用经验法规定训练token数大约是模型参数量的20~40倍。比如训练一个1.3B的模型语料量大概在26B~52B tokens之间。学习率峰值设置在1e-4到3e-4之间先跑500~1000步观察loss是否按预期下降。batch size不超过总token数的0.5%防止模型更新步数过少。这里有一个具体计算案例假设你有4张A100每张80G目标训练一个7B模型。粗略估算7B模型在BF16混合精度下模型权重加优化器状态加梯度大约需要权重7B×2Bytes 14GB梯度7B×2Bytes 14GBAdamW优化器状态参数7B×4Bytes 动量7B×4Bytes 56GB这意味着每张卡至少要90GB以上4张A100也只能勉强塞下且没有空间放激活值。这个估算直接说明了一个残酷事实单人或小团队用商用卡全量训练7B经济上完全不划算LoRA或QLoRA微调才是现实选择。如果你想训练自己的模型把目标定在0.5B~1.5B之间卡的压力会小很多。3.3 优化器与学习率调度优化器方面AdamW是绝对的主流理由很朴素它处理稀疏梯度和不同参数尺度差异的能力比SGD稳得多。很多人为了省显存换用AdamW的8bit版本我建议你在第一次跑通时不要换保持标准版本线路通了再去优化显存。学习率调度我用的是warmup cosine decay。推荐配置warmup步数占总步数的3%-5%然后用余弦退火把学习率从峰值逐步降到峰值的1/10左右。warmup的目的是防止初期梯度爆炸会掉得很快不用慌。cosine decay到后期loss也会有平台期这个和模型的学习能力无关更多是数据信息已经被充分榨取的表现。顺便提一句batch size的bs趋势在传统分布式训练里增大batch size通常会要求同步提高学习率。如果你把batch size从128调到512同时不动学习率模型大概率收敛明显变慢。一个粗略的参考是把学习率乘以sqrt(4)即2倍。这个关系不完全精确但能保证训练不至于崩掉。4. 训练过程的关键细节看懂loss曲线救你无数次4.1 Loss曲线怎么读不是所有下降都值得开心训练早期的loss曲线往往像心电图抖动很大这很正常。真正要留意的是以下几个信号Loss平台期连续几千步loss不变你需要检查是否存在数据泄漏导致模型记忆了答案或者数据配比失衡比如领域知识太多太重复。Loss反弹出现过拟合的典型信号或者学习率过高。先降学习率如果还反弹再检查数据重复率。Loss突刺个别step loss突然飙升后又恢复多半是某个batch里混入了异常数据或优化器状态被极端梯度污染了。我的处理办法是在数据管线里加配置文件式的过滤规则把文本长度异常超大或超小的样本直接丢出训练集。每当我看到新手在loss平台期调了半天模型架构我就知道他把因果关系搞反了大多数情况下loss平台期跟你的模型架构没关系而是数据和训练配置出了偏差。我有个快速诊断流程先用同一个模型跑一个极少量的子集比如5000条样本如果loss能顺畅下降说明架构代码没问题如果再跑一个完整数据的子集loss下降变慢就能坐实是数据问题。4.2 训练稳定性问题与检测训练崩溃NaN、梯度爆炸是每个人的必修课。最常见的三个原因学习率过大解决方法是Warmup 梯度裁剪把梯度范数裁剪到1.0左右。数据数值异常文本里有超长的数字串或特殊字符会让注意力计算中的Softmax进入饱和区。建议在Tokenizer阶段直接设置max_length超长截断。混合精度精度不足FP16在小梯度值下会下溢建议用BF16它对loss值范围的容忍度高得多。训练中途千万不要只盯着loss看。有条件就定期如每500步跑一次小评测集看BLEU、准确率或者人工抽样的文本质量。我见过一个模型loss从2.1降到1.8看着很漂亮生成出来的中文却全是“的”和“了”因为这是最容易拟合的统计模式。loss是代理指标最终要解决的业务问题才是真目标。4.3 微调与强化学习从“会说话”到“会推理”如果你是走“build a reasoning model from scratch”这条路训练流程跟普通预训练完全不同。核心分三个环节构造思维链数据每个训练样本包含“问题-思路-解答”三段。思路部分不要只写一句话要展开成多步推理已知条件、中间结论、候选方案排除、最终推导。为保证数据质量我习惯先用规则图谱校验结果再人工抽检5%。监督微调SFT把构造好的思维链数据用标准交叉熵损失微调底座模型这个阶段让模型理解输出格式和推理节奏。训练时注意让模型学习的是“思考过程”而不只是“答案格式”因此loss的计算不能只放在答案部分思路部分也要参与训练。偏好优化DPO这一步比PPO稳定得多不需要额外训练一个奖励模型。核心逻辑是收集同一个问题下“模型自己生成的多种解法”让领域专家或规则系统打分把正确答案对上的样本归为偏好对然后通过DPO来加大正确解法和错误解法的概率差。我自己在DPO里踩过的坑是温度参数太高导致采样出的负样本过于离谱。负样本如果差到完全不在谱上DPO会让模型过度收敛到“只输出唯一标准话术”失去多样性。调整方法是把采样温度控制在0.7到0.9之间并用拒绝采样过滤掉明显低质量的负样本。5. 推理与部署模型训完这才是真正价值兑现的开始5.1 推理显存估算为什么模型能跑但服务跑不动训练完成之后很多人马上把模型部署上线结果发现单个并发请求都喘不过气。原因在于推理阶段除了模型权重占用的显存还有KV Cache这个最大隐性开销。KV Cache的大小计算公式并不复杂KV Cache字节数 2K和V两组 × 层数 × 注意力头数 × 头维度 × 序列长度 × 精度字节数举个例子一个7B模型通常有32层32个注意力头头维度128如果用户输入的序列长度是2048单头单层的KV Cache 2 × 2048 × 128 × 2BytesBF16 1MB单层全部注意力头 32 × 1MB 32MB全模型 32层 × 32MB 1GB也就是说每处理一个2048长度的序列单靠KV Cache就要吃掉1GB显存。如果你的服务同时来4个并发就得预留4GB以上给缓存。很多人没算清这笔账选了“看起来够用”的显存结果上线第一天就被流量击穿。好在现有推理框架已经内置缓存管理比如vLLM的PagedAttention把KV Cache按页管理能明显提升显存利用率。我的建议是部署前先压测调好max_num_seqs和gpu_memory_utilization参数这个参数决定多大比例的显存被用来做缓存设置为0.85通常是安全值。5.2 量化选型从FP16到INT4的取舍量化是我认为对普通团队“最友好的性能优化”方案。它思路朴素把模型参数从高精度浮点数压缩成低精度整数。常见方案有方案精度显存占用7B模型质量损耗适用场景FP16/BF1616bit~14GB无基准测试、追求最高质量INT8W8A88bit~7GB极小延迟敏感型业务INT4W4A164bit~4GB中等显存紧张的本地部署选择哪个取决于模型是“输出给用户直接看”还是“输出给另一个模型解析”。如果是前者INT4在复杂逻辑任务上的生成质量下降能感知到如果是后者量化带来的语义理解偏差可能让整个人Agent流水线出错。所以我在做Agent系统的模型路由时会优先把好模型部署给“复杂推理”节点量化版本部署给“简单抽取”节点这样既控制了成本又保住了体验。5.3 投机采样把速度再提升一档如果你把模型部署到实际业务里大概率会遇到一个问题单卡推理速度跑不满用户的等待耐心阈值。这时除了上更小模型、换量化还有一个被很多人忽略的正向加速手段——投机采样Speculative Decoding。它的核心思路是用一个小模型draft model快速生成一串候选token大模型target model再一次性验证这串token是否可接受。如果小模型足够聪明能猜中大部分token那么大模型只需要做一次批量前向就能确认推理延迟大幅降低。如果猜错了就退回正确位置重新生成保证最终输出和大模型单独生成的概率分布完全等价。实操上我用过LLaMA系列小模型做draft model将大模型的同一序列长度推理提速约1.6-2.1倍。但有个前提条件小模型和主干模型的词表必须完全一致否则无法直接做token映射。如果你的draft model词表与大模型不一致就得先在词表层面做对齐这个工程量有时候比提速收益还大。6. 评测、对齐与踩坑记录模型好不好最终要拿到场景里验一验6.1 评测集通用基准是参考自己造的才是信任BBH、MMLU、HumanEval这些公开基准可以帮你横向对比模型能力但你最终要解决的具体任务它们很可能根本覆盖不到。所以我会做一套“领域评测集”流程如下从历史业务数据中抽取真实请求人工标注正确答案构建大概200-1000条样本的小评测集。把评测集按难度分成三档简单单步知识检索、中等多步推理、困难条件约束不明确。每次训练后跑全量评测记录分档准确率而不仅仅是总分。这样做的好处是能快速判断新迭代是全面变强还是靠牺牲某类能力换另一个指标。举个真实例子有一次我调高数据里代码的比例MMLU分数只是小降但领域评测里的“长文档归纳”分档准确率掉了近10个点。如果只看通用基准这次迭代会被误判为“无损升级”。6.2 对齐的基本功从安全话题到风格控制对齐Alignment不是玄学本质上是“让模型输出符合人类期望”的系统工程。最基础的三板斧指令遵循训练时把指令与回答的边界规范成固定模板让模型学会区分“命令”和“内容”。拒绝能力当请求明显超出模型能力或违反基本规则时模型应能明确表示无法完成而不是强行生成模糊答案占位。这需要在训练数据里有意识地构造负面样本。风格控制如果业务场景是客服输出必须简洁温和如果是代码助手输出必须结构清晰。风格对齐可以在SFT阶段通过大量干例子完成也可以在推理阶段用System Prompt约束。从我实践来看很多新手把对齐当成“加一段prompt”这是天大的误解。Prompt只是在推理时约束模型对齐是在训练时重塑模型两者的力度差异巨大。举个直观例子一个未对齐的模型你给一万句“请友善回答”的提示它可能还是输出嘲讽但你要是SFT阶段用两万条友善风格的语料教它它会自发地保持稳定语调。6.3 实操中的高频坑一份值得收藏的避坑清单我把过去踩过的坑整理成一个速查表希望能帮你绕开问题现象可能原因处理方法训练loss一直不降数据没有洗好或学习率过小先用小数据集验证代码是否跑通再看数据清洗验证集loss回升训练数据与验证集有重叠做严格去重检查数据泄漏输出内容重复上下文长度超出训练时的长度重新统计训练语料的长度分布适当增加截断中文生成英文词表中中文token数量太少换一个中文友好的Tokenizer或扩充中文语料模型推理非常慢未使用KV Cache或未做缓存复用框架默认开启检查配置是否被关闭部署后首字延迟很高Prefill阶段计算量过大优化首字延迟考虑用更小块来切分输入第6条值得多说两句。推理延迟分两段首字延迟用户发出请求到第一个字返回的时间和整体延迟整个回复生成结束的时间。很多人只盯整体延迟忽略了首字延迟是用户感知最强烈的指标。首字延迟的主要消耗在Prefill阶段也就是对输入序列做并行预计算。输入越长首字延迟越高。如果一个用户粘性很高的应用首字延迟超过3秒体验一定崩。优化方向是缩短每次请求的输入长度比如把无关历史折叠掉、用投机采样减少生成轮数、或把计算密度低的请求路由到小模型。最后我写这篇长文的时候又回想起自己第一次在单卡上跑通一个小模型的训练流程时一百多个小时后看到loss降到一个理想范围那一刻确实有“一扇门打开”的成就感。但真正让我受益的是之后无数次在推理环节被显存击穿、在评测环节被领域指标打脸、在部署环节被延迟折磨出来的工程感。如果你问我现在开始从零做AI工程第一步该干嘛我的回答不是“去租GPU”也不是“去看那本经典书”。而是先拿到一份真实业务的数据哪怕只有几千条然后在你熟悉的框架里把一个开源小模型微调起来跑通评测和部署。这一步做完你自然知道自己下一个“零”在哪里。最后分享一个我从踩坑中摸索出的习惯每次实验之前先写半页实验笔记记录数据版本、模型配置、预期结果、评估方式。不用写得多高级但一定要写清楚“为什么做这个实验”。AI工程最贵的不是显卡是时间而减少时间消耗最好用的工具就是记下你上次踩坑的位置。