个人开发者单卡跑通LLM全流程：从继续预训练到领域适配部署

1. 个人开发者跑LLM全流程先想清楚边界我最初也以为个人开发者做LLM预训练是天方夜谭直到我用一张24GB显存的卡在没有多机分布式的情况下把一个1.3B级别的开源基座模型完成继续预训练再做领域适配跑通了从数据准备、训练、评估到部署的完整链路。这篇东西就是那段时间的总结。要说明的是标题里的“LLM全流程”不是指从零训练一个GPT-4级别的模型而是指一个人、一台单卡机器也能走完“预训练—领域适配—评估—部署”这几大步让模型在特定领域真正可用。这适合三类人看刚接触大模型、想深入训练细节的算法工程师想在垂直领域做私有知识助手的后端开发者以及研究生阶段想自己做一个可复现小模型的学生。很多人会问我为什么不直接用开源模型API非要自己折腾训练我的回答是如果你只是调API你只能了解输入输出的表象当你动手做一次继续预训练和领域适配之后你才会真正理解模型的能力边界、数据的作用、超参数的意义。这也是我写下这篇文章的原因。1.1 这里的“预训练”到底指什么如果对一个普通开发者说“预训练”他脑海里会浮现出几千张A100卡、TB级语料、几个月的训练周期然后觉得这件事和自己无关。这其实是被工程上的规模吓住了。从原理上看预训练就是让模型在大量文本上做自回归语言建模根据前文预测下一个token然后通过交叉熵损失不断调整参数。模型规模小一点、语料少一点、训练时间短一点它在“通用能力”上当然比不上大模型但在某个垂直领域里它完全可以被你调教得非常好用。所以个人开发者的“预训练”更准确的说法是“继续预训练”或者“领域预训练”。不是从随机初始化开始而是拿一个已经具备通用语言能力的开源基座模型在其上喂入领域语料让模型熟悉特定领域的概念、表达方式和文本分布。这个思路的关键在于你不需要重新发明轮子只需要把轮子改造成适合你这段路的样子。1.2 要跑通全流程的资源和心态我先说最低配置这是我自己实测的下限单张24GB显存显卡比如RTX 3090、4090或者云上租一块类似的卡。如果你只有16GB显存也不是不能做但参数规模要压到0.5B到1B之间或者依赖量化训练体验会差不少。操作系统用Ubuntu即可磁盘至少留200GB因为基座模型权重、训练缓存、数据集、checkpoint加起来很快会吃掉大量空间。软件层面最核心的就是Hugging Face Transformers、PEFT、DeepSpeed、Tokenizer、Datasets这些库。数据层面你不用准备几十T的语料。个人项目做领域适配语料量从几十万token到几亿token都是常见区间。我跑过的项目里继续预训练的语料是大约2.5GB中文领域文本清洗之后大约8000万token在单卡上训练了20多个小时效果已经能明显感知到。后面我会拆开讲为什么这个量级够用。心态上需要明确一点个人开发者追求的不是“复现ChatGPT”而是“让一个小模型在一个窄领域里做到80分以上的可用性”。目标一旦清晰很多决策就会变得容易。2. 选基座模型本质是选可塑性和稳定性的平衡基座模型是整个流程的天花板。你后面花大量时间做的数据清洗、训练调参都只能在一个给定的天花板下发挥作用。所以这个选择值得多花一点时间。2.1 基座选型看四个维度参数量、词表、许可证、生态个人开发者选基座不要只盯着“开源”两个字还要看四个具体维度。第一是参数量。24GB显卡跑全参数微调7B模型已经接近上限如果用LoRA7B也很从容。我的建议是领域任务明确、数据量不大时优先选1.5B到4B的模型如果你想让模型有更强的通用对话能力和复杂推理能力可以试着用7B但训练时间会明显拉长。表格里整理了我当时对比过的一批候选基座模型参数量中文能力社区生态显存友好度Qwen系列1.8B / 7B强很活跃中LLaMA系列7B / 13B中需扩充词表极活跃中高Mistral系列7B较强活跃中Phi系列1.5B / 2B中等活跃高第二是词表。这个非常关键尤其做中文领域。有些模型以英文词表为主中文token切得很碎一个常见中文词被切分成三四个token导致模型有效上下文长度缩水训练效率也差。建议下载基座后先跑一段真实领域文本统计一下平均每个中文词被切成的token数量。如果明显偏高要么换基座要么做词表扩展。第三是许可证。每个开源模型的开源协议不同有的是完全商用可用有的是“小于月活用户数才能免费商用”。在开始训练之前一定要把协议看清楚特别是如果你有产品化打算。这是很多个人开发者容易忽略、但一旦被追责就非常麻烦的地方。第四是生态。Transformers支持程度、是否有现成的chat模板、是否有大量LoRA案例决定了你遇到问题后能不能快速找到答案。冷门模型即使能力不错也容易让你卡在莫名其妙的格式问题上。2.2 词汇表要不要改领域新词的三种处理方式做垂直领域比如法律、医疗、工业制造一定会遇到通用基座模型没有见过的领域词。这里有三种处理路径。第一种是“不改词表直接让模型在上下文里学习”。当领域新词不太多时模型可以通过周围词推断含义。缺点是模型生成时可能反复写错词而且词被切得很碎会影响效率。第二种是“扩展词表新词单独做embedding初始化”。在Tokenizer里加入领域词汇例如把所有出现频次超过阈值且当前分词的子词数大于1的领域词加入词表并随机初始化对应embedding。这个操作效果好但后续需要让这些新embedding在训练中逐渐对齐原词表。实现时需要将模型embedding层和lm_head的权重矩阵同步扩容代码上有一定工作量。第三种是“不改词表但用缩写或唯一标记替换”。把高频领域短语映射成特殊预留token例如“ 设备故障码C-2048”变为“DEV_CODE”。适合字典式、格式化的文本不适合自由文本生成。个人项目我更推荐第二种因为词表扩展带来的收益很直接。一个小技巧是扩展后先跑几十步训练观察新增token的embedding范数是否从很小逐渐增大如果没有变化多半是新token在训练时没有被触发需要检查数据里这些词有没有被正确切分。2.3 语料准备的取舍数量和质量先解决哪个大部分第一次做预训练的人都会陷入一个误区拼命增加数据量却忽略了噪音。领域语料来自爬虫、归档文件、日志导出往往包含大量页面导航、重复段落、无意义符号、乱码编码这些东西如果不清理模型会学到很多错误的“语言习惯”。我的经验是数据清洗的优先级是去重 质量过滤 格式统一 数量扩展。去重不只是删除完全一样的文档而是要按MinHash或简单SimHash做近似去重。很多爬虫会抓到同一篇内容的多个版本只是多了几行签名和页脚。近似去重后有效信息量会明显提升。质量过滤方面我会用几条规则组合文本长度小于200字且不包含一个完整句子的直接丢弃包含连续无意义乱码比例超过5%的丢弃纯表格转换产物如果大量列错乱也丢弃。最后再做一个敏感信息筛查把身份证号、手机号、银行卡号等个人隐私字段做脱敏这个不只是合规问题也是保护自己。为什么不建议一开始就追求数量因为个人开发者的训练时间是有限的。喂了10GB低质量语料可能不如喂2GB质检过的语料。模型从低质量文本里学到的重复、噪音模式后期要花更大代价才能纠正。3. 继续预训练阶段别指望喂几万条文本就脱胎换骨如果说数据是食材那继续预训练就是小火慢炖。这一步不会让模型瞬间变得“专业”但会让它在领域文本上的“语感”明显提升。3.1 继续预训练的训练目标和注意力机制继续预训练使用的目标和预训练完全一致自回归语言建模。给定一段文本模型需要预测下一个token是什么训练信号就是真实下一个token和预测概率之间的交叉熵。用大家熟悉的话说这张模型里的每一个token都同时扮演着三个角色因为要预测下一个词当前token就像在问“我到底在找什么”这是Query前面的token序列提供了“我在哪、已经在读什么”的背景这是Key而真正能用来预测下一步的信息是每个token携带的具体内容这是Value。虽然这是简化说法但能帮你理解为什么预训练会让模型学到大量语言规律和世界知识。继续预训练与从头预训练的区别在于它不是在零基础条件下让模型统计语言规律而是把已有参数作为先验再用领域语料进行定向补充。因此学习率要非常保守否则会破坏原有能力。3.2 单卡跑继续预训练的参数配置如果你只有24GB显存要跑一个7B模型的全参数继续预训练即使Batch Size开得很小也基本会OOM。更合理的做法是先用全参数训练小模型1.5B以下或者用LoRA训练大模型。但我个人更倾向在语料量比较小的情况下用全参数微调1.5B模型因为LoRA在继续预训练阶段会限制模型更新幅度。下面是我实际用过的训练参数示例基于Transformers的Trainerfrom transformers import AutoTokenizer, AutoModelForCausalLM, Trainer, TrainingArguments model AutoModelForCausalLM.from_pretrained(your_base_model) tokenizer AutoTokenizer.from_pretrained(your_base_model) training_args TrainingArguments( output_dir./continued_pretrain, per_device_train_batch_size4, gradient_accumulation_steps8, learning_rate1e-5, lr_scheduler_typecosine, warmup_ratio0.03, num_train_epochs3, logging_steps20, save_steps500, save_total_limit2, fp16True, gradient_checkpointingTrue, optimadamw_torch, )这里的重点有两处。一是learning_rate继续预训练建议在1e-5到5e-5之间不要学得太猛。二是per_device_train_batch_size配合gradient_accumulation_steps等效出一个大一点的Global Batch Size我一般让它维持在32到64。这样训练更稳定loss曲线不会像心电图一样乱跳。数据加载上我建议每次从多个不同来源的文档里随机采样拼成一条训练样本中间用分隔符隔开长度截断到1024或2048。不要一股脑把一整篇超长文档拼到4096因为大部分个人显卡跑不动而且短序列的全局Batch Size更容易调大。3.3 怎么判断有没有学进去Loss下降是必要条件但不是唯一指标。继续预训练有时候会出现loss下降、生成质量却没有变化的情况这多半是模型在记忆训练文本的局部模式而不是在学可泛化的领域知识。所以我通常会做几个固定样本的“人工观察”准备20段领域文本每段取前200个token让模型续写后面的内容。训练前生成一遍作为baseline训练中每500步生成一遍。观察三个信号模型是否开始使用领域专有名词是否延续原文的论证结构是否出现重复、无意义循环。另外一个量化指标是领域PPL困惑度。用留出集在训练前后分别计算PPL下降幅度如果超过20%说明模型确实适应当前语料了。但要注意如果训练集和评估集是同源的PPL会乐观很多所以评估集最好来自一个独立时段或独立来源不要只做同一个知识库里的随机划分。4. 领域适配的核心是SFT和偏好对齐不是塞知识继续预训练之后模型已经“知道”了很多领域词汇和文本分布但它不一定会按你期望的方式回答用户。接下来这一步业内叫领域适配实际操作中通常包含监督微调SFT和偏好对齐如DPO。4.1 先区分“知识”和“能力”很多人把领域适配理解成“把知识库文档扔给模型微调”这是一个很大的误区。模型回答不好领域问题原因通常不是“不知道知识”而是“不知道该怎么组织回答”。具体来说它需要具备这几项能力听懂用户用领域黑话提出的问题把回答组织成固定格式比如“结论先行—分点解释—补充注意事项”在不确定时明确说不知道而不是编造。这些能力是SFT阶段的核心目标。知识本身的更新有两条路径要么通过RAG在推理时从外部知识库检索要么通过继续预训练注入。如果你依赖SFT去硬记几百个知识点大概率会过拟合而且模型会在你没有覆盖到的问题上表现更差。所以我在项目里的做法是知识更新交给RAG能力对齐交给SFT。4.2 指令数据的构造与清洗SFT数据的质量比数量重要得多。个人开发者通常能写出的高质量样本也就是几千到几万条但几千条干净数据调教出来的效果经常好于十几万条模型生成的伪数据。指令数据的典型结构是三元组system、user、assistant。system描述角色和输出规则user是用户输入assistant是期望输出。构造时我会做三类样本真实历史对话如果有客服记录、工单记录直接清洗成标准格式。场景构造问答根据领域文档人工撰写“用户会怎么问”和“正确回答应该是什么”重点覆盖常见难点。格式示范样本专门写一批“用户没有给足够信息时应该追问什么”和“用户问法很模糊时如何澄清”的样本。注意这里不能插入图片应去掉。需要在文本中说明不用插入。由于要求纯Markdown我打算不写图片。下面的内容保持文本。数据清洗有几个细节值得关注。第一回答里不要包含“根据以上资料”“从文中可以看出”这类套话这类话会让模型学会在正式回答前说废话。第二不要只在回答里放“正确结果”也要放一些“错误示范”并在assistant里给出纠正式回答提升稳定性。第三所有样本里的实体、数值必须和对应文档一致防止模型背错事实。4.3 SFT训练参数与LoRA实操SFT阶段我一般会对继续预训练后的模型进行LoRA微调。原因是SFT数据量通常只有几千到几万条全参数微调容易破坏预训练阶段好不容易养出来的语言能力。LoRA在训练效率和稳定性上更好。LoRA的典型配置from peft import LoraConfig lora_config LoraConfig( r32, lora_alpha64, target_modules[q_proj, k_proj, v_proj, o_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, )训练参数上学习率可以从2e-5到5e-5比继续预训练略高一点但仍不能放飞。批量大小建议等效16到32。轮数要严格控制SFT阶段非常容易过拟合我在实际中发现很多项目训练到第5轮后在训练集上loss还在降但评估集上的回答质量已经开始退化。所以我习惯的做法是每1个epoch保存一次最后用评估集挑最优checkpoint而不是默认最后一版。另一个关键点是attention mask和padding。不同批次的样本长度不一样要把pad token设置为eos token或者在训练数据里明确用mask忽略padding位置的loss。不处理这个问题模型会被逼着预测一堆无意义的pad token严重干扰效果。4.4 DPO偏好对齐的简短实践SFT负责让模型学会“正确回答的格式”偏好对齐负责让模型“更愿意输出用户喜欢的内容”。偏好对齐阶段我优先推荐DPO因为实现简单、资源占用低不需要训练一个独立的奖励模型。DPO需要的数据是偏好对同一条用户问题对应两个回答一个是更优的一个是相对较差的模型被要求优化两者的对数概率差。DPO训练数据怎么来个人项目可以通过两个途径一是人工撰写尽量明显的优劣示例二是用不同参数版本的SFT模型生成候选回答再由领域专家做对比排序。这个话题容易做得很主观我建议只对“和领域专业事实冲突”和“明显不礼貌或回避问题”这两类坏case做负样本不要试图统一所有风格偏好否则模型会变得过于模板化。DPO的超参数除了学习率另一个重点是beta它控制对偏好对的置信程度。一般取值0.1到0.3。beta过小模型会被强烈拉向偏好数据容易失去通用性beta过大对齐效果又不够明显。这块没有标准答案建议每调一次beta就做一次评测集验证而不是靠感觉。5. 评估、部署与持续迭代全流程的最后一公里训练结束不是项目结束。个人开发者的全流程实践最后一个阶段是把模型放进真实运行环境并且建立持续观察和迭代机制。5.1 建立领域评估集别只看通用榜单很多初学者喜欢拿Open LLM Leaderboard上的通用benchmark来衡量自己的领域模型结果发现分数既不涨也不跌。原因是通用榜单面向的是广泛知识和你的领域任务很可能不是一回事。我建议自己建立一份“任务导向评估集”包含约200到500条来自真实场景但未参与训练的问题覆盖正常问题、模糊问题、缺信息问题、边界安全问题和对抗性诱导。每次训练前后都要跑一遍计算几个固定指标回答格式合规率、关键实体正确率、观点与立场一致性、拒答准确率。建议人工评估和自动指标结合。自动指标可以先用LLM-as-judge用另一个更强大的通用模型给回答打分但要用一批人工标注样本校准judge模型防止它偏爱长回答、惯用套话等问题。5.2 量化部署的取舍训练好的模型最终要部署在低成本环境里。我推荐先做4bit量化比如AWQ或GPTQ再转换为ONNX或其他推理后端。ONNX部署对大模型的优化已经很成熟尤其适合需要嵌入现有推理管线的场景。一个7B模型用4bit量化后显存需求可以压缩到6GB左右对线上服务压力小很多。这里有一个取舍必须知道量化之后模型的生成质量会有轻微下降。语法结构一般保持良好但领域中的冷门实体更容易出错。我的做法是如果量化后模型在关键实体准确率上下降超过2个百分点就退回8bit或者调整提示词让模型把不确定的地方交给检索环节。部署时另一个关键动作是加一层“守卫”。无论是API网关还是简单的服务封装里都要加入输入和输出过滤拦截脚本注入和强制套answer的攻击性提示。我的原则是领域模型宁可多拒答一次也不能被提示词绕过后输出错误结论。5.3 数据飞轮把坏case回流成训练样本部署上线后最重要的事情是收集badcase。我会在服务日志中标记两类数据用户对回答点了“无帮助”的以及领域审核标记为“有事实性错误”的。这些坏case经过人工修正后可以进入下一轮SFT或DPO数据池。个人项目迭代节奏不需要快一个月收集一两百条高价值的badcase重新训练一轮模型质量会稳定提升。但要小心“数据回流污染”如果只是把模型自己生成的高分回答直接加进训练集就会逐渐固化学到的问题。所以我的建议是回流数据必须经过人工修正至少要修正关键事实和格式否则宁可不要。6. 实战中反复踩到的六个坑最后记录几个我在实际项目里踩过、也帮身边朋友排查过的坑希望能让后来的开发者少浪费几周时间。第一个坑继续预训练阶段用了过大的学习率导致模型通用能力崩溃。症状是训练loss下降很快但模型开始反复生成同一个词。原因是领域语料分布和通用语料差异大过大的学习率让模型把原有参数冲坏了。解决方式是降低学习率并加入回滚逻辑每隔一定步数做一次在通用任务上的小样本验证。第二个坑SFT阶段没有处理padding位置的loss。症状是训练出来的模型总喜欢在回答前面输出一个空行或者重复的pad token。检查方式是看训练日志里的loss有没有包含padding位置。解决方式是把pad token的labels设为-100或用data collator自动完成掩码。第三个坑评估集和训练集混在一起导致评估指标虚高。很多朋友从同一个文档里随机切出训练集和测试集模型可能已经全文背诵了这些句子。正确做法是评估集必须来自独立的文档集合、独立的时间段或外部采集。第四个坑显存不足时盲目减小batch size导致模型不收敛。单卡训练时如果把global batch size降得太小比如小于8训练会非常不稳定。正确的做法是保持较小的per_device_batch_size同时用gradient_accumulation_steps把global batch size调到32左右。第五个坑领域适配只用生成内容没有做检索兜底。AIGC模型再训练也还是会幻觉部署前如果没有RAG或规则校验兜底用户就能轻易问出一个模型编造的答案。我的一般设计是“检索优先、生成辅助、规则兜底”重要事实都要从知识库中捞出来再生成。第六个坑把所有时间花在调超参数上却不肯花时间整理数据。我遇到过不少人用同一个数据集反复调学习率效果始终上不去。后来我把训练集中的重复段落、无关页面清掉模型效果立刻提升。数据工程粗糙后面无论怎么调参都是在浪费电费。如果让我给一条最核心的个人体会个人开发者做LLM全流程最大的杠杆永远在数据侧其次才是训练技巧。先把评估集建好再去做训练你会发现很多纠结的调参问题其实并不是问题。