从零手写大模型训练：Transformer、BPE与工程细节全解析

1. 为什么值得从零写一遍：先想清楚再动手

先说个让我印象挺深的场景。有段时间我身边突然冒出一堆“AI工程师”，简历上清一色写着“精通大模型微调”，可真到项目里，稍微改个loss、调个数据格式就卡壳。后来我跟几个朋友复盘，发现问题出在一个共同的习惯上——大家太习惯用现成的训练框架了。代码一拉、配置一改、显卡一开始冒热气，loss就在那儿往下掉，至于里面到底发生了什么，很多人心里其实是模糊的。

所以我决定给自己一个硬性任务：不依赖任何大模型训练框架，从零写一个能跑通完整流程的AI训练项目。这个项目的标题叫“ai-engineering-from-scratch”，目标很直接——把分词、数据管道、模型架构、训练循环、评估微调这些环节全部亲手实现一遍。不是要复刻GPT-4那种几千亿参数的怪物，而是要搭一个参数规模可控、每一步都知道why的完整链路。

1.1 先回答三个问题

动手之前，我反复问了自己三件事，也想清楚了边界在哪：

• 第一个问题：从零到什么程度？如果连Tensor的矩阵乘法都要自己实现，那就失去工程意义了，我也不会去重新发明PyTorch。我的定义是：核心的训练流程、模型结构、数据逻辑、优化策略都自己写，库存依赖只做基础计算和自动求导。这就像你不用自己造钢筋水泥，但要亲手把房子结构搭出来。
• 第二个问题：这种项目适合谁？一句话，适合那些已经会调API、会用现成库，但感觉自己对模型内部“心里没底”的人。如果你刚开始接触AI，直接看这个可能会有点痛苦，建议先跑通一个现成的小模型，再回来看会有完全不同的感受。
• 第三个问题：做完能获得什么？最直接的收获是，你再也不会把数据预处理、mask、梯度累积这些概念停留在“听过”的程度。更实用的是定位问题的能力——当训练不收敛、显存爆炸、loss变成NaN的时候，你能从原理层判断问题出在哪，而不是像无头苍蝇一样到处试。

这个边界想清楚之后，后面每一步就顺了。

1.2 项目目标与技术选型

我给自己定的目标是训练一个参数规模在1亿到3亿之间的Decoder-only模型，语言上用中文和英文混合语料，最终能生成连贯的文本，并且能通过一套自己写的评估逻辑看出它的学习进度。为什么选这个规模？因为在一张24GB显存的卡上，这个体量可以比较舒服地训练，又不至于小到体现不出工程问题。太小的话，你根本遇不到梯度累积、重启动续训、显存优化这些真正的工程挑战，项目也就失去了“从零开始”的意义。

技术栈方面我选得很克制：

• 基础框架：PyTorch 2.x，用它做张量计算和自动求导
• 分词：Hugging Face的tokenizers库（只保留它的BPE实现，不引入整个Transformers）
• 数据：自己写数据集类和采样逻辑
• 训练：手写训练循环，不用Trainer
• 监控：本地用文本日志，长期训练挂WandB（可选）

这套选型的原则是：每个库都只承担它最不可替代的任务，其余环节全部亲手实现。理由很简单，如果你想理解一个东西，最好的方式是把它能拆的部分都拆开看一遍。

2. 环境与数据准备：被低估的第一个拦路虎

说句实在话，模型架构反而是整个项目里最“确定性”的部分，真正的麻烦从环境和数据就开始了。尤其是数据这一步，很多人嫌它枯燥，但最后模型行不行，八成在数据上就见分晓了。

2.1 硬件与软件选型

训练这种规模的模型，硬件门槛比很多人想象的低，但也有些细节要提前想好：

• 显卡：我用的是一张RTX 4090（24GB），如果你只有3090或A5000也完全够用。关键是显存大小决定了batch size和模型规模的组合方式，这个后面会讲。
• CPU内存：建议至少32GB。你可能觉得训练时CPU没什么用，但实际上数据流式处理、分词、洗数据都吃内存。
• 硬盘：SSD是刚需，最好是有1TB以上空余的NVMe。训练数据预处理后会有不少中间文件，经常随机读取，机械硬盘慢起来能让你怀疑人生。
• CUDA版本：直接用能匹配PyTorch的最新CUDA 12.x即可，不要追求硬件厂商驱动版本越高越好，而是PyTorch要能稳定调用。

