企业官网建设流程全解析

Puro-2B 这个项目最有价值的点，不是它做了一个新的 2B 模型，而是它把一个完整的训练流程压进了一张 RTX 5090，总预算控制在 5090 美元左右。听到这里很多人的第一反应是：5090 本来就贵，算什么 Poor Lab？但如果你对比的对象是 A100、H100，或者八卡服务器整机，"穷实验室"这个说法其实非常准确。

这篇文章不吹这个方案多神，而是按实际落地顺序拆一遍：用一张高端消费级显卡训练 2B 模型，硬件和软件怎么规划，数据怎么准备，训练参数怎么设，训练中卡住或爆显存怎么排查，以及最后这笔钱到底花得值不值。

1. 先搞清楚：在单卡上训练 2B 模型，到底在训练什么

1.1 2B 为什么是单卡训练的甜点区

模型参数量的选择不是越大越好，而是要看你的显卡、数据和目标是否匹配。2B 这个量级正好处在甜点区：比 0.5B、1B 拥有更强的语言理解和指令跟随能力，又不像 7B 那样，全参微调时对显存和训练时间的要求直接上升一个台阶。

以 32GB 显存的 RTX 5090 为例，全参微调一个 2B 模型，权重、梯度和优化器状态加起来大约需要 24GB 左右。这意味着在不开复杂并行、不依赖多卡通信的情况下，单卡就能装下，再把序列长度和 batch size 控制住，训练是可以稳定跑完的。

如果换成 7B 模型，全参微调在同样显存下就非常紧张，通常要引入 LoRA、量化、梯度卸载或者多卡并行。这些手段不是不能用，但调试成本明显增加。2B 的价值就在这里：用最朴素的训练方式，也能把流程跑通。

1.2 Puro-2B 的底座：为什么选 Qwen2-1.5B

从项目名称看，Puro-2B 不是从零训练的新模型，而是基于 Qwen2-1.5B 这个开源底座继续往下做。Qwen2-1.5B 本身就是经过大规模预训练的中英文底座，语法、常识和基础推理能力已经具备，没必要从随机初始化开始。

在这个底座上继续训练，通常分两类：

• 继续预训练：在特定领域语料上继续训练，让模型学会领域内的术语、表达方式和知识结构，但模型的对话形式不变。
• 指令微调（SFT）：用问答对、任务描述、输入输出样本来训练，让模型学会按照指令完成任务。

Puro-2B 的命名意味着最终得到一个约 2B 参数量的模型。相比原始底座，它可能在某个领域上更专精，或者在指令跟随能力上做了定向优化。这种"站在开源底座肩膀上做增量"的做法，是目前小团队做垂直模型最成熟的路线。

1.3 你真正想做的是哪种训练

动手之前，先问自己一个问题：我要做的是哪种训练？

如果你希望模型变成某个垂直领域的"半个专家"，比如法律、医疗、客服，那应该以继续预训练为主，配合少量指令微调。如果你希望模型快速具备某种行为模式，比如写周报、整理 JSON、做信息抽取，那直接做 SFT 就够了。

最不推荐的是从零训练一个 2B 模型。即便数据量足够，单卡训练的时间和能耗成本也会非常高，而且最终效果大概率不如在 Qwen 这类成熟底座上继续训练。Puro-2B 这个项目真正传递的思路，就是聪明地站在现有底座上，用有限的算力做增量。

2. 硬件与软件环境：一张 5090 怎么撑起整个训练

2.1 整机配置不只是显卡

很多人以为训练大模型只买显卡就行，实际跑起来才发现瓶颈在别处。以 RTX 5090 为核心配置整机时，有几个部件不能省。

内存建议 64GB 起步，最好上 128GB。训练过程中要加载数据集、做 tokenization、缓存放中间结果，数据量大时内存不够会直接拖慢速度，甚至触发进程被杀。CPU 不用太顶级，但主板要能稳定支持 PCIe 通道和供电，电源建议选择高瓦数型号，因为训练时显卡满载运行，整机功耗会明显上升。

存储建议 NVMe SSD，容量 2TB 以上。训练数据、模型检查点、日志这些文件在训练期间会反复读写，机械硬盘的随机读写速度会成为瓶颈。如果你的数据集有几千万条样本，SSD 和 HDD 的差距会在数据加载阶段被成倍放大。

