企业官网建设流程全解析

做这行的时间长了会发现，很多人一提到“预训练语言模型”就自动把它和“几千张显卡、几百亿参数”绑定在一起，觉得这跟个人开发者毫无关系。但实际情况完全不是这样。开源生态成熟之后，个人开发者完全有能力走通一条从预训练到领域适配的完整链路：拿开源基座模型做继续预训练，灌入领域语料，再通过指令微调做行为对齐，最后接上RAG知识库并部署成可用服务。这篇文章是我最近半年跑完这条链路的完整复盘，不是路线图，是干完活之后回头写的总结，会尽量多说些文档里不写的东西。

这套流程适合三类人：想把LLM真正用在自己业务里的开发者，想搞懂预训练内部机制但没有大集群的学习者，以及接了垂直领域项目、需要从通用模型做出专用模型的交付团队。整条链路涉及的核心关键词就那么几个：LLM、预训练、领域适配，但每一个词展开后都是一大堆细节。下面按我实际执行的顺序来讲。

1. 先想清楚：个人开发者到底需不需要“从零预训练”

1.1 从Karpathy的llm wiki项目谈起

我是在GitHub上刷到karpathy的llm wiki项目时，才真正把“个人开发者也能碰LLM训练”这件事想明白的。那个项目不是让你去复现一个GPT级别的东西，而是把LLM背后的每一个关键环节拆成可运行、可实验的最小单元：tokenizer怎么训练、embedding怎么初始化、训练稳定性怎么保证、loss怎么解读。它更像一本能跑的教科书。

llm wiki项目给我最大的启发不是代码本身，而是一句话：预训练不是非黑即白的事，你可以只训练一个十几层的迷你模型，也可以只做其中一个阶段。对个人开发者来说，最实用的理解方式是——预训练是一个“连续谱”，从零训练、阶段训练、继续预训练、低成本微调都是这条谱系上的不同位置。你没必要每次都从零开始，但你必须知道每个位置发生了什么。

1.2 三条路线怎么选

实际操作中，个人开发者面前有三条路，对应不同目标和预算：

• 从零预训练：自己造数据、自己定词表、从头初始化参数。这条路的数据处理量和调参成本极高，通常要几十亿token起步的语料才能让模型具备基本语言能力。个人如果抱着学习目的，推荐用几千万token跑一个小模型做实验；如果是为了交付项目，强烈不建议。
• 继续预训练（domain-adaptive pretraining）：在开源基座权重上，用领域语料继续训练。这是我在垂直项目里的首选，因为资源需求大幅下降，还能让模型补上领域知识。
• 直接基座加SFT：完全不碰预训练，只做指令微调。最便宜，见效最快，但基础知识的缺失会让效果天花板很低。

我的默认选择是第二条路。原因很朴素：从零预训练的大部分成本根本不在显卡上，而在数据清洗和训练稳定性调试上。对一个只有几块消费级显卡的个人开发者来说，把时间花在“让训练过程不崩溃”上，远不如把开源基座当成“已经学会了人类语言的大脑”，然后用领域语料给它做专业深造。

有个现象值得注意：现在很多人搜“yolo预训练模型下载”、“resnet预训练模型权重”，下意识觉得计算机视觉的预训练模型才是自己够得着的；而LLM的预训练权重一样可以从HuggingFace直接拉下来用，本质上没有区别。预训练模型的意义在于它已经掌握了语言和世界知识的基础分布，你要做的不是重新教它说话，而是让它懂你的领域。想通这一点，个人开发者的重心自然就从“如何训练”转移到“如何适配”。

2. 数据：整条流程里最该花时间的环节

2.1 数据清洗与抽样

领域适配的成败，一半以上由数据决定。我从一开始就记住了这个教训：与其花两周调参，不如花两周处理数据。数据工作的优先级远高于模型结构、学习率这些看着更“技术”的东西。

预训练和继续预训练对数据质量的要求极高，脏数据带来的损失往往要训练很久之后才暴露出来，那时想回头就晚了。我的清洗规则大致有四条：