环境搭建有个我踩过的坑：不要用Python 3.8以下的版本，有些新库和新语法不支持；也不要一上来就装最新的Python 3.13，部分PyTorch早期版本还没适配。选Python 3.10或3.11最稳妥，兼容性好，遇到问题也最好搜到答案。

2.2 数据源选取与清洗策略

数据我用的是公开的英文数据集The Pile的子集和一份中文维基语料。如果你想更省事，直接用OpenWebText也行。但无论选什么，清洗都是一道绕不过去的关键工序。

我的清洗流水线长这样：

• 第一步，去HTML标签：很多爬下来的网页文本里残留HTML实体和标签，不用复杂的解析器，正则配合简单的替换就能处理大部分噪音。
• 第二步，去重：这一步最容易被忽略。我一开始偷懒没做重复检测，结果发现评估集里混进了和训练集一模一样的句子，导致评估指标好看得离谱。后来用MinHash做了一层近似去重，把相似度高的段落直接丢弃。
• 第三步，过滤低质量文本：规则很朴素——过滤掉平均句子长度过短的、特殊字符占比过高的、整段全是大写或全数字的。这些段落通常没什么信息量，留着只会让模型学出一堆废话模式。
• 第四步，标准化：统一全角半角、压缩连续空白符、统一换行符。文本在成为训练样本前就应该保持干净稳定，不然模型会学到各种无意义的格式噪音。

清洗这件事，建议不要试图写一个“完美”的脚本。因为完美的定义取决于目标数据的真实形态，你需要做的是先抽样看50条原始文本，再对照清洗后的50条，用眼睛亲手把关一遍感受一下。

2.3 构建可扩展的数据加载管线

数据清洗完之后，还面临一个工程问题：几个GB的文本不能一次性全塞进内存，也不该每次训练都重新解析一遍原始文本。我的做法分两段：

• 第一段，把清洗后的全部文本分词，转成token id序列，然后使用内存映射格式（比如PyTorch的MemmapDataset或自己写一个numpy的memmap类）持久化到磁盘。
• 第二段，训练时通过索引随机读取token序列，切成长度为seq_len的样本块。

这样的好处是：显存只负责模型参数和激活值，数据本体住在磁盘和CPU内存里，可以无限扩展。数据准备和训练解耦后，调试和重跑的成本也大幅降低。

注意：训练集和验证集一定要在token化之前就切分好，而且要用不同的随机种子。否则模型很可能在你不知情的情况下“背”过验证集的原文，后期评估会误导你。

import numpy as np import torch from torch.utils.data import Dataset class MemmapTokenDataset(Dataset): def __init__(self, path, seq_len, memmap_mode="r"): self.data = np.memmap(path, dtype=np.uint16, mode=memmap_mode) self.seq_len = seq_len # 总样本数：能切出多少个长度为seq_len的连续窗口 self.num_samples = len(self.data) // seq_len def __len__(self): return self.num_samples def __getitem__(self, idx): start = idx * self.seq_len chunk = self.data[start: start + self.seq_len + 1].astype(np.int64) x = torch.from_numpy(chunk[:-1]) y = torch.from_numpy(chunk[1:]) return x, y

这个数据类的思路很直白：每个样本取seq_len + 1个token，前seq_len个作为输入，右移一位作为标签。也就是说，每个位置都要预测下一个token，这就是语言模型最核心的训练信号。

3. 分词与采样：模型看到的世界是什么样

很多人一开始对分词不太重视，觉得不就是把文本切碎吗？但你要知道，模型没有“词”的概念，只有token id的序列。分词策略直接决定了模型的词汇表大小、序列长度效率、以及它对陌生词的处理方式。

3.1 为什么是BPE而不是按字切分

