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 python3.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 微调但一定要把训练轮数和序列长度控制住否则等待时间会非常长。如果要把这套方案放进生产我的建议是把索引构建、训练数据、微调参数、量化前后评测结果全部记录成文档。模型和工具版本都会更新没有记录几个月后你想复现当时的实验结果会非常痛苦。真正的稳定不是代码不报错而是每次变更之后你都能清楚知道哪些结果变了、为什么变。