1. 为什么个人开发者现在值得认真跑一遍LLM全流程很多人对个人开发者做LLM这件事有个误解觉得要么是调个API写个套壳应用要么是动辄八卡A100的烧钱游戏。这两种认知都偏离了实际。真实情况是从零预训练一个小规模LLM再把它适配到具体领域这条完整链路在单张RTX 3090上是可以跑通的而且跑通之后你对LLM的理解会发生质变——你不再是一个只会调接口的使用者而是真正知道模型内部在发生什么的人。我自己走这条路的时候最初的动机很朴素网上关于LLM的资料要么是论文级的理论推导要么是pip install然后调用的浅层教程中间那层我到底该怎么动手、每一步为什么这么做、哪里会炸的实操经验几乎是空白的。尤其是预训练阶段大部分人直接跳到微调跳过了从原始文本到token、从token到向量、从向量到概率分布这一整套流程。结果就是遇到问题时完全不知道从哪排查。这篇内容面向的是有一定Python和深度学习基础、手上有单卡消费级显卡、想真正搞懂LLM全流程的个人开发者。我会把从数据准备、分词器训练、GPT-2架构预训练到领域适配微调的完整路径拆开讲重点放在那些文档里不会写、但实际跑起来一定会遇到的坑上。关键词里的LLM、预训练、领域适配、GPT-2、RTX 3090这几个点会贯穿全文因为这就是个人开发者最现实的起点组合。先说结论性的判断个人开发者做LLM核心价值不在于训出一个比肩商用模型的产物而在于掌握数据到模型的完整控制权。当你自己训过一遍你才知道领域适配时该动哪一层、学习率该设多少、数据该配比成什么样。这些判断力是调API永远给不了你的。2. 预训练之前必须想清楚的三个现实约束2.1 显存决定了你的模型规模上限RTX 3090的24GB显存是个人开发者最现实的硬件。这个数字直接框定了你能玩的模型规模。先算一笔账预训练时显存占用大致由三部分组成——模型参数、梯度、优化器状态。如果用AdamW优化器每个参数需要存储参数本身fp16约2字节、梯度fp16约2字节、一阶矩和二阶矩fp32各4字节加起来每个参数约12字节。再加上激活值实际开销更大。按这个算法24GB显存能舒服预训练的模型规模大概在1亿到3.5亿参数之间具体取决于你的batch size和序列长度。GPT-2 small是1.24亿参数GPT-2 medium是3.55亿参数这两个是个人开发者最现实的选择。我建议从GPT-2 small的架构起步不是因为它小而是因为它的架构足够经典、社区资料足够多、出问题容易对照排查。如果你非要上更大的模型就得用梯度累积、梯度检查点、混合精度这些技术来换显存。梯度检查点是用计算时间换显存能把激活值占用降到原来的几分之一但训练速度会慢20%到30%。这个取舍在个人场景下通常是值得的。2.2 数据质量比数据量更致命个人开发者拿不到Common Crawl那种级别的数据也没必要。预训练阶段真正重要的是数据的干净程度和领域一致性。我见过太多人爬了几十GB文本直接开训结果模型输出全是乱码和重复。问题不在模型在数据。一个可操作的判断标准你的原始文本经过清洗后如果重复率超过5%、乱码率超过1%、或者单条样本长度分布极度不均那这批数据就不能直接用。清洗流程至少要包含去重精确去重加近似去重、去乱码过滤非目标语言字符占比过高的样本、长度过滤去掉过短和过长的极端样本、以及敏感内容过滤。数据量方面个人预训练不需要几十GB。1GB到5GB的高质量领域文本配合充分的训练轮次就能让模型学到该领域的语言模式。关键是这批数据要和你后续的领域适配目标一致。比如你要做医疗领域那预训练数据里就应该有相当比例的医学文本而不是拿通用语料训完再指望微调能救回来。2.3 训练时间要有心理预期在单张3090上预训练GPT-2 small处理1GB文本、跑3到5个epoch大概需要几天到一周的连续训练时间。这个时间成本必须提前接受。如果你指望几小时出结果那说明你对预训练的预期需要调整。实际训练中吞吐量tokens/sec是你要盯的核心指标。GPT-2 small在3090上用fp16混合精度batch size设到16、序列长度512的情况下吞吐量大概在每秒几千到一万多token之间。你可以用这个数字反推总训练时间总token数除以吞吐量就是小时数。提前算好避免训到一半发现时间不够。提示训练前务必用小批量数据跑通完整流程确认loss能正常下降、显存不爆、checkpoint能正常保存再上全量数据。这个小步验证能帮你省下大量返工时间。3. 分词器被大多数人跳过却最关键的一步3.1 为什么不能直接用现成的GPT-2分词器很多人图省事直接加载gpt2的预训练分词器就开始训。这在通用场景下勉强能用但一旦涉及领域适配现成分词器就是灾难。原因很简单通用分词器的词表是在通用语料上训出来的你的领域术语在它眼里会被切成一堆无意义的子词碎片。举个例子假设你的领域里有心肌梗死这个词。通用分词器可能把它切成心、肌、梗、死四个token甚至更碎。这意味着模型要花额外的容量去学习这四个token连在一起表示一个概念效率极低。而如果你用自己的领域语料训练分词器心肌梗死很可能就是一个完整的token模型学起来直接得多。分词器的质量直接决定了模型的学习效率。这是我在实际项目中体会最深的一点同样的数据和架构换一个领域适配的分词器收敛速度和最终效果能差出一大截。3.2 用SentencePiece训练领域分词器的实操我推荐用SentencePiece它是目前最成熟的开源分词工具支持BPE和Unigram两种算法。对于中文为主的领域语料Unigram通常效果更好中英混合的话BPE更稳。训练分词器的核心参数就几个词表大小vocab_size、字符覆盖率character_coverage、以及是否保留字节回退。词表大小建议设在32000到50000之间太小会导致切分过碎太大则稀疏。字符覆盖率对中文建议设0.9995以上确保生僻字不被丢弃。import sentencepiece as spm spm.SentencePieceTrainer.train( inputcorpus.txt, model_prefixdomain_tokenizer, vocab_size40000, character_coverage0.9995, model_typeunigram, pad_id0, unk_id1, bos_id2, eos_id3, user_defined_symbols[|endoftext|], num_threads16 )训练完之后一定要做验证拿一批领域文本过一遍分词器看平均每条文本被切成多少token。如果切出来的token数比用通用分词器还多说明词表没训好得调整参数重来。正常情况下领域分词器应该能把领域文本的token数压到通用分词器的70%到85%。3.3 特殊token的设计不能马虎预训练用的特殊token必须提前规划好。至少需要padding token、unknown token、句子起始和结束token、以及文档分隔token。这些token的ID一旦确定后续所有环节都要保持一致改起来代价极大。我踩过的坑是一开始没设文档分隔token结果多个文档拼在一起训练时模型学不会文档边界生成时经常把两篇不相关的内容缝在一起。后来加了|endoftext|作为分隔符重新训了一遍才解决。这个教训是特殊token的设计要在预训练开始前就定死不要中途改。4. GPT-2架构预训练从配置到收敛的完整过程4.1 模型配置的取舍逻辑GPT-2 small的原始配置是12层、768隐藏维度、12个注意力头、上下文长度1024。这个配置在3090上跑起来比较舒服。但你可以根据领域特点微调如果领域文本普遍较短比如对话、短文本分类可以把上下文长度降到512省下的显存用来加大batch size如果领域需要长距离依赖比如长文档理解就保持1024甚至用位置插值扩展到更长。层数和隐藏维度的调整要谨慎。减层会显著降低模型容量加层则显存和时间成本陡增。个人开发者的甜点区就是12层768维这个量级不要轻易偏离。注意力头的数量要和隐藏维度匹配768维配12个头每个头64维是标准做法。如果你改了隐藏维度头数要相应调整保证每个头的维度在64左右。4.2 训练超参数的设置与调整预训练的超参数里学习率、warmup步数、batch size这三个是最关键的。学习率建议从1e-4到3e-4之间起步配合线性warmup和余弦衰减。warmup步数设总步数的1%到5%让模型有个平稳的起步。batch size在显存允许的前提下尽量大因为大batch能稳定梯度。如果显存不够就用梯度累积模拟大batch。比如你想要等效batch size 64但显存只够放16那就设梯度累积步数为4。# 关键训练配置示例 config { learning_rate: 2e-4, warmup_steps: 2000, max_steps: 100000, per_device_batch_size: 16, gradient_accumulation_steps: 4, # 等效batch size 64 weight_decay: 0.01, max_grad_norm: 1.0, fp16: True, gradient_checkpointing: True, }梯度裁剪max_grad_norm一定要开设1.0是安全值。预训练早期梯度容易爆炸不开裁剪很容易训飞。混合精度fp16能省显存提速但要配合loss scaling防止梯度下溢。4.3 怎么判断模型是不是在正常收敛预训练的loss曲线是你唯一的导航仪。健康的loss曲线应该是初期快速下降然后进入缓慢下降的长尾阶段整体平滑没有剧烈震荡。如果loss上下乱跳多半是学习率太大或batch size太小如果loss几乎不降检查数据是否有问题、学习率是否太小。我习惯每隔一定步数记录一次验证集loss。验证loss和训练loss的差距能反映过拟合程度。预训练阶段过拟合通常不是大问题数据量大但如果验证loss很早就开始上升说明模型容量相对数据量偏大或者数据重复率太高。还有一个实用技巧定期用模型生成一些样本人眼检查。loss再好看生成出来是乱码也没用。我一般每训几千步就生成几段看看观察模型是不是在逐步学会领域语言的语法和用词习惯。这个定性判断比loss数字更直观。注意预训练checkpoint要定期保存并且保留多个版本。训练崩溃、显存溢出、断电这些意外随时可能发生没有checkpoint就得从头再来。建议至少保留最近3个checkpoint加一个最佳checkpoint。5. 领域适配让预训练模型真正能干活5.1 领域适配到底在适配什么预训练出来的模型学会了领域的语言但不会干具体的活。领域适配要解决的是把语言能力对齐到具体任务上。这里有个关键认知领域适配不是简单地拿领域数据再训一遍而是要有明确的任务目标和数据格式。领域适配通常分两个层次。第一个层次是继续预训练continued pretraining用领域语料在预训练模型基础上再训让模型更深入地吸收领域知识。第二个层次是指令微调instruction tuning用指令-回答格式的数据训练模型遵循指令。个人开发者做领域适配通常两个层次都要走。5.2 继续预训练的数据配比与学习率继续预训练的数据要领域语料和通用语料混合纯领域语料会让模型丧失通用能力出现灾难性遗忘。我的经验配比是领域语料占70%到80%通用语料占20%到30%。通用语料的作用是锚定防止模型跑偏。学习率要比预训练时小一个量级用1e-5到5e-5之间。继续预训练是精细调整不是重新学习学习率太大会把预训练学到的知识冲掉。训练轮次也不要多1到2个epoch通常就够训太多同样会过拟合领域数据。5.3 指令微调的数据构造指令微调的数据质量决定最终效果。个人开发者拿不到大规模标注数据但可以用模板化方法从领域文档自动构造指令数据。比如从医学文档里抽取症状-诊断对构造成患者出现XX症状可能是什么病这样的指令格式。数据格式要统一通常用指令输入输出的三段式。构造时要注意指令的多样性同一个知识点用不同问法表达避免模型只学会匹配固定模板。我一般会为每个知识点准备3到5种不同的指令表述。指令微调的学习率可以比继续预训练再小一点用1e-5到2e-5。训练轮次2到3个epoch。这个阶段要密切监控验证集因为指令数据量通常不大很容易过拟合。5.4 适配效果的评估方法领域适配做完怎么知道效果好不好不能只看loss要看实际任务表现。我通常从三个维度评估一是生成质量人工看生成内容是否通顺、是否符合领域规范二是任务准确率如果有标注测试集直接算准确率三是通用能力保持度用一些通用问题测试模型有没有变傻。如果发现模型在领域任务上表现好但通用能力严重下降说明继续预训练时领域数据占比太高要调整配比重训。如果领域任务表现也不好检查指令数据质量多半是数据格式或内容有问题。6. 单卡3090上的工程优化与踩坑记录6.1 显存优化的几个实用手段24GB显存跑预训练优化手段要组合使用。梯度检查点是最有效的单手段能省一半以上激活值显存代价是速度慢一些。混合精度训练fp16或bf16能省显存又提速3090对bf16支持不错优先用bf16。优化器方面如果显存实在紧张可以用8-bit Adam把优化器状态从fp32压到int8能省不少显存。还有一个容易被忽略的点数据加载器的工作进程数num_workers。设太小会导致GPU等数据设太大会占满CPU内存。一般设成CPU核心数的一半左右比较合适。我一开始设成0结果GPU利用率只有30%改成8之后直接拉满。6.2 训练中断与恢复的处理长时间训练一定会遇到中断。checkpoint要保存完整的训练状态不只是模型权重还要包括优化器状态、学习率调度器状态、当前步数、随机数种子。这样恢复训练时才能无缝衔接否则学习率会重置、优化器动量会丢失影响收敛。# 保存完整训练状态 torch.save({ model_state_dict: model.state_dict(), optimizer_state_dict: optimizer.state_dict(), scheduler_state_dict: scheduler.state_dict(), global_step: global_step, epoch: epoch, rng_state: torch.get_rng_state(), }, checkpoint_path)恢复时把这些状态全部加载回去从断点继续。我踩过的坑是只存了模型权重恢复后loss直接跳变白训了好几天。完整状态保存是长训练的保命符。6.3 那些文档里不会写的坑第一个坑是tokenizer和模型词表不匹配。自己训的分词器词表大小如果和模型embedding层对不上训练直接报错。这个要在建模时就对齐embedding层的vocab_size必须等于分词器的词表大小。第二个坑是padding策略影响loss计算。如果padding token的loss没有mask掉模型会花大量精力学习预测padding浪费容量还影响效果。计算loss时一定要把padding位置的label设成-100PyTorch的ignore_index。第三个坑是学习率调度器和优化器的初始化顺序。必须先定义优化器再定义调度器否则调度器拿不到正确的参数组。这个顺序错了不会报错但学习率会一直不对很难排查。第四个坑是数据预处理和训练用不同的分词器版本。预处理时用A版本分词器编码训练时加载了B版本token ID全乱套。分词器文件要固定版本并和预处理数据绑定。7. 从预训练到领域适配的完整链路复盘把整条链路串起来看个人开发者的LLM实践路径其实很清晰数据清洗 → 分词器训练 → 预训练 → 继续预训练 → 指令微调 → 评估。每一步都有明确的输入输出和验证标准。我自己的项目里这套流程跑下来大概花了两周多其中预训练占了大头。最终得到的模型在领域任务上表现不错虽然规模不大但完全可控、可解释、可迭代。这种掌控感是调API给不了的。几个关键的经验数字再强调一遍词表大小40000左右、模型12层768维、学习率预训练2e-4微调1e-5、领域数据占比70%到80%、梯度裁剪1.0。这些是我实测下来比较稳的配置可以作为你的起点再根据具体情况微调。最后分享一个心态上的体会个人做LLM不要追求一步到位。先跑通最小闭环再逐步优化。我第一版模型效果很一般但整个流程跑通了后面每一步优化都有明确的对照基准。如果一开始就追求完美配置很可能卡在某个环节出不来。先让它跑起来再让它跑得好这个顺序不能反。
个人开发者单卡RTX 3090实战：从零预训练LLM到领域适配全流程
1. 为什么个人开发者现在值得认真跑一遍LLM全流程很多人对个人开发者做LLM这件事有个误解觉得要么是调个API写个套壳应用要么是动辄八卡A100的烧钱游戏。这两种认知都偏离了实际。真实情况是从零预训练一个小规模LLM再把它适配到具体领域这条完整链路在单张RTX 3090上是可以跑通的而且跑通之后你对LLM的理解会发生质变——你不再是一个只会调接口的使用者而是真正知道模型内部在发生什么的人。我自己走这条路的时候最初的动机很朴素网上关于LLM的资料要么是论文级的理论推导要么是pip install然后调用的浅层教程中间那层我到底该怎么动手、每一步为什么这么做、哪里会炸的实操经验几乎是空白的。尤其是预训练阶段大部分人直接跳到微调跳过了从原始文本到token、从token到向量、从向量到概率分布这一整套流程。结果就是遇到问题时完全不知道从哪排查。这篇内容面向的是有一定Python和深度学习基础、手上有单卡消费级显卡、想真正搞懂LLM全流程的个人开发者。我会把从数据准备、分词器训练、GPT-2架构预训练到领域适配微调的完整路径拆开讲重点放在那些文档里不会写、但实际跑起来一定会遇到的坑上。关键词里的LLM、预训练、领域适配、GPT-2、RTX 3090这几个点会贯穿全文因为这就是个人开发者最现实的起点组合。先说结论性的判断个人开发者做LLM核心价值不在于训出一个比肩商用模型的产物而在于掌握数据到模型的完整控制权。当你自己训过一遍你才知道领域适配时该动哪一层、学习率该设多少、数据该配比成什么样。这些判断力是调API永远给不了你的。2. 预训练之前必须想清楚的三个现实约束2.1 显存决定了你的模型规模上限RTX 3090的24GB显存是个人开发者最现实的硬件。这个数字直接框定了你能玩的模型规模。先算一笔账预训练时显存占用大致由三部分组成——模型参数、梯度、优化器状态。如果用AdamW优化器每个参数需要存储参数本身fp16约2字节、梯度fp16约2字节、一阶矩和二阶矩fp32各4字节加起来每个参数约12字节。再加上激活值实际开销更大。按这个算法24GB显存能舒服预训练的模型规模大概在1亿到3.5亿参数之间具体取决于你的batch size和序列长度。GPT-2 small是1.24亿参数GPT-2 medium是3.55亿参数这两个是个人开发者最现实的选择。我建议从GPT-2 small的架构起步不是因为它小而是因为它的架构足够经典、社区资料足够多、出问题容易对照排查。如果你非要上更大的模型就得用梯度累积、梯度检查点、混合精度这些技术来换显存。梯度检查点是用计算时间换显存能把激活值占用降到原来的几分之一但训练速度会慢20%到30%。这个取舍在个人场景下通常是值得的。2.2 数据质量比数据量更致命个人开发者拿不到Common Crawl那种级别的数据也没必要。预训练阶段真正重要的是数据的干净程度和领域一致性。我见过太多人爬了几十GB文本直接开训结果模型输出全是乱码和重复。问题不在模型在数据。一个可操作的判断标准你的原始文本经过清洗后如果重复率超过5%、乱码率超过1%、或者单条样本长度分布极度不均那这批数据就不能直接用。清洗流程至少要包含去重精确去重加近似去重、去乱码过滤非目标语言字符占比过高的样本、长度过滤去掉过短和过长的极端样本、以及敏感内容过滤。数据量方面个人预训练不需要几十GB。1GB到5GB的高质量领域文本配合充分的训练轮次就能让模型学到该领域的语言模式。关键是这批数据要和你后续的领域适配目标一致。比如你要做医疗领域那预训练数据里就应该有相当比例的医学文本而不是拿通用语料训完再指望微调能救回来。2.3 训练时间要有心理预期在单张3090上预训练GPT-2 small处理1GB文本、跑3到5个epoch大概需要几天到一周的连续训练时间。这个时间成本必须提前接受。如果你指望几小时出结果那说明你对预训练的预期需要调整。实际训练中吞吐量tokens/sec是你要盯的核心指标。GPT-2 small在3090上用fp16混合精度batch size设到16、序列长度512的情况下吞吐量大概在每秒几千到一万多token之间。你可以用这个数字反推总训练时间总token数除以吞吐量就是小时数。提前算好避免训到一半发现时间不够。提示训练前务必用小批量数据跑通完整流程确认loss能正常下降、显存不爆、checkpoint能正常保存再上全量数据。这个小步验证能帮你省下大量返工时间。3. 分词器被大多数人跳过却最关键的一步3.1 为什么不能直接用现成的GPT-2分词器很多人图省事直接加载gpt2的预训练分词器就开始训。这在通用场景下勉强能用但一旦涉及领域适配现成分词器就是灾难。原因很简单通用分词器的词表是在通用语料上训出来的你的领域术语在它眼里会被切成一堆无意义的子词碎片。举个例子假设你的领域里有心肌梗死这个词。通用分词器可能把它切成心、肌、梗、死四个token甚至更碎。这意味着模型要花额外的容量去学习这四个token连在一起表示一个概念效率极低。而如果你用自己的领域语料训练分词器心肌梗死很可能就是一个完整的token模型学起来直接得多。分词器的质量直接决定了模型的学习效率。这是我在实际项目中体会最深的一点同样的数据和架构换一个领域适配的分词器收敛速度和最终效果能差出一大截。3.2 用SentencePiece训练领域分词器的实操我推荐用SentencePiece它是目前最成熟的开源分词工具支持BPE和Unigram两种算法。对于中文为主的领域语料Unigram通常效果更好中英混合的话BPE更稳。训练分词器的核心参数就几个词表大小vocab_size、字符覆盖率character_coverage、以及是否保留字节回退。词表大小建议设在32000到50000之间太小会导致切分过碎太大则稀疏。字符覆盖率对中文建议设0.9995以上确保生僻字不被丢弃。import sentencepiece as spm spm.SentencePieceTrainer.train( inputcorpus.txt, model_prefixdomain_tokenizer, vocab_size40000, character_coverage0.9995, model_typeunigram, pad_id0, unk_id1, bos_id2, eos_id3, user_defined_symbols[|endoftext|], num_threads16 )训练完之后一定要做验证拿一批领域文本过一遍分词器看平均每条文本被切成多少token。如果切出来的token数比用通用分词器还多说明词表没训好得调整参数重来。正常情况下领域分词器应该能把领域文本的token数压到通用分词器的70%到85%。3.3 特殊token的设计不能马虎预训练用的特殊token必须提前规划好。至少需要padding token、unknown token、句子起始和结束token、以及文档分隔token。这些token的ID一旦确定后续所有环节都要保持一致改起来代价极大。我踩过的坑是一开始没设文档分隔token结果多个文档拼在一起训练时模型学不会文档边界生成时经常把两篇不相关的内容缝在一起。后来加了|endoftext|作为分隔符重新训了一遍才解决。这个教训是特殊token的设计要在预训练开始前就定死不要中途改。4. GPT-2架构预训练从配置到收敛的完整过程4.1 模型配置的取舍逻辑GPT-2 small的原始配置是12层、768隐藏维度、12个注意力头、上下文长度1024。这个配置在3090上跑起来比较舒服。但你可以根据领域特点微调如果领域文本普遍较短比如对话、短文本分类可以把上下文长度降到512省下的显存用来加大batch size如果领域需要长距离依赖比如长文档理解就保持1024甚至用位置插值扩展到更长。层数和隐藏维度的调整要谨慎。减层会显著降低模型容量加层则显存和时间成本陡增。个人开发者的甜点区就是12层768维这个量级不要轻易偏离。注意力头的数量要和隐藏维度匹配768维配12个头每个头64维是标准做法。如果你改了隐藏维度头数要相应调整保证每个头的维度在64左右。4.2 训练超参数的设置与调整预训练的超参数里学习率、warmup步数、batch size这三个是最关键的。学习率建议从1e-4到3e-4之间起步配合线性warmup和余弦衰减。warmup步数设总步数的1%到5%让模型有个平稳的起步。batch size在显存允许的前提下尽量大因为大batch能稳定梯度。如果显存不够就用梯度累积模拟大batch。比如你想要等效batch size 64但显存只够放16那就设梯度累积步数为4。# 关键训练配置示例 config { learning_rate: 2e-4, warmup_steps: 2000, max_steps: 100000, per_device_batch_size: 16, gradient_accumulation_steps: 4, # 等效batch size 64 weight_decay: 0.01, max_grad_norm: 1.0, fp16: True, gradient_checkpointing: True, }梯度裁剪max_grad_norm一定要开设1.0是安全值。预训练早期梯度容易爆炸不开裁剪很容易训飞。混合精度fp16能省显存提速但要配合loss scaling防止梯度下溢。4.3 怎么判断模型是不是在正常收敛预训练的loss曲线是你唯一的导航仪。健康的loss曲线应该是初期快速下降然后进入缓慢下降的长尾阶段整体平滑没有剧烈震荡。如果loss上下乱跳多半是学习率太大或batch size太小如果loss几乎不降检查数据是否有问题、学习率是否太小。我习惯每隔一定步数记录一次验证集loss。验证loss和训练loss的差距能反映过拟合程度。预训练阶段过拟合通常不是大问题数据量大但如果验证loss很早就开始上升说明模型容量相对数据量偏大或者数据重复率太高。还有一个实用技巧定期用模型生成一些样本人眼检查。loss再好看生成出来是乱码也没用。我一般每训几千步就生成几段看看观察模型是不是在逐步学会领域语言的语法和用词习惯。这个定性判断比loss数字更直观。注意预训练checkpoint要定期保存并且保留多个版本。训练崩溃、显存溢出、断电这些意外随时可能发生没有checkpoint就得从头再来。建议至少保留最近3个checkpoint加一个最佳checkpoint。5. 领域适配让预训练模型真正能干活5.1 领域适配到底在适配什么预训练出来的模型学会了领域的语言但不会干具体的活。领域适配要解决的是把语言能力对齐到具体任务上。这里有个关键认知领域适配不是简单地拿领域数据再训一遍而是要有明确的任务目标和数据格式。领域适配通常分两个层次。第一个层次是继续预训练continued pretraining用领域语料在预训练模型基础上再训让模型更深入地吸收领域知识。第二个层次是指令微调instruction tuning用指令-回答格式的数据训练模型遵循指令。个人开发者做领域适配通常两个层次都要走。5.2 继续预训练的数据配比与学习率继续预训练的数据要领域语料和通用语料混合纯领域语料会让模型丧失通用能力出现灾难性遗忘。我的经验配比是领域语料占70%到80%通用语料占20%到30%。通用语料的作用是锚定防止模型跑偏。学习率要比预训练时小一个量级用1e-5到5e-5之间。继续预训练是精细调整不是重新学习学习率太大会把预训练学到的知识冲掉。训练轮次也不要多1到2个epoch通常就够训太多同样会过拟合领域数据。5.3 指令微调的数据构造指令微调的数据质量决定最终效果。个人开发者拿不到大规模标注数据但可以用模板化方法从领域文档自动构造指令数据。比如从医学文档里抽取症状-诊断对构造成患者出现XX症状可能是什么病这样的指令格式。数据格式要统一通常用指令输入输出的三段式。构造时要注意指令的多样性同一个知识点用不同问法表达避免模型只学会匹配固定模板。我一般会为每个知识点准备3到5种不同的指令表述。指令微调的学习率可以比继续预训练再小一点用1e-5到2e-5。训练轮次2到3个epoch。这个阶段要密切监控验证集因为指令数据量通常不大很容易过拟合。5.4 适配效果的评估方法领域适配做完怎么知道效果好不好不能只看loss要看实际任务表现。我通常从三个维度评估一是生成质量人工看生成内容是否通顺、是否符合领域规范二是任务准确率如果有标注测试集直接算准确率三是通用能力保持度用一些通用问题测试模型有没有变傻。如果发现模型在领域任务上表现好但通用能力严重下降说明继续预训练时领域数据占比太高要调整配比重训。如果领域任务表现也不好检查指令数据质量多半是数据格式或内容有问题。6. 单卡3090上的工程优化与踩坑记录6.1 显存优化的几个实用手段24GB显存跑预训练优化手段要组合使用。梯度检查点是最有效的单手段能省一半以上激活值显存代价是速度慢一些。混合精度训练fp16或bf16能省显存又提速3090对bf16支持不错优先用bf16。优化器方面如果显存实在紧张可以用8-bit Adam把优化器状态从fp32压到int8能省不少显存。还有一个容易被忽略的点数据加载器的工作进程数num_workers。设太小会导致GPU等数据设太大会占满CPU内存。一般设成CPU核心数的一半左右比较合适。我一开始设成0结果GPU利用率只有30%改成8之后直接拉满。6.2 训练中断与恢复的处理长时间训练一定会遇到中断。checkpoint要保存完整的训练状态不只是模型权重还要包括优化器状态、学习率调度器状态、当前步数、随机数种子。这样恢复训练时才能无缝衔接否则学习率会重置、优化器动量会丢失影响收敛。# 保存完整训练状态 torch.save({ model_state_dict: model.state_dict(), optimizer_state_dict: optimizer.state_dict(), scheduler_state_dict: scheduler.state_dict(), global_step: global_step, epoch: epoch, rng_state: torch.get_rng_state(), }, checkpoint_path)恢复时把这些状态全部加载回去从断点继续。我踩过的坑是只存了模型权重恢复后loss直接跳变白训了好几天。完整状态保存是长训练的保命符。6.3 那些文档里不会写的坑第一个坑是tokenizer和模型词表不匹配。自己训的分词器词表大小如果和模型embedding层对不上训练直接报错。这个要在建模时就对齐embedding层的vocab_size必须等于分词器的词表大小。第二个坑是padding策略影响loss计算。如果padding token的loss没有mask掉模型会花大量精力学习预测padding浪费容量还影响效果。计算loss时一定要把padding位置的label设成-100PyTorch的ignore_index。第三个坑是学习率调度器和优化器的初始化顺序。必须先定义优化器再定义调度器否则调度器拿不到正确的参数组。这个顺序错了不会报错但学习率会一直不对很难排查。第四个坑是数据预处理和训练用不同的分词器版本。预处理时用A版本分词器编码训练时加载了B版本token ID全乱套。分词器文件要固定版本并和预处理数据绑定。7. 从预训练到领域适配的完整链路复盘把整条链路串起来看个人开发者的LLM实践路径其实很清晰数据清洗 → 分词器训练 → 预训练 → 继续预训练 → 指令微调 → 评估。每一步都有明确的输入输出和验证标准。我自己的项目里这套流程跑下来大概花了两周多其中预训练占了大头。最终得到的模型在领域任务上表现不错虽然规模不大但完全可控、可解释、可迭代。这种掌控感是调API给不了的。几个关键的经验数字再强调一遍词表大小40000左右、模型12层768维、学习率预训练2e-4微调1e-5、领域数据占比70%到80%、梯度裁剪1.0。这些是我实测下来比较稳的配置可以作为你的起点再根据具体情况微调。最后分享一个心态上的体会个人做LLM不要追求一步到位。先跑通最小闭环再逐步优化。我第一版模型效果很一般但整个流程跑通了后面每一步优化都有明确的对照基准。如果一开始就追求完美配置很可能卡在某个环节出不来。先让它跑起来再让它跑得好这个顺序不能反。