中文按字切分会把序列拉得很长，英文按空格切分又无法处理时态、复数等词形变化，而且遇到没见过的单词就沦为一个[UNK]。字节对编码（BPE）的思路完全不同：它先从单个字符开始，然后迭代地合并出现频率最高的相邻字符对，逐步形成子词单元。这样常见的词可能整体就是一个token，不常见的词会被拆成几个子词片段，但绝不会变成未知词。

举个例子，“playing”在BPE词汇表里可能是一个完整token，也可能被拆成“play”和“ing”，具体取决于语料中“playing”出现的频率。这种灵活性让模型既保持序列紧凑，又不会丢掉对生词的表达力。

3.2 训练一个专属tokenizer

我用的是Hugging Face的tokenizers库，只使用了它的底层BPE实现，并没有引入整套Transformers。我踩过一个坑：直接用默认的GPT-2分词器来处理中文语料，结果很多常用中文字符被硬拆成bytes片段，序列长度凭空多了30%以上。后来我决定在混合语料上从头训练一个42k词汇量的中文为主的BPE分词器，序列长度和生成汉字自然度都有明显改善。

训练tokenizer时，有几个超参数值得留意：

• vocab_size：词汇量越大，序列越短，但embedding矩阵也越大。中文为主的话32k-48k是合理区间。
• min_frequency：只有出现次数超过这个阈值的token才被保留，它过滤掉大量只出现过一两遍的垃圾token。
• special_tokens：永远要给[PAD]、[BOS]、[EOS]、[UNK]预留固定id，并且顺序不要乱动，因为训练好的模型权重和tokenizer的id是严格绑定在一起的。

训练tokenizer本身很快，几分钟就能完成。训练完要立即用一段没见过的文本做 sanity check，把分词结果打印出来肉眼看一遍，检查是不是符合直觉。

3.3 训练时的上下文构造策略

模型训练时，我需要把token id序列切成batch喂给模型，这里有两个关键点：

• 因果掩码：Decoder模型在预测第i个token时只允许看到第i个之前的token。实现上是对attention score矩阵的上三角部分填充负无穷，这样softmax之后注意力就完全落在当前位置之前。这是“GPT式生成模型”的基石，也是和BERT这类双向模型最本质的区别。
• padding与packing的选择：训练序列长度我固定为512，这样能完全避免padding带来的计算浪费。但真实语料的长短总是不齐的，所以我在数据准备阶段就把语料连续切割成固定长度的块。相比等长batch填充的方式，这种“打包”策略训练效率高很多，代价是相邻的两段文本之间可能眉飞色舞毫无关联，但实践中这点影响微乎其微。

def create_attention_mask(seq_len, device): # 因果掩码：允许看到当前位置及之前的token mask = torch.tril(torch.ones(seq_len, seq_len, device=device)) mask = mask.masked_fill(mask == 0, float("-inf")) mask = mask.masked_fill(mask == 1, 0.0) return mask

这个函数构造的矩阵是标准的“倒三角”，左下角是0表示允许关注，右上角是负无穷表示禁止关注。

4. 模型架构：Transformer从图纸到肌肉记忆

从这节开始进入真正的“硬核”区域。我会把整个模型拆成几个可以独立验证的模块，一步一步写出来。每个模块都配代码，但更重要的是理解它为什么长这样。

4.1 输入嵌入与位置编码

Token序列进入模型后，第一步是查找词表得到稠密向量。这就是nn.Embedding在做的事，本质上是一个大的查找表，把每个token id映射成一个可以学习的向量。嵌入维度d_model我选了768，这个数字和GPT-2 small一致，在模型容量与计算开销之间比较平衡。

位置编码我直接用了可学习的nn.Embedding(seq_len, d_model)，而不是Transformer论文里的sinusoidal编码。原因有三点：现代实现里可学习位置编码更好优化；序列长度固定时参数开销可以接受；实践中它并不比sinusoidal差。但要注意，如果未来想处理超过训练长度的序列，可学习位置编码的泛化性就弱了，到时需要换成RoPE或ALiBi之类的相对位置编码方案。

class GPTEmbeddings(nn.Module): def __init__(self, vocab_size, d_model, max_seq_len): super().__init__() self.token_embedding = nn.Embedding(vocab_size, d_model) self.position_embedding = nn.Embedding(max_seq_len, d_model) def forward(self, input_ids): seq_len = input_ids.size(1) pos_ids = torch.arange(seq_len, device=input_ids.device).unsqueeze(0) token_embeds = self.token_embedding(input_ids) position_embeds = self.position_embedding(pos_ids) return token_embeds + position_embeds

