企业官网建设流程全解析

1. 先搞清楚 QAT、全量微调和 LoRA 到底在解决什么问题

我先把结论放在前面：量化感知训练、全量微调、LoRA 微调，这三者不是互斥关系，而是大模型落地链路里不同环节的不同手段。很多人一上来就问“该选 QAT 还是 LoRA”，这个问法本身就有点偏，因为 QAT 关心的是模型怎么压缩、推理怎么变快；LoRA 关心的是在有限算力下怎么把模型调整成适合自己业务的版本；全量微调则适合那些算力和数据都充足、需要把模型整体能力都改变的场景。

而 AgentRAG、Embedding 模型、LLaMA-Factory 这些东西拼在一起，其实是一条非常典型的真实工程链路：先用 Embedding 模型把私域知识库变成可检索的向量，再通过 RAG 让 Agent 能够引用外部资料回答问题，最后用 LLaMA-Factory 对底座模型做微调，把模型的表达风格、领域知识或工具调用能力修正到更贴业务的状态。跑完整条链路之后，如果还要做大规模部署，再把量化压缩提上来，QAT 才真正派上用场。

这篇文章我会按实际落地顺序拆：先说清楚全量微调和 LoRA 微调怎么选、为什么 LoRA 在大多数个人和中小团队场景里更现实，再说 QAT 和普通量化有什么区别、什么时候值得做，最后把 AgentRAG 和 Embedding 模型在这条链路里的位置讲透，并且给出基于 LLaMA-Factory 的一套可复现流程。不是只列概念，是每一步都告诉你先做什么、看什么、遇到问题往哪个方向查。

适合看的读者很明确：已经用过大模型 API，想转本地微调但不知道从全量还是 LoRA 入手的人；手里有一批业务文档，想搭 AgentRAG 但还没把 Embedding 和微调的关系理顺的人；以及模型已经能跑，但部署时发现显存或推理速度不够，开始考虑量化的工程师。如果你只是想快速产出一篇“大模型科普”，这篇也能帮你把概念理清，但真正的价值在后面的实操边界和坑点里。

2. 全量微调与 LoRA 微调：先选对路线，再谈参数

2.1 全量微调的适用场景和真实成本

全量微调，通俗讲就是把整个模型的全部权重都放进训练流程里更新。这种做法的好处是模型能力调整空间最大。如果业务场景需要模型学会一种全新的语言风格、改变对某个领域的整体判断逻辑，或者需要把大量新知识稳定压进模型内部，全量微调通常是能达到的路径。

但全量微调的代价也非常直接。首先是显存门槛。一个 7B 参数的模型，光权重按 FP16 存就是大约 14GB，但训练过程中还要额外存放优化器状态、梯度、激活值。实际经验是，7B 模型做全量微调，单卡至少准备 40GB 以上可用显存才比较稳。如果是 13B 或 70B，那就需要多卡并行和更复杂的内存调度方案。很多个人开发和中小团队不是买不起一张大显存卡，而是整套流程里的数据存储、多卡通信、容错恢复都会跟着变复杂。

其次是数据要求。全量微调会把模型原本的一部分能力也可能改动掉，这对数据质量和分布提出很高要求。如果你只有几百条样本，全量微调很容易过拟合，而且可能把模型在通用任务上的能力拉低，这就是所谓的灾难性遗忘。我自己见过一个项目，团队拿两万条客服对话做了全量微调，跑完之后垂直场景的效果确实提升，但写代码、做通用问答的体验明显下降，最后不得不重新混入大量通用数据做恢复。

所以我的建议是，在以下条件里至少满足大半，再考虑全量微调：

• 有足够的高质量垂直数据，至少数万条级别。
• 有稳定的多卡环境或单卡 40GB 以上显存。
• 愿意承担长时间训练和多轮实验的成本。
• 业务确实需要模型整体能力发生结构性变化。

如果只是让模型“更懂某类文档”“回答更口语化”“学会按固定格式输出”，全量微调往往不是首选。

2.2 LoRA 微调为什么更适合多数业务场景

LoRA 的核心思路是在不修改原模型权重的前提下，在旁边增加少量低秩矩阵来学习任务变化。训练完以后，原来的模型主体完全不变，只保存一个很小的低秩权重文件。这个文件通常只有几十到几百兆，比动辄十几GB 的完整权重小得多。

