企业官网建设流程全解析

从去年年中开始，我带着一个七人小团队把一条完整的训练链路跑了三遍：数据清洗、预训练、SFT、DPO、评估、部署。网上关于大模型的论文和课程多到看不完，但真正能把手把手把“数据→预训练→SFT→DPO/RLHF→评估”全流程走通的人并不多。这活儿确实脏、确实累、也确实贵，但一旦跑通一次，你对大模型的理解会彻底不一样——以后再看任何训练相关的东西，基本都有谱了。这里把整条路线的事情写透一点，想把模型从零搞起的团队可以先照着做，至少能绕开我们踩过的那些大坑。

1. 先想清楚：从零训练的适用场景与资源门槛

很多团队一上来就问“我要从零训一个自己的模型”，但这句话背后的动机差别很大。有的是为了私有化部署、数据不出域；有的是觉得开源模型不够贴合自己的业务；有的纯粹想锻炼团队能力。这三种诉求，对应的方案完全不同。

1.1 什么情况下值得从零训练

作为过来人，我的判断标准很简单：你要解决的问题，改开源模型性价比更高，就不要自己从头训。比如给客服做个FAQ助手，用Qwen或Llama微调就够了；但如果你要的是“金融法规条文的精准问答”、“医疗病历结构化抽取”这类垂直场景，开源通用模型在术语准确性、格式合规性上经常差一口气。再加上企业级数据不能出域的话，从零预训练一个专属底座就变成了刚需。

还有一个情况值得从零训练：你需要一个可控的技术底座。开源模型用起来方便，但你不知道它训练数据里有什么，出问题不好排查，将来想针对垂直场景做继续预训练也受到上游限制。自己训的模型，从tokenizer到数据配比都清楚，出任何质量问题都好溯源。

1.2 资源估算：先算账再动手

从零训练一个大模型，最大的门槛不是技术，是钱。我给你一个可以套用的粗略估算方法。

• 模型规模：如果做垂直场景，7B量级在这个阶段是性价比比较合适的点，参数量再往下能力下降明显，往上训练成本指数级上升。
• 数据规模：常见的做法是1T到2T token，这基本是7B模型能力涌现的及格线。数据少到几百B的话，模型也有用，但比较“笨”。
• 硬件估算：以7B模型、1T token、序列长度2048为例，按Llama架构的算力需求粗算（6N×D，N是参数量，D是token数），需要约 6×7B×1T ≈ 4.2e22 FLOPs。用一张A100 80G（BF16算力约312TFLOPs），考虑60%左右的MFU，大概需要 4.2e22 / (312e12×0.6) ≈ 2.2e5 秒，约62小时。也就是说，大约24张A100跑3天多，或者8张跑9天多。如果改用H100，时间差不多减半。

这个数字只是训练本身，还没算调试失败、数据重构、评估测试的时间。所以务实建议是：如果你只有一两张显卡，不要碰从零预训练。先用LoRA微调做业务验证，等业务模型的需求被验证清楚了，再预算从零训练的性价比。如果预算在几十万到百万量级，直接从零训练是可行的。

1.3 少走弯路的起点判断

不少人一开始就冲“从零”两个字，其实可以“从中间出发”。目前主流平台还是有公开的开源底座，比如Llama系列、Qwen系列、Mistral系列。这些模型经过完整训练，底子扎实，如果你的垂直场景数据量大，完全可以做增量预训练（continue pretraining），比从随机权重训起节省至少一个数量级的成本。

真实项目里做增量预训练比例更高。它保留通用能力，注入垂直知识，风险比随机初始化小很多。如果你非要随机初始化，建议也先跑一个几百M或1B参数的小模型验证数据质量和训练流程，再放大到7B。我们第一次直接上7B随机初始化，结果训练到两万步发现数据有系统性污染，全部推倒重来，那个酸爽不说了。

2. 数据工程：语料清洗与配比

很多人觉得训练大模型拼的是显卡，但跑完一轮你会发现，真正的瓶颈在数据。模型能力的天花板，几乎完全由数据质量决定。尤其从零训练，数据直接决定你后续所有环节的成败。

2.1 预训练语料从哪里来、怎么洗