• 按行去重，按段落模糊去重，防止同一知识在不同页面里的重复文本反复训练；
• 过滤低质量文本，包括无标点长串、纯乱码、广告导航类内容，以及明显机器生成的重复文本；
• 按来源分层抽样，让权威文献、操作手册、知识库文章、问答记录按比例混合，避免单一来源失衡；
• 统一格式，去掉多余空行、统一换行符、清理HTML标签残留。

这里有个细节容易忽略：清洗环节的过滤规则一定要记录成配置，不要用完就丢。训练效果不好时，90%的排查方向会指向数据，如果连“数据是怎么来的”都说不清，排查就没法进行。

2.2 tokenizer词表到底要不要扩

继续预训练里最容易被忽略的是tokenizer问题。中文领域项目的痛点尤其典型：通用模型的词表大多是中英混合，遇到医学、法律、工程这些专业领域，一个词组会被切成一堆碎片，不仅增加序列长度，还让模型很难学到稳定的“词义”。

比如“肝细胞癌”这个词，如果词表里没有它，分词器会切成“肝”加“细胞”加“癌”，每个token单独看都认识，但模型要花很大力气才能把它们关联成一个完整概念。领域语料里这类专业复合词组一多，训练效率就会明显下降。

解决办法是扩展词表。在基座模型的tokenizer里新增一批领域词元，然后把新增embedding和lm_head矩阵做随机初始化并拼到原有权重上。这里有个关键点：不能只加词元不调权重，否则模型遇到新词元会不知所措，训练初期loss会异常飙升。扩展之后，需要用包含大量新词元的语料做几步warmup，让模型先适应新embedding的分布。

不过词表扩展不是越多越好。我试过一次性加了三万个词元，结果基础英文能力明显下降，因为新增词元稀释了原词表的概率分布。后来控制在两千到五千个词元，效果最稳。

2.3 怎么把wiki知识库变成训练语料

Karpathy llm wiki里有个思路我特别认同：把高质量、结构化程度高的知识库作为预训练语料的首选来源。实际项目里，我处理过大量wiki类知识库，总结出一个重要差异——同是知识库，RAG用的源文档和训练用的语料不是一回事。

RAG的源文档要求短、结构化、检索友好，每个片段相对独立。训练语料则要求完整、连贯、叙述性强，因为模型需要通过长文本学到知识之间的承接关系。把wiki上的碎片章节直接拼起来喂给模型，效果通常不好。

我的做法是把知识库条目重写成“陈述句段落”。以中药处方审核方向为例，我不会直接把“药品A与药品B存在配伍禁忌”这样的条目丢进训练集，而是改写成：“在处方审核中，药品A与药品B联合使用时存在明确的配伍禁忌风险，临床应避免同时开具；若确有联用需求，必须在审方系统中进行风险提示。”改写后，模型学到的不仅是事实，还有事实的使用语境。这个过程叫“语料叙述化”，是领域适配里性价比极高的一步。

3. 预训练实操：框架选型与训练细节

3.1 框架选型与显存控制

个人开发者做继续预训练，不需要一上来就用重型分布式框架。当前可用选项大致有四类：

我的选择是HuggingFace Trainer加DeepSpeed，理由特别实际：出问题时最容易搜到答案。个人开发者最怕的不是性能低，而是报错后找不到参考。

显存控制是必答题。继续预训练通常吃显存最多的部分是优化器状态，光AdamW的fp32状态就要占参数量的12倍空间。用ZeRO Stage 2把优化器状态分片到多卡，再配合梯度累积，几张24GB的卡也能跑7B模型。

3.2 关键参数怎么定

分享一组我用下来比较稳的起点参数，基于8卡24GB显存、7B基座模型的场景：

• 全局batch size：128，通过micro batch 4加梯度累积8实现；
• 序列长度：2048，不贪长，够用就行，长了显存和数据处理成本都会翻倍；
• 学习率：1e-5到2e-5，明显低于SFT阶段的学习率，继续预训练本质是“微调基础上的微调”，学率太大会破坏原有权重；
• warmup比例：3%，让学习率先缓后升再缓降。

有个容易被忽略的点是学习率调度器在继续预训练中的作用。我的经验是先用500步warmup，观察loss有没有“跳水式下降”，如果没有，问题大概率出在数据而不是学习率上。训练过程里，loss的下降应该是平滑的，如果曲线出现明显锯齿，我会先检查是不是数据批次混合不均，而不是急着调学习率。

