1. 为什么个人开发者要跑通LLM全流程1.1 从“调API”到“自己动手”的分水岭过去两年绝大多数个人开发者接触大语言模型的方式就是调API——写几行Python把请求发给远端服务拿回结果完事。这种方式门槛低、见效快但有一个致命问题你对模型本身没有任何控制权。你不知道它为什么在某些任务上表现好、在某些任务上一塌糊涂你也没法针对自己的垂直领域做深度定制。一旦遇到需要私有数据、需要特定输出格式、需要控制推理成本的场景调API的路子就会撞墙。我自己是从2023年下半年开始认真琢磨这件事的。当时手上有一个中医药处方审核的辅助项目需要模型理解处方配伍逻辑判断是否存在十八反、十九畏这类禁忌。直接调通用API的效果很不理想——模型对中药名称的识别经常出错对配伍规则的理解也停留在表面。那时候我就意识到必须走一遍从预训练到领域适配的完整流程才能真正把模型的能力“捏”成自己需要的样子。这篇文章要聊的就是我个人在单卡RTX 3090环境下从零开始跑通LLM预训练、微调、领域适配的全流程经验。不是教科书式的理论综述而是实打实的操作记录、踩坑复盘和参数选择逻辑。适合有一定Python和PyTorch基础、想深入理解LLM底层机制、或者需要做垂直领域模型定制的个人开发者。如果你只是想快速搭个聊天机器人这篇文章可能偏“重”了但如果你想真正搞明白模型是怎么“炼”出来的那接下来的内容应该对你有用。1.2 RTX 3090单卡的真实能力边界先泼一盆冷水。RTX 3090有24GB显存在消费级显卡里算得上第一梯队但放到LLM预训练的场景里它其实非常局促。很多人看到“预训练”三个字就想到GPT-3、LLaMA那种千亿参数的巨兽觉得个人开发者根本不可能碰。这个认知需要修正个人开发者做预训练目标不是复现GPT-4而是训练一个参数量在100M到1B之间的小模型用在自己的垂直场景里。具体来说24GB显存能做什么以GPT-2架构为例124M参数的模型做全量预训练batch size开到16、序列长度512显存占用大约在8-10GB完全跑得动。355M参数的模型同样的配置下显存占用会到18-20GB需要开梯度累积或者混合精度才能稳住。再往上到774M单卡就比较吃力了得用LoRA或者冻结部分层的方式做。这里有一个关键的计算逻辑需要说清楚显存占用大致等于“模型参数显存 梯度显存 优化器状态显存 激活值显存”。以124M参数的GPT-2为例FP32下参数本身占约500MB梯度再占500MBAdam优化器需要维护一阶和二阶动量又是1GB加起来基础开销就2GB了。激活值显存跟batch size和序列长度成正比这部分才是真正吃显存的大头。所以调参的时候优先降batch size和序列长度而不是急着换模型。注意RTX 3090的24GB显存里系统会预留一部分给显示输出。如果你同时接了显示器实际可用显存大约在23GB左右。做预训练时建议用无头模式或者把显示输出接到核显上能多挤出几百MB。2. 预训练阶段的核心设计与实操2.1 数据准备比模型更重要的环节预训练的数据质量直接决定模型的下限。我见过太多人把精力全花在调模型结构上数据随便找点维基百科就开跑结果loss降不下去或者降下去了但模型生成的东西前言不搭后语。数据这件事怎么强调都不过分。我的数据来源分三块通用中文语料、领域专业语料、结构化知识文本。通用中文语料用的是开源数据集大概20GB左右主要是新闻、百科、论坛帖子。领域专业语料是我自己爬的中医药相关文献和处方记录大概3GB。结构化知识文本是把中药数据库里的性味归经、配伍禁忌等条目转成自然语言描述大概500MB。三部分按7:2:1的比例混合通用语料保证模型的语言基础能力领域语料注入专业知识结构化文本强化特定格式的理解。数据清洗的步骤不能省。我用的流程是先去重用MinHash做近似去重阈值设0.8能去掉大量重复的新闻转载然后过滤低质量文本规则包括长度少于50个字符的丢掉、中文字符占比低于60%的丢掉、包含大量特殊符号的丢掉最后做敏感内容过滤这一步用关键词黑名单加分类器双重把关。# 数据去重示例MinHash from datasketch import MinHash, MinHashLSH def deduplicate(texts, threshold0.8): lsh MinHashLSH(thresholdthreshold, num_perm128) minhashes {} for i, text in enumerate(texts): m MinHash(num_perm128) for token in set(text.split()): m.update(token.encode(utf8)) lsh.insert(fdoc_{i}, m) minhashes[fdoc_{i}] m # 返回去重后的索引 unique_indices set() for i, text in enumerate(texts): key fdoc_{i} if key in minhashes: result lsh.query(minhashes[key]) if len(result) 1: unique_indices.add(i) return [texts[i] for i in sorted(unique_indices)]分词器这块我一开始想自己训练一个针对中医药领域的BPE分词器后来发现没必要。GPT-2的中文分词器虽然对中文支持一般但通过扩充词表的方式加入领域专有名词效果更好。具体做法是收集领域高频词比如“黄芪”“当归”“十八反”用SentencePiece训练一个补充词表然后合并到原分词器里。这样既保留了通用分词能力又提升了领域词汇的编码效率。2.2 模型架构选择GPT-2还是别的GPT-2虽然是2019年的架构但作为个人开发者的预训练起点非常合适。原因有三第一架构简单清晰就是Transformer Decoder堆叠没有MoE、没有GQA这些复杂变体调试起来直观第二社区资源丰富HuggingFace上的实现经过充分验证踩坑成本低第三参数量可控124M到1.5B的区间都有现成配置方便做消融实验。我最终选的是GPT-2 Medium的配置做缩放层数24注意力头数16隐藏维度1024参数量约350M。为什么不上Large因为3090的显存限制350M是我实测能稳定跑全量预训练的上限。再大就得用模型并行或者ZeRO Stage 3个人开发者的调试复杂度会指数级上升。模型初始化有个细节值得说不要用默认的随机初始化。我试过用GPT-2 Small的预训练权重做热启动然后继续在自己的数据上预训练收敛速度比从零开始快将近一倍。这个技巧叫“继续预训练”Continual Pre-training本质上是把通用语言知识作为先验模型只需要学习领域增量。对于数据量有限的个人开发者来说这是性价比最高的方案。# 加载预训练权重并继续预训练 from transformers import GPT2LMHeadModel, GPT2Config config GPT2Config( vocab_size50257, n_positions1024, n_embd1024, n_layer24, n_head16 ) model GPT2LMHeadModel.from_pretrained(gpt2-medium, configconfig) # 替换词表大小以适配扩充后的分词器 model.resize_token_embeddings(new_vocab_size)2.3 训练配置与显存优化实战训练配置这块我踩过的坑最多。先说学习率预训练的学习率不能太高我一开始用1e-4loss直接飞了。后来降到5e-5配合warmup 2000步才稳定下来。最终用的是5e-5的峰值学习率余弦退火到1e-6warmup比例0.01。Batch size的选择跟显存直接挂钩。我试过batch size 32序列长度512显存直接爆了。后来改成batch size 8梯度累积4步等效batch size 32显存占用降到18GB左右训练速度虽然慢一点但稳定。这里有个经验公式等效batch size在32到64之间时预训练效果比较理想太小了梯度噪声大太大了收敛慢。混合精度训练是必须开的。用PyTorch的AMPFP16前向传播加FP32主权重显存能省30%左右速度还能提升20%。但要注意loss scaling我遇到过梯度下溢导致loss变成NaN的情况后来把初始scale设成2^16动态调整就没再出问题。# 混合精度训练配置 from torch.cuda.amp import GradScaler, autocast scaler GradScaler(init_scale65536.0) for batch in dataloader: optimizer.zero_grad() with autocast(dtypetorch.float16): outputs model(**batch) loss outputs.loss scaler.scale(loss).backward() scaler.unscale_(optimizer) torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0) scaler.step(optimizer) scaler.update()梯度检查点Gradient Checkpointing是另一个省显存的大杀器。原理是用计算换显存前向传播时不保存中间激活值反向传播时重新计算。显存能省50%以上代价是训练速度慢20%-30%。对于3090这种显存紧张但算力还行的卡这个 trade-off 很划算。实操心得训练过程中用nvidia-smi实时监控显存如果发现显存占用持续增长不是波动而是单调上升大概率是内存泄漏。常见原因是dataloader的worker没有正确释放或者日志里累积了计算图。解决办法是定期调用torch.cuda.empty_cache()并确保日志记录时用.detach()。3. 领域适配的关键技术与落地3.1 全量微调 vs LoRA怎么选预训练完成后模型有了通用的语言能力但要在具体领域任务上表现好还需要领域适配。这里有两个主流路线全量微调和LoRA。全量微调就是拿预训练好的模型在领域数据上继续训练所有参数。优点是效果上限高模型能充分吸收领域知识缺点是显存占用大、训练慢、容易过拟合。我在中医药处方审核任务上试过全量微调350M的模型batch size 4序列长度256显存占用约16GB训练3个epoch大约需要6小时。LoRA是在原模型旁边挂低秩矩阵只训练这些新增的小参数。优点是显存占用极低350M模型用LoRA rank8显存占用不到6GB、训练快、不容易过拟合缺点是效果上限可能不如全量微调尤其是当领域数据和预训练数据分布差异很大时。我的选择策略是如果领域数据超过1GB且任务复杂度高优先全量微调如果数据量在100MB到1GB之间或者需要快速迭代多个任务用LoRA。实际项目中我经常先用LoRA快速验证方案可行性确认方向没问题后再切全量微调做最终版本。# LoRA配置示例 from peft import LoraConfig, get_peft_model lora_config LoraConfig( r8, lora_alpha32, target_modules[c_attn, c_proj], lora_dropout0.1, biasnone, task_typeCAUSAL_LM ) model get_peft_model(base_model, lora_config) model.print_trainable_parameters() # 输出trainable params: 1,179,648 || all params: 355,xxx,xxx || trainable%: 0.33%3.2 指令微调数据的构造方法领域适配不只是让模型“见过”领域文本还要让它“会做”领域任务。这就需要指令微调数据。我构造指令数据的方法是“模板实体替换”先定义任务模板比如“判断以下处方是否存在配伍禁忌{处方内容}”然后用领域数据库里的实体填充模板生成大量训练样本。以中医药处方审核为例我定义了五类任务配伍禁忌判断、剂量合理性评估、功效归类、相似处方推荐、不良反应预警。每类任务构造2000-5000条样本总共约2万条。数据格式统一成“指令输入输出”的三段式用特殊token分隔。{ instruction: 判断以下中药处方是否存在十八反配伍禁忌, input: 甘草、甘遂、大戟、海藻, output: 存在禁忌。甘草与甘遂、大戟、海藻均属十八反范畴合用可能产生毒性反应。 }构造指令数据时有个容易忽略的点负样本的多样性。不能只给模型看“正确”的处方还要给它看各种“错误”的处方包括剂量错误、配伍错误、证型不匹配等。负样本的比例我一般控制在30%左右太少了模型学不会判别太多了模型容易过度保守。3.3 领域词表扩充与嵌入对齐领域适配还有一个容易被忽视的环节词表扩充后的嵌入对齐。前面提到我扩充了分词器词表新增了约5000个领域专有名词。这些新token的嵌入是随机初始化的如果直接拿去微调模型需要很长时间才能学会它们的语义。我的做法是分两步先用领域语料做继续预训练让新token的嵌入在语言建模任务中自然学习然后在指令微调阶段冻结原有token的嵌入只训练新token的嵌入和模型的上层参数。这样既能快速对齐新token的语义又不会破坏原有的语言能力。具体实现上HuggingFace的resize_token_embeddings会自动处理嵌入矩阵的扩展但新token的初始化策略需要手动指定。我试过用均值初始化新token嵌入取原有token嵌入的均值和随机初始化前者收敛更快推荐使用。# 词表扩充与嵌入初始化 old_embeddings model.get_input_embeddings().weight.data model.resize_token_embeddings(new_vocab_size) new_embeddings model.get_input_embeddings().weight.data # 新token用原有token的均值初始化 new_embeddings[old_vocab_size:] old_embeddings.mean(dim0, keepdimTrue)4. 常见问题与排查技巧实录4.1 训练不收敛的排查路径训练不收敛是预训练阶段最常见的问题表现是loss震荡或者持续不降。我的排查顺序是先看数据再看学习率最后看模型结构。数据问题占不收敛原因的六成以上。检查方法很简单从dataloader里随机抽几条样本人工看一眼。如果文本乱码、长度异常、标签错位那就是数据问题。我遇到过因为编码问题导致中文全部变成乱码的情况loss自然降不下去。学习率问题占三成。预训练的学习率通常在1e-5到1e-4之间超过1e-4很容易飞。如果loss在前几百步就变成NaN先把学习率降一个数量级试试。另外warmup不能省没有warmup直接上高学习率模型参数会被瞬间打乱。模型结构问题占一成。常见的是维度不匹配、注意力掩码错误、位置编码越界。这类问题通常会在第一次前向传播时就报错不太会表现为“loss不降”。如果前向传播正常但loss不降优先怀疑数据和超参。4.2 显存溢出的应急处理显存溢出OOM是3090用户的日常。我的应急处理清单如下问题现象可能原因应急处理训练开始就OOMbatch size太大减半batch size开梯度累积训练中途OOM激活值累积开梯度检查点清理缓存验证时OOM验证batch太大验证时用更小batch或分块推理多任务OOM多个模型同时加载用del释放不用的模型调empty_cache除了应急处理日常开发中养成几个习惯能大幅减少OOM用torch.cuda.memory_summary()定期查看显存分布训练循环里用try-except捕获OOM自动降batch size重试验证和测试阶段用torch.no_grad()包起来避免构建计算图。避坑技巧PyTorch的显存分配器有缓存机制有时候nvidia-smi显示显存占用很高但实际可用显存还有。判断是否真的OOM要看PyTorch报的错而不是nvidia-smi的数字。如果PyTorch没报错但nvidia-smi显示快满了可以调大PYTORCH_CUDA_ALLOC_CONF的max_split_size_mb参数减少碎片。4.3 领域适配后的灾难性遗忘灾难性遗忘是领域适配的经典问题模型在领域任务上表现好了但通用能力大幅下降。我遇到过微调后的模型在中医药问答上很准但让它写个简单的邮件都磕磕巴巴。缓解方法有三第一在领域数据里混入10%-20%的通用数据让模型在学领域知识的同时不忘通用能力第二用LoRA而不是全量微调低秩矩阵对原模型参数的扰动更小第三用EWCElastic Weight Consolidation等正则化方法对重要参数加约束。我实际用得最多的是第一种方法简单有效。混合比例需要实验通用数据太少防不住遗忘太多又影响领域适配效果。我的经验值是通用数据占15%左右比较平衡。4.4 推理部署的性能优化模型训练完只是第一步部署推理还有一堆坑。3090上跑350M模型的推理如果不做优化生成速度可能只有每秒几个token体验很差。优化手段按性价比排序第一用KV Cache这是Transformer推理的标配能把自回归生成的速度提升5-10倍第二用FP16推理显存减半速度翻倍精度损失几乎可以忽略第三用ONNX Runtime或者TensorRT做图优化能再提升20%-30%第四如果延迟要求极高考虑量化到INT8但精度会有可感知的下降。# 带KV Cache的生成 from transformers import GPT2LMHeadModel, GPT2Tokenizer model GPT2LMHeadModel.from_pretrained(./my_model).half().cuda() tokenizer GPT2Tokenizer.from_pretrained(./my_model) input_ids tokenizer.encode(判断以下处方是否存在配伍禁忌甘草、甘遂, return_tensorspt).cuda() with torch.no_grad(): output model.generate( input_ids, max_new_tokens100, do_sampleTrue, temperature0.7, top_p0.9, use_cacheTrue # 开启KV Cache ) print(tokenizer.decode(output[0], skip_special_tokensTrue))5. 从预训练到领域适配的完整工具链5.1 训练框架选型对比个人开发者做LLM训练框架选型直接影响开发效率。我主要用过三个HuggingFace Transformers、Megatron-LM、DeepSpeed。HuggingFace Transformers是首选生态最全文档最友好社区问题最容易搜到答案。缺点是性能不是最优尤其是分布式训练的支持比较一般。但对于单卡训练它的性能损失可以接受。Megatron-LM是NVIDIA出的性能极强支持各种并行策略。但配置复杂学习曲线陡峭个人开发者单卡场景下用不太上它的优势。DeepSpeed是微软的ZeRO系列优化很出名能在有限显存下训练大模型。但它的配置项太多调试成本高。我一般只在模型参数量超过1B时才考虑DeepSpeed。我的建议是单卡训练用HuggingFace Transformers加PyTorch AMP就够了如果模型大到单卡放不下再考虑DeepSpeed的ZeRO Stage 2或3。5.2 实验管理与版本控制做LLM实验实验管理很重要。我见过太多人跑了几十组实验最后分不清哪个模型对应哪组参数。我的做法是用Weights Biaseswandb记录所有实验的超参、loss曲线、评估指标每个实验一个run命名规则是“日期_模型_数据_关键超参”。模型版本控制用Git LFS每个版本的模型权重单独打tag。数据版本用DVC管理确保每次实验的数据可追溯。这套组合拳打下来实验复现的成本大幅降低。# 实验管理示例 wandb init --project llm-pretrain # 训练脚本里记录超参 wandb.config.update({ learning_rate: 5e-5, batch_size: 8, grad_accum: 4, seq_length: 512, model_size: 350M })5.3 评估体系的建立预训练和领域适配的效果评估不能只看loss。我建立了一个三层评估体系第一层是语言建模指标包括困惑度PPL和bits-per-characterBPC用来监控训练过程第二层是领域任务指标包括准确率、F1、BLEU等用来评估领域适配效果第三层是人工评估抽样生成结果从流畅性、相关性、准确性三个维度打分。人工评估虽然成本高但不能省。我遇到过自动指标很好但人工一看全是废话的情况。自动指标只能反映模型和参考文本的相似度不能反映生成内容的实际质量。我的做法是每个版本抽100条生成结果自己逐条看记录问题类型作为下一轮迭代的依据。实操心得评估集要和训练集严格分离最好来自不同的数据源。我一开始用训练集的一部分做验证结果模型在验证集上表现极好但上线后一塌糊涂。后来改成用完全独立的测试集评估结果才靠谱。6. 个人开发者的资源规划与心态管理6.1 时间与算力的现实预期个人开发者做LLM全流程最大的挑战不是技术而是资源和时间的约束。我完整跑一遍预训练加领域适配从数据准备到最终部署大约花了六周时间。其中数据准备两周预训练两周领域适配一周评估和调优一周。算力方面3090满载运行电费一个月大概多出两三百块。训练350M模型做预训练一个epoch在20GB数据上大约需要30小时。我一般晚上跑训练白天做数据分析和调参这样时间利用率最高。心态上要做好“大部分实验都会失败”的准备。我跑过的实验中真正有效果的不到三分之一。但每一次失败都让我更清楚哪些方向行不通这本身就是价值。6.2 从单卡到多卡的扩展路径如果项目需要更大的模型或者更快的迭代速度单卡3090迟早不够用。扩展路径有两条一是加卡做数据并行二是用云算力按需租用。加卡做数据并行最直接的是再买一张3090用NCCL做通信PyTorch的DistributedDataParallel能自动处理梯度同步。但要注意数据并行的加速比不是线性的两张卡大概能提速1.7倍四张卡大概3倍。通信开销和同步等待会吃掉一部分收益。云算力适合短期的大规模实验。按需租用A100或者H100跑完就释放成本可控。但云上的环境配置、数据传输、调试都比本地麻烦适合已经在本地方案验证过的场景。6.3 持续迭代的节奏把控LLM项目不是一次性的需要持续迭代。我的迭代节奏是每周做一次小版本更新主要是数据增量和超参微调每月做一次大版本更新可能涉及模型结构调整或训练策略变更。每次迭代前先明确这次迭代要解决什么问题是领域准确率不够还是生成流畅度不行还是推理速度太慢。问题定义清楚了再去设计实验。避免“为了调参而调参”那样很容易陷入局部最优出不来。最后分享一个我个人的习惯每次训练完一个模型不管效果好坏都写一份简短的复盘笔记记录这次实验的配置、结果、观察到的现象和下一步计划。这些笔记积累下来就是我自己的“领域知识库”比任何教程都管用。 RTX 3090单卡实战：从零跑通LLM预训练与领域适配全流程
1. 为什么个人开发者要跑通LLM全流程1.1 从“调API”到“自己动手”的分水岭过去两年绝大多数个人开发者接触大语言模型的方式就是调API——写几行Python把请求发给远端服务拿回结果完事。这种方式门槛低、见效快但有一个致命问题你对模型本身没有任何控制权。你不知道它为什么在某些任务上表现好、在某些任务上一塌糊涂你也没法针对自己的垂直领域做深度定制。一旦遇到需要私有数据、需要特定输出格式、需要控制推理成本的场景调API的路子就会撞墙。我自己是从2023年下半年开始认真琢磨这件事的。当时手上有一个中医药处方审核的辅助项目需要模型理解处方配伍逻辑判断是否存在十八反、十九畏这类禁忌。直接调通用API的效果很不理想——模型对中药名称的识别经常出错对配伍规则的理解也停留在表面。那时候我就意识到必须走一遍从预训练到领域适配的完整流程才能真正把模型的能力“捏”成自己需要的样子。这篇文章要聊的就是我个人在单卡RTX 3090环境下从零开始跑通LLM预训练、微调、领域适配的全流程经验。不是教科书式的理论综述而是实打实的操作记录、踩坑复盘和参数选择逻辑。适合有一定Python和PyTorch基础、想深入理解LLM底层机制、或者需要做垂直领域模型定制的个人开发者。如果你只是想快速搭个聊天机器人这篇文章可能偏“重”了但如果你想真正搞明白模型是怎么“炼”出来的那接下来的内容应该对你有用。1.2 RTX 3090单卡的真实能力边界先泼一盆冷水。RTX 3090有24GB显存在消费级显卡里算得上第一梯队但放到LLM预训练的场景里它其实非常局促。很多人看到“预训练”三个字就想到GPT-3、LLaMA那种千亿参数的巨兽觉得个人开发者根本不可能碰。这个认知需要修正个人开发者做预训练目标不是复现GPT-4而是训练一个参数量在100M到1B之间的小模型用在自己的垂直场景里。具体来说24GB显存能做什么以GPT-2架构为例124M参数的模型做全量预训练batch size开到16、序列长度512显存占用大约在8-10GB完全跑得动。355M参数的模型同样的配置下显存占用会到18-20GB需要开梯度累积或者混合精度才能稳住。再往上到774M单卡就比较吃力了得用LoRA或者冻结部分层的方式做。这里有一个关键的计算逻辑需要说清楚显存占用大致等于“模型参数显存 梯度显存 优化器状态显存 激活值显存”。以124M参数的GPT-2为例FP32下参数本身占约500MB梯度再占500MBAdam优化器需要维护一阶和二阶动量又是1GB加起来基础开销就2GB了。激活值显存跟batch size和序列长度成正比这部分才是真正吃显存的大头。所以调参的时候优先降batch size和序列长度而不是急着换模型。注意RTX 3090的24GB显存里系统会预留一部分给显示输出。如果你同时接了显示器实际可用显存大约在23GB左右。做预训练时建议用无头模式或者把显示输出接到核显上能多挤出几百MB。2. 预训练阶段的核心设计与实操2.1 数据准备比模型更重要的环节预训练的数据质量直接决定模型的下限。我见过太多人把精力全花在调模型结构上数据随便找点维基百科就开跑结果loss降不下去或者降下去了但模型生成的东西前言不搭后语。数据这件事怎么强调都不过分。我的数据来源分三块通用中文语料、领域专业语料、结构化知识文本。通用中文语料用的是开源数据集大概20GB左右主要是新闻、百科、论坛帖子。领域专业语料是我自己爬的中医药相关文献和处方记录大概3GB。结构化知识文本是把中药数据库里的性味归经、配伍禁忌等条目转成自然语言描述大概500MB。三部分按7:2:1的比例混合通用语料保证模型的语言基础能力领域语料注入专业知识结构化文本强化特定格式的理解。数据清洗的步骤不能省。我用的流程是先去重用MinHash做近似去重阈值设0.8能去掉大量重复的新闻转载然后过滤低质量文本规则包括长度少于50个字符的丢掉、中文字符占比低于60%的丢掉、包含大量特殊符号的丢掉最后做敏感内容过滤这一步用关键词黑名单加分类器双重把关。# 数据去重示例MinHash from datasketch import MinHash, MinHashLSH def deduplicate(texts, threshold0.8): lsh MinHashLSH(thresholdthreshold, num_perm128) minhashes {} for i, text in enumerate(texts): m MinHash(num_perm128) for token in set(text.split()): m.update(token.encode(utf8)) lsh.insert(fdoc_{i}, m) minhashes[fdoc_{i}] m # 返回去重后的索引 unique_indices set() for i, text in enumerate(texts): key fdoc_{i} if key in minhashes: result lsh.query(minhashes[key]) if len(result) 1: unique_indices.add(i) return [texts[i] for i in sorted(unique_indices)]分词器这块我一开始想自己训练一个针对中医药领域的BPE分词器后来发现没必要。GPT-2的中文分词器虽然对中文支持一般但通过扩充词表的方式加入领域专有名词效果更好。具体做法是收集领域高频词比如“黄芪”“当归”“十八反”用SentencePiece训练一个补充词表然后合并到原分词器里。这样既保留了通用分词能力又提升了领域词汇的编码效率。2.2 模型架构选择GPT-2还是别的GPT-2虽然是2019年的架构但作为个人开发者的预训练起点非常合适。原因有三第一架构简单清晰就是Transformer Decoder堆叠没有MoE、没有GQA这些复杂变体调试起来直观第二社区资源丰富HuggingFace上的实现经过充分验证踩坑成本低第三参数量可控124M到1.5B的区间都有现成配置方便做消融实验。我最终选的是GPT-2 Medium的配置做缩放层数24注意力头数16隐藏维度1024参数量约350M。为什么不上Large因为3090的显存限制350M是我实测能稳定跑全量预训练的上限。再大就得用模型并行或者ZeRO Stage 3个人开发者的调试复杂度会指数级上升。模型初始化有个细节值得说不要用默认的随机初始化。我试过用GPT-2 Small的预训练权重做热启动然后继续在自己的数据上预训练收敛速度比从零开始快将近一倍。这个技巧叫“继续预训练”Continual Pre-training本质上是把通用语言知识作为先验模型只需要学习领域增量。对于数据量有限的个人开发者来说这是性价比最高的方案。# 加载预训练权重并继续预训练 from transformers import GPT2LMHeadModel, GPT2Config config GPT2Config( vocab_size50257, n_positions1024, n_embd1024, n_layer24, n_head16 ) model GPT2LMHeadModel.from_pretrained(gpt2-medium, configconfig) # 替换词表大小以适配扩充后的分词器 model.resize_token_embeddings(new_vocab_size)2.3 训练配置与显存优化实战训练配置这块我踩过的坑最多。先说学习率预训练的学习率不能太高我一开始用1e-4loss直接飞了。后来降到5e-5配合warmup 2000步才稳定下来。最终用的是5e-5的峰值学习率余弦退火到1e-6warmup比例0.01。Batch size的选择跟显存直接挂钩。我试过batch size 32序列长度512显存直接爆了。后来改成batch size 8梯度累积4步等效batch size 32显存占用降到18GB左右训练速度虽然慢一点但稳定。这里有个经验公式等效batch size在32到64之间时预训练效果比较理想太小了梯度噪声大太大了收敛慢。混合精度训练是必须开的。用PyTorch的AMPFP16前向传播加FP32主权重显存能省30%左右速度还能提升20%。但要注意loss scaling我遇到过梯度下溢导致loss变成NaN的情况后来把初始scale设成2^16动态调整就没再出问题。# 混合精度训练配置 from torch.cuda.amp import GradScaler, autocast scaler GradScaler(init_scale65536.0) for batch in dataloader: optimizer.zero_grad() with autocast(dtypetorch.float16): outputs model(**batch) loss outputs.loss scaler.scale(loss).backward() scaler.unscale_(optimizer) torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0) scaler.step(optimizer) scaler.update()梯度检查点Gradient Checkpointing是另一个省显存的大杀器。原理是用计算换显存前向传播时不保存中间激活值反向传播时重新计算。显存能省50%以上代价是训练速度慢20%-30%。对于3090这种显存紧张但算力还行的卡这个 trade-off 很划算。实操心得训练过程中用nvidia-smi实时监控显存如果发现显存占用持续增长不是波动而是单调上升大概率是内存泄漏。常见原因是dataloader的worker没有正确释放或者日志里累积了计算图。解决办法是定期调用torch.cuda.empty_cache()并确保日志记录时用.detach()。3. 领域适配的关键技术与落地3.1 全量微调 vs LoRA怎么选预训练完成后模型有了通用的语言能力但要在具体领域任务上表现好还需要领域适配。这里有两个主流路线全量微调和LoRA。全量微调就是拿预训练好的模型在领域数据上继续训练所有参数。优点是效果上限高模型能充分吸收领域知识缺点是显存占用大、训练慢、容易过拟合。我在中医药处方审核任务上试过全量微调350M的模型batch size 4序列长度256显存占用约16GB训练3个epoch大约需要6小时。LoRA是在原模型旁边挂低秩矩阵只训练这些新增的小参数。优点是显存占用极低350M模型用LoRA rank8显存占用不到6GB、训练快、不容易过拟合缺点是效果上限可能不如全量微调尤其是当领域数据和预训练数据分布差异很大时。我的选择策略是如果领域数据超过1GB且任务复杂度高优先全量微调如果数据量在100MB到1GB之间或者需要快速迭代多个任务用LoRA。实际项目中我经常先用LoRA快速验证方案可行性确认方向没问题后再切全量微调做最终版本。# LoRA配置示例 from peft import LoraConfig, get_peft_model lora_config LoraConfig( r8, lora_alpha32, target_modules[c_attn, c_proj], lora_dropout0.1, biasnone, task_typeCAUSAL_LM ) model get_peft_model(base_model, lora_config) model.print_trainable_parameters() # 输出trainable params: 1,179,648 || all params: 355,xxx,xxx || trainable%: 0.33%3.2 指令微调数据的构造方法领域适配不只是让模型“见过”领域文本还要让它“会做”领域任务。这就需要指令微调数据。我构造指令数据的方法是“模板实体替换”先定义任务模板比如“判断以下处方是否存在配伍禁忌{处方内容}”然后用领域数据库里的实体填充模板生成大量训练样本。以中医药处方审核为例我定义了五类任务配伍禁忌判断、剂量合理性评估、功效归类、相似处方推荐、不良反应预警。每类任务构造2000-5000条样本总共约2万条。数据格式统一成“指令输入输出”的三段式用特殊token分隔。{ instruction: 判断以下中药处方是否存在十八反配伍禁忌, input: 甘草、甘遂、大戟、海藻, output: 存在禁忌。甘草与甘遂、大戟、海藻均属十八反范畴合用可能产生毒性反应。 }构造指令数据时有个容易忽略的点负样本的多样性。不能只给模型看“正确”的处方还要给它看各种“错误”的处方包括剂量错误、配伍错误、证型不匹配等。负样本的比例我一般控制在30%左右太少了模型学不会判别太多了模型容易过度保守。3.3 领域词表扩充与嵌入对齐领域适配还有一个容易被忽视的环节词表扩充后的嵌入对齐。前面提到我扩充了分词器词表新增了约5000个领域专有名词。这些新token的嵌入是随机初始化的如果直接拿去微调模型需要很长时间才能学会它们的语义。我的做法是分两步先用领域语料做继续预训练让新token的嵌入在语言建模任务中自然学习然后在指令微调阶段冻结原有token的嵌入只训练新token的嵌入和模型的上层参数。这样既能快速对齐新token的语义又不会破坏原有的语言能力。具体实现上HuggingFace的resize_token_embeddings会自动处理嵌入矩阵的扩展但新token的初始化策略需要手动指定。我试过用均值初始化新token嵌入取原有token嵌入的均值和随机初始化前者收敛更快推荐使用。# 词表扩充与嵌入初始化 old_embeddings model.get_input_embeddings().weight.data model.resize_token_embeddings(new_vocab_size) new_embeddings model.get_input_embeddings().weight.data # 新token用原有token的均值初始化 new_embeddings[old_vocab_size:] old_embeddings.mean(dim0, keepdimTrue)4. 常见问题与排查技巧实录4.1 训练不收敛的排查路径训练不收敛是预训练阶段最常见的问题表现是loss震荡或者持续不降。我的排查顺序是先看数据再看学习率最后看模型结构。数据问题占不收敛原因的六成以上。检查方法很简单从dataloader里随机抽几条样本人工看一眼。如果文本乱码、长度异常、标签错位那就是数据问题。我遇到过因为编码问题导致中文全部变成乱码的情况loss自然降不下去。学习率问题占三成。预训练的学习率通常在1e-5到1e-4之间超过1e-4很容易飞。如果loss在前几百步就变成NaN先把学习率降一个数量级试试。另外warmup不能省没有warmup直接上高学习率模型参数会被瞬间打乱。模型结构问题占一成。常见的是维度不匹配、注意力掩码错误、位置编码越界。这类问题通常会在第一次前向传播时就报错不太会表现为“loss不降”。如果前向传播正常但loss不降优先怀疑数据和超参。4.2 显存溢出的应急处理显存溢出OOM是3090用户的日常。我的应急处理清单如下问题现象可能原因应急处理训练开始就OOMbatch size太大减半batch size开梯度累积训练中途OOM激活值累积开梯度检查点清理缓存验证时OOM验证batch太大验证时用更小batch或分块推理多任务OOM多个模型同时加载用del释放不用的模型调empty_cache除了应急处理日常开发中养成几个习惯能大幅减少OOM用torch.cuda.memory_summary()定期查看显存分布训练循环里用try-except捕获OOM自动降batch size重试验证和测试阶段用torch.no_grad()包起来避免构建计算图。避坑技巧PyTorch的显存分配器有缓存机制有时候nvidia-smi显示显存占用很高但实际可用显存还有。判断是否真的OOM要看PyTorch报的错而不是nvidia-smi的数字。如果PyTorch没报错但nvidia-smi显示快满了可以调大PYTORCH_CUDA_ALLOC_CONF的max_split_size_mb参数减少碎片。4.3 领域适配后的灾难性遗忘灾难性遗忘是领域适配的经典问题模型在领域任务上表现好了但通用能力大幅下降。我遇到过微调后的模型在中医药问答上很准但让它写个简单的邮件都磕磕巴巴。缓解方法有三第一在领域数据里混入10%-20%的通用数据让模型在学领域知识的同时不忘通用能力第二用LoRA而不是全量微调低秩矩阵对原模型参数的扰动更小第三用EWCElastic Weight Consolidation等正则化方法对重要参数加约束。我实际用得最多的是第一种方法简单有效。混合比例需要实验通用数据太少防不住遗忘太多又影响领域适配效果。我的经验值是通用数据占15%左右比较平衡。4.4 推理部署的性能优化模型训练完只是第一步部署推理还有一堆坑。3090上跑350M模型的推理如果不做优化生成速度可能只有每秒几个token体验很差。优化手段按性价比排序第一用KV Cache这是Transformer推理的标配能把自回归生成的速度提升5-10倍第二用FP16推理显存减半速度翻倍精度损失几乎可以忽略第三用ONNX Runtime或者TensorRT做图优化能再提升20%-30%第四如果延迟要求极高考虑量化到INT8但精度会有可感知的下降。# 带KV Cache的生成 from transformers import GPT2LMHeadModel, GPT2Tokenizer model GPT2LMHeadModel.from_pretrained(./my_model).half().cuda() tokenizer GPT2Tokenizer.from_pretrained(./my_model) input_ids tokenizer.encode(判断以下处方是否存在配伍禁忌甘草、甘遂, return_tensorspt).cuda() with torch.no_grad(): output model.generate( input_ids, max_new_tokens100, do_sampleTrue, temperature0.7, top_p0.9, use_cacheTrue # 开启KV Cache ) print(tokenizer.decode(output[0], skip_special_tokensTrue))5. 从预训练到领域适配的完整工具链5.1 训练框架选型对比个人开发者做LLM训练框架选型直接影响开发效率。我主要用过三个HuggingFace Transformers、Megatron-LM、DeepSpeed。HuggingFace Transformers是首选生态最全文档最友好社区问题最容易搜到答案。缺点是性能不是最优尤其是分布式训练的支持比较一般。但对于单卡训练它的性能损失可以接受。Megatron-LM是NVIDIA出的性能极强支持各种并行策略。但配置复杂学习曲线陡峭个人开发者单卡场景下用不太上它的优势。DeepSpeed是微软的ZeRO系列优化很出名能在有限显存下训练大模型。但它的配置项太多调试成本高。我一般只在模型参数量超过1B时才考虑DeepSpeed。我的建议是单卡训练用HuggingFace Transformers加PyTorch AMP就够了如果模型大到单卡放不下再考虑DeepSpeed的ZeRO Stage 2或3。5.2 实验管理与版本控制做LLM实验实验管理很重要。我见过太多人跑了几十组实验最后分不清哪个模型对应哪组参数。我的做法是用Weights Biaseswandb记录所有实验的超参、loss曲线、评估指标每个实验一个run命名规则是“日期_模型_数据_关键超参”。模型版本控制用Git LFS每个版本的模型权重单独打tag。数据版本用DVC管理确保每次实验的数据可追溯。这套组合拳打下来实验复现的成本大幅降低。# 实验管理示例 wandb init --project llm-pretrain # 训练脚本里记录超参 wandb.config.update({ learning_rate: 5e-5, batch_size: 8, grad_accum: 4, seq_length: 512, model_size: 350M })5.3 评估体系的建立预训练和领域适配的效果评估不能只看loss。我建立了一个三层评估体系第一层是语言建模指标包括困惑度PPL和bits-per-characterBPC用来监控训练过程第二层是领域任务指标包括准确率、F1、BLEU等用来评估领域适配效果第三层是人工评估抽样生成结果从流畅性、相关性、准确性三个维度打分。人工评估虽然成本高但不能省。我遇到过自动指标很好但人工一看全是废话的情况。自动指标只能反映模型和参考文本的相似度不能反映生成内容的实际质量。我的做法是每个版本抽100条生成结果自己逐条看记录问题类型作为下一轮迭代的依据。实操心得评估集要和训练集严格分离最好来自不同的数据源。我一开始用训练集的一部分做验证结果模型在验证集上表现极好但上线后一塌糊涂。后来改成用完全独立的测试集评估结果才靠谱。6. 个人开发者的资源规划与心态管理6.1 时间与算力的现实预期个人开发者做LLM全流程最大的挑战不是技术而是资源和时间的约束。我完整跑一遍预训练加领域适配从数据准备到最终部署大约花了六周时间。其中数据准备两周预训练两周领域适配一周评估和调优一周。算力方面3090满载运行电费一个月大概多出两三百块。训练350M模型做预训练一个epoch在20GB数据上大约需要30小时。我一般晚上跑训练白天做数据分析和调参这样时间利用率最高。心态上要做好“大部分实验都会失败”的准备。我跑过的实验中真正有效果的不到三分之一。但每一次失败都让我更清楚哪些方向行不通这本身就是价值。6.2 从单卡到多卡的扩展路径如果项目需要更大的模型或者更快的迭代速度单卡3090迟早不够用。扩展路径有两条一是加卡做数据并行二是用云算力按需租用。加卡做数据并行最直接的是再买一张3090用NCCL做通信PyTorch的DistributedDataParallel能自动处理梯度同步。但要注意数据并行的加速比不是线性的两张卡大概能提速1.7倍四张卡大概3倍。通信开销和同步等待会吃掉一部分收益。云算力适合短期的大规模实验。按需租用A100或者H100跑完就释放成本可控。但云上的环境配置、数据传输、调试都比本地麻烦适合已经在本地方案验证过的场景。6.3 持续迭代的节奏把控LLM项目不是一次性的需要持续迭代。我的迭代节奏是每周做一次小版本更新主要是数据增量和超参微调每月做一次大版本更新可能涉及模型结构调整或训练策略变更。每次迭代前先明确这次迭代要解决什么问题是领域准确率不够还是生成流畅度不行还是推理速度太慢。问题定义清楚了再去设计实验。避免“为了调参而调参”那样很容易陷入局部最优出不来。最后分享一个我个人的习惯每次训练完一个模型不管效果好坏都写一份简短的复盘笔记记录这次实验的配置、结果、观察到的现象和下一步计划。这些笔记积累下来就是我自己的“领域知识库”比任何教程都管用。