由于 ChatGPT 和 GPT4 兴起，如何让人人都用上这种大模型，是目前 AI 领域最活跃的事情。当下开源的 LLM（Large language model）非常多，可谓是百模大战。面对诸多开源本地模型，根据自己的需求，选择适合自己的基座模型和参数量很重要。选择完后需要对训练数据进行预处理，往往这一步就难住很多同学，无从下手，更别说 training。

然后再对模型进行 finetuning 来更好满足自己的下游任务。那么对于如果要训练一个专家模型。预训练也是必不可缺的工作。不管是预训练还是 finetuning（微调），无论选用何种方案，都避免不了训练中产生的灾难性遗忘问题，那么怎么减少和避免这种情况的发生，也是本文想讲的一个重点。对于推理，在 GPU 资源不富裕的情况，如何最小化的利用内存，提升推理效率，也是可以讨论的内容。

模型选择

先看一下最好的模型有哪些，以下数据是最新 LLM 排行，来自 UC 伯克利 [1]

当然这里前 3 名都闭源模型，后面开源模型，大多数也都是英文的模型。如果 GPU 资源充足（至少 A100*8），这里也可以基于开源模型做中文的预训练，最后再 finetuning 。但我们没有 GPU 资源， 我们可以选择开源的中文模型直接做微调。

具体有哪些中文模型可以选择，可以参考这两个地址 中文语言理解测评基准（CLUE）[2] 和 SuperCLUE 琅琊榜 [3]。开源领域 ChatGLM，LLAMA，RWKV 主要就是这 3 种模型， 中文好一点就是 ChatGLM，潜力最好的就是 LLAMA，RNN 架构决定 RWKV 有很好的推理效率（随输入长度内存占比线性自增，而 LLAMA 则是指数增加） 和 Length Extrapolation （关于长度外推性，可以参考苏神的文章 [4]）。

当然 MPT-7B-StoryWriter-65k+ [5] 模型也有较长的外推能力，主要在于，注意力这块使用了 ALIBI [6]。要拥有什么样的长度，取决你的需求。对于对话模型，往往不需要那么长的外推能力。但对于想做知识库领域相关的应用， 需要模型能够看更多的内容，是有这个需求的。

这里不做推荐，一切来自你的具体需求和 GPU 资源，不知道怎么样选择，可以将您的需求和资源情况留言，我给你做一个选择。

模型大小选择

当然对于模型参数的选择，往往是参数越大效果越好。如果资源充足，当然是推荐 30B 以上的模型。不管是 6B, 7B 和 13B 同样的训练数据，同样训练参数，模型参数量大效果则优于低参数的模型。那么根据模型参数，如何预估我们的训练所需的内存开销，这里有一个简单的方法 比如 6B 模型，60 亿规模参数，根据以下公式计算：

模型参数 + 梯度参数 + 优化器参数 = 6B * 1bytes + 6GB + 2*6GB = 24GB

以上是全量预训练，当然如果采用 lora 这种方法，则会有更低内存占用。当然我们还可以对模型进行量化，来提高内存效率。

注意：参数多量化低的模型要优于参数低量化高的模型，举例 ：33B-fb4 模型要优于 13b-fb16 模型.

数据处理

对于 LLM 训练，数据质量很重要。预训练时，我们可以将数据先进行预处理，比如对数据进行一定规则的筛选，数据去重，去除一些低质量的数据。同时，我们可能面临各种类型的数据，PDF，Word，HTML，代码文件等等，对于这种不同类型的数据我们需要都处理成文本，同时还过滤掉一些干扰项或乱码的数据。

当然，我们也可以利用一些工具去处理，比如 justext [7]，trafilatura [8]，来提取文档主要内容，减少数据的噪音。对于空的文档或文档长度低于 100 进行过滤，进一步减少噪音。

对于一些机器生成的文本或 OCR 识别错误的文本，质量不高，由没有什么逻辑性，虽然比较难以检测，但是还是会有一些工具能做这样的事情，比如 ctrl-detector [9]。当然对于一些有毒的或带有偏见的数据，可以采用 PerspectiveAPI [10] 或垃圾邮件检测的办法来过滤。