3.3 训练监控与loss解读

监控是预训练里唯一能让“不崩溃”变成“受控”的手段。除了常规的loss曲线，我会额外记录三样东西：梯度范数、token级困惑度、学习率实时值。

loss下降慢并不一定代表训练失败。有一回我训练一个法律领域模型，loss绝对值降得很慢，但生成质量的提升非常明显。原因是loss值受高频通用词影响大，领域术语本身的低频属性让它在全局loss里的占比很小。所以不要只看loss数字，要看生成案例的实际变化。

训练中断是很常见的事。建议开启自动保存，并把checkpoint存在独立磁盘分区上。我吃过一次亏：中途磁盘写满，整个checkpoint目录损坏，前三天白跑。从那以后我养成了“先把checkpoint同步到另一块盘再继续训练”的习惯。

4. 领域适配：继续预训练、指令微调与偏好对齐

4.1 继续预训练和SFT的分工

很多初学者会把“预训练”和“微调”搅在一起，实际这两件事解决的是完全不同的问题：

• 继续预训练解决“模型知不知道你的领域知识”；
• 指令微调（SFT）解决“模型能不能按你的要求回答问题”；
• 偏好对齐（DPO等）解决“模型更愿意给什么样的回答”。

先后顺序有讲究。先做继续预训练，再做SFT，最后做偏好对齐。如果反过来，模型在SFT阶段学到的指令遵循能力很容易被后续的预训练破坏掉。这个顺序我实测过，不可逆。

4.2 SFT数据格式与label设计

指令微调数据的基本格式是三段式：instruction、input、output。我把它比喻成“教一个新人做事”：说出要求，给出背景，然后给标准答案。SFT阶段的主要工作不是收集海量数据，而是设计高质量label。

我写label时踩过不少坑，总结下来这么几条：

• label必须只含最终回答，不要出现“好的，让我来回答这个问题”这类寒暄话，训练时模型会学这种废话；
• 答案风格要统一，同一批数据里不要一会儿用正式报告风格、一会儿用口语风格，模型学到的输出风格会混乱；
• 问题要贴近真实使用场景，不要只写“什么是XX”这种教科书式问题，更要覆盖“我手里的处方里有A和B，要不要紧”这类真实业务提问；
• 复杂问题要带限制条件，比如“在不考虑患者过敏史的前提下”之类的约束，否则模型会给一个笼统模糊的答案。

做领域微调时，我有一个技巧：把之前叙述化的知识库段落，用prompt模板批量改写成问答对。比如给定一段关于配伍禁忌的陈述，要求生成对应的“药师问、系统答”数据。生成之后必须人工抽查清洗，因为模板生成的数据会有不少废话式回答，直接训练会污染模型风格。

4.3 DPO偏好对齐的实操经验

偏好对齐阶段，个人开发者首选DPO而不是传统RLHF。理由很朴素：RLHF需要单独训练一个奖励模型，成本高、稳定性差；DPO只需要构造“好回答/坏回答”成对数据，直接在原有SFT模型上微调即可。

DPO的数据主体是偏好对。我自己的做法是让模型针对同一问题生成多个回答，然后人工标注排序，选出最好和最差各一个。标注标准要具体，比如“是否直接给出结论”、“是否包含必要风险提示”、“是否在不确定时明确说不确定”。

DPO训练里有两个容易出错的地方。一个是beta参数，控制偏好对齐的强度，我一般从0.1开始，效果不理想再微调。另一个是参考模型一定要冻结，如果把参考模型也训练了，DPO的损失函数就没有了参照基准。我在早期犯过这个错误，结果训练出来的模型输出变得极端且不可控。

5. 知识库落地的关键一步：RAG与GraphRAG

5.1 为什么微调之后还要RAG

领域适配完成后，模型对领域知识的理解能力会上一个台阶，但你很快会发现另一个问题：模型里的知识是冻结的。知识库今天更新了一条审方规则，模型不会自动知道。重新训练一次的成本又太高。这正是RAG存在的意义。