因为大部分模型权重被冻结，LoRA 微调需要更新的参数量非常少，显存占用、训练时长和数据需求都会明显下降。实际测试中，一张 24GB 显存的显卡跑 7B 模型 LoRA 微调是可行的，很多 16GB 显存的环境也能通过降低批次大小和序列长度来跑通。个人用 MacBook 跑一些小型模型的 LoRA 微调也有不少案例，只是训练速度会比较慢，更适合做小规模验证。

LoRA 的另一个实际好处是灵活。同一个底座模型可以训练多个不同的 LoRA 适配器，分别对应不同业务场景。比如你可以用一个基础模型，一套 LoRA 负责法律问答，另一套 LoRA 负责营销文案，推理时按场景加载对应适配器。这样就不需要为每个场景都保留一份完整模型，维护成本低很多。

需要提醒的是，LoRA 微调不是万能药。如果业务需要模型掌握大量全新知识，低秩矩阵的容量可能不够。打个比方：全量微调像是把整本书重写一遍，LoRA 像在书页边缘做一批高质量批注。批注可以帮你更快找到重点，但不能凭空把一本技术手册变成一本长篇小说。所以垂直领域有明显知识缺口时，优先考虑用 RAG 补齐外部知识，而不是把所有压力都给 LoRA。

2.3 微调前必须先想清楚的几个问题

很多人拿到模型就开始调参数，这是最忌讳的。我建议在启动任何微调任务之前，先写下一份很短的需求确认单：

• 你希望模型改进的到底是什么？是输出格式、回答风格、指令跟随，还是领域知识？
• 这些改进更适合用提示词工程、RAG 检索，还是必须通过微调来实现？
• 你的数据有多少条？每条的输入和期望输出是否一致？
• 你希望微调后的模型只在当前任务上更准，还是要保留通用能力？
• 你打算怎么保存和部署最终产物？是完整权重、LoRA 适配器，还是量化后的模型？

这些问题的答案决定了下面每一步的配置。比如数据量很少，就不该直接上大学习率跑很多轮；如果只改输出格式，用几百条高质量样本 + LoRA 可能就够了；如果涉及大量私域知识，就应该先搭知识库和 RAG，再考虑微调优化表达。

3. QAT 量化感知训练：部署提速前必须理解的压缩手段

3.1 普通量化和 QAT 之间差了什么

模型训练完成之后，直接拿 FP16 或 FP32 权重做推理，显存占用大、速度慢。量化简单说就是把模型里的浮点数从 16 位或 32 位压缩到 8 位甚至 4 位，从而减少显存占用和计算量。量化又分成训练后量化和量化感知训练两种常见路线，二者的差别非常关键。

训练后量化是模型已经训练好了，再做一次数值映射。它的优点是实现简单，很多时候一行配置就能跑通，不需要重新训练。缺点也很明显：模型原本在浮点精度下学到的权重分布，在压缩到低比特后会出现精度损失。对于分布比较规整的模型，训练后量化可能损失不大；但一旦模型里某些层对数值很敏感，输出质量会明显下降。

QAT 的思路则是在训练阶段就把量化过程模拟进去。它不是等模型训完才去压缩，而是在前向计算时故意把权重和激活量化到目标位宽，让模型在训练过程中逐步适应低比特数值带来的误差。这样最终部署时再转成真正的低比特模型，精度损失会小很多。

如果只是个人学习或者对部署资源不敏感，训练后量化已经能在很多情况下满足需求。但如果是产品化部署，尤其模型需要长时间稳定运行、输出质量要求较高的场景，QAT 更值得关注。它用多一次训练准备，换来了部署后更稳的推理表现。

3.2 QAT 在什么时候值得做

我见过不少团队的落地路径是这样的：先全量微调或者 LoRA 微调，得到一个效果满意的模型，然后直接做训练后量化，结果发现模型在某些测试例上开始胡言乱语或输出变差。这时再去查是哪一层出了问题，往往很费劲。如果一开始就带着量化感知做训练，这种问题会少很多。

以下几种情况我会认真考虑 QAT：

• 模型部署在边缘设备或低显存服务器，必须使用 4bit 或 8bit 表示。
• 业务对响应质量很敏感，不能接受量化后明显掉点。
• 已经确定量化方案是长期部署方式，不想每次发布都重新排查精度损失。
• 硬件对低比特计算有较好支持，量化后能真正拿到推理速度收益。

反过来，如果只是临时跑个 Demo，或者机器显存足够，不需要压到很低的位宽，先训练后量化就够了。QAT 毕竟要多做一轮带量化模拟的训练，耗时更长，数据准备和调参成本也更大。

