1. 为什么要在本地从零训练一个 64M 参数的语言模型大多数人第一次接触大语言模型都是从调用 API 开始的。调几次之后就会产生一种错觉模型是个黑盒输入一段话输出一段话中间发生了什么完全不知道。这种状态做应用没问题但如果你想真正理解语言模型是怎么工作的光看论文和博客是不够的必须亲手训练一次。问题在于训练一个像样的模型成本太高。7B 参数的模型光是加载权重就要十几 GB 显存全量微调更是需要多卡 A100 集群。对于个人开发者来说这个门槛直接把从零训练变成了只能围观。MiniMind 这个项目的价值就在这里它把模型规模压缩到 64M 参数整个训练流程——从分词器训练、预训练、监督微调到最后的对话效果验证——全部可以在单张消费级显卡上跑完甚至用 CPU 也能勉强跑通。按照项目给出的数据预训练阶段用一张 3090 大约 2 小时电费折算下来不到 3 块钱。这个规模当然做不了什么正经业务但它能让你完整地走一遍训练管线。你会亲眼看到 loss 从 10 以上降到 3 左右看到模型从输出乱码变成能简单对话看到 SFT 前后模型行为的差异。这些体感是看多少篇论文都换不来的。这篇文章我会把整个流程拆开讲数据怎么准备、分词器为什么要单独训、预训练和 SFT 的区别在哪、显存不够怎么调、训练完怎么验证效果。每一步我都会说明为什么这么做以及我在实际操作中踩过的坑。2. MiniMind 的整体架构与训练管线拆解2.1 64M 参数是怎么分配出来的先看模型结构。MiniMind 采用的是标准的 Decoder-only Transformer 架构和 GPT 系列同源。64M 参数听起来很小但拆开看其实分配得挺合理组件配置参数量占比Token Embedding词表 6400维度 512约 3.3M每层 Attention8 头头维度 64约 2.1M/层每层 FFN隐藏维度 2048约 4.2M/层层数8 层—输出投影512 到 6400约 3.3M词表只有 6400这是关键设计。常规中文模型词表动辄 5 万以上光 embedding 就占掉大量参数。MiniMind 把词表压到 6400意味着它用的是字符级或小粒度 subword 分词牺牲了一部分语义压缩效率换来的是参数预算能更多分给 Transformer 层本身。8 层、512 隐藏维度、8 个注意力头这个配置在 2020 年左右的轻量模型里很常见。它的表达能力有限但足以学会基本的语法结构和简单的事实关联。你可以把它理解成能说人话的最小可行模型。2.2 三阶段训练管线预训练、SFT、可选的对齐MiniMind 的训练流程分三个阶段每个阶段的目标完全不同第一阶段预训练Pretrain。目标是让模型学会预测下一个 token。喂进去的是海量无标注文本模型通过不断预测被遮住的下一个词来调整参数。这个阶段结束后模型能生成语法通顺的句子但不会遵循指令——你问它今天天气怎么样它可能会接着编一段新闻。第二阶段监督微调SFT。目标是让模型学会按照指令回答。数据格式变成问题-答案对模型学习的是在给定问题的情况下输出对应答案。这个阶段数据量小得多但质量要求高。第三阶段对齐可选。包括奖励建模和强化学习让模型的输出更符合人类偏好。MiniMind 把这个阶段做成可选的因为对小模型来说SFT 之后的效果已经能看出明显变化对齐的边际收益不高。注意很多人会跳过预训练直接做 SFT觉得反正预训练数据难找。但这样做的结果是模型没有语言基础SFT 阶段会非常不稳定loss 震荡严重。预训练是地基不能省。2.3 为什么这个管线值得亲手跑一遍我见过不少开发者微调过好几个模型但从来没碰过预训练。他们对模型怎么学会说话这件事的理解是断裂的。亲手跑一遍 MiniMind 的完整管线你会建立起几个关键认知第一你会理解数据质量对预训练的影响有多大。同样的模型结构喂不同来源的语料loss 下降曲线完全不一样。第二你会看到 SFT 数据格式的重要性。同样的问题答案的写法不同模型学到的行为就不同。第三你会对参数量和能力的关系有直观感受。64M 能做什么、不能做什么跑完就有数了。3. 环境准备与依赖安装中的实际坑点3.1 硬件门槛与显存估算官方给出的最低配置是单卡 8GB 显存。我实测下来预训练阶段 batch size 设为 16、序列长度 512 的情况下显存占用大约 6.5GB。如果你的显卡只有 6GB需要把 batch size 降到 8同时开启梯度累积来保持等效 batch size。显存占用的主要来源有三块模型参数本身64M 参数fp32 下约 256MB、优化器状态Adam 需要保存一阶和二阶动量约 512MB、激活值和 batch size、序列长度成正比。前两块是固定的第三块是你能调的。如果你只有 CPU也能跑但速度会慢到令人发指。我试过用 8 核 CPU 跑预训练一个 epoch 要十几个小时。建议至少有一张 6GB 以上的 N 卡。3.2 依赖安装的版本陷阱MiniMind 依赖 PyTorch、transformers、datasets 这几个核心库。安装时最容易出问题的是 PyTorch 和 CUDA 的版本匹配。我的建议是直接用官方推荐的组合pip install torch2.1.0 torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 pip install transformers4.36.0 datasets2.16.0 pip install sentencepiece protobuf这里有几个坑要说清楚。第一transformers 版本不要装最新的4.36 之后的版本改了一些 APIMiniMind 的代码可能不兼容。第二sentencepiece 是训练分词器必须的但它的编译依赖比较多如果 pip 装不上可以试试 conda。第三protobuf 版本冲突是常见问题如果报错说 descriptor 相关降级到 3.20.x 通常能解决。提示装完之后跑一句python -c import torch; print(torch.cuda.is_available())确认输出是 True。如果 False说明 CUDA 没配好后面训练会直接报错。3.3 目录结构规划在开始之前建议把目录结构规划好不然后面数据、模型、日志混在一起很难管理。我的做法是minimind/ ├── data/ │ ├── raw/ # 原始语料 │ ├── processed/ # 清洗后的数据 │ └── sft/ # SFT 数据 ├── tokenizer/ # 分词器文件 ├── checkpoints/ # 训练中间产物 ├── outputs/ # 最终模型 └── logs/ # 训练日志这个结构不是必须的但能让你在训练中断后快速定位到该从哪里恢复。4. 分词器训练被大多数人忽略的关键一步4.1 为什么不能直接用现成的分词器很多人会想直接用 BERT 或 GPT 的分词器不就行了技术上可以但效果会打折扣。现成分词器的词表是针对大规模通用语料训练的词表动辄几万。MiniMind 的模型维度只有 512如果词表是 5 万embedding 层就会占掉 2560 万参数接近总参数的一半留给 Transformer 层的预算就不够了。所以 MiniMind 选择自己训练一个 6400 词表的分词器。这个规模的分词器embedding 层只占 330 万参数剩下的 6000 多万参数都能用在真正的计算层上。4.2 用 sentencepiece 训练分词器的完整流程训练分词器的代码大致是这样import sentencepiece as spm spm.SentencePieceTrainer.train( inputdata/processed/corpus.txt, model_prefixtokenizer/minimind, vocab_size6400, model_typebpe, character_coverage0.9995, num_threads8, pad_id0, unk_id1, bos_id2, eos_id3, )几个参数需要解释。model_typebpe表示用字节对编码这是目前最主流的选择平衡了词表大小和语义粒度。character_coverage0.9995表示覆盖 99.95% 的字符剩下的作为 unknown 处理。这个值不要设成 1.0否则遇到生僻字会出问题。pad_id、unk_id、bos_id、eos_id这四个特殊 token 的编号要记牢后面数据处理和模型定义都要用到。MiniMind 用的是 0/1/2/3 这套编号和很多开源模型不一样别搞混。4.3 分词器质量怎么验证训练完之后一定要验证分词器的效果。我一般会做两个测试第一编码解码一致性。随便找一段中文编码再解码看是否和原文一致。如果不一致说明有字符没被覆盖。第二压缩率。统计一段文本编码后的 token 数量除以字符数。中文的理想压缩率在 0.6 到 0.8 之间也就是一个 token 对应 1.2 到 1.6 个汉字。如果压缩率接近 1说明分词器粒度太细模型学起来会吃力。sp spm.SentencePieceProcessor() sp.load(tokenizer/minimind.model) text 今天天气不错适合出去走走。 tokens sp.encode(text, out_typestr) print(tokens) print(f压缩率: {len(tokens) / len(text):.2f})我踩过的一个坑是语料里有大量英文和数字但训练时没做归一化导致分词器把每个数字都当成独立 token。后来在预处理阶段加了全角转半角、数字统一处理压缩率才正常。5. 预训练阶段数据、参数与 loss 曲线解读5.1 预训练数据从哪来、怎么清洗MiniMind 官方推荐用开源中文语料比如维基百科 dump、新闻语料、小说文本。数据量不需要很大几 GB 纯文本就够 64M 模型学出基本语言能力。清洗流程我总结成四步去重用 MinHash 或简单的哈希去重去掉重复段落。重复数据会让模型过拟合。过滤去掉长度过短少于 10 字或过长超过 2048 字的样本去掉含大量特殊符号的样本。归一化全角转半角、统一标点、去掉多余空白。拼接把所有文本拼成一个长文件用分词器编码成 token id 序列存成二进制文件。这里有个细节预训练数据的拼接方式会影响训练效率。如果每条样本单独 padding 到固定长度会浪费大量计算在 padding token 上。更好的做法是把所有文本拼成一条长序列然后按固定长度切块。这样每个 batch 都是满的没有浪费。5.2 关键超参数怎么定预训练的超参数直接决定训练能不能收敛。我整理了一份实测可用的配置参数值说明batch_size168GB 显存下的安全值seq_len512再长显存不够learning_rate3e-4小模型可以用大一点warmup_steps500防止初期 loss 爆炸weight_decay0.01常规正则化grad_clip1.0梯度裁剪必开epochs3再多会过拟合学习率是最关键的。3e-4 对 64M 模型来说偏大但配合 warmup 和梯度裁剪是安全的。如果你发现 loss 在前几百步震荡剧烈把学习率降到 1e-4 试试。5.3 loss 曲线怎么看、异常怎么处理正常的预训练 loss 曲线应该是前 500 步快速下降从 10 左右降到 5 以下然后进入缓慢下降期几千步后稳定在 3 到 4 之间。如果出现以下情况说明有问题loss 不降反升学习率太大或者数据有问题。先检查数据里有没有大量乱码。loss 降到 2 以下可能是过拟合或者数据重复度太高。检查去重是否彻底。loss 震荡剧烈batch size 太小或者梯度裁剪没开。loss 卡在某个值不动模型容量不够或者学习率衰减太快。我实测下来3 个 epoch 大约 15000 步loss 能稳定在 3.2 左右。这个水平的模型生成的中文已经语法通顺但逻辑性一般。提示训练过程中一定要定期保存 checkpoint。我遇到过训练到一半断电的情况没有 checkpoint 就只能重来。建议每 1000 步存一次。6. SFT 微调让模型学会回答问题6.1 SFT 数据的构造逻辑预训练完的模型只会续写不会问答。SFT 的目的就是教会它看到问题输出答案这个模式。数据格式通常是bos问题今天天气怎么样答案今天天气晴朗气温适宜。eos关键在于问题和答案之间要用固定的分隔符让模型学会区分。MiniMind 用的格式比较简单你可以根据自己需求调整。SFT 数据量不需要大几千到几万条就够。但质量要求高答案要准确、简洁、风格统一。如果答案风格混乱模型学出来的行为也会混乱。6.2 训练参数与预训练的区别SFT 阶段的超参数和预训练有明显区别参数预训练SFTlearning_rate3e-41e-5epochs33-5batch_size168数据量GB 级MB 级学习率要降一个数量级因为模型已经有基础大学习率会破坏预训练学到的知识。batch size 可以小一点因为数据量小小 batch 反而有助于跳出局部最优。6.3 怎么判断 SFT 是否成功SFT 成功的标志不是 loss 降到多低而是模型行为的变化。训练前后各测几个问题对比输出训练前模型可能会续写问题比如问今天天气怎么样它输出今天天气怎么样我这边也是……训练后模型应该直接回答比如今天天气晴朗适合外出。如果训练后模型还是续写说明 SFT 数据格式有问题或者学习率太大把预训练知识冲掉了。我踩过的一个坑是SFT 数据里问题和答案的比例失衡问题太长答案太短导致模型学会了忽略问题直接输出短句。后来调整了数据配比问题答案长度接近 1:2效果才正常。7. 训练完成后的效果验证与推理部署7.1 用哪些指标评估小模型64M 模型不能用 MMLU 这种 benchmark 来评它肯定不及格。更实际的评估方式是语法正确性生成的句子是否通顺有没有明显的语法错误。指令遵循给定简单指令模型是否按指令输出。事实一致性问一些常识问题看回答是否离谱。多样性同一个问题多次生成输出是否有变化。我一般会准备 20 个测试问题人工打分。分数不重要重要的是对比训练前后的变化。7.2 推理时的参数调节推理阶段有几个参数可以调outputs model.generate( input_ids, max_new_tokens128, temperature0.7, top_k50, top_p0.9, repetition_penalty1.1, )temperature控制随机性0.7 是比较平衡的值。top_k和top_p是采样策略配合使用能避免生成重复内容。repetition_penalty对小模型特别重要因为小模型容易陷入重复循环。7.3 部署到本地的最简方案训练完的模型可以存成 Hugging Face 格式用 transformers 直接加载from transformers import AutoModelForCausalLM, AutoTokenizer model AutoModelForCausalLM.from_pretrained(outputs/minimind-sft) tokenizer AutoTokenizer.from_pretrained(tokenizer/minimind)如果想做成服务可以用 FastAPI 包一层几十行代码就能跑起来。不过要提醒一句64M 模型的推理速度很快CPU 上也能做到实时响应但输出质量有限适合做演示或教学不适合生产环境。8. 几个只有亲手跑过才会知道的细节第一个细节预训练数据的顺序会影响收敛速度。我试过把维基百科放在最前面、小说放在最后结果模型前期学得很快后期 loss 下降变慢。后来打乱顺序整体收敛更平滑。原因是不同来源的文本难度不同集中喂同一类数据会让模型在某个阶段过拟合。第二个细节SFT 之后模型会变笨。这是正常现象因为 SFT 数据量小模型会偏向于模仿 SFT 数据的风格损失一部分预训练学到的通用能力。如果你发现 SFT 后模型连基本的续写都不会了说明 SFT 过头了减少 epoch 或降低学习率。第三个细节分词器的特殊 token 编号一定要和模型定义一致。我有一次改了分词器的 bos_id忘了同步改模型配置结果训练出来的模型输出全是乱码。排查了半天才发现是编号对不上。第四个细节显存不够时梯度累积是比降低 batch size 更好的选择。降低 batch size 会影响梯度稳定性而梯度累积可以在保持等效 batch size 的同时降低显存占用。具体做法是每算 N 个 micro-batch 才更新一次参数。第五个细节训练日志要记全。除了 loss还要记学习率、梯度范数、显存占用。梯度范数突然变大通常意味着要出问题提前干预能省很多时间。这套流程跑下来你对语言模型的理解会从知道概念变成知道每一步在干什么。64M 模型的能力边界很清楚但训练它的经验可以迁移到任何规模的模型上。