从零训练2亿参数大模型：踩坑实录与工程经验

一次「反潮流」的实验

用 Unsloth 加载 Llama 3、花一个下午做微调，如今已是稀松平常的操作。但一位开发者偏偏想反其道而行——他决定完全不依赖现成框架，从头手写 BPE 分词器、实现 RoPE 位置编码、编写 SwiGLU 前馈网络，并用纯 PyTorch 写出完整训练循环。

最终的产物是 EmsyAI（V4），一个 1.967 亿参数的语言模型，在消费级 GPU 上完成训练。这不是又一个刷榜的模型，而是一份珍贵的「工程踩坑手册」——它真实记录了当架构从 8800 万参数扩展到近 2 亿参数时，那些教科书不会告诉你的边缘情况。

模型配置：精简的现代架构

尽管体量不大，EmsyAI 采用的却是当下主流大模型的技术栈，麻雀虽小五脏俱全：

• 激活参数：196.7M（约 180M 在 Transformer 块，其余约 16k 词表的嵌入层）
• 训练 token 量：19.6 亿
• 上下文窗口：4096 tokens
• 隐藏维度：1024
• 注意力机制：GQA（16 个 Query 头 / 4 个 KV 头）
• FFN 维度：2816

有意思的是 GQA（分组查询注意力） 的采用——这是 Llama 2/3、Mistral 等主流模型用于降低推理显存占用的关键技术。作者在如此小的规模上就引入这一机制，说明这次实验的目标不是「能跑就行」，而是尽可能贴近工业级架构的真实实现。

GQA（分组查询注意力，Grouped Query Attention） 是介于多头注意力（MHA）和多查询注意力（MQA）之间的一种折中方案。传统 MHA 中，每个注意力头都拥有独立的 Q、K、V 投影矩阵；MQA 则让所有头共享同一组 K/V，极大压缩了 KV Cache 的显存占用，但会牺牲表达能力。GQA 将 Query 头分成若干组，每组共享一对 K/V 头——以本文的配置为例，16 个 Query 头对应 4 个 KV 头，每 4 个 Query 头共享一组 K/V。这一设计在推理时可将 KV Cache 显存降低至 MHA 的 1/4，同时保留比 MQA 更强的建模能力。Llama 2 70B 和 Llama 3 系列正是通过引入 GQA 才得以在有限显存的消费级硬件上运行更长的上下文。

预训练：与NaN的心理博弈

作者用 FP16 混合精度训练了 15000 步。他坦言预训练过程「令人恐惧」——你始终提心吊胆地盯着 loss 曲线，生怕它突然飙升为 NaN，让数小时的算力付诸东流。

所幸曲线稳住了，验证困惑度（perplexity）最终收敛到 5.86。

「看着原始输出从第 100 步的随机乱码，逐渐变成第 10000 步可辨认的 Python 语法，是一种奇妙的满足感。」

这句话或许道出了从零训练模型最本质的价值：你能亲眼见证「智能」是如何一点点从噪声中涌现的。这种直观体验，是调用现成 API 永远无法获得的。

困惑度（Perplexity，PPL） 是语言模型最核心的评估指标之一，衡量模型对测试文本的「惊讶程度」。直觉上，PPL 越低代表模型对下一个词的预测越自信、越准确。数学上它等于测试集交叉熵损失的指数：PPL = exp(loss)，因此 loss=1.77 对应 PPL≈5.86。对于一个仅在 19.6 亿 token 上训练的 197M 参数模型，5.86 的验证困惑度处于合理区间——GPT-2（117M 参数，40GB 数据）在 WikiText-103 上约为 18-29，而训练数据更丰富的现代小模型可低至 3 以下。困惑度与模型规模和训练数据量均呈幂律关系，这正是 Chinchilla 缩放定律所描述的核心规律。

FP16 混合精度训练是指前向传播和梯度计算使用半精度浮点数（16位）以节省显存和加速计算，而模型参数的「主副本」和优化器状态（如 Adam 的一阶、二阶矩）仍以 FP32 保存，以避免精度损失导致训练不稳定。NaN（Not a Number）通常源于溢出或梯度爆炸，在 FP16 下更易发生，因为其数值范围远小于 FP32（最大约 65504 对比约 3.4×10³⁸）。

HumanEval 0分背后的深刻洞察

预训练完成后，作者使用一个仅 230 万参数的 LoRA 适配器 在 CodeAlpaca 数据集上做指令微调，随后跑了 OpenAI 的 HumanEval 代码基准测试。

结果是——0.0%。

这个成绩听上去很惨，但作者的分析恰恰是全文最有价值的部分。他指出，对于一个仅在 20 亿 token 上训练的小模型而言，无法解决多步算法难题本就是符合预期的基线表现。

数据污染的反直觉发现

更耐人寻味的是，作者进一步审计了训练数据。他采用 GPT-3 论文中标准的 13-gram 精确匹配阈值，在 CodeAlpaca 中发现了 1644 条泄露 HumanEval 测试逻辑的序列。

换言之，模型在微调阶段其实「见过」部分答案。但即便如此，它依然拿了 0 分。作者的解读很清醒：

