企业官网建设流程全解析

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模型已经接近上限，如果用LoRA，7B也很从容。我的建议是：领域任务明确、数据量不大时，优先选1.5B到4B的模型；如果你想让模型有更强的通用对话能力和复杂推理能力，可以试着用7B，但训练时间会明显拉长。表格里整理了我当时对比过的一批候选：

第二是词表。这个非常关键，尤其做中文领域。有些模型以英文词表为主，中文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的Trainer：

from 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_size=4, gradient_accumulation_steps=8, learning_rate=1e-5, lr_scheduler_type="cosine", warmup_ratio=0.03, num_train_epochs=3, logging_steps=20, save_steps=500, save_total_limit=2, fp16=True, gradient_checkpointing=True, optim="adamw_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( r=32, lora_alpha=64, target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "up_proj", "down_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_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全流程，最大的杠杆永远在数据侧，其次才是训练技巧。先把评估集建好，再去做训练，你会发现很多纠结的调参问题其实并不是问题。