开源可用的预训练语料主要包括：RedPajama、SlimPajama、Falcon RefinedWeb，中文场景还有WuDaoCorpora、SkyPile等。但直接拿来用是不行的，必须做清洗。我们跑了几轮清洗后，原始文本大约只剩三分之二，其中不少是重复内容和无意义符号。

我实际用到的清洗流水线，按顺序大概是：

1. 格式统一：把所有语料转成统一UTF-8文本格式，处理PDF抽出来的乱码、HTML里的广告导航残留。
2. 去重：先做精确去重（MD5），再做模糊去重（MinHash + LSH）。网上很多公开语料重复率高到离谱，同一段新闻在不同网页出现几十次，不去重模型会严重过拟合，表现为生成内容大量重复。
3. 语言过滤：按业务需要筛选语言，用fastText或语种识别模型过滤掉无关语种。
4. 质量过滤：用规则结合困惑度过滤。规则主要筛掉纯表格、纯URL、无换行的超长文本；困惑度可以借助一个小的语言模型计算，把那些困惑度过高、不像正常语言的文本剔除。
5. 隐私与安全过滤：把身份证号、手机号、私钥这类信息用规则+正则清洗。

这五步不是可选项，是必须项。我们第一版数据因为去重不够，训练出来的模型在生成时经常出现大段重复文本，这个事后修补成本极高，建议一开始就做扎实。

2.2 数据配比：怎么搭才不出偏

不同来源的数据不能简单堆在一起，配比很重要。一个从零训出的中文模型，一般英文知识类数据占大头，中文占一部分，代码和数学要有相当比例，因为推理能力很多是从代码数据里学到的。

注意：代码和数学这类结构化数据，占比低会让模型逻辑能力明显偏弱；占比过高又会让模型语感变僵硬，在写作和对话场景显得机械。需要按业务场景做平衡。

我用的初始配比大致是：英文百科/网页/书籍 50%，中文百科/新闻/社区 25%，代码 15%，数学与推理 5%，其他 5%。这不是标准答案，但作为起点，比随便堆效果好很多。

配比调整有个技巧：先做小模型实验。拿1B模型，用不同配比训各10B token，看下游任务表现差异，能用小成本把数据配比调到较优，再放大到7B，省下的是几十万的训练费。

2.3 Tokenizer训练：基础一定要打牢

Tokenizer很多时候被忽略，但它直接影响压缩率和模型表现。中文场景下，直接用Llama的tokenizer中文效率很低，词表里中文token太少，同一个词拆得更碎，序列更长，训练和推理都变慢，效果也受影响。

训练自己的tokenizer时，我一般这么配置：

• 词表大小：中文+英文场景选50K到64K比较稳。太小了压缩率差，太大了容易过拟合，而且embedding层参数也变多。
• 训练语料：最好在正式预训练数据的同分布采样上进行，混合比例跟你预训练数据一致。
• 验证指标：看**字节覆盖率（byte coverage）**和平均分片长度。一个好的中文tokenizer，常见中文字符应该单个token能覆盖大半，极少出现把一个常用词切成三四个token的情况。

如果从头训练确实麻烦，可以考虑用现有开源中文tokenizer做扩展，但要注意embedding层是随机初始化的，如果模型是增量预训练，扩展词表后还需要做旧词表权重对齐的冷启动处理。这一块的细节不少人踩坑，建议实操时留意。

3. 预训练实操：从模型配置到loss收敛

数据就位之后，下一步就是预训练。这部分看起来就是跑脚本，实际训练过程中问题很多，loss不降、NaN、OOM、节点掉线，每个问题都能耗掉半天到一天时间。我把关键部分拆开讲。

3.1 模型架构与配置选择

如果你随机初始化，架构可以直接参考LLaMA的设计：标准decoder-only transformer，Pre-Norm（RMSNorm），SwiGLU激活函数，RoPE旋转位置编码，无偏置项。这套架构经过大量验证，训练稳定性和效果都有保障，不用特地去搞发明创造。

关键配置参数可以考虑从如下数值起步：

一个容易忽略的点是全局batch size。大模型训练的batch size建议保持较大的tokens总量，效果好且训练稳定；但batch太大会导致单卡显存爆炸，需要靠梯度累积实现。我们用的是512的micro-batch（每条2048 token），配合64步梯度累积，等效全局batch 65536条样本，约134M tokens。

3.2 训练框架与并行策略怎么选

