单卡两小时从零预训练64M中文小模型：完整实测与思考-开发者社区

最近我把 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 下权重大约 128MB，Adam 优化器需要维护两份 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_size=32、max_seq_len=128，所以每个 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 预测第 N+1 个 token”，这意味着输入序列和标签序列之间必须有一个位置的偏移。如果直接把输入当标签，模型学习的任务就变成了“预测当前位置的 token”，而不是“预测下一个位置”，这会导致 loss 一直很高。简单验证方法：检查训练代码里labels是不是input_ids[..., 1:]前面补了一个特殊的起始符或者做了 roll 操作。

5.3 生成乱码或者全是重复词

训练好了，生成结果却不如预期，这是另一种让人抓狂的情况。我曾经遇到一个模型，loss 看着已经挺低了，但生成的文本里到处是“的的的的”“了了了了”这种重复。这通常不是模型没学好，而是生成策略的问题。

解码的时候如果采样温度太高（比如 temperature=1.5），模型会在低概率词里乱跳，生成内容会变得散乱无逻辑；如果温度太低（比如 0.1），模型会盯着概率最大的几个词反复输出，导致重复。64M 小模型的经验值是 temperature 设在 0.7 到 0.9 之间，配上 top_p=0.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 小时里看见语言模型的整个成长轨迹，这件事本身就挺值的。如果看完你也想跑一版，不用纠结显卡够不够、语料多不多，先拿手头的东西跑起来再说。跑了，才知道问题在哪。