企业官网建设流程全解析

个人开发者想在本地把一个大语言模型从零训练到能干活，这件事在两年前还像是天方夜谭，现在却已经变成了一条相对清晰的工程路径。我前后用一台单卡 RTX 3090 的机器折腾了大半年，从最开始的 GPT-2 复现，到后来做领域适配、跑通推理部署，中间踩的坑足够写一本小册子。这篇就把整条链路完整摊开讲一遍：预训练到底在做什么、单卡能训到什么程度、领域适配该怎么下手、数据从哪来、显存怎么省、训完怎么验证效果。不管你是刚接触 LLM 想搞明白底层原理，还是已经会调 API 但想自己动手训一个模型，这篇都能给你一条能直接照着走的路线。

1. 先想清楚个人开发者做 LLM 全流程到底图什么

很多人一上来就问"3090 能不能训 GPT-4"，这个问题本身就问错了方向。个人开发者做 LLM 全流程，目标从来不是复现一个通用大模型，而是搞清楚三件事：模型是怎么从随机权重变成能说人话的、领域知识是怎么灌进去的、训完之后怎么让它真正跑起来服务。把这三件事走通一遍，你对 LLM 的理解会超过 90% 只会调 API 的人。

1.1 预训练、微调、领域适配三者的边界

先把概念理清楚，不然后面全是糊涂账。预训练（Pre-training）指的是用海量无标注文本，通过自监督目标（对 GPT 系列就是预测下一个 token）让模型学会语言的统计规律。这个阶段产出的叫基座模型（Base Model），它只会"续写"，不会"对话"。微调（Fine-tuning）是在基座之上，用有标注或高质量数据继续训练，让模型学会遵循指令、适应特定任务。领域适配（Domain Adaptation）是微调的一个特化方向，目标是把通用模型的能力迁移到某个垂直领域，比如医疗、法律、工业设备日志。

这三者的关系可以这样理解：预训练是让一个人学会认字和说话，微调是教他做具体工作，领域适配是让他去某个行业上班。个人开发者受限于算力，通常不会从零预训练一个几十亿参数的模型，而是走"小规模预训练验证流程 + 开源基座做领域适配"的组合路线。我自己的做法是：先用 GPT-2 这种小模型完整跑一遍预训练，把数据管线、训练循环、checkpoint 管理全部摸熟，再拿开源的中文基座做领域适配，这样既有原理层面的理解，又有实际可用的产出。

1.2 单卡 3090 的真实能力边界

RTX 3090 有 24GB 显存，这是个人开发者能拿到的性价比最高的卡之一。它的能力边界大致是这样的：从零预训练，GPT-2 small（124M 参数）用 FP16 加梯度累积，batch size 能开到 8 到 16，一天能跑几百万 token；GPT-2 medium（355M）就吃力了，需要梯度检查点（gradient checkpointing）才能勉强跑起来。如果是做领域适配，7B 参数级别的模型用 QLoRA（4-bit 量化 + LoRA）可以在 24GB 显存内跑通，13B 就非常紧张，需要精细调优。

这里有个反直觉的点：显存瓶颈往往不在模型参数，而在优化器状态和激活值。以 7B 模型全量微调为例，FP16 权重占 14GB，Adam 优化器状态（一阶动量 + 二阶动量）又是权重的两倍即 28GB，再加上激活值，轻松突破 60GB。所以个人开发者必须用参数高效微调（PEFT）技术，把可训练参数压到 1% 以下。我实测下来，QLoRA 训 7B 模型，显存占用稳定在 18 到 20GB，留出了足够的余量给长序列。

1.3 全流程的五个阶段拆解

把整条链路拆开，个人开发者的 LLM 全流程可以分成五个阶段，每个阶段都有明确的输入输出和验收标准：

这五个阶段不是线性的，实际做的时候会反复回到数据准备阶段补数据、回到评估阶段发现问题。我建议第一次做的时候严格按顺序走一遍，把每个阶段的坑都踩一遍，之后再迭代就有感觉了。

2. 预训练阶段：从 GPT-2 开始把流程跑通

为什么选 GPT-2 而不是别的？因为它足够小、结构足够经典、社区资料足够多。GPT-2 是纯 decoder 架构，和现在主流的 LLM 架构一脉相承，把它训明白了，再看 LLaMA、Qwen 这些模型的结构就是水到渠成的事。而且 GPT-2 的代码实现非常简洁，nanoGPT 那种几百行的实现就能跑通，非常适合个人开发者理解每一个细节。

2.1 数据管线的搭建与清洗

预训练的数据质量直接决定模型质量，这一步偷懒后面全是坑。我的数据来源主要是三类：公开的中文语料（如维基百科 dump、新闻语料）、自己领域的文档、以及一些高质量的书籍文本。数据清洗要做的操作包括：去除 HTML 标签、统一全半角、过滤乱码和重复段落、去除过短或过长的样本。