训练7B模型，单机多卡到多机多卡的情况都有。我的建议是这样分层级走：

• 单机8卡A100/H100：直接用DeepSpeed ZeRO-3或PyTorch FSDP就够了。ZeRO-3把模型参数、梯度、优化器状态分片到各卡，训练7B模型很轻松，显存占用约60~70GB每卡。
• 多机多卡（≥16卡）：建议上张量并行（TP）+ ZeRO/FSDP组合，或者直接用Megatron-LM。张量并行能减少跨机通信量，训练效率高不少。
• 有稳定集群且长期训练：可以直接上Megatron-LM + 流水线并行 + 数据并行全套，但门槛较高，需要专职的并行工程师维护。

如果你只是想把流程跑通，FSDP是上手比较快的方案。注意用BF16而不是FP16，大模型梯度在FP16下很容易溢出变成NaN，BF16虽然精度低一点，但动态范围大，训练更稳。我们第一次用FP16，跑到几千步就NaN了，换了BF16解决。

3.3 训练监控：不要只看loss曲线

预训练阶段，loss肯定是一路下降的，但loss本身不够判断模型好坏。建议同步关注几个辅助指标：

• 验证集困惑度（Perplexity）：固定一个和训练数据同分布的验证集，每500步算一次困惑度。如果训练loss继续降、验证困惑度不再降甚至抬升，说明对训练数据过拟合了。预训练阶段这事不多见，但数据不足时会遇到。
• loss spike观察：训练中偶尔出现loss突然跳高又回落，通常是训练数据里混入了异常样本（超长重复段、非UTF字符等）。遇到loss spike，不要急着调参数，先去查那批数据的分布；查不清就减小心学习率，或者降低batch size。
• checkpoint策略：建议每500到1000步保存一个checkpoint，并且同时保存优化器状态。只存模型权重的话，中途训练中断连优化器状态都要重建，会浪费不少时间。我们有个习惯：每2000步传一份完整checkpoint到独立存储，避免节点故障导致整机数据丢失。

预训练的目标不是loss越低越好，而是保证后续SFT、DPO阶段还有足够的“学习空间”。一般训到loss区域平稳下降、困惑度符合预期，就可以切到SFT了。如果从零训练到困惑度明显高于参考开源模型的水平，大概率是数据量或数据质量没到位。

4. SFT：指令微调与对话能力塑造

预训练模型只是一个“文本接龙高手”，能续写但不会好好回答问题。SFT（监督微调）通过大量指令-回答对，把模型的生成行为对齐到“问答”模式。这一步做得好不好，直接影响用户感知到的模型智商和情商。

4.1 指令数据怎么构造与清洗

SFT数据现在公开资源不少：Alpaca、ShareGPT、Dolly、BELLE、OpenAssistant等都能用，但直接混合效果一般。SFT数据的核心要求是多样性+高质量，不是数量大。我们第一轮SFT用了30万条公开+自建数据，效果远不如后面精筛后的15万条，因为公开数据里大量是重复模板和低质量问题。

指令数据一般包含三类角色：system（系统提示）、user（用户指令）、assistant（助手回复）。构造时要注意：

• 指令要多样：同一意图换多种表达方式，覆盖“请帮我……”、“……怎么做”、“解释一下……”等句式，防止模型只会某一种句式。
• 回答要有依据：对于专业领域，每条回答最好附带参考来源，模型才能养成“有依据才答”的习惯，少生成幻觉内容。
• 包含拒绝样本：用户问违规或超出能力范围的问题时，要构造“我无法回答……”的回复，否则模型会强行编答案。
• 清洗PII信息：自建SFT数据往往包含用户真实对话，身份证、手机号、公司名必须过滤，别让训练数据把你出卖了。

4.2 全参微调还是LoRA

很多新手一上来就问要不要上LoRA。我直接给结论：

• 如果GPU显存够（如4卡A100），且想追求模型最佳效果：全参微调。SFT数据量不大（几万到几十万条），全参微调的收敛速度和效果上限都更高。
• 如果想快速实验、显存不够（单卡24G）：LoRA或QLoRA。LoRA只训练一小部分参数，显存和训练时间都节省不少，效果接近全参的80%~90%。

训练细节上有几个容易被忽略的地方：