一个小细节：位置编码必须适应batch纬度，所以pos_ids要加一个维度变成(1, seq_len)再做广播。

4.2 多头注意力：手写一遍才算真的懂

Attention机制是整个模型最核心的部分。它的计算逻辑可以概括成三步：把每个token映射为Query、Key、Value三个向量；计算Query和所有Key的点积作为相似度分数；用相似度分数对Value做加权平均。

多头就是把d_model维度的向量切成n_head份，每份独立做注意力，最后拼接起来，再过一层线性投影。为什么要多头而不是一个头？因为不同头可以关注不同的关系模式——有的头可能关注语法依赖，有的头关注指代关系，有的头关注位置邻近性。这种多视角并行是Transformer表达能力的重要来源。

我这里把缩放点积注意力单独写成了一个函数，方便做mask逻辑和注意力可视化。代码里有个工程细节：attn_weights在内存里是(batch, head, seq, seq)的四维矩阵，序列长度512时不大，但如果你以后把序列长度推到2048甚至4096，这个矩阵就会爆炸式增长，需要改用Flash Attention之类的内存高效实现。

def scaled_dot_product_attention(q, k, v, mask=None): d_k = q.size(-1) scores = q @ k.transpose(-2, -1) / (d_k ** 0.5) if mask is not None: scores = scores + mask attn_weights = torch.softmax(scores, dim=-1) out = attn_weights @ v return out, attn_weights class MultiHeadAttention(nn.Module): def __init__(self, d_model, n_head, dropout=0.1): super().__init__() self.d_model = d_model self.n_head = n_head self.d_k = d_model // n_head self.wq = nn.Linear(d_model, d_model) self.wk = nn.Linear(d_model, d_model) self.wv = nn.Linear(d_model, d_model) self.out_proj = nn.Linear(d_model, d_model) self.dropout = nn.Dropout(dropout) def forward(self, x, mask=None): batch, seq_len, _ = x.shape q = self.wq(x).view(batch, seq_len, self.n_head, self.d_k) k = self.wk(x).view(batch, seq_len, self.n_head, self.d_k) v = self.wv(x).view(batch, seq_len, self.n_head, self.d_k) q = q.transpose(1, 2) k = k.transpose(1, 2) v = v.transpose(1, 2) out, _ = scaled_dot_product_attention(q, k, v, mask) out = out.transpose(1, 2).contiguous().view(batch, seq_len, self.d_model) return self.out_proj(out)

为什么缩放因子是sqrt(d_k)？因为当维度变大时，点积的数值范围会变大，softmax会进入饱和区，梯度接近0，学不动。缩放后就稳定在高斯分布的方差范围附近。这个设计是论文里反复验证过的，属于那种“看着小但很重要”的细节。

4.3 前馈网络与层归一化的位置玄机

每个注意力层后面会接一个前馈网络（FFN），结构很简单：线性层把768维放大到4倍（3072维），经过GELU激活再压缩回768维。这个结构的意义是给模型引入非线性变换能力，相当于在每个位置上做一个“深思熟虑”的特征转换。

关键的玄机在于LayerNorm放哪里。经典Transformer用的是post-LN（先过注意力/FFN，再归一化），但训练深层模型时梯度不稳定，经常要配合warmup很久。现代GPT用的都是pre-LN（先归一化，再进子层），训练更稳定，收敛更快。代价是深层模型极端加深时表达能力有所损失，但对我们的规模来说，pre-LN是明确更优的选择。

class TransformerBlock(nn.Module): def __init__(self, d_model, n_head, d_ff, dropout=0.1): super().__init__() self.attn = MultiHeadAttention(d_model, n_head, dropout) self.ffn = nn.Sequential( nn.Linear(d_model, d_ff), nn.GELU(), nn.Linear(d_ff, d_model), nn.Dropout(dropout) ) self.ln1 = nn.LayerNorm(d_model) self.ln2 = nn.LayerNorm(d_model) self.dropout = nn.Dropout(dropout) def forward(self, x, mask=None): # pre-LN结构：先归一化，再进入子层，最后残差连接 x = x + self.dropout(self.attn(self.ln1(x), mask)) x = x + self.dropout(self.ffn(self.ln2(x))) return x