3.3 QAT 和 LoRA 可以结合吗

可以。实际工程里，LoRA 微调后接 QAT 再导出低比特模型，是一条很常见的路线。先通过 LoRA 把模型业务能力调整到位，再把适配器合并回基础模型，然后做量化感知训练，最后导出适合推理框架的格式。

这个组合的好处是节约两头的成本：LoRA 阶段不需要全量更新所有参数，数据量和显存压力都小；QAT 阶段让模型提前适应低比特表示，避免部署时才暴露精度问题。需要注意的是，LoRA 训练完的适配器合并和量化脚本是有顺序的，先合并且确认输出正常，再做量化，不要跳步。

如果你用的是 LLaMA-Factory，它本身对 LoRA 训练和模型导出有比较完整的支持，可以在微调完成之后，先把 LoRA 权重合并进 Base Model，再进入量化环节。这样操作链路会清晰很多。

4. LLaMA-Factory 实操流程：从安装到 LoRA 微调

4.1 LLaMA-Factory 是什么，为什么用它

LLaMA-Factory 是一个大模型微调工具，它把多种模型的加载、数据集准备、训练参数配置、LoRA 和全量微调切换、模型导出等环节整合在一起，同时提供命令行和 WebUI 两种交互方式。对个人学习来说，WebUI 能降低上手门槛；对生产实践来说，命令行和脚本方式更容易固化流程。

它支持的主流底座模型范围比较广，包括 Qwen、Llama、Baichuan、ChatGLM 等常见系列。输入材料没有限定具体版本，所以我建议你落地前先确认当前版本和底座模型的兼容性，不要直接照搬网上旧的参数配置。

用 LLaMA-Factory 做微调，最核心的价值是可以快速对比不同策略。同一个数据集，你可以在里面分别跑全量微调、LoRA 微调，甚至 Freeze 微调。通过对比训练耗时、显存占用和评估集效果，能更快找到适合你业务的方案。

4.2 安装与环境准备

先说一个基本判断：LLaMA-Factory 本身是一个需要 Python 环境的工具，不要把它当成纯图形软件来理解。安装步骤通常是先建好 Python 虚拟环境，再按官方文档安装依赖，最后启动 WebUI 或命令行接口。

建议的前置条件：

• Linux 服务器优先，Windows 需要在 WSL 或 Docker 环境里运行，也可以用 Windows 原生跑一些小规模实验，但坑会多一些。
• 显存方面，LoRA 微调 7B 模型建议至少 16GB 到 24GB；全量微调则按前面说的要求准备。
• PyTorch 版本要配合 CUDA 版本安装，别直接装最新版了事。
• 磁盘空间要足够，底座模型下载通常需要十几GB 到几十GB，加上微调中产生的检查点，至少要预留模型体积两倍以上的空间。

原始材料没有给出具体版本号，这很正常，因为这类工具更新很快。正确做法是打开官方文档或项目仓库，查看当前推荐的 Python、PyTorch 和 CUDA 组合。我自己的习惯是先新建一个干净的 conda 环境，再安装依赖，避免跟其他项目冲突。

# 以下只是通用示例，具体命令要以官方文档为准 conda create -n llm-factory python=3.10 conda activate llm-factory pip install -r requirements.txt

环境装好后，先做一次小测试：加载一个很小的模型，跑一次推理。不要一上来就进入微调。很多启动失败其实是环境问题，比如 CUDA 版本不匹配、模型路径错误、依赖之间冲突。先跑通加载，再跑微调，能省很多排查时间。

4.3 数据准备是 LLaMA-Factory 微调的关键

LLaMA-Factory 对数据集格式有要求。一般要把数据整理成 JSON 或 JSONL 格式，每个样本包含指令、输入和输出等字段。不同来源的数据集模板可能略有差异，但对新手来说，最稳妥的是先找项目自带的示例数据集，把格式看清楚，再把自己的数据映射成同样结构。

我在实测里遇到过很多次这种情况：微调能跑，Loss 也在下降，但生成结果完全不按预期输出。最后排查下来，大部分原因是数据格式不对，比如把问题和参考答案放在同一个字段、输入输出混在一起，或者 dataset_info 配置里没有正确注册数据集。

所以数据处理这里要慢。先拿 10 条数据跑通流程，确认模型能正常记住这些样本。如果 10 条样本的格式都不对，几千条数据只会浪费更多算力。

4.4 LoRA 微调关键参数说明

以 LLaMA-Factory 的 WebUI 或命令行为例，LoRA 微调时你需要重点看的参数有这些：