这里有个容易被忽略的点：去重比清洗更重要。如果训练数据里有大量重复内容，模型会过度拟合这些片段，生成时反复输出同样的句子。我用 MinHash + LSH 做近似去重，把重复率从 30% 降到了 5% 以下，效果立竿见影。具体做法是把每篇文档切成 shingle，算 MinHash 签名，再用 LSH 分桶找相似文档。这个流程用 datasketch 库几十行代码就能实现。

分词环节，中文场景我建议直接用现成的 tokenizer，比如 GPT-2 的中文扩展版或者 BERT 的中文词表。自己训 BPE 词表也可以，但要注意词表大小和压缩率的平衡。词表太小会导致序列过长，词表太大会让 embedding 层参数膨胀。我实测中文场景下 5 万到 8 万的词表大小比较合适，压缩率能到 2.5 左右，也就是一个 token 平均对应 2.5 个汉字。

2.2 训练循环的关键参数设置

训练循环看起来简单，但参数设置直接决定能不能收敛。我用的配置是这样的：优化器选 AdamW，学习率 6e-4 配 cosine 衰减加 warmup，warmup 步数占总步数的 2% 左右，权重衰减 0.1，梯度裁剪阈值 1.0。batch size 受显存限制开不大，就用梯度累积凑等效 batch size，我一般累积到 64 到 128。

学习率是最需要调的参数。太大直接发散，loss 变成 NaN；太小收敛慢，跑几天看不出效果。我的经验是先用小学习率跑几百步看 loss 趋势，如果下降太慢就逐步放大，直到 loss 开始震荡再回调一半。GPT-2 small 在 3090 上，6e-4 是个比较稳的起点。另外 FP16 训练容易溢出，建议用 BF16（如果卡支持）或者加 loss scaling。3090 是支持 BF16 的，我强烈建议用 BF16，省去了 loss scaling 的麻烦，数值稳定性也好很多。

2.3 显存优化：梯度累积与检查点

显存不够是个人开发者的常态，必须掌握几个省显存的技巧。梯度累积是最基础的，把一个大 batch 拆成几个小 batch 依次前向反向，梯度累加后再更新，等效于大 batch 但显存占用只有小 batch 的水平。梯度检查点（gradient checkpointing）是拿计算换显存，前向时不保存中间激活值，反向时重新计算，显存能省 50% 到 70%，代价是训练速度慢 20% 到 30%。

还有一个技巧是混合精度训练，权重用 FP32 主副本，前向反向用 BF16，这样既保证数值稳定又省显存。我实测 GPT-2 small 用 BF16 加梯度检查点，batch size 能从 8 提到 24，训练速度只慢了一点点。如果还嫌不够，可以考虑 DeepSpeed 的 ZeRO 阶段 2 或 3，把优化器状态和梯度分片，但单卡场景收益有限，主要是多卡才明显。

2.4 怎么判断预训练"训到位了"

预训练没有明确的终点，但有几个信号可以参考。第一是loss 曲线，训练 loss 和验证 loss 都稳定下降且没有明显发散，验证 loss 不再下降时可以考虑停。第二是生成质量，定期用固定 prompt 生成文本，看是否通顺、是否重复、是否跑题。第三是下游任务表现，如果预训练是为了后续微调，可以定期拿一个小验证集测一下。

我踩过的一个坑是：loss 降得很低但生成质量很差。后来发现是数据里混入了大量重复的模板文本，模型学会了"背模板"。所以验证 loss 低不等于模型好，一定要人工看生成结果。我一般每跑 5000 步就存一个 checkpoint，然后手动测几个 prompt，记录生成质量的变化，这样能直观看到模型是怎么一步步变好的。

3. 领域适配：让通用模型学会你的行话

预训练跑通之后，真正的价值在于领域适配。通用模型什么都懂一点，但一到专业场景就开始胡说八道。领域适配的目标就是让它学会你所在领域的术语、表达习惯和知识。个人开发者做领域适配，主流路线是 LoRA 或 QLoRA，成本低、见效快、不容易灾难性遗忘。

3.1 领域数据的构造：从原始文档到指令对

领域适配的数据和预训练数据完全不同，它需要的是"指令-回答"对。原始文档不能直接拿来用，要经过转换。常见的方法有三种：一是人工标注，质量最高但成本也最高；二是用强模型蒸馏，拿 GPT-4 之类的模型把文档转成问答对；三是模板生成，针对结构化文档用规则生成问答。