残差连接就是那种“看不到却很重要”的设计。没有它，几十层Transformer基本无法训练；有了它，梯度可以从输出端直接“抄近道”流回浅层，缓解梯度消失。

4.4 配置选择与参数量验证

写完整模型后，我强烈建议你做一个简单的参数量估算，来验证自己对模型的掌握程度。以我的配置为例：

总参数量大约是120M。这个规模很合适——比它小的模型不容易暴露工程问题，比它大的又会卡在单卡训练的效率和显存边界上。模型主体拼完后，建议先构造一个batch随机数据，跑一次前向和反向，确认loss能顺利打印出来，再做正式训练。

5. 训练循环：那些框架没教你的工程细节

这一步是整个项目里“从0到1”感觉最强烈的地方。训练循环本身就是十几行代码，但真正决定训练质量和稳定性的，是优化器、学习率、混合精度、断点续训等一堆配套逻辑。

5.1 优化器选型：为什么用AdamW而不是SGD

训练Transformer模型，Adam仍然是默认选择。但有个关键细节：标准的Adam在实现中会把权重衰减加在梯度更新上，这其实是不对的。AdamW把权重衰减从梯度更新中分离出来，直接对参数本身做衰减，在语言模型上效果稳定且明显。

这里我还想强调一下warmup存在的必要性。训练初期模型参数随机，如果一上来就大学习率，梯度方向可能非常不稳定，容易一下子冲到一个坏区域。warmup阶段让学习率从小慢慢爬升，等效于先“摸索”一下地形，再放心大步走。我的经验值是warmup steps占总训练步数的3%-5%，效果比较稳。

5.2 学习率调度：warmup加余弦退火

训练到后期，我们希望loss在最小值附近精细收敛，而不是在函数低谷里来回震荡，因此需要余弦退火把学习率逐渐降到一个接近0的小值。下面这段调度器的实现可以直接抄：

import math from torch.optim import AdamW from torch.optim.lr_scheduler import LambdaLR def build_scheduler(optimizer, warmup_steps, total_steps, min_lr_ratio=0.1): def lr_lambda(current_step): if current_step < warmup_steps: return (current_step + 1) / warmup_steps progress = (current_step - warmup_steps) / max(1, total_steps - warmup_steps) return max(min_lr_ratio, 0.5 * (1.0 + math.cos(math.pi * progress))) return LambdaLR(optimizer, lr_lambda) def build_optimizer(model, lr=3e-4, weight_decay=0.1): # 只对需要梯度的参数做AdamW，LayerNorm和bias不衰减 decay_params = [] no_decay_params = [] for name, param in model.named_parameters(): if not param.requires_grad: continue if param.ndim <= 1 or name.endswith(".bias"): no_decay_params.append(param) else: decay_params.append(param) return AdamW([ {"params": decay_params, "weight_decay": weight_decay}, {"params": no_decay_params, "weight_decay": 0.0}, ], lr=lr)

这里有个容易忽略的细节：为什么LayerNorm和bias不做权重衰减？因为这些参数本身是缩放和偏移的辅助角色，不存在“拟合过度”的问题。给它们加L2惩罚反而会限制模型的表达能力。很多开源框架在实现时都把这个细节处理好了，但你如果不自己写一遍，根本不会意识到。

5.3 梯度累积与混合精度

单卡24GB显存时，一个batch直接塞max seq len的样本，能放的batch size大概只有几十。想让batch size到128或256怎么办？两条路：

• 梯度累积：把多个小batch的梯度先累加，再统一做一次参数更新。数学上相当于用更大的batch训练。要注意的是，loss需要除以累积步数，否则loss绝对值会看着偏大，影响训练曲线判断。
• 混合精度：用FP16做前向和反向计算，用FP32保存主权重和优化器状态。前提是配上scaler自动做梯度缩放。实际提升通常在1.5到2倍之间，而且显存占用大幅下降。