• 模型名称和路径：确认加载的是基座模型还是 Chat 模型，不同底座对指令数据的适应程度不一样。
• 微调方法：选 LoRA，不是全量。
• LoRA 秩：秩越高，能学习的表达能力越强，但可训练参数也越多。常见尝试从 8、16、32 开始，不要一上来就设 128。
• 学习率：LoRA 微调通常建议从 1e-4 到 2e-4 这个范围起步，全量微调则常用 1e-5 到 2e-5。学习率太大容易训崩，太小训练速度慢。
• 批次大小：显存不够时，先把批次调小，比调低序列长度更优先。
• 训练轮数：数据质量高时，3 到 5 轮通常够用。轮数过多容易过拟合，Loss 很低不代表泛化很好。

LLaMA-Factory 页面上会显示显存占用和训练进度，这是你判断参数是否合理的最直观依据。如果显存直接被撑爆，日志会直接报错，那就把批次大小和序列长度往下降。

4.5 单条验证、批量训练与导出合并

微调完成后，不要直接进入部署。先用测试集做一轮单条推理，确认模型输出格式、风格、内容都符合预期。这里记住一个原则：先单条、再批量、最后才考虑并发和接口化。

如果单轮推理表现不错，再在更多测试样本上检查稳定性。尤其要看模型是否在无关问题上也正常工作，避免因为微调破坏通用能力。如果微调后输出明显变差，优先检查数据质量和轮数，而不是立刻调 LoRA 秩。

当 LoRA 训练结果稳定后，需要在 LLaMA-Factory 里做模型导出。导出时可以选择是否合并 LoRA 权重。如果后续还要做量化或部署到其他推理框架，一般先导出一个已经合并好的完整模型。导出完再重新加载，确认模型输出和训练时一致，才算这一步完成。

5. Embedding 模型与 AgentRAG：在微调之外补上知识短板

5.1 Embedding 模型解决的核心问题

大模型最让人头疼的一点是知识有截止日期，也缺少企业内部资料。你可以在提示词里塞一段背景资料，但提示词长度有限，而且每次把所有资料都放进去，成本和速度都不划算。Embedding 模型解决的就是“如何快速找到和当前问题最相关的资料片段”这个问题。

Embedding 模型会把文本转换成一串向量。语义相近的文本，它们的向量距离也更近。通过向量检索，系统可以先在知识库里找出最相关的几段文字，再把这些文字作为上下文交给大模型生成答案。这就是把海量知识先筛选成少量上下文的过程。

选择 Embedding 模型时，不能只看参数多少。你要关注的是它对中文的支持、对长文档的分块策略、检索的准确率，以及向量维度对后续存储和检索性能的影响。社区里常见做法是拿一组你自己的业务问题做小范围评测，把几条最可能被问到的问题在知识库里检索，看返回的结果是不是真的切题。

5.2 AgentRAG 里 Agent 和 RAG 是怎么配合的

RAG 的意思是检索增强生成。传统 RAG 流程通常比较固定：用户提问，系统检索相关文档，把文档拼进提示词，再让模型生成。AgentRAG 则在流程里加入了多步判断和工具调用。Agent 不是只做一次检索，而是先判断用户问题是否需要查知识库、需要查哪类知识，甚至可能需要多轮检索，或者在回答中引用多个来源。

这种设计更适合复杂问题。比如用户问“我们的产品退款政策里，哪些情况不支持退款，客服应该怎么回复”，简单 RAG 可能只检索到最像的一段政策文档，如果那段文档没写完全，回答就可能缺项。AgentRAG 可以先分解问题，分别检索“退款政策”和“客服回复规范”，再把两部分信息整合给模型。多轮检索、判断、汇总，这就是 Agent 在 RAG 流程里增加的价值。

实现 AgentRAG 不一定需要从零写复杂框架。你可以先用一个支持工具调用的模型，把知识库检索封装成一个工具函数，再让模型决定何时调用。搜索材料里提到了 DeepSeek Embedding 和 RAGFlow，这说明在中文场景里，选择合适的中文 Embedding 模型和 RAG 引擎，确实能让整体效果提升不少。但具体选用哪个，要结合你的数据量、部署环境和预算来定。

5.3 RAG 和微调怎么分工，不要重复造轮子

很多团队在建设大模型应用时会陷入一个误区：想用微调把所有业务知识都塞进模型，结果数据量不够，训完效果也不好。正确的思路是让 RAG 负责事实知识检索，让微调负责表达风格、输出格式和工具调用能力。