• 损失只计算回答部分：标准做法是prompt部分的token不参与loss计算，只算assistant回复的交叉熵，否则模型会把“跟着问题念一遍”学进去。代码实现上一般通过labels矩阵把prompt位置设为-100忽略。
• 学习率要比预训练低：全参微调通常用1e-5到3e-5；LoRA可以用稍高的1e-4到3e-4。太高了会破坏预训练学到的通用特征。
• epoch一般不用太多：SFT数据规模不大，通常1到3个epoch就够了。过拟合的判断标准是验证集loss回升或模型开始“背诵训练数据”而不是泛化。

4.3 SFT常见翻车现场

这一阶段翻车频率非常高，列举几个我们真实遇到过的：

• 复读机：模型反复重复同一句话，尤其是长回答时。原因大概率是SFT数据里有大量包含重复句的回答，或者是预训练阶段数据重复率过高没洗干净。
• 回答格式乱：模型自己造出一堆不存在的markdown语法、错误换行。这类问题需要在SFT数据里统一格式，并在评估时重点检查格式一致性。
• 混入system内容：模型把system里的指令原样输出，或者自己发明system内容。这通常是SFT数据没有严格按照chat template填，导致模型没学会区分角色。注意在训练和推理时使用同一个chat template，这是新手容易踩的隐坑。

SFT完成后，模型已经能“正确回答”了，但“正确”和“符合人类偏好”是两码事。接着要上对齐阶段。

5. DPO/RLHF：偏好对齐，让模型学会说人话

SFT教会模型模仿数据里的回答方式，但它不会判断两个回答哪个好。偏好对齐的目标，是让模型学会输出“人类更偏好的回答”，比如更安全、更有用、更简洁。这一步走完，模型才能真正用在实际业务中。

5.1 Reward Model、RLHF 和 DPO 的差异与选型

RLHF（Reinforcement Learning from Human Feedback）的经典流程是：先训练一个Reward Model打分，再用PPO等强化学习算法去优化策略模型，让回答在RM得分高的同时，不过度偏离SFT基线（加KL惩罚）。

DPO（Direct Preference Optimization）出现之后，这个流程被大幅简化。它去掉了Reward Model和强化学习环境，直接用偏好对数据微调策略模型，让模型增大对chosen回答的概率、降低对rejected回答的概率。

考虑到大部分团队只有有限的GPU资源和工程人力，第一次做对齐建议直接用DPO。RLHF那套流程复杂，PPO的KL散度控制、优势估计裁剪、RM训练等环节有一环没调好就白费工夫。DPO在7B量级上的效果已经被大量验证过，是性价比更高的起点。

5.2 DPO数据构造与超参要点

DPO的数据形式是偏好对：同一个问题，给出一个chosen（人类更喜欢的回答）和一个rejected（人类不太喜欢的回答），模型从中学会区分好坏。

数据来源一般有两种：

1. 人工标注：让标注员对比SFT模型的多个回答，选出好坏。成本高但质量可靠。
2. 模型自动构造：用强模型（如GPT-4）对SFT模型的多个输出打分排序，选出一好一坏。成本低但需注意作弊问题（模型可能偏好它自己风格的答案）。

我们实际跑下来，发现DPO效果好坏主要靠数据质量而非数量。5万对高质量偏好数据，效果比20万对弱监督数据好得多。至少要保证chosen和rejected来自同一个场景、同一个长度范围，不然模型容易走捷径（比如学习到“长的就是好的”这类虚假特征）。

DPO训练时几个关键配置：

• beta参数（KL约束系数）：默认0.1到0.5之间。beta越大，模型越不敢偏离参考模型；越小，模型更激进地偏好chosen。我们常用0.1，稳定性和效果平衡较好。
• 参考模型（ref_model）：用SFT阶段的模型作为参考模型，不要在DPO开始后又重训参考模型。两个模型同源是DPO收敛的保障。
• 学习率：DPO学习率一般比SFT低，通常1e-6到1e-5。我们全参DPO用2e-6，LoRA DPO用1e-5。
• 混合SFT数据：只训练DPO数据容易让模型学歪（比如对话风格突变）。实操中，我们会把DPO数据和少量SFT数据混合训练，比例大概3：1，能保持基本问答能力不退化。

5.3 对齐之后必然付出的代价