这两个手段组合时有个顺序问题：混合精度下梯度数值很小，容易下溢到FP16可表示范围之外，所以要先乘以一个很大的scale因子，等更新前再缩回来。PyTorch的torch.cuda.amp.GradScaler处理的就是这件事。我一开始没搞懂这个逻辑，直接把FP16梯度和梯度累积硬凑一起，遇到好几次loss突然NaN，后来才意识到是数值范围的问题。

5.4 断点续训：给训练上个保险

训练一个120M参数的模型在小数据集上可能只要几小时，但如果你扩展到更大数据，一跑就是几天，中途显卡过热、机房断电、代码被同事误杀，哪个都让你崩溃。所以checkpoint是必须做的工程基建。

我保存的checkpoint是一个字典，包括：

• 模型权重
• 优化器状态
• 学习率调度器状态
• 当前epoch和step数
• tokenizer配置
• 随机数生成器的状态（这个很关键，否则续训时数据顺序会变）

接着看续训的加载代码，和保存对应：

def save_checkpoint(path, model, optimizer, scheduler, scaler, step, rng_state): checkpoint = { "model_state": model.state_dict(), "optimizer_state": optimizer.state_dict(), "scheduler_state": scheduler.state_dict(), "scaler_state": scaler.state_dict(), "step": step, "rng_state": rng_state, } torch.save(checkpoint, path) def load_checkpoint(path, model, optimizer, scheduler, scaler): checkpoint = torch.load(path, map_location="cpu") model.load_state_dict(checkpoint["model_state"]) optimizer.load_state_dict(checkpoint["optimizer_state"]) scheduler.load_state_dict(checkpoint["scheduler_state"]) scaler.load_state_dict(checkpoint["scaler_state"]) return checkpoint["step"]

我习惯同时保留最近3个checkpoint轮换覆盖，以及每训练一定步数保存一个永久存档点。轮换覆盖是为了省磁盘，永久存档是为了出问题时能回退对比。

5.5 日志与监控体系

训练过程中如果只看loss一条曲线，你会错过很多先兆信号。我会周期性记录这些指标：step loss、当前学习率、梯度范数、权重范数、显存占用、缩放因子。梯度范数尤其有用——如果它突然飙升到几百上千，大概率是数值不稳定或数据异常的前兆，可以在出事之前早做处理。

6. 评估与迭代：别被训练loss骗了

训练loss下降只能说明模型在拟合训练集，完全不能证明它学会了语言规律。这一节聊聊我如何评估一个刚训练出来的小模型，以及怎么判断它到底是真的会了，还是在记题。

6.1 验证集loss与困惑度

我每个epoch结束都会在验证集上算一次loss。不同长度的上下文、不同来源的文本分开统计，这样能暴露出模型在某些领域上的薄弱环节。验证集loss换算成困惑度（perplexity）后更直观：困惑度接近词表大小时约等于瞎猜；降到50以下才算有点像样；小数据集上好模型可以到20-30附近。

还需要对比训练loss和验证loss的走势。如果训练loss一直降但验证loss开始反弹，说明过拟合了。这种情况在小模型上尤其容易遇到，对策是加数据多样性、增强dropout、或引入weight decay。

6.2 文本生成验证

最直观的验证方式是把模型当文本续写器用。给定一个开头，模型逐token自回归地生成。推理时不能直接把每一步的logits都argmax，因为那样生成结果会非常无聊，而且容易陷入重复循环。标准的做法是温度采样加top-k截断：

def generate(model, tokenizer, prompt, max_new_tokens=100, temperature=0.8, top_k=40): model.eval() input_ids = tokenizer.encode(prompt) input_tensor = torch.tensor([input_ids], device=model.device) with torch.no_grad(): for _ in range(max_new_tokens): logits = model(input_tensor)[:, -1, :] / temperature top_k_logits, top_k_indices = torch.topk(logits, top_k, dim=-1) probs = torch.softmax(top_k_logits, dim=-1) next_token = top_k_indices.gather(1, torch.multinomial(probs, 1)) input_tensor = torch.cat([input_tensor, next_token], dim=-1) if next_token.item() == tokenizer.token_to_id("[EOS]"): break return tokenizer.decode(input_tensor[0].tolist())

