最近我把 minimind 这个项目完完整整跑了一遍一块 3090一份自己动手清理的中文语料从随机初始化的权重开始训练一个只有 64M 参数的小语言模型总共烧了大概 2 小时电。网上聊大模型的教程多到泛滥但绝大多数是讲怎么调 API、怎么微调开源权重真正敢带你把“从零预训练”这件事走一遍的少之又少。这篇就记录我这次实测的完整过程顺便回答一个问题一个 64M 参数的小模型从零训练 2 小时到底能干嘛、不能干嘛。先给结论省得你往下翻它能学会说“通顺的人话”能续写、能生成看起来像样的中文短句但它记不住事实、不会推理、答不了复杂问题。它适合用来理解 LLM 的训练机制、验证想法、做教学实验不太适合直接当生产力工具。如果你是刚接触 LLM、手里只有一张消费级显卡、想看看“大模型到底是怎么从随机权重长出语言能力”的人这篇实测经验应该能帮你少走不少弯路。1. 先聊聊 64M 这个规模到底意味着什么1.1 不是所有模型都要 7B 起步一说到训练语言模型很多人脑子里只有 GPT-3 的 175B、Llama 的 70B动辄就是几千张显卡跑几个月。这个印象不能说错但它吓退了绝大多数想在本地玩一玩的人。实际上语言模型的能力不是“有或没有”的突变而是随着参数量、数据量、训练时长连续增长的。64M 参数是什么概念它大约只有 7B 模型的百分之一放在大模型圈子里连“小不点”都算不上。但正因为小它才能在单张显卡上、在几个小时内完成从零训练。我这次选 64M 这个规模不是因为它能打而是因为这个量级恰好处在“训练成本可接受”和“效果可观察”的交叉点上。再小比如 10M可能连流畅的短句都生成不了实验做起来没有成就感再大比如 500M虽然能力更强但单卡训练时间会从小时级变成天级调试一次的成本翻倍都不止。64M 是一个能让你完整跑通“数据准备、模型设计、训练、评估”全流程的甜点尺寸。这里也顺带说一句很多人搜“小模型”会跑到电路领域的 CMOS 小信号模型去那是模拟电路里的概念跟本文说的神经网络语言模型完全不搭边。我们在 LLM 语境下说的小模型指的是参数量很小的 Transformer 模型。它依然拥有完整的注意力机制、多层网络结构只是每一层都更窄、层数更少所以计算量小、显存占用低适合在本地玩。1.2 minimind 项目到底做了什么minimind 这个开源项目的核心价值就是告诉你“一个语言模型是怎么从零开始被训练出来的”并且把所有代码、配置、数据流程都摊开给你看。它不是调用现成框架的配置文件而是把训练循环、模型定义、数据加载这些核心代码都浓缩在一个简洁的工程里特别适合拿来当教学模板。我拿到的这个版本工程结构大致长这样minimind/ ├── config/ # 模型和训练参数配置 ├── data/ # 语料存放与预处理脚本 ├── model/ # Transformer 模型定义 ├── train.py # 从零训练入口 ├── generate.py # 训练完的推理生成脚本 └── utils/ # 分词、数据加载等工具模型结构上它选的是标准的 decoder-only Transformer基本沿袭 GPT-2 那一套token embedding 加上若干层 masked self-attention 和 feed-forward最后接一个 LM head 输出词表上的概率分布。没有 encoder没有 cross-attention就是最纯粹的“根据前文预测下一个 token”的架构。这个选择很聪明因为对于教学来说decoder-only 结构最简单、最容易讲清楚而当前主流生成式大模型基本都是这个路线。具体到我这边的配置64M 参数对应的是一组比较紧凑的超参数比如 6 层 Transformer、8 个注意力头、隐藏维度 512、词表大小 20000 左右。这样一个模型在 FP16 混合精度下权重文件才一百多 MB单张 8GB 显存的显卡就完全能放下。它虽然小但五脏俱全——学习率调度、权重衰减、梯度裁剪、checkpoint 保存这些大模型训练必备的机制一个都没少。2. 训练前准备硬件、数据、环境三板斧2.1 一张消费级显卡就够用先说你最关心的硬件问题。我这次用的是 RTX 3090 24GB但我可以负责任地讲这个规模用不着这么好的卡。64M 参数在 FP16 下权重大约 128MBAdam 优化器需要维护两份 FP32 的动量加起来也就几百 MB再加上梯度和激活值完整训练状态通常不超过 2GB。所以哪怕是 8GB 显存的 RTX 3060、4060 甚至甜品级的 2060都能轻松跑起来。当然显存够不代表速度快。64M 模型虽然小但数据加载、反向传播、优化器更新这些环节一样不少。我实测下来3090 上大概能跑到每秒 3000 到 5000 个 token 的吞吐量3060 这类卡预计会慢一半左右。2 小时在 3090 上能做的训练量在 3060 上可能需要 3 到 4 小时。这仍然在“睡一觉就能出结果”的可接受范围内。如果是纯 CPU 训练我试过在 8 核的机器上跑速度大约只有 GPU 的几十分之一2 小时可能只够跑几百步效果基本没法看。所以我的建议是能用 GPU 就用 GPU哪怕是老一点的卡都行CPU 训练只适合验证代码能不能跑通不适合真正训练模型。2.2 数据准备语料不用太大但一定要干净这次训练我准备的语料不算多自己从公开的中文文本里扒了些百科词条、新闻短文和散文片段清洗完大概 50MB 左右。很多人一听 50MB 会觉得这也太少了吧大模型动辄吃几个 TB。话是没错但要注意参数量和数据量要匹配。64M 参数的模型本身容量就有限给它喂 1TB 数据它也记不住那么多反而可能因为数据量太大、一个 epoch 都跑不完导致模型训练不充分。我这次控制的 token 总量大约在 3000 万左右2 小时里勉强能跑完接近一个 epoch。这个比例是比较合适的数据太少模型会反复看同一批句子容易过拟合生成的时候老是重复数据太多一个 epoch 都跑不完模型见都没见全语言能力会比较残缺。清洗数据才是最花时间的环节。我踩过的坑包括全角半角标点混用、HTML 标签残留、大量重复的广告文案、莫名其妙的空行和乱码。这些脏数据如果直接喂进去模型会学到很多奇怪的模式。我处理的时候用了几个简单的规则统一转成简体中文、把连续空行压缩成单个、去掉所有非中文字符和标点以外的符号、按行去重。清洗完的文本干净很多训练 loss 下降也明显更稳定。2.3 环境搭建与几个坑训练环境其实不复杂核心依赖就是 PyTorch 加上 tokenizers、datasets 等几个库。我用的版本是 Python 3.10、PyTorch 2.1、CUDA 11.8这套组合比较稳定。安装命令就不贴了照着官方文档装就行重点说一下我踩过的三个坑。第一个坑在 Windows 上。数据加载时如果用num_workers开多进程Windows 下经常卡死不动这是因为 Windows 的多进程数据加载和 Linux 行为不一样。解决方案很粗暴在 Windows 上把num_workers设成 0让数据在主进程里加载速度慢一点但至少不会卡死。第二个坑是中文路径问题。如果训练脚本或者数据文件放在带中文的路径下有些老版本的 PyTorch 在保存 checkpoint 时会报编码错误。我后来统一把项目和数据放在纯英文路径下这个毛病就再也没出现过。第三个坑是混合精度。AMP 自动混合精度在 3090 这类 Ampere 架构上很稳但在一些老显卡或者驱动没更新的机器上偶尔会出现 loss 变成 NaN 的情况。解决办法是给 AMP 加一个grad_scaler并且在反向传播前做梯度裁剪双重保险下来几乎不会出问题。3. 从零训练的完整实操记录3.1 训练参数到底怎么设训练参数这块我单独拎出来讲因为这是最容易“照抄别人的配置但是跑不出效果”的地方。我用的一组参数如下model: vocab_size: 20000 n_layer: 6 n_head: 8 d_model: 512 intermediate_size: 2048 max_seq_len: 128 train: batch_size: 32 learning_rate: 3e-4 warmup_steps: 500 weight_decay: 0.1 grad_clip: 1.0 max_steps: 5000 eval_interval: 500 save_interval: 500每个参数都有它的道理。max_seq_len设成 128是因为这个规模的小模型注意力窗口有限太长的序列一方面显存占用会涨另一方面它也没能力建模特别长的依赖。训练的时候把文本切成 128 个 token 的块每个块作为一个训练样本这其实是在强制模型学会在有限的上下文里做预测。learning_rate我用了 3e-4这是小模型比较常用的起点。大模型动辄用 1e-4 甚至更低是因为模型大、梯度噪声大学习率太高会震荡64M 的小模型相对稳定可以稍微激进一点收敛也更快。warmup_steps设成 500意思是前 500 步学习率从 0 线性升到设定值。这么做的原因是模型刚开始是一堆随机数梯度方向非常不准如果一上来就用大学习率很容易把参数冲到特别差的区域后面怎么训都救不回来。热身阶段相当于让模型先用小步伐适应一下地形再放开步子跑。weight_decay0.1 是 AdamW 的常见设置主要作用是抑制一部分参数过大提升泛化能力。grad_clip1.0 是防止个别 batch 产生特别大的梯度把参数一步推飞。这两个组合起来能非常有效地避免训练发散。3.2 2 小时到底能训多少个 step这一步我把它算仔细一点。我的训练配置里batch_size32、max_seq_len128所以每个 step 处理的 token 数量是 32 乘以 128也就是 4096 个 token。在 3090 上实测的吞吐量大约是每秒 4000 个 token那么每个 step 大约耗时 1 秒。2 小时就是 7200 秒理论上能跑接近 5000 个 step。实际跑下来因为中间有 checkpoint 保存、验证集评估这些额外开销最终在 2 小时前后大概跑了 4600 多步。对应到数据量上大约是 1900 万个 token占我准备的总语料3000 万 token的六成左右。也就是说这次训练严格来说并没有完整跑完一个 epoch但语言能力的核心阶段已经在这种数据量下基本定型了。这里要特别解释一下“batch”和“step”对底子不牢的同学的迷惑点。很多人以为一个 step 就是把一条样本过一遍不是的。一个 step 是把当前这一个 batch这里就是 32 条样本一起算一遍梯度然后更新一次参数。所以 step 数越多模型参数被更新的次数越多。5000 步听起来不多对 64M 小模型来说已经足够学到很多语言规律了。3.3 训练过程中的 loss 曲线观察训练过程中我一直在盯 loss 曲线因为 loss 是判断模型学得怎么样的最直接信号。一开始的 loss 大概在 11 左右因为词表 20000 个词如果完全随机猜测每个词的负对数似然大约是 ln(20000) ≈ 9.9加上初始化的影响从 11 开始是正常的。前 500 步是下降最快的阶段loss 很快就从 11 掉到了 6 以下。这说明模型正在飞速学习“哪些字符组合是常见词”“中文的基本顺序是什么”。到 1000 步左右loss 降到 5 附近这时候我抽了一些生成结果已经能偶尔看到成词的中文了但句子还不通顺。2000 步以后loss 降到 4 左右生成的句子开始有模有样能出现“我” “你” “他”这些人称代词动词和名词的搭配也有点意思了。到 4000 多步的时候loss 大约稳定在 3.5 到 3.8 之间再往后下降速度明显放缓。这个曲线说明一个非常重要的规律语言模型的学习不是线性的而是在某个阶段突然从“胡言乱语”变成“能看”。这个拐点大概在 1000 到 2000 步之间。如果你训练的模型跑了 2000 步还在出乱码基本可以判断是数据或者参数出了问题而不是“还没训练够”。我还做了另外一个观察把模型在验证集上的 loss 和训练集 loss 对比两者差距不大说明没有严重的过拟合。小模型容量有限反而让它不容易把训练语料背下来更多是在学一种“统计规律”。这也是为什么小模型生成的内容虽然通顺但几乎不会一字不差地复现训练语料里的原句。4. 训练完能干嘛实测场景记录4.1 文本生成实测训练结束后最激动人心的当然是跑一下generate.py看看这个从零开始训出来的模型到底能吐出什么。我用“秋天的夜晚”作为开头模型续写出来的句子大致是“秋天的夜晚月光洒在小路上四周非常安静远处偶尔传来几声狗叫”这样的内容。说实话第一次看到这个输出我还是有点惊讶的。这个模型没有加载任何预训练权重所有参数都是从正态分布随机初始化开始的最终却能生成语法完全正确、语义还算连贯的中文句子。这说明语言能力确实可以被纯粹的下一个词预测任务“逼”出来。模型不需要任何人教它“主语后面要跟谓语”“形容词修饰名词”这些规则它自己在海量语料里把这些统计规律摸清了。我又试了几个不同风格的 prompt比如“今天在公司遇到一件麻烦事”模型能续写一段关于“开会、协调、加班”的小作文“第一次学做饭”它能接出“洗菜、切菜、油锅冒烟”这种场景描述。这些内容都没啥深度但很顺畅像一个小学生在认真写作文。这里有一个细节值得注意生成的时候用了随机采样所以每次输出的内容都不一样但这种不同不是真正的“创意”而是模型在概率分布上随机挑了一条路径。如果改用贪心解码就是每次都挑概率最高的那个字输出会明显更“模板化”经常陷入重复循环。两种方式各有适用场景玩小模型的时候可以都试试。4.2 能力边界在哪里光说能干嘛不够我更在意它不能干嘛。实测下来这个模型有三个非常明显的短板。第一个短板是记不住事实。你问它“中国的首都是哪里”它可能会回答“中国的首都是北京”但你再问“世界上最高的山是什么”它就开始一本正经地胡说八道了。原因很简单50MB 的语料里关于这些常识的句子太少模型只能靠训练时见过的统计共现来猜猜对了是运气猜错了是常态。第二个短板是上下文一长就乱。因为训练时序列长度只有 128模型的注意力机制只学会了在 128 个 token 的范围内寻找关联。你让它写超过两三百字的短文前半段还勉强说得过去后半段就开始逻辑断裂、话题漂移甚至出现前后矛盾的句子。这本质上是模型容量和训练序列长度的双重限制。第三个短板是完全没有“指令跟随”能力。你给它一句“请写一首关于夏天的诗”它不会真的当成指令来执行而是会把这句话当成上下文的一部分然后顺着“夏天的诗”这几个字往下续写。这意味着它不能直接用来做对话助手或任务型 Agent。现在很多跑在本地的小模型之所以需要额外做一层指令微调SFT就是为了解决这个问题。没有经过 SFT 的模型本质上是“文本模拟器”而不是“任务执行器”。这也顺便回答了一个我经常在网上看到的问题为什么智能体应用很少用本地小模型来当大脑因为智能体需要的是严格的指令遵循、稳定的输出格式和一定的推理能力这些恰恰是 64M 这种量级的小模型最不擅长的地方。它更适合被当作一个“文本生成模块”嵌入到更大的流程里而不是独立承担推理决策。4.3 把它放到生产环境里能干什么既然不能当对话助手那这个小模型到底有什么用我实测下来至少有三个方向是靠谱的。第一个是数据增强。如果你在做中文文本分类数据量不够可以让小模型根据你现有的语料风格生成一些“假样本”扩充训练集。因为小模型生成的文本在局部语法上很通顺有时候比简单的回译增强效果更好。第二个是做一个低成本的“文本风格模仿器”。只要在某个特定领域语料上继续训练几十步它就能写出很像那个领域的句子。比如你给它投一批菜谱它就学会“食材、步骤、火候”那套话术给它投一批商品评论它就能生成以假乱真的使用心得。在合规的前提下这种能力可以在做 demo、造测试数据的时候派上用场。第三个是教学和可视化。因为模型足够小你可以把每一层注意力的权重全部导出画成热力图直观地看模型在预测下一个词的时候到底“看”了哪些位置。这种实验在大模型上想做都做不了因为 7B 模型一次前向的计算量够小模型跑无数次了。对小模型来说一切内部机制都摊在你面前非常适合用来理解 Transformer 的工作原理。5. 常见问题与排查技巧实录5.1 显存不足与 batch size 调整训练小模型最常见的报错就是 CUDA out of memory。虽然 64M 模型本身很小但如果你把batch_size设成 128、max_seq_len设成 512显存立刻就会爆。小模型的显存开销大头不在权重本身而在激活值——也就是每一层中间计算的张量。遇到这个报错按优先级做三件事第一把batch_size减半这个最有效第二减max_seq_len从 256 减到 128或者从 128 减到 64内存占用是按序列长度线性增长的第三再不行就开梯度累积就是每过几个小 batch 才更新一次参数相当于用多次前向模拟一个大 batch 的效果显存占用能压到很低。我建议的排查思路是先看报错信息里是哪个张量分配失败通常是在模型前向传播的第几层。如果是在第一层就爆说明 batch 太大如果是在 loss 计算那一步爆说明可能是标签张量的形状没写对。总之要具体问题具体分析别一上来就把 batch 调到 1那样训练效率太低不值得。5.2 loss 不下降或者震荡如果你发现训练跑了上千步loss 还在 10 左右徘徊那肯定不是“训练不够”而是哪里出了问题。我碰到过的、也见过别人碰到过的原因有三类。第一类是学习率不合适。学习率太大loss 会一直震荡甚至飞升学习率太小loss 下降慢如蜗牛。解决办法是先确认学习率在 3e-4 到 1e-3 之间小模型再看 warmup 有没有生效。如果修改之后 loss 还是死活不动可以把初始学习率调大一倍再试反复对比几次就能找到合适的区间。第二类是标签错位。语言模型的任务是“根据前 N 个 token 预测第 N1 个 token”这意味着输入序列和标签序列之间必须有一个位置的偏移。如果直接把输入当标签模型学习的任务就变成了“预测当前位置的 token”而不是“预测下一个位置”这会导致 loss 一直很高。简单验证方法检查训练代码里labels是不是input_ids[..., 1:]前面补了一个特殊的起始符或者做了 roll 操作。第三类是数据太乱。我之前试过用一堆没清洗的网页文本训练里面全是导航栏、版权声明这些重复字符模型光顾着学这些噪声模式语言能力反而上不去。如果 loss 跌到一定程度就下不去了建议统计一下语料里最常见的 100 个句子看看是不是有大量重复。如果有先做去重然后再重训。5.3 生成乱码或者全是重复词训练好了生成结果却不如预期这是另一种让人抓狂的情况。我曾经遇到一个模型loss 看着已经挺低了但生成的文本里到处是“的的的的”“了了了了”这种重复。这通常不是模型没学好而是生成策略的问题。解码的时候如果采样温度太高比如 temperature1.5模型会在低概率词里乱跳生成内容会变得散乱无逻辑如果温度太低比如 0.1模型会盯着概率最大的几个词反复输出导致重复。64M 小模型的经验值是 temperature 设在 0.7 到 0.9 之间配上 top_p0.9 采样效果比较平衡。如果调了温度还是重复那就是模型真的没学好。一个有效的检查方法是看 checkpoint 是第几步保存的。如果用的还是 1000 步的早期 checkpoint生成效果差完全正常。另外如果训练数据太少模型会倾向于机械记忆而不是学会泛化这种情况加数据比调参数更有效。5.4 其他一些容易忽略的小坑还有一个比较隐蔽的问题断点续训。训练到一半断电或者手动中断如果你只保存了.pt模型权重文件而没有保存优化器和学习率调度器的状态重新加载后参数虽然没变但优化器里的动量信息全丢了学习率也会重置。这会导致继续训练的前几百步效率极低甚至出现 loss 短期反弹。正确做法是保存 checkpoint 的时候把model_state_dict、optimizer_state_dict、scheduler_state_dict、当前 step 数一并存下来。最后提醒一下训练日志一定要记录好。我在train.py里顺手加了一句每隔一定步数把训练时间、当前 loss、学习率、显存占用写进一个文本文件。训练完再看这些记录分析问题会轻松得多。别嫌麻烦等到你哪天发现“昨天还能跑今天突然崩了”的时候这些小记录就是救命稻草。6. 从这次实测里得到的一些真心体会跑完这几个小时我最大的感受是大模型的训练原理其实没有想象中那么玄乎关键是把规模降下来之后很多被隐藏的细节都会暴露出来。你看大模型的论文它不会告诉你数据里的一个空行会让 loss 震荡多久也不会告诉你学习率热身的 500 步里模型到底经历了什么。但你自己从零训练一个 64M 小模型这些问题全都摆在面前。如果之后你还想往深了玩我建议按这个顺序扩展第一步把语料从 50MB 加到 500MB训练时间延长到一晚你会发现模型的能力有明显提升第二步把自己的小模型做一遍指令微调让它学会回答“你叫什么名字”这类问题这会让你理解 SFT 的真正作用第三步试试用 LoRA 在小模型上做领域微调在某个垂直场景里把它调到能用的程度。每走一步你对“大模型是怎么工作的”这个问题都会有更具体的答案。这次实测就到这。说实话64M 模型什么都做不好但它能让你在 2 小时里看见语言模型的整个成长轨迹这件事本身就挺值的。如果看完你也想跑一版不用纠结显卡够不够、语料多不多先拿手头的东西跑起来再说。跑了才知道问题在哪。