「这并不能证明它是泛化天才，只能说明这个 230 万参数的微型 LoRA 适配器根本没有能力逐字背下这些序列。数据污染没能帮它作弊，因为它压根记不住答案。」

这一观察对整个行业都有警示意义：数据污染的危害程度，与模型的记忆容量正相关。大模型之所以能靠污染数据「刷分」，正是因为它们有足够的参数去死记硬背；而容量受限的小模型即使接触污染数据也无从「受益」。这也从侧面提醒我们，评估大模型基准成绩时必须警惕训练集泄露问题。

N-gram 精确匹配是检测数据污染最常用的方法之一。GPT-3 论文采用的 13-gram 阈值含义是：若训练集中存在任意连续 13 个词（token）与评测集完全一致的片段，则该样本被标记为可能泄露。13 这个数字被认为足够长以排除随机巧合，同时足够短以捕捉真实的文本重叠。这一方法的局限在于只能检测字面重复，无法发现语义等价但表述不同的污染——例如将变量名改写后的代码。更严格的污染检测方法包括嵌入相似度匹配和模型困惑度对比，但计算成本显著更高。

扩展到2亿参数时「崩掉」的三件事

当架构从 88M 扩展到 196M，一系列在小规模下被完全掩盖的问题浮出水面。这部分是整篇实录中含金量最高的工程经验。

注意力 logit 爆炸

在隐藏维度达到 1024 时，注意力 logit 会偶发性地剧烈飙升。标准架构在做点积前不会对 Query 和 Key 做归一化，这在规模扩大后成了严重的稳定性隐患。

作者原以为 Qwen 2.5、Gemma 2 等近期发布的模型直接修复了这一问题，但后来发现自己搞错了——Gemma 2 用的是「注意力 logit 软封顶（soft-capping）」。真正让 QK-Norm（对 Q/K 归一化）被广泛认可为训练稳定利器的，是 OLMo 2，以及后续受 Meta Chameleon 启发的 Gemma 3 和 Qwen 3。

V5 版本将引入 QK-Norm 来彻底根治这些尖峰。这一段技术溯源本身就很有价值——它展示了架构改进在开源社区中的真实传播路径。

QK-Norm 是指在计算注意力权重之前，对 Query 和 Key 向量分别做 RMSNorm 或 LayerNorm 归一化。标准 Transformer 的注意力点积结果会被除以 √d_k（头维度的平方根）来缩放，但当模型规模增大、训练深度加深时，这种静态缩放不足以防止 logit 分布在某些层或某些训练步骤中出现极端值，导致 softmax 饱和（输出趋近于 one-hot），梯度消失，进而引发 loss 尖峰甚至 NaN。QK-Norm 通过动态约束 Q/K 向量的 L2 范数来从根本上限制 logit 的量级，是近年来大模型训练稳定性工程的重要进展之一。与此同时，Gemma 2 采用的「软封顶（soft-capping）」策略则是在 logit 计算后应用 tanh 函数将其截断到固定范围，属于不同的工程路径，两者并不完全等价。

分词器字节冲突

手写 BPE 分词器时，作者搞错了回退字节映射：字节 0-3 与特殊控制 token（如 <|endoftext|>）发生了重叠。这个 bug 不会导致训练崩溃，却是一个静默地拖累性能的隐患。V5 将彻底重建分词器，并把词表规模从 16k 翻倍到 32k。

跨文档注意力污染

当前的数据加载器只是简单地把文本文件拼接起来凑满 4096 的上下文长度。这意味着模型会浪费大量算力，去关注那些仅仅碰巧落在同一训练窗口、但内容毫不相关的文档。

解决方案是实现文档感知的打包（document-aware packing） 并配以正确的注意力掩码，确保注意力不会跨越文档边界。这也是许多从零训练大模型的开发者容易忽视的细节。

亲自跑一个2亿参数模型

作者把最终权重导出为 GGUF 格式，任何人都可以在 Ollama 中运行它，亲眼看看一个 196M 模型如何「尝试（并失败）写出 FizzBuzz」：

git clone https://github.com/gulding/EmsyAI.git
cd EmsyAI
huggingface-cli download gulding/EmsyAI emsyai-v4-instruct-f32.gguf --local-dir .
ollama create emsyai-v4 -f Modelfile
ollama run emsyai-v4

完整的 PyTorch 训练循环、架构与分词器代码均已开源在 GitHub。

为什么这样的实验值得关注

在人人都能一键微调的时代，从零手写一个大模型看似「重复造轮子」，但它的价值恰恰在于暴露了框架为你隐藏的一切复杂性。QK-Norm 的稳定性作用、数据污染与模型容量的关系、跨文档注意力的隐性浪费——这些都是只有真正下场从头搭建，才会切身体会到的痛点。

对于想深入理解 LLM 内部机制的开发者而言，与其只会调 API，不如亲手踩一遍坑。毕竟，看着 loss 曲线在 NaN 边缘反复横跳而最终稳住的那份紧张与满足，才是理解这些庞然大物真正开始的地方。