散热也要认真对待。连续几天满载训练，显卡温度和机箱风道都会影响稳定性。有条件的话，做好机箱风道规划，训练前先跑一个小时的满载压力测试，确认温度不再异常攀升再上正式任务。

2.2 软件栈选型

软件环境本身不复杂，核心是 Python 加 PyTorch，再加 HuggingFace 生态。需要装的东西包括：

• Python 3.10 或更高版本
• PyTorch，注意匹配 CUDA 版本
• Transformers、Accelerate、PEFT
• bitsandbytes，用于量化优化器
• DeepSpeed 或 LLaMA-Factory 这类训练框架

这里容易踩坑的是版本匹配。PyTorch 和 CUDA 版本不匹配，训练代码可能根本跑不起来，或者提示算子不存在。建议先看一眼显卡驱动支持的 CUDA 版本，再安装对应版本的 PyTorch，不要直接装最新版就以为万事大吉。

新手我比较推荐直接用 LLaMA-Factory，它把数据格式、训练方式、LoRA 和全参微调都封装好了，配置文件写清楚就能跑。如果你希望更好地理解训练机制，可以用 Transformers 加 Accelerate 自己写训练脚本，但调试成本更高。第一次跑通，选更省心的工具更重要。

2.3 先算显存，再跑代码

显存规划是单卡训练里最值得先做的一件事。以 2B 模型全参微调为例，粗略估算：

• 模型权重用 bf16 存储：约 4GB
• 梯度：约 4GB
• AdamW 优化器状态：fp32 优化器需要两份动量加一份参数副本，约 16GB
• 激活值：取决于序列长度和 batch size

前三项加起来大约 24GB，还没算激活值。这意味着如果不做任何优化，32GB 显存只剩 8GB 给激活值，一个 4096 序列长度、batch size 4 的训练任务就可能爆显存。

解决办法是组合使用这些手段：

• 开启梯度检查点，牺牲少量计算速度换取显存释放
• 降低 batch size，用梯度累积模拟大 batch
• 序列长度从 4096 降到 2048
• 使用 8 位优化器，把优化器状态从 16GB 压到 4GB 左右

如果选择 LoRA，显存压力会小很多。基础模型权重固定不动，只需要训练一个很小的适配器，优化器状态只针对适配器计算，整个训练占用通常在 12GB 到 16GB 之间。新手起步阶段，LoRA 是更稳妥的选择。

3. 数据准备比模型训练更值得花时间

3.1 数据从哪里来

数据是模型效果的天花板。同等参数量下，喂进去的数据质量直接决定最终输出质量。单卡训练的算力有限，数据量不能无限大，所以更要走"小而精"的路线。

继续预训练的数据来源可以是公开领域语料、你的私有文档、行业知识库、技术文档等。指令微调的数据来源可以是公开 SFT 数据集，也可以根据业务场景自己构造。自己构造时要注意格式一致性，比如统一的问题字段、输入字段、输出字段。

有一个红线要提前处理：版权和隐私。使用未授权的数据训练模型，发布时可能面临法律风险。内部研究问题不大，但如果你打算公开模型权重，数据来源一定要干净。这个环节不能偷懒。

3.2 清洗和去重

原始数据几乎不能直接使用。常见问题包括：网页残留标签、重复句子、过短片段、全英文混杂、日志或者乱码。如果直接训练这些数据，模型生成的文本会包含大量垃圾字符，甚至出现重复输出。

我的处理顺序一般是：

• 去掉明显噪声：HTML 标签、URL、特殊符号、控制字符
• 长度过滤：太短的样本通常信息量低，比如小于 50 个字符的直接丢弃
• 去重：按句子或段落做 MinHash 去重，尤其是从开源数据集拼接的数据，重复率往往很高
• 语言过滤：如果模型只面向中文，可以把纯英文占比过高的样本筛掉
• 敏感内容过滤：涉及违法违规的内容直接清除

清洗完之后，建议再统计一遍 token 数，确认数据总量在合理范围。2B 模型的继续预训练，一般不需要几百亿 token，几亿到几十亿 token 已经是一个合理区间，具体取决于你想让模型"学"多少新知识。