比如法律咨询场景：法律条文、公司内部案例，这些内容更新频繁、数量多，应该放进知识库，通过 Embedding 模型做检索，再交给大模型回答。但律师希望回答有固定的格式，开头说结论、中间给依据、结尾给免责提示，这种输出偏好可以用 LoRA 微调来强化。

从工程效率来看，RAG 改知识库内容只需要替换文档和重建索引，成本低、速度快。微调则要重新训练和评估，周期长。所以当知识发生变化时，优先更新 RAG 的知识库；当模型行为需要变化时，再考虑微调。二者互相配合，是更稳妥的架构设计。

6. AgentRAG + 微调 + 量化的完整落地顺序与检查清单

6.1 推荐的落地顺序

根据前面几个部分，一条完整的大模型应用落地链路可以拆成下面几个阶段。

第一阶段是搭底座环境。先选好基础模型，装好推理环境，确认单机推理能跑通。这一阶段的判断标准不是速度多快，而是模型能不能正常加载、输出是否稳定。

第二阶段是搭知识库和检索链路。把业务文档清洗、分块，用 Embedding 模型做向量化，搭起一个最小可用的检索接口。测试方式是拿几组真实业务问题去检索，人工判断召回结果是否准确。

第三阶段是决定要不要微调。如果模型的表达格式、风格、指令跟随需要调整，用 LLaMA-Factory 做 LoRA 微调。数据先小规模验证，再逐步放大。

第四阶段是接入 Agent 流程。把知识库检索封装成工具，让模型在主流程里能够调用工具、处理多轮检索。这一步要在微调后重新测一遍，因为微调可能轻微改变模型的工具调用能力。

第五阶段才是量化和部署。根据目标硬件资源，决定是训练后量化还是 QAT。先离线评估量化后模型的输出质量，再接入对外服务。

6.2 每个阶段怎么判断是否正常

判断标准不能只看“能跑”。能跑只是一个底线，每一阶段都要有自己的验收指标：

• 环境阶段：模型能成功加载，推理不报错，显存占用稳定。
• RAG 阶段：检索命中率、返回片段的相关性、回答是否引用了正确来源。
• 微调阶段：训练 Loss 收敛，测试集上输出格式和内容达到业务预期，同时不破坏通用能力。
• Agent 阶段：多轮对话中模型能在正确时机调用工具，不会在不需要检索时强行检索。
• 部署阶段：量化后的回答质量、延迟、吞吐、显存占用都符合目标。

如果某一阶段没达标，不要急着往下走。比如 RAG 检索本身就召不回正确文档，后面微调和 Agent 设计得再好，也不可能得到更好的答案。

6.3 一张可直接使用的排查清单

我自己排查这类链路问题时，会按照下面的顺序来看，效率比到处看报错日志要高很多。

先看输入侧。用户问题是否清晰，是否有错别字或歧义；文档是否被正确读取和分块；Embedding 模型是否支持当前语言和文档类型。

再看检索侧。查询向量和文档向量的匹配效果如何；分块大小是否合适；是否还有多轮检索的改进空间；知识库是否更新到了最新版本。

再看模型行为。模型的 Prompt 是否写清楚了；工具调用格式是否匹配；是否用了微调后的模型，还是误加载了基础模型；输出结果是否被后处理逻辑截断。

最后看资源侧。显存、内存、磁盘是否足够；推理队列是否堵塞；量化后的数值是否造成精度损失；日志里有没有反复出现的重试错误。

6.4 我最后想强调的几个边界

整套链路看着环节多，但每一步都可以拆开验证。不要试图一次把 AgentRAG、Embedding、微调、量化全部搭完再测试，那样出了问题你根本不知道该查哪一环。先跑通最小闭环，再逐步增加复杂度。

如果只是做学习验证，模型规模选 7B 左右即可，数据量从几百条开始，LoRA 秩设置在 16 左右，学习率用 1e-4 量级。如果你手头是 MacBook，内存够大也能跑一些小模型的 LoRA 微调，但一定要把训练轮数和序列长度控制住，否则等待时间会非常长。

如果要把这套方案放进生产，我的建议是：把索引构建、训练数据、微调参数、量化前后评测结果全部记录成文档。模型和工具版本都会更新，没有记录，几个月后你想复现当时的实验结果，会非常痛苦。真正的稳定不是代码不报错，而是每次变更之后，你都能清楚知道哪些结果变了、为什么变。