你有过这种念头吗:不靠别人的发布模型,也不微调,而是从零开始预训练一个“自己的大语言模型”?听到“从零训练”,多数人第一反应是几百万的算力账单,但今天我想告诉你,花3块钱、租一块按小时计费的普通显卡,就能把64M参数的小Transformer从随机权重练到能续写通顺中文。
这篇文章会把这套流程里最像“黑盒”的部分——数据准备、模型架构、损失曲线、显存占用、调试踩坑——全部摊开给你看。它不教你做ChatGPT,而是让你明白:大模型训练的本质是什么,为什么公开资料里动辄千亿参数,而你几十分钟训练的小模型到底学到了什么。
如果你正在犹豫要不要入坑,或者已经试过跑代码但只学会调用别人的训练脚本,这篇内容应该能帮你在“训练大模型”这面墙上开一道窗。
1. 3块钱的数学账:这笔预算到底够干什么
1.1 显卡成本:一小时一块钱的时代
先算最简单的账。现在很多云GPU平台都支持按小时租卡,一张24G显存的消费级显卡,价格大概在每小时1到2元之间。我训练时租了两小时,平台实际扣费3元出头,和标题里的“3块钱”基本吻合。
可能有人会问:这么便宜的卡能用?我用的是某平台闲置时段的价格,卡不算新,但跑64M参数的小模型绰绰有余。注意,这里说的“大语言模型”是全流程从零预训练,只是规模小。任何时候只要你看到“从零训练”,真正的门槛从来不是显存大小,而是你是否愿意去理解训练过程中每一步在干什么。3块钱预算最大的价值,是逼你把每秒钟都用在刀刃上。
这一点对新手特别有意义:如果是包月租卡,你很容易反复跑一些“差不多但没跑通”的代码,因为心理上没有成本压力。按小时计费时,定义好目标、选好数据、把代码一次性写好再启动,这种习惯本身就是训练工程能力。
1.2 64M参数方案的显存与算力估算
决定“能不能训”之前,你得先算清楚手里的显存够不够。这里给一套很实用的估算方法:
- fp16参数占用:64M × 2字节 = 128MB
- fp16梯度占用:64M × 2字节 = 128MB
- AdamW优化器状态(一阶动量m + 二阶动量v):64M × 4字节 × 2 = 512MB
- 如果保留一份fp32的权重副本:64M × 4字节 = 256MB
各项加起来大约1GB,再加上中间激活值、临时变量,实际训练峰值会明显高于这个理论值,但整体不会超过5GB。简单说:显存只要大于12G,跑这个规模就足够宽裕。
那为什么选64M参数,而不是更小的10M或者更大的几百M?原因有两个。第一,64M已经能体现出Transformer结构里所有关键组件的作用,包括注意力、位置编码、残差和层归一化,裁剪到太小就会丢失这些结构的代表性。第二,在按小时租卡的场景下,64M可以在1到2小时内从随机权重训到loss明显下降、生成文本可读的状态,这是一个“性价比甜点位”。
1.3 认清3块钱的边界
3块钱能训练,但不代表能训练出能聊天的模型。64M参数在如今的大模型版图里只能算“模型小样”,它做不到复杂的多轮对话、常识推理,也记不住多少事实,最合适的定位是:让你亲眼见证一次完整的预训练流程,观察数据和参数如何相互作用。
我建议把预期分成三层。第一层,能看到loss从ln(vocab_size)附近稳定下降;第二层,能观察到模型从输出乱码进步到“词与词之间有搭配关系”;第三层,能理解影响训练收敛的关键因素是什么。三块钱买到的主要是第二层和第三层,别强求第一层变成“智能”。
2. 喂什么、怎么喂:给模型准备训练语料
2.1 语料来源与体量选择
数据是大模型的“教材”。我这里准备的是一份约50MB的中文纯文本库,内容以百科类词条为主,混了一点古诗和短句。50MB看着不多,换算成token大概在4000万到5000万级别——对这个规模的模型来说,已经属于“长见识”和“饥饿训练”之间的状态。
选数据时有三个原则:
- 文本质量优先于数量:宁可要100万字干净的中文百科,也不要1000万字混杂大量网页噪声的原始抓取
- 风格要尽量统一:如果你想训练出一个偏“书面语”的模型,就少放口语文本;想训练“诗歌风”,就大幅提高诗歌比例
- 覆盖基础词汇搭配:语料里必须有大量主谓宾完整的句式,这样模型才有机会学习词与词之间的共现关系
很多人一上来就找“全网最大中文语料”,结果预处理先卡了三天。我的建议是:先用你能顺利打开、能快速切分的文本,跑通全流程,再考虑增量。
2.2 清洗、切分与token化
拿到文本后,我做的事可以概括成四步:
- 去掉所有不可见字符、多余空行、重复的版权声明尾巴
- 统一把全角标点转成半角,或者反过来,总之要保持一致
- 按段落切分成长片段,确保大多数片段长度落在256到512字符之间
- 做一遍去重——去掉完全相同的长句和段落
这四步看着琐碎,但直接影响训练质量。最容易翻车的点是“没有去重”。如果你的语料里同一段话出现几百次,模型会花大量算力去背这段话,而不是学习通用语言规律。我从第一次跑开始就吃过这个亏,loss前期降得飞快,后期卡住不动,一查发现某个词条重复了上百遍。
Token化我采用了最简单的方案:对中文按“字”级别切分。你可能想问,为什么不用更高级的BPE或SentencePiece?对64M参数的小模型而言,中文字符级词表天然较小,一般几千个常用字就能覆盖大部分语料,我们把词表预留到10000,实际用到的不到一半。这样既能控制embedding矩阵的规模,又省去了BPE训练的复杂度。对教学项目来说,简单可靠比“先进”更重要。
2.3 一条训练样本长什么样
模型真正看到的东西不是文字,而是数字序列。假设原文是“春眠不觉晓”,预处理后会变成这样的流程:
- 分词后得到 [“春”, “眠”, “不”, “觉”, “晓”]
- 查表映射为 [12, 348, 290, 78, 1024]
- 组装训练样本时,输入是除最后一个位置外的序列,标签就是向右平移一位的序列
所以标准样本就是“看到前四个字,预测第五个字”。整个大语言模型的预训练,本质上是在最大化这样一个概率:在给定前文条件下,下一个token出现的概率。这个想法朴素到让很多初学者吃惊,但正是它支撑起了当前所有大模型的基本范式。
我在提取样本时用了滑动窗口方式:对于一段长度为512的文本,不一次性切成互不相交的块,而是每隔128个字符取一个长度为256的窗口。这样做的原因是让模型能反复看到同一个token出现在不同上下文中的组合,增加训练样本的有效数量,代价只是数据预处理多几行代码。
3. 手写Transformer:只依赖PyTorch的核心实现
3.1 架构选型与参数量分配表
这个项目的代码只依赖PyTorch,不加载任何预训练权重。为什么要从零手写Transformer?因为只有自己手写一遍,才能搞清楚每层结构到底是干什么的,也才能真正理解“训练黑盒”里装的不是魔法,就是一堆矩阵乘法。
我用的配置如下:
| 组件 | 设定值 |
|---|---|
| vocabulary size | 10000 |
| embedding dim | 768 |
| 层数 | 8 |
| 注意力头数 | 8 |
| 每个头维度 | 96 |
| FFN隐藏维度 | 3072 |
| 最大序列长度 | 256 |
这组配置下参数量大致这样分配:
- token embedding:10000 × 768 ≈ 7.68M
- 每层自注意力模块:QKV线性层 3×768×768 + 输出线性层768×768 ≈ 2.36M
- 每层前馈网络:两层线性 768×3072 + 3072×768 ≈ 4.72M
- 每层归一化参数等少量参数,合计8层约57M
- 最后输出层与embedding共享权重(weight tying),所以不额外增加词表大小的权重
加起来的数字在64M上下浮动,写代码时可以用model.parameters()直接统计确认,不用完全精确到小数。你可能会问我为什么把词表设为10000:这是中等规模中文模型里比较省事的选择,既能覆盖常见汉字和标点,又不会让embedding矩阵吃掉过多参数。
3.2 最小可运行的训练代码解析
训练循环不需要写成几百行的复杂框架,核心代码其实很精简。我先把最关键的Transformer Block写出来:
import torch import torch.nn as nn import torch.nn.functional as F import math class CausalSelfAttention(nn.Module): def __init__(self, config): super().__init__() self.n_head = config.n_head self.n_embd = config.n_embd self.head_dim = config.n_embd // config.n_head self.c_attn = nn.Linear(config.n_embd, 3 * config.n_embd, bias=False) self.c_proj = nn.Linear(config.n_embd, config.n_embd, bias=False) def forward(self, x): B, T, C = x.shape q, k, v = self.c_attn(x).split(C, dim=2) q = q.view(B, T, self.n_head, self.head_dim).transpose(1, 2) k = k.view(B, T, self.n_head, self.head_dim).transpose(1, 2) v = v.view(B, T, self.n_head, self.head_dim).transpose(1, 2) mask = torch.tril(torch.ones(T, T, device=x.device)).view(1, 1, T, T) att = (q @ k.transpose(-2, -1)) / math.sqrt(self.head_dim) att = att.masked_fill(mask == 0, float('-inf')) att = F.softmax(att, dim=-1) y = (att @ v).transpose(1, 2).contiguous().view(B, T, C) return self.c_proj(y) class Block(nn.Module): def __init__(self, config): super().__init__() self.ln1 = nn.LayerNorm(config.n_embd) self.attn = CausalSelfAttention(config) self.ln2 = nn.LayerNorm(config.n_embd) self.mlp = nn.Sequential( nn.Linear(config.n_embd, 4 * config.n_embd), nn.GELU(), nn.Linear(4 * config.n_embd, config.n_embd), ) def forward(self, x): x = x + self.attn(self.ln1(x)) x = x + self.mlp(self.ln2(x)) return x注意力计算里最关键的是mask。你不能让模型在做第t个位置的预测时看到它后面的token,否则训练就是在“抄答案”。mask矩阵会挡住未来信息,保证每个位置只能看到自己和之前的内容。如果你曾经跑过语言模型却完全没关心过mask,建议停下来仔细体会这一块的逻辑。
GPT主体再包一层:
class GPT(nn.Module): def __init__(self, config): super().__init__() self.tok_emb = nn.Embedding(config.vocab_size, config.n_embd) self.pos_emb = nn.Parameter(torch.zeros(1, config.block_size, config.n_embd)) self.drop = nn.Dropout(config.dropout) self.blocks = nn.ModuleList([Block(config) for _ in range(config.n_layer)]) self.ln_f = nn.LayerNorm(config.n_embd) self.lm_head = nn.Linear(config.n_embd, config.vocab_size, bias=False) def forward(self, idx, targets=None): B, T = idx.shape x = self.tok_emb(idx) + self.pos_emb[:, :T, :] x = self.drop(x) for block in self.blocks: x = block(x) x = self.ln_f(x) logits = self.lm_head(x) loss = None if targets is not None: loss = F.cross_entropy(logits.view(-1, logits.size(-1)), targets.view(-1)) return logits, loss训练时用最朴素的循环:
optimizer = torch.optim.AdamW(model.parameters(), lr=3e-4, weight_decay=0.1) for step in range(total_steps): xb, yb = next_batch() logits, loss = model(xb, yb) optimizer.zero_grad() loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0) optimizer.step()3.3 四个影响成败的小细节
第一,weight tying。我让最后的输出线性层复用了token embedding的权重矩阵。这样做既减少参数量,又符合语言模型里“高频词向量质量和输出层语义一致”的经验。写代码时注意:如果共享权重,就不能给两个模块分别初始化不同的参数。
第二,梯度裁剪。明确讲,梯度裁剪是保命用的。小模型训练偶尔会出现某个极端样本把梯度拉爆,不裁剪loss可能直接变成NaN。clip grad norm设置为1.0基本够用。
第三,学习率调度。我用的是前500步warmup,随后按cosine衰减到0。warmup阶段的作用是让Adam的动量估计先稳定下来,避免一上来步子太大把参数推飞。这不是玄学,可以多做几组对比实验验证。
第四,混合精度。用torch autocast把forward和loss计算切到fp16,能明显提升速度并减少显存占用。但优化器状态我仍然用fp32保存,避免精度损失累积。如果你显存宽裕、运行速度也能接受,纯fp32训练也不是不行,只是浪费了预算。
4. 训练实录:损失曲线、显存和行为观察
4.1 实测训练配置与速度记录
实操时的配置我记录如下:
- batch size:32
- 序列长度:256
- 梯度累积:4步,等效batch size为128
- 优化器:AdamW,β=(0.9, 0.95),学习率3e-4,权重衰减0.1
- 训练总步数:6000步
- 混合精度:开启
每个batch的token数是32×256=8192,6000步合计约4900万token。显存峰值在4GB到5GB左右,12G显存的卡完全能跑下来。速度实测每秒大概8000到12000 token,换算下来每步约1秒,6000步大约需要1到1.5小时,正好落在3块钱的预算范围内。
有人会问:batch size是不是越大越好?对语言模型来说,增大batch确实能提升训练稳定性,但代价是总步数不变时训练的迭代更新次数变少。我取32×4的组合,是单卡不加额外复杂优化时的合理平衡点。
4.2 从乱码到有意义文本:生成效果演化
观察训练的乐趣在于,你能看到模型行为在几十个小时内飞快变化。我在训练的不同阶段用同一条 prompt 去做采样,记录下这句“花开春去也”的续写:
- 第200步时,输出大概是“的的在也在也也也……”这种完全不成词的字串
- 第1500步时,输出变成“花开春去也,花开花落花飞去”这样有限词组的重复
- 第4000步时,输出出现“花开春去也,江边日暮时,秋风吹叶落,明月照高楼”这种表面通顺、内部逻辑依然薄弱的句子
- 第6000步时,文本开始出现更自然的主谓结构,虽然依旧无法承载任何严谨的事实
这个演化过程比任何文字描述都有说服力。模型并不是突然学会了语法,而是先学会高频字、再学会常用搭配、最后才在有限的语料里总结出句式。如果只看最终loss,你看不到这中间发生了什么,这也是我坚持在训练时把中间样本打印出来的原因。
4.3 怎么判断模型“训好了”
“训好了”没有绝对标准,但有几个可量化的参考。
- 初始loss:随机初始化时,交叉熵约等于ln(vocab_size),我的词表10000,所以初始loss大约在9.2附近
- 收敛loss:6000步后降到4.5上下,说明模型对下一个汉字已经有了明显的预测能力
- 困惑度:用
math.exp(loss)算下来约90,意思是一句话下一个字需要在约90个候选字里找,对比10000的原始词表已经缩减了两个数量级
需要注意,小模型继续训练loss还会缓慢下降,但边际收益会越来越小。我在实验里从第4000步到第6000步,loss只降了0.2左右,生成文本肉眼可见的改善也有限。这种“后期平台期”是正常现象,不代表训练失败。
5. 问题速查:常见异常与排查思路
5.1 典型故障对照表
把这次训练中踩过的坑整理成一张速查表,希望能帮你省下一些排查时间。
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| loss不下降,一直在9附近 | 学习率过高或过低、数据没有正确配对 | 打印几条样本检查输入与标签是否错位 |
| loss变成NaN | 某一层出现数值溢出、学习率太大 | 开梯度裁剪,调小学习率到1e-4级别 |
| 前期下降很快,后期卡住 | 语料重复过多、序列长度不够 | 检查语料去重,增大序列长度或batch |
| 显存OOM | batch大小或序列长度超显存上限 | 先减半batch,再把序列长度从256降到128 |
| 生成内容不断重复 | 模型容量不足、训练步数不够 | 这不是bug,是小模型常见行为,可以调高采样温度缓解 |
| 训练速度过慢 | 未开混合精度、数据加载是瓶颈 | 开启autocast,检查数据加载是否涉及大量CPU操作 |
最容易被忽略的是第一条:数据错位。我曾在预处理时因为数组切片越界,导致输入和标签整体偏移了一位。表面上看loss也在下降,但生成结果完全发散。这类“看起来正常、实际错误”的bug很难发现,最好是训练前抽一条样本人眼检查一遍。
5.2 我的几条训练经验
如果你也准备用3块钱预算跑一次,下面几条经验可能对你有帮助。
第一,先在100步小规模run里做快速验证。很多新手在完整训练开始后才发现代码有bug,不仅浪费预算,而且会在等待中逐渐失去耐心。我只花5分钟运行100步,如果loss曲线形状正常,再启动正式训练。
第二,把生成函数写到训练循环里。每500步触发一次采样,打印几行当前模型续写的文字。这比只看loss直观得多。我第一次跑的时候,正是靠这种“中断式观察”发现模型在第2500步左右开始产生有意义的中文短语。
第三,保存检查点不要太频繁。小模型检查点只有100多MB,但每500步存一次依然会拖慢训练。建议每1500到2000步保存一次,既够恢复断点,又不会显著影响训练节奏。
第四,硬件约束下别调参过度。学习率、batch、序列长度这些核心参数我基本沿用公开小模型训练里验证过的经验值。你只有一两个小时,不适合做大规模网格搜索,先跑通、记录结果,再在下一次训练中有针对性地调整一个变量就好。
写在最后
这次用3块钱把64M参数的模型从零训完,最真实的感受是:大模型的训练过程并不会因为你把规模缩小而省略任何一个灵魂环节——数据、架构、优化器、学习率调度、loss下降、生成采样、调试翻车,全部都要走一遍。3块钱买的其实不是一个模型,而是一次对“黑盒”的拆解机会。
如果你拿到了同样的预算,我建议你从准备一份干净的中文语料开始,手写一个能跑通的极简Transformer,然后盯着loss曲线耐心等。别急着追求漂亮的生成效果,先观察模型从随机权重到勉强通顺的每个脚印。有过这样一次完整经历之后,再去看那些动不动几十亿参数的公开训练报告,你会清楚它们做了哪些事、省略了哪些事,也更明白自己的机器到底能跑什么。毕竟,模型再大,底层的训练逻辑并没有你想象中那样遥不可及。