预训练或继续预训练的本质是“把知识压缩进参数”，RAG的本质是“把知识放在模型外面，需要时检索出来送进上下文”。两者互补。我在实际项目里的分工是：高频、稳定、需要深度推理的知识放进模型参数；低频、频繁更新、按条件检索的知识放进RAG。比如配伍禁忌这类相对稳定的规则靠预训练掌握，而药品说明书里的厂商信息、库存状态这类高频变化的信息靠RAG解决。

5.2 本地wiki知识库的构建流程

构建wiki知识库的流程我梳理成了五步：

1. 解析wiki dump或爬取页面，把正文抽取出来，去掉模板、目录、导航等噪音；
2. 做文本切分，按语义段落切，而不是按固定字数切；
3. 向量化，常用方案是bge或text-embedding类模型，把段落转成向量；
4. 建索引，我用过faiss和milvus，数据量不大时faiss足够；
5. 接检索，把用户问题和知识片段同时向量化，做相似度检索后拼进prompt。

切分这里要特意讲一下。固定256字切分是我用过最省事但效果最差的办法，经常把一个完整概念切断。我现在倾向于先按markdown标题或段落语义切，再把过短的片段合并，过长的二次切分。切分的粒度直接影响回答的准确程度，值得花时间调。

我在一个本地ERP产品检索项目里也验证过这条路。把产品手册、历史工单、售前问答整理成知识库，再通过RAG给客服系统做检索增强，完全没有重新训练模型，只靠prompt模板就做到了“回答带出处”的效果。对大多数业务场景来说，这已经是最划算的落地方式。

5.3 GraphRAG和本体RAG到底好在哪

传统RAG的短板是“只认相似不认关系”。向量相似度能帮你找到包含“布洛芬”的段落，但很难回答“哪些药和布洛芬存在相互作用”这种涉及多跳关系的问题。GraphRAG的思路就是先抽取出文本里的实体和关系，构建成图再检索。

GraphRAG的落地成本不低。先要把知识库里的实体关系抽取出来，这本身就是一次小型的LLM工程；然后存储图结构以支持子图检索；最后把检索到的路径拼进context。但它对多跳问题的提升确实明显。我在审方知识库上试过，传统RAG能回答“A和B能否同服”，GraphRAG则能回答“A代谢受影响后，与依赖该代谢酶的C药同服是否有风险”，这种问题靠纯向量是答不出来的。

本体RAG是进一步的进阶方案，它用领域本体（一套预先定义好的概念、实体、关系框架）来约束图构建和检索过程。不用本体时，GraphRAG抽出来的关系可能是“A与B相关”这种泛化关系；用本体约束后，关系会被规范成“抑制”、“诱导”、“配伍禁忌”这样明确的类型，检索结果的质量差别很大。这里的经验是：本体设计要简单实用，先覆盖核心关系，别贪全。贪全的下场是本体维护工作量爆炸，而实际推理用不上那么多关系。

6. 部署上线：ONNX、推理框架与量化

6.1 ONNX导出LLM模型的几个坑

很多个人开发者习惯用PyTorch直接跑模型，但交付项目时ONNX是绕不开的。ONNX的推理性能、跨平台能力、与边缘设备适配性都好于直接跑PyTorch。我自己在导出时踩过三个坑：

第一个坑是动态轴没配置。LLM的输入长度是可变的，导出时必须把序列长度维度标记为动态轴，否则推理时换个长度就报错。第二个坑是注意力掩码的拼接错误。生成式推理需要维护一个不断增长的past key values，如果在导出时就把这部分逻辑写死，后续扩展性会很差。第三个坑是精度问题。ONNX默认用fp32导出，模型文件和推理速度都不理想，实际部署至少要转成fp16。

导出完成后，一定要先在本地用真实请求测一遍，确认输出与PyTorch原版一致。我遇到过ONNX导出后个别token和原模型对不上的情况，排查了很久才发现是把attention mask当普通tensor一起量化导致的。

6.2 推理框架选型

模型部署方式我试过三种：纯ONNX Runtime、vLLM、llama.cpp。各有各的适用场景。

如果服务是给多人用的API，我首选vLLM。它的continuous batching能把多个请求打包进一个batch，吞吐量比逐请求推理高很多。如果只是自己在本地用，llama.cpp加GGUF量化是最省心的组合，一张16GB显卡就能流畅跑7B模型。项目交付给客户做内网部署时，我一般选ONNX Runtime，因为它不依赖Python环境，打包成一个服务就行。