我主要用第二种加第三种结合。比如我手头有一批设备维修手册，先用规则把"故障现象-排查步骤-解决方案"抽出来生成问答对，再用强模型对生成的问答做润色和扩充。这样既保证了领域知识的准确性，又保证了表达的自然度。数据量上，领域适配不需要太多数据，几千到几万条高质量指令对就能有明显效果，关键是质量而不是数量。

构造数据时要注意多样性。如果所有样本都是同一种句式，模型会过拟合这种模式。我一般会刻意设计多种任务类型：问答、摘要、改写、分类、抽取，让模型在多个任务上都能表现。另外要留出一部分数据做验证集，不要全部拿去训练。

3.2 LoRA 与 QLoRA 的选型逻辑

LoRA 的原理是在原模型的权重矩阵旁边挂一个低秩分解矩阵，训练时只更新这个小矩阵，原权重冻结。这样可训练参数能降到原来的 0.1% 到 1%，显存占用大幅下降。QLoRA 更进一步，把原模型量化成 4-bit，进一步省显存，代价是推理速度略慢、精度略有损失。

选型上我的建议是：如果显存够（比如 3090 训 7B），优先用 LoRA 配 BF16，效果最稳；如果显存紧张或者想训更大的模型，用 QLoRA。LoRA 的秩（rank）一般设 8 到 64，秩越大表达能力越强但参数越多。我实测 7B 模型做领域适配，rank 设 16 到 32 就够了，再大收益递减。alpha 一般设成 rank 的两倍，这是社区的经验值。

还有一个关键参数是目标模块，也就是 LoRA 挂在哪些层上。最早 LoRA 只挂在 attention 的 q、v 上，后来发现挂在所有线性层（q、k、v、o、gate、up、down）效果更好。我实测下来，全挂比只挂 q、v 在领域任务上能提升 3 到 5 个百分点，代价是参数多了一点，但完全可接受。

3.3 训练配置与灾难性遗忘的规避

领域适配最大的风险是灾难性遗忘，也就是模型学会了领域知识却忘了通用能力。规避方法有几个：一是学习率要小，比预训练小一到两个数量级，我一般用 1e-4 到 2e-4；二是训练轮数要少，1 到 3 个 epoch 通常就够，多了容易过拟合；三是可以在训练数据里混入一部分通用数据，让模型保持通用能力。

我踩过的一个坑是：领域数据训了 5 个 epoch，领域问答确实变准了，但模型开始不会正常聊天了，问它"今天天气怎么样"都能扯到专业术语上。后来把 epoch 降到 2，学习率降到 1e-4，并在数据里混了 20% 的通用指令数据，问题就解决了。所以领域适配不是训得越久越好，要盯着验证集上的通用能力指标。

评估领域适配效果，我一般看三个维度：领域问答准确率、通用对话流畅度、以及生成内容的专业性。前两个用自动指标加人工抽检，第三个主要靠人工。如果领域准确率涨了但通用能力掉得厉害，说明适配过头了，要回调。

4. 评估与部署：让模型真正跑起来

训完模型只是第一步，能不能用起来才是关键。评估环节要回答"模型到底行不行"，部署环节要回答"怎么让它在生产环境跑"。这两步个人开发者往往做得比较粗糙，但恰恰是决定项目成败的地方。

4.1 自动指标与人工评估的配合

自动指标方面，困惑度（perplexity）是最基础的，但它只反映语言建模能力，不反映任务表现。任务相关的指标更实用，比如问答用准确率、F1，摘要用 ROUGE，翻译用 BLEU。但自动指标都有局限，尤其是生成任务，指标高不代表人看着好。

所以人工评估不可省。我的做法是准备一个 50 到 100 条的测试集，覆盖各种任务类型和难度，让模型生成结果，然后自己或找同事盲评打分。评分维度包括：准确性（内容对不对）、流畅性（读起来顺不顺）、相关性（有没有答非所问）。这个流程虽然土，但最能发现问题。我经常在人工评估时发现自动指标看不出来的问题，比如模型学会了讨好式回答，什么都说"好的"，但实际没解决问题。

还有一个技巧是对比评估，把适配前后的模型输出放一起，让人判断哪个更好。这样能直观看到适配带来的提升，也能发现适配引入的退化。

4.2 量化与推理加速的实操

部署阶段，量化是绕不开的。FP16 的 7B 模型占 14GB 显存，量化到 4-bit 只占 4GB 左右，能在消费级显卡上跑。常用的量化方案有 GPTQ、AWQ、GGUF 等。GPTQ 和 AWQ 适合 GPU 推理，GGUF 适合 CPU 或混合推理。我实测 4-bit 量化后，模型质量下降很小（人工评估几乎看不出），但显存占用和推理速度改善明显。