对齐不是免费的。偏好对齐本质上是在压缩模型的输出空间，模型会变得更“正确”，但也可能变得更保守、更啰嗦、丢失一些创造力。我们对比过，SFT模型能给出更有“灵性”的答案，DPO之后更规范，但有时显得模板化。

所以对齐的目标要跟业务挂钩：如果是客服、知识问答、审核这类场景，宁保守勿出错，DPO可以多跑几个epoch；如果是创意写作、文案生成，DPO收敛太快反而会损失多样性，建议用较低beta、较少步数，保留更多生成空间。

6. 评估与落地：没有评估就是盲人摸象

很多人训完模型就急着部署，问“效果怎么样”却说不上来。大模型评估是拿着放大镜看细节的活，不做系统评估，你根本不知道模型哪里好哪里坏，上线了才知道问题就晚了。

6.1 自动评测基准不是万能的

业界常用的自动基准有：MMLU、CEval、CMMLU、HumanEval、BBH、GSM8K等。跑一遍确实能看出大概水平，但有几个前提要搞清楚：

• 数据污染问题：开源基准数据很可能出现在你用的预训练或SFT数据里，模型对这些“见过”的题有虚高表现。这非常常见，我们有一次训练到CEval 80分，但实际使用时逻辑推理和通用常识都明显拉胯。
• 自动评估只能测上限，不能测真实体验：模型在选择题任务上能得分高，但在自由生成格式的任务里可能一团糟，比如回答冗长、格式乱、编造来源。

建议做法：自动基准只是门槛，真正决定上不上线的是任务场景里的专业测试集。如果你是做法律问答，就找法律题库和真实咨询记录构造评测集；如果是代码生成，就用业务相关的小型代码编写任务，让资深工程师人工打分。

6.2 人工评估的完整流程

我们团队跑了两轮人工评估，这里给出一个能复用的框架：

1. 样本选择：从真实业务场景中随机抽取200到500个问题，覆盖常见场景、边界场景、安全场景。
2. 盲测对比：让评估员同时看两个模型的输出，但隐藏模型身份，对“正确性、有用性、安全性、格式”四个维度分别打分。
3. 双人交叉评判：同一批样本分配给两个评估员独立打分，不一致的样本由组长讨论复核，减少主观偏差。
4. bad case分析：凡是得分低的样本，逐条分析原因，归类整理后回填到训练迭代里。

另外，**红队测试（red teaming）**也建议认真做一次：尝试用对抗性提示让模型输出有害内容、泄露隐私、绕过限制。这一步对模型上线后的安全性有实际作用，尤其是面向外部用户的产品。

6.3 部署与推理：模型训完怎么用起来

模型评估没问题后，部署选型直接影响落地体验。目前比较成熟的方向有：

• vLLM：吞吐量高，支持PagedAttention，对并发请求场景合适，是目前自建推理最主流的引擎。7B模型用单张A10G/A100就能跑得比较顺，配合Tensor Parallel可以进一步降低延迟。
• Ollama：本地单机场景很合适，一条命令把模型跑起来，适合个人电脑、小团队的内部试用。它的推理速度和灵活性不如vLLM，但胜在省心。
• 量化部署：如果资源紧张，可以考虑AWQ或GPTQ量化到INT4/INT8。7B模型INT4大概占4~5GB显存，速度提升明显，但要注意量化后效果会有一定损失，建议用评测集测一轮再决定是否上线。

我们在实际部署时发现，推理时上下文长度和SFT阶段不一致会导致效果明显变差。如果你SFT用的是2048上下文，部署时突然给模型塞6000字的长文档，模型表现会非常不稳定。部署前最好把上下文长度对齐，或者多测几组长度看看效果梯度。

最后分享一点个人体会

这条链路走下来，我最大的感受是：大模型训练不拼技巧，拼的是工程耐心和数据洁癖。从零训练的时间分配，数据工程占了一半以上，训练本身反而不是最耗时的环节。任何偷工减料的数据处理方式，都会在后面某个阶段加倍还回来。

另一个体会是：不要迷信某个单一环节的惊艳效果。SFT好不代表DPO好，DPO好不代表业务表现好，每一轮都要用评估说话，bad case分析比benchmark分数重要得多。以后拿到一个新模型，花一个下午做一轮针对自己业务的bad case分析，比看十篇评测报告更有用。