6.3 量化与显存的配合

量化是在显存和效果之间做权衡。我常用的几档配置是：

• fp16：效果无损，一个7B模型大概需要14GB到16GB显存；
• int8：效果损失极小，显存降到7GB到9GB；
• int4（如GGUF Q4_K_M）：效果会有可见损失，但显存只需4GB到6GB。

量化对知识型任务的影响相对较小，对逻辑推理和数学任务影响更明显。我在一个需要计算剂量的审方场景里对比过，int4模型在简单计算上的错误率明显高于fp16。所以我的原则是：除非显存实在不够，否则至少保留int8；关键场景绝不压到int4。

部署阶段还有个常被忽略的问题：请求日志。无论是ONNX服务还是vLLM服务，我都会记录完整的请求和响应log。有一次客户反馈“模型回答不靠谱”，排查下来不是模型问题，而是上游调用方把参数传错了。如果没有日志，这种问题要查很久。

7. 常见问题与排查技巧实录

7.1 loss不降或震荡

训练中最常遇到的三个现象是loss不降、loss下降后反弹、loss剧烈震荡。我的排查顺序是：

• 先看数据：数据是否重复、语料是否过短、上下文是否完整；
• 再看学习率：继续预训练阶段如果学习率大于5e-5，很容易把原有权重冲乱；
• 接着看梯度：如果梯度范数异常大，加梯度裁剪，我一般设在1.0；
• 最后看tokenizer：如果大量输入被切成单字，说明词表扩展没做好。

loss不降有一半以上是数据问题。不要一上来就怀疑模型结构或框架，先拿一段干净语料在基座模型上做小规模对比实验，如果基座在小语料上也降不下去，那问题就在数据预处理。

7.2 领域能力上来，通用能力却崩了

这是继续预训练最容易出的副作用。模型训练了一个星期，领域问题回答得头头是道，但写一段通用文案反而退步了。原因是训练语料过于单一，把模型的通用能力“覆盖”掉了。

解决办法是混合通用语料。我实践下来比较好用的比例是领域语料与通用语料约1比3到1比5，通用语料可以来自开源的中文语料库或清洗后的通用网页文本。这样既确保了领域知识的占比，也不至于把基座模型的通用能力冲垮。

7.3 provider rejected the request schema这类部署报错

部署时我遇到过很多次“provider rejected the request schema or tool payload”之类的报错。这类问题的根源通常是：你用的网关或代理框架对工具调用的schema有严格校验，而模型生成的工具参数没有严格符合JSON Schema格式，于是请求在到达模型前就被拦下了。

排查思路是三步。第一步确认工具调用的schema定义和模型输出格式是否一致，重点检查必填字段名大小写；第二步给模型打开JSON mode或约束解码，让输出严格按schema生成；第三步如果你是靠SFT来教模型调用工具，需要在SFT数据里加入大量工具调用格式样例，让模型学到“什么时候调用什么工具、参数长什么样”。单纯改prompt治标不治本。

还有一个隐藏原因：网关层对tool payload字段有类型校验，比如某个字段预期是string，模型输出却是array，被拒就是必然的。这类问题多用在线JSON Schema校验工具验证一遍再改模型侧会比较高效。

7.4 一份个人项目的排错速查表

我把踩过的坑整理成一张速查表，后续项目直接照着排查：

以上所有排查项都对应着一句话：不要假设最坏的情况，从最简单、最可控的环节开始切。训练和部署这类长链路任务，问题往往不在最显眼的位置，而是藏在某个被默认忽略的配置里。

跑完这套流程，我个人最大的体会是：预训练和领域适配之间的边界，没有想象中那么大。个人开发者的优势在于灵活，不需要像大团队那样维护复杂的基建，可以快速试错、快速调整。如果条件有限，可以从“最贵的步骤”反推——把预算和精力优先砸在数据上，训练框架追求稳定够用即可，部署方案从最小可行版本开始，效果验证之后再往上加成本。这套路线我现阶段跑得很顺，后续如果再深入，我会优先补两件事：一是把数据清洗和检测流程进一步自动化，二是给RAG加上更细粒度的知识版本管理。先分享到这儿，等有新坑再回来填。