3.3 数据格式和序列长度

不同的训练框架对数据格式要求不同。使用 LLaMA-Factory 时，SFT 数据通常是 JSON 或 JSONL 格式，每个样本包含指令、输入、输出字段。继续预训练则直接使用纯文本语料，会按行切割并打包成序列。

序列长度建议设为 2048 或 4096。序列越长，单条样本覆盖的上下文越多，但显存占用也越高。如果数据里有大量长文档，建议把文档按段落切分，而不是直接截断，避免丢失太多语义。训练时可以用"packing"策略，把多个短样本拼接到一个序列里，减少 padding 带来的算力浪费。

4. 训练配置与参数：从能跑到跑稳

4.1 全参微调还是 LoRA

这是单卡训练最先要做的技术选择。我把两者的特点列出来，你在选之前先看自己的目标和显存余量。

我的建议是：第一次跑实验，先用 LoRA 把流程走通，确认数据、损失、输出都正常。然后再决定要不要全参微调。直接上全参微调，一旦参数设置不合理，很容易出现 loss 不降或者模型崩溃的情况，排查起来更麻烦。

4.2 核心参数怎么设

训练 2B 模型时，最需要关注的参数有几个。

学习率：全参微调一般从 2e-5 到 5e-5 起步；LoRA 可以从 1e-4 到 3e-4 起步。继续预训练建议比 SFT 更低一点，因为模型已经具备基础能力，学习率太大容易破坏原有知识。

batch size：受显存限制，单卡 batch size 通常只能设 1 到 8。为了模拟更大的有效 batch，使用梯度累积。比如实际 batch size 为 2，累积 16 步，等效 batch size 就是 32。梯度累积不是越大越好，过大的有效 batch 会让模型收敛变慢。

epoch：SFT 一般 1 到 3 轮就够，继续预训练通常 1 轮到 2 轮。小模型在小数据上反复跑很多轮，很容易过拟合。

warmup：前几百步先让学习率从零慢慢爬升，可以避免训练初期 loss 剧烈震荡。一般设置总步数的 3% 到 10%。

训练精度：优先使用 bf16。bf16 的动态范围比 fp16 更大，不容易出现梯度溢出，对训练稳定性更友好。

序列长度：建议 2048 起步。如果显存充足，可以尝试 4096，但要评估显存占用和训练速度。

4.3 训练三步：小样、正式、断点续训

建议把训练流程拆成三步，不要一上来就跑全量数据。

第一步，小样验证。从数据集里随机抽 2000 到 5000 条样本，用目标配置跑 10 到 20 步。这一步要确认三件事：loss 正常下降、GPU 利用率和显存占用在合理范围、日志能正常输出。如果 loss 完全不降或者指标一直异常，先停下来排查数据和参数，而不是继续烧时间。

第二步，正式训练。确认小样没问题后，再跑全量数据集。训练时设置检查点保存策略，比如每 500 步保存一次，发生中断可以从最近的检查点续训。输出目录建议按日期和实验名组织，避免多个实验混在一起。

第三步，阶段性验证。不要等全部训练结束才看效果。建议训练到 1/3、1/2 时各做一次小规模生成测试，看看模型输出是否符合预期。如果早期输出已经有明显问题，越早停下来调整成本越低。

5. 训练稳定性与常见故障排查

5.1 常见现象和对策

单卡训练过程中，问题通常会以几种固定形式出现。先把现象列出来，再对症处理。

Loss 不下降。先看学习率是否过低，再看数据是否太乱，最后确认模型是否真的处于训练模式。很多时候不是参数问题，而是数据清洗不彻底。

Loss 突然飙升或者变为 NaN。常见原因是学习率过高、数据中出现异常长样本、或者 fp16 精度下梯度溢出。降到 bf16，降低学习率，检查数据里是否有超大文本块，通常能解决。

显存溢出（OOM）。这是最直接的报错。处理顺序是：先开梯度检查点，再降低 batch size，再降低序列长度，最后才考虑换 LoRA 或者引入 offload。不要一上来就把 batch 压到 1，因为有效训练效率会明显下降。