我们还不得不考虑数据的一些隐私风险，也需要考虑，比如身份证号，银行卡等信息，比如 presidio 和 pii-codex 等工具提供了检测、分析和处理文本数据中的个人身份信息的能力。

指令微调数据，我们可以使用 PromptSource [11] 来创建微调数据。当然我们还可以让 GPT4 给我们标注一些数据，这样蒸馏知识，可以让数据质量进一步提升。这里我分享一个我使用的 Prompt 工程：

first_prompt = """
作为一位专业的xxxx，您的任务是从给定的上下文回答问题。
给定的上下文：
"""
last_prompt = """
请综合上述信息，你给出的回复需要包含以下三个字段：
1.questions: 基于上下文内容，提出与这个内容相关的问题，至少两个以上。
2.answers: 然后根据问题，分别给出每个问题的答案，请用 markdown 格式。
3.instruction: 给出上下文内容的总结，尽量精简，用 markdown 格式。
请按照以下JSON格式来回答：
前括号
      "questions": [
          "<内容相关问题1>",
          "<内容相关问题2>"
      ],
      "answers": [
           "<内容相关问题1的答案>",
           "<内容相关问题2的答案>"
      ],
      instruction: "<总结性的内容>"
后括号
注意：如果碰到上下文内容信息不够，无法回答问题的情况，answers和questions可以返回空。
最后强调一下：你的回复将直接用于javascript的JSON.parse解析，所以注意一定要以标准的JSON格式做回答，不要包含任何其他非JSON内容，否则你将被扣分！！！
"""

微调方案

目前对于 LLM 微调方案有很多，我将常用的一些方案和相关资料做一个列举。

根据实际经验，这里推荐采用 Lora 或 QLora。简单介绍一下 QLoRA，重点改进是将模型采用 4bit 量化后加载，训练时把数值反量化到 bf16 后进行训练，利用 LoRA 可以锁定原模型参数不参与训练，只训练少量 LoRA 参数的特性使得训练所需的显存大大减少。例如 33B 的 LLaMA 模型经过这种方式可以在 24GB 的显卡上训练，也就是说消费级单卡都可以实现，大大降低了微调的门槛。

英文模型需要做词表扩充吗？

对于像 LLaMA 模型的词表大小是 32K，其主要针对英语进行训练（具体详见 LLaMA 论文 [15]），对多语种支持不是特别理想（可以对比一下多语言经典模型 XLM-R 的词表大小为 250K）。

通过初步统计发现，LLaMA 词表中仅包含很少的中文字符，所以在切词时会把中文切地更碎，需要多个 byte token 才能拼成一个完整的汉字，进而导致信息密度降低。比如，在扩展词表后的模型中，单个汉字倾向于被切成 1 个 token，而在 LLaMA 中可能就需要 2-3 个才能组合成一个汉字，显著降低模型的推理效率。

如何避免灾难遗忘

通常我们有以下方式，可以减少或避免灾难性遗忘问题

推理加速

对于推理，一般我们采用量化方案，这里有两个办法。第一个则是采用 ggml 工具，比如 llama.cpp [18] 针对 llama 模型，将模型量化运行在 cpu 或 gpu 上，也可以 cpu 和 gpu 一起跑，内存则大大减少，推理速度有极大的提高。

▲ image.png

这里如果将 llama.cpp 运行在 gpu 上， 编译时一定要加 LLAMA_CUBLAS=1，同时推理的时候，指定 --gpu-layers|-ngl 来分配运行在 gpu 上的层数，当然越大，占用 gpu 的内存会越多。

如果是 RWKV 模型，则考虑采用 rwkv.cpp [19]，此方法与 llama.cpp 类似，使用方式也是类似的。

还有 Llama 模型还可以考虑使用 exllama [20] 纯 GPU 的加速，虽然还不够完善，但也可以值得一试。

另一个，采用 LLM Accelerator [21]，LLM 存在大量的相似性推理，基于此，可以做一些优化加速推理，具体请看论文。最后采用架构上的调整，faster transformer [22] 要优于传统的 transformer 架构。

总结

最后总结几条原则：

技术交流群