推理框架方面，vLLM 是目前吞吐最高的选择，它用 PagedAttention 管理 KV cache，并发能力强。如果只是本地测试，transformers 加 bitsandbytes 就够了。我一般开发阶段用 transformers 方便调试，部署阶段换 vLLM 提吞吐。这里要注意，量化后的模型和原模型在 tokenizer 和生成参数上可能有细微差异，切换时要重新验证。

4.3 服务化与接口设计

模型跑起来之后，要包装成服务才能被调用。最简单的方案是用 FastAPI 起一个 HTTP 服务，接收请求、调用模型、返回结果。要注意的几个点：一是并发处理，模型推理是计算密集型的，要用异步或队列避免阻塞；二是超时和限流，防止单个请求拖垮服务；三是流式输出，长文本生成时流式返回能大幅提升体验。

接口设计上，我建议对齐 OpenAI 的 API 格式，这样前端和工具链都能直接复用。请求参数包括 prompt、max_tokens、temperature、top_p 等，返回包括生成文本和 token 统计。如果要做 RAG（检索增强生成），还要在服务里集成向量检索，先检索相关文档再拼进 prompt。这块内容展开又是一大篇，这里先点到为止。

5. 个人开发者最容易踩的五个坑

这一节是我用血泪换来的经验，每一条都是实际踩过之后才明白的。写出来希望能帮你少走弯路。

5.1 数据质量比模型规模更重要

我一开始迷信"模型越大越好"，花了很多时间折腾大模型，结果发现用同样的数据，小模型加高质量数据的效果反而更好。后来才明白，在数据质量不过关的情况下，模型规模带来的收益会被数据噪声抵消。一条错误标注的数据，可能比十条正确数据的影响还大。所以个人开发者的精力应该优先花在数据上，清洗、去重、标注，这些脏活累活才是决定效果的关键。

5.2 学习率调度不是玄学

学习率调度看起来是玄学，其实有章可循。warmup 是为了让模型在训练初期稳定，cosine 衰减是为了后期精细收敛。我踩过的坑是 warmup 设得太短，模型前期震荡得厉害；或者衰减太快，模型还没学好就收敛了。经验值是 warmup 占总步数的 1% 到 5%，cosine 衰减到峰值的 10% 左右。如果训练不稳定，先检查学习率和 warmup，八成是这里的问题。

5.3 checkpoint 管理要趁早

训练中断是常态，3090 跑几天难免遇到断电、OOM、系统更新。我一开始没做 checkpoint 管理，一次意外中断损失了三天的训练。后来养成了习惯：每 N 步存一次 checkpoint，保留最近几个加最优的几个，checkpoint 里记录步数、loss、优化器状态，方便断点续训。另外要把 checkpoint 存到独立的盘上，别和训练数据放一起，避免磁盘满了把数据也搞坏。

5.4 评估集不能拿来调参

这是最隐蔽的坑。我一开始把评估集当验证集用，反复在评估集上调参，结果模型在评估集上表现很好，一到真实场景就拉胯。后来才明白，评估集一旦被用来调参，就不再是评估集了。正确做法是分三份：训练集、验证集（调参用）、测试集（只在最后用一次）。测试集的结果才是模型真实能力的反映。

5.5 部署不是训练的附属品

很多人训完模型就以为大功告成，结果部署时发现各种问题：显存不够、延迟太高、并发上不去。部署是独立的工程问题，要提前规划。我的建议是训练阶段就考虑部署约束，比如目标部署环境有多少显存、能接受多大延迟，据此决定模型规模和量化方案。别训完了才发现部署不了，那就白干了。

6. 从单卡实践到持续迭代的路线图

走完一遍全流程之后，接下来就是持续迭代。个人开发者的优势是灵活，可以快速试错，但要避免盲目折腾。我给自己定的路线图是这样的：先把一个垂直领域的适配做深做透，形成可复用的数据管线和训练脚本；然后横向扩展到相邻领域，验证方法的通用性；最后把整个流程工具化，降低每次实验的成本。

具体来说，第一阶段聚焦一个领域，把数据、训练、评估、部署全部跑通，产出一个能用的模型。第二阶段把这套流程抽象成配置驱动的脚本，换领域只需要换数据和配置。第三阶段考虑多模型对比、A/B 测试、持续学习等进阶话题。这个路线图不追求快，追求的是每一步都扎实，积累下来的工程能力比单个模型更有价值。

我个人在实际操作中的体会是，LLM 全流程实践最大的收获不是训出了多好的模型，而是建立了一套对模型行为的直觉。知道什么数据会带来什么效果、什么参数会影响什么指标、什么场景会遇到什么问题，这种直觉是看多少篇论文都换不来的。所以如果你也想动手，别纠结于算力够不够、模型大不大，先跑起来，在做的过程中理解，比什么都强。