训练速度慢。先看 GPU 利用率，如果利用率长期在 50% 以下，大概率不是算力不够，而是数据加载太慢。检查数据读取路径、dataloader 的 num_workers、是否在做无关的 CPU 预处理。

5.2 排查顺序

遇到问题，我建议按这个顺序排查，不要跳步。

先看现象和数据。训练日志有没有明确报错？数据格式是否符合框架要求？路径是否存在？文件编码是否有问题？很多看似玄学的 bug，最后都是路径、权限或编码问题。

再看环境。CUDA 版本和 PyTorch 是否匹配，显存是否被其他进程占用，磁盘空间是否不足，主板供电是否稳定。连续训练几天后出现卡死，先查温度和磁盘写满。

再看参数。学习率、batch size、梯度累积、序列长度，检查是否和你的显存以及数据规模匹配。参数设置没有绝对正确的值，但要有合理的初始范围。

最后再怀疑模型和框架。确认模型加载的是你期望的底座，确认没有加载错误的检查点，确认框架版本不存在已知 bug。单卡训练的场景比较简单，绝大多数问题都出在前面三环。

6. 评估、成本与这条路的适用边界

6.1 模型效果怎么评估

训练结束不代表工作完成。你需要一套评估标准来判断模型是否可用。

最直接的评估方式是做领域测试集。如果你做的是法律问答，就准备一份包含标准答案的法律问题集；如果你做的是文本摘要，就准备一批摘要测试样本。把这套测试集固定下来，训练前后、多个检查点之间用同一套标准比较。

常见的客观指标包括：困惑度（Perplexity）、准确率、ROUGE、BERTScore 等。这些指标适合快速横向对比，但不能完全替代人工评估。生成类任务建议每次抽取几十条样本，人工看输出是否符合预期、有没有幻觉、有没有重复、有没有格式错误。

这里要补一句：小模型的幻觉问题比大模型更明显。2B 模型不会因为你在单卡上训练过就拥有更强的知识储备，遇到超出数据范围的提问，它更倾向于编造看起来合理的答案。做应用时要在提示词或后处理环节加入兜底机制。

6.2 成本核算：5090 美元到底花在哪

Puro-2B 项目名里的 "within $5090" 很有意思，预算数字刚好和显卡型号撞上。真实场景中，5000 美元左右的预算要覆盖显卡、整机配件、电费和时间成本。

显卡是大头，但整机其他部件也不便宜。算下来，这套投入对比租云 GPU 有两个明显优势：第一，长期反复训练时，本地硬件没有按时计费的压力；第二，数据完全留在本地，不用上传到云端，适合对数据保密有要求的场景。

反过来，如果你只跑一次实验，跑完就结束，租云端显卡可能更划算。云 GPU 可以按小时租，遇到高需求场景临时加卡也方便。单卡训练的劣势在于扩展性：同一时间只能跑一个实验，模型规模也被显存锁死。如果团队有多个并行任务，本地单卡方案就捉襟见肘了。

6.3 这条路什么时候该走，什么时候不该走

最后总结一下这条路的适用边界。

适合走这条路的情况包括：预算在几万美元以内；团队有一定工程能力，能处理数据清洗和训练脚本；数据涉及隐私或版权，不适合上传云端；需要高频迭代，比如每周训练一个新版模型；目标模型规模在 2B 到 4B 之间。

不适合走这条路的情况包括：你需要训练几十 B 甚至上百 B 的模型；训练数据量在千亿 token 级别；训练任务属于一次性实验，跑完就不用再跑；团队没有足够的人手处理本地硬件维护。这些场景下，租用集群或者直接用云平台提供的训练服务，反而更省钱、更省时间。

单卡训练 2B 模型，本就不是为了替代大规模算力方案。它解决的是另一个问题：让预算有限的人也有机会完整经历一遍训练流程，把一个开源的 1.5B 底座，在本地变成自己的 2B 模型。Puro-2B 的意义在于证明这条路可行，而你要做的，是判断自己是不是该走这条路的人。

如果决定走，建议从最小闭环开始：先准备一份干净的小数据集，用 LoRA 跑通一次完整训练，然后逐步扩大到全参微调和更长序列。把前面每一步都跑稳，比一上来就追求最大参数和最大数据量要可靠得多。