温度决定了随机性：温度越低，生成越确定；温度越高，越有创意但越容易胡言乱语。top-k限制候选范围，避免模型偶尔抽到概率极低的垃圾token。这两个参数的配合是控制生成质量最直接的手段。

6.3 填补“中文效果”实战

在生成验证阶段，我看到一个比较明显的中文问题——刚开始模型会把所有标点后都加一个空格，因为我的tokenizer是从英文习惯的BPE基础上训练的，中英混排时经常出现“你说得 对”这种割裂形式。这个问题的根源不是模型，而是数据里中英文之间空格规则不统一。修正是在清洗阶段给中文字符和英文字符之间加特定标记，并且对BPE的合并顺序做了限制，不让它在中文单字之间做过度合并。改完之后，中文生成质量肉眼可见地上了一个台阶。

这类问题如果只看loss是发现不了的，必须靠人工产出样本来找毛病。所以说，训练和评估是个来回修正的闭环。

6.4 从“模仿”到“推理”：什么才算真学会

最后聊一个比较容易抬杠的问题：模型生成的文本看起来流畅，就代表它“理解”了吗？我的态度是不要纠结哲学问题，而是用行为去判断。初训完的模型基本只能模仿局部统计规律，你给它一个数学题，它可能说出貌似合理的但完全错误的过程。真正想让它有一点推理能力，需要额外的微调数据。

在项目后半程，我构造了一批“思考-回答”式的训练数据做指令微调：输入一个问题，模型先输出推理过程，再给出最终答案。具体数据像是：

• 问题：“一个矩形长6厘米，宽4厘米，面积是多少？”
• 思考：“矩形面积等于长乘宽，所以是6乘4等于24。”
• 回答：“这个矩形的面积是24平方厘米。”

这类数据不需要太多，几千条高质量样本经过两到三个epoch的训练后，明显能看到模型在回答类似问题时开始使用“先推理再下结论”的模式。这个过程让我体会到，所谓“推理能力”很大程度是训练数据的分布塑造出来的行为模式。

7. 踩坑清单与调参心得：我花时间最多的地方

这个项目做完，我在纯模型代码上花的时间其实不算多，真正消耗大头的，全是各种“隐形坑”。这里整理一份我踩过的坑清单，希望能帮后来者省点时间。

再分享几个调参经验。第一点，学习率不是越大约好，也不是越大越快。对120M参数这个规模，3e-4上下比较稳健，超过1e-3大概率震荡。第二点便是warmup，它的作用真的被很多人低估了，尤其是从随机权重开始训练时，稳定的warmup往往比调多久的正式学习率都重要。第三点是梯度裁剪，把梯度的全局范数限制在1.0附近，训练稳定性会有立竿见影的提升。

torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0)

如果你发现限制很紧还是爆炸，就先检查一下是不是数据里混入了异常的超长或超怪文本，很多时候问题是出在数据而非训练参数上。

8. 复盘与下一步扩展

从零手写这个AI训练项目，最大的收获并不是模型指标的提升，而是把那些被框架“包装好”的工程细节一个个暴露在眼前。以前用Trainer时，我根本不会去思考batch size到底怎么影响吞吐量、梯度累积的数学边界是什么、权重的学习率为什么不能一概而论。自己动手写一遍之后，这些概念都被“焊”在了脑子里，再也去不掉。

如果你也想做类似项目，我有一句比较实用的建议：不要一上来就追求训练一个超大模型。挑一个小一点但完整的数据集，把一个能跑通的完整闭环搭起来，再逐步加大规模。因为工程框架问题在模型小的时候暴露得最快，也最好修。等基建稳了，升级规模只是时间和算力的问题。

后续我想在这个项目上扩展的方向有两个。第一个是把推理优化做起来，写一个简单的KV Cache缓存机制，让生成效率提升几倍；第二个是用合成数据做更多推理类的微调实验，观察模型在不同类型任务上的泛化能力变化。整个项目从零到一的过程，有点像是给之前所有“互联网快餐式”的学习方式补了一堂真正扎实的基础课。