LoRA 训练怎么做：微调原理、QLoRA、部署与评估

如果已经有一套效果扎实的提示词，模型却仍反复出现风格、格式或任务判断错误，就可以考虑 LoRA 训练。它为每个需要适配的权重矩阵训练 2 个小矩阵，同时冻结原始权重；QLoRA 还会以 4-bit 精度存储冻结的基座模型。真正有价值的结果，是在你的任务上取得可衡量的改进，并通过合适的部署方案把改进保留下来。

文档与部署限制已于 2026 年 10 月 26 日核实。原理依据为最初的 LoRA 论文和 QLoRA 论文。

对开发者来说，是否微调，要从反复出现的错误出发。比如，客服模型的上下文里已经有正确的政策，却总是选错升级处理标签；写作助手理解了要求，却一再偏离既定的内容风格。这些都值得尝试微调。但如果模型不知道今天的退款政策，首先该做的是让它拿到这份政策。

LoRA 训练是什么？为什么只需微调少量参数？

LoRA 通过学习对指定权重矩阵的小幅修正，改变模型的行为。在常规 LoRA 训练中，原始矩阵保持冻结。权重矩阵可以理解为一张由模型学到的数值表，负责转换模型内部的信息；适配器则是一组额外学习的参数，用来调整这种转换。

可以把它想成给一栋建筑加装一个量身定制的入口模块：建筑主体保留，人员进出的方式发生变化。模块比整栋楼小得多，但仍依赖这栋楼。LoRA 适配器也是如此：它既不是完整的语言模型，也不能替代基座模型。

LoRA 的全称是 Low-Rank Adaptation（低秩适配）。它不直接学习一个与原权重矩阵同样大的更新矩阵，而是用两个更小矩阵的乘积表示更新，通常将这两个矩阵称为 A 和 B。在线性层中，实际变换可以写成 W + sBA：冻结的权重 W，加上经过缩放的适配器更新。输入分别经过基座路径和适配器路径，两路输出再相加。参见 LoRA 原始公式。

因此，适配器可以学会既定的输出格式，而不必为每个基座权重保存一份修改后的副本。这也意味着，基座模型本身必须已经适合这项任务。修正只能在所选模型的基础上发挥作用。

参数量算例：不能据此推算显存需求

假设某一层有 4,096 × 4,096 个权重，也就是 16,777,216 个原始参数。秩为 8 时，LoRA 的两个矩阵分别包含 8 × 4,096 和 4,096 × 8 个参数，合计 65,536 个可训练参数，约为原矩阵参数量的 0.39%。

这是我们根据论文中的矩阵形状做的计算，不是基准测试，也不是推荐的秩。它只描述一个被适配的矩阵。冻结的权重依然存在，训练还需要工作内存来存放中间计算结果、适配器梯度和优化器状态。优化器状态就是用来决定下一次训练更新的记录信息。

实际使用时，要区分更新多少参数和整个训练任务需要多少内存。适配器很小，不代表底层模型也变小了。

这些方法的区别依据 LoRA 和 QLoRA 论文。无论采用哪个名称，都不能保证它在你的数据上达到某种特定效果。

LoRA 微调参数怎么看：秩、目标模块与缩放

这些设置决定修正的规模和位置，不决定模型有多聪明。**秩（rank）**是 A、B 两个矩阵相乘时的内部维度，增大它会增加可训练参数。**目标模块（target modules）**指定给模型的哪些部分添加适配器。Alpha 控制更新的缩放，dropout 则可用于适配器训练的正则化。LoRA 配置参考定义了这些选项。

先从针对所选模型、持续维护的训练方案开始，只有验证结果给出理由时，再调整设置。如果模型混淆两类客服问题，应先检查标签是否矛盾、边界案例是否缺失。提高秩并不能告诉模型：相互矛盾的示例中，究竟哪一个才符合业务要求。

还要检查实际有哪些参数参与训练。某些配置除了适配器，还会训练输出头等额外模块。把一次训练称为“LoRA”，并不能说明只有 A 和 B 发生了变化；要看具体配置。

QLoRA 多做了什么？又没有解决什么？

QLoRA 不仅减少需要训练的参数，还处理冻结基座模型本身的内存占用。它的核心配置以 4-bit 形式存储基座，并通过基座计算训练精度更高的 LoRA 适配器。基座虽然被冻结，仍然参与学习适配器所需的计算。参见 QLoRA 论文。

论文结合了三种机制：NF4，一种为服从正态分布的权重设计的数值表示；双重量化（double quantization），用于压缩量化过程中的常数；以及分页优化器（paged optimizers），用于处理内存占用峰值。使用持续维护的 QLoRA 训练方案，并不需要自己实现这些机制。

“4-bit 训练”很容易让人误解。它不表示每一次计算、每个激活值和每个适配器参数都使用四位精度，也不表示训练所需内存与仅加载量化权重时相同。更长的样本和更大的批次依然会消耗工作内存。

如果障碍在于基座模型的内存占用，且训练栈支持所需模型，可以选择 QLoRA。如果常规 LoRA 已经能装得下，就用验证样例比较两者，不要默认量化一定更好。压缩会改变数值计算条件，它对任务的影响需要通过评估确认。

我们的 LLM 量化指南讨论的是另一个部署问题：推理引擎能执行哪种压缩表示。训练出一个 QLoRA 适配器，并不意味着它能兼容所有量化部署格式。

什么时候该微调，什么时候继续用提示词或 RAG？

当剩余问题是稳定出现的行为错误，而且能用审核通过的示例说明正确做法时，可以微调。如果清晰的指令已经满足要求，就继续用提示词。需要在请求时提供相关文档或数据库事实，则使用检索增强生成（RAG）。更完整的选择框架见 RAG 与微调如何取舍。

对于统一内容风格，先尝试在提示词中加入简明的风格规范和有代表性的示例。只有目标风格已经确定，而且模型面对不同输入仍反复违反同样的规则时，才考虑训练。示例应教会模型做选择，例如先给答案，或避免没有依据的极限词，而不是反复背诵一句口号。

对于输出格式，要分清语法和语义。如果运行时支持受约束的结构化输出，应先测试它，不必为了生成合法 JSON 就直接训练。输出可能符合 schema，却选错了类别。当持续出错的是这种语义判断时，LoRA 才更值得尝试。即使适配器带来了改进，也要保留应用层校验。

对于范围明确的任务，要先定义决策边界。用户不认识某笔扣款，可能需要先核验账户；如果已经确认是重复付款，则需要账单复核。用审核通过的输入输出样例训练这种区别，并纳入需要进一步澄清的情况。目标是让某类决策更稳定、更准确，而不是笼统地宣称模型变聪明了。

对于持续变化的知识，检索仍是更清晰可靠的事实来源。一个风格适配器不应成为判断产品当前是否可用的依据。检索与微调也可以结合：先检索最新政策，再训练模型依据提供的证据，按要求的结构回答。评估这种组合应用时，基线与微调模型应使用相同的检索上下文。

对开发者而言，这意味着先测量提示词等方法未能解决的错误，再选择训练栈。对运营人员而言，这意味着负责审核训练示例，并决定哪些错误最重要。对采购方而言，这意味着要求看到改进前后的评分表，以及实际可部署的模型文件，不能仅凭“定制模型”几个字就认定效果有所提升。

如果训练小模型的示例来自一个更大的教师模型，这同时也是一种模型蒸馏流程。LoRA 描述的是学生模型更新哪些参数；蒸馏描述的是训练信号从哪里来。两者可以结合，但生成的目标答案仍需审核。

选择托管 API，还是使用自己的 GPU？

如果托管服务支持的模型、数据处理方式和部署选项适合你的应用，可以选择托管路线。如果需要掌控检查点、训练方案和运行时，而且有能力运维整套系统，就使用自己的 GPU。开始训练之前，先确定如何提供推理服务。

Together AI：明确支持 LoRA 训练与导出

Together AI 提供托管微调 API，快速入门文档明确演示了如何启动 LoRA 任务。Python 调用 client.fine_tuning.create() 默认使用 LoRA，也可以显式设置 lora=True。完整流程包括准备对话数据、校验并上传、训练，最后部署结果。参见 Together AI 快速入门。

关键限制在于模型是否具备部署条件。支持训练不等于能用 serverless 推理；现行指南通过专用模型推理部署来服务微调模型。确定基座之前，应先核实它是否支持相应的专用部署。

导出方式也需要单独选择。Together 文档说明，checkpoint="adapter" 只导出适配器权重，checkpoint="merged" 则导出合并了基座与适配器的检查点。如果运行时会把适配器加载到匹配的基座上，就选择适配器；如果需要独立模型，就选择合并后的模型文件。参见部署与检查点类型。

Fireworks AI：训练支持与推理支持要分开核实

Fireworks AI 在托管监督微调流程中提供了 LoRA 文档。**监督微调（SFT）**通过期望回答的示例进行学习。要明确配置适配器训练任务，REST API 使用 loraRank，Python SDK 使用 lora_rank。参见 Fireworks SFT 文档。

要留意 Tunable 和 Supports Lora 的区别。某个基座可能支持加载外部训练的适配器进行推理，却不支持在 Fireworks 上训练。训练指南也接受单独的 evaluation_dataset，因此可以自行提供验证样例，不必依赖自动划分。

推理服务方面，Fireworks 文档介绍了两种方式：live merge 在部署时合并适配器，multi-LoRA 则将选定的适配器应用到共享基座。现行部署指南说明，训练后的 LoRA 需要按需专用部署，不支持 serverless 部署。指南还指出，FP8 和 FP4 部署规格不支持 LoRA 附加组件。因此，能选择压缩部署，并不代表该选项一定兼容适配器。参见 Fireworks 部署指南。

用 LoRA 微调，选 PEFT 还是 Unsloth？

Hugging Face PEFT 是实现参数高效微调方法的开源库，LoRA 也是其中之一。如果希望明确控制模型、量化配置和适配器模块，可以选择它。其量化指南介绍了如何加载量化基座、完成训练前的准备，再接入适配器。

文档中的 QLoRA 路线通过 BitsAndBytesConfig 配置 load_in_4bit=True、NF4 和双重量化；先用 prepare_model_for_kbit_training() 准备模型，再由 get_peft_model() 封装。要按 QLoRA 的方式覆盖线性层，指南使用的是 target_modules="all-linear"。这是一种受支持的配置方式，并不能证明所有模型架构或下游运行时都能接受任意适配器。

PEFT 的边界在于训练系统的其他部分：它不会替你选择样例、修正聊天模板，也不会为产品制定成功指标。

Unsloth 是一个开放的训练工具包，提供持续维护的微调指南和 notebook。其指南涵盖 LoRA、QLoRA 和全量微调，量化路线使用的配置包括 load_in_4bit=True。如果有持续维护的 notebook 与目标模型和硬件匹配，可以选用 Unsloth，并以该 notebook 作为训练起点。参见 Unsloth 微调指南。

Unsloth 的关键限制是训练方案的兼容性。notebook 能完成训练，并不能证明导出的模型在其他环境中也会保持同样的行为。应保持分词器、聊天模板和生成设置一致，再评估实际提供推理服务的模型。聊天模板是一套格式，用来向模型标记用户、助手及其他消息角色。

Hugging Face TRL 提供 SFTTrainer，这是一个可与 PEFT 集成的监督训练循环。它支持训练数据集和评估数据集；搭配兼容的聊天模板，还可设置 assistant_only_loss=True，只从助手回复中学习，而不是对整段对话的每个 token 都计算训练损失。这里的限制是，模板必须支持所需的助手掩码，因此要检查经过模板格式化后的训练样例。参见 TRL SFTTrainer。

使用自己的 GPU 做实验时，流程很明确：选择受支持的基座和训练方案，将一段样例对话按模板格式化，检查哪些 token 会计算训练损失，接入适配器，提供训练和验证数据，再保存检查点。检查点是保存下来的模型版本，可用于评估或恢复。更完整的项目决策见我们的 LLM 微调流程指南。

适配器如何部署和切换？

适配器必须与基座模型的身份信息和配置一起保存、迁移。在 PEFT 中，save_pretrained() 保存的是适配器权重和 adapter_config.json，这些文件不能替代基座权重。应在适配器旁同时保存准确的基座修订版本、分词器、聊天模板和训练配置。参见 PEFT 检查点格式。

如果多个任务变体需要共享同一个基座，或需要切换变体，就将适配器单独保留。PEFT 的 load_adapter() 加载另一个具名适配器，set_adapter() 则选中它。加载和激活不是同一操作。disable_adapter() 上下文管理器允许按基座原有行为进行推理。参见 PEFT 模型 API。

这种区别有助于评估，但共享应用中的适配器选择还必须保证并发安全。不要在其他请求仍运行时，切换全局模型当前激活的适配器，并想当然地认为每个请求都会得到预期行为。应使用明确支持按请求路由的推理运行时。

vLLM 是一种推理引擎，可在兼容的模型实现上支持 LoRA。其服务端用 --enable-lora 和 --lora-modules 注册适配器，请求通过 model 字段选择适配器。需要检查模型是否支持 LoRA、允许的最大适配器秩，以及配置的适配器同时运行容量。这些是推理服务的约束，不是训练设置。参见 vLLM LoRA 文档。

文档也介绍了运行时加载和卸载适配器的能力，但 vLLM 提醒：除非环境隔离且完全可信，否则不应在生产环境中使用这项功能。常规部署时，在启动阶段注册已知适配器，是更简单的运维选择。

如果需要一个独立模型，且该模型文件不需要支持适配器切换，就合并适配器。PEFT 的 merge_and_unload() 将更新合入基座，返回不再具备 PEFT 适配器功能的模型。某些量化配置不支持合并。如果之后还想恢复分离使用的流程，就应分别保留原始适配器和基座。参见 PEFT 合并限制。

可移植性还有一个容易忽略的问题：所谓匹配的基座，指的是完全一致的权重，不只是同一个熟悉的模型系列名称。Fireworks 明确提醒，训练时使用的厂商检查点可能与公开权重不同。将适配器迁出平台之前，要先确认这项依赖。参见适配器导出指南。

LoRA 微调效果怎么评估？先建立基线，再比较

只有当选定的适配器在未参与模型选择的样例上改善了目标行为，才应该上线。训练损失下降，只能说明模型对训练样例拟合得更好了，不能作为发布标准。

下面以客服工单路由为例，给出一套评估流程。这是建议采用的方法，并非某次训练实验的结果报告。

1. 1

   训练前写清验收规则

   定义允许的标签、必需的输出字段，以及升级处理规则。决定哪些错误会阻止发布。对于内容风格，应写出可观察的规则，例如“先给答案，再交代背景”和“不添加没有依据的说法”。“写得更好”这样的模糊要求，无法支撑可靠的比较。

2. 2

   分开训练集、验证集与最终测试集

   训练样例用于更新适配器，验证样例用于选择训练方案和检查点，最终测试集则在这些选择确定前保持封存。相关工单、同一文档的改写版本，以及近乎重复的样例，都应放在同一数据子集中。否则，测试可能奖励的是对内容的熟悉程度，而不是泛化能力。

3. 3

   记录有竞争力的基线

   用实际可行的最佳提示词运行未经微调的基座，并启用计划保留的结构化输出控制。对于检索应用，还要记录检索得到的证据。保存模型修订版本、提示词、模板、生成设置、输出和评估器版本。适配器应优于真正可用的替代方案，而不是刻意写差的提示词。

4. 4

   用验证集选定方案，再用封存测试集比较

   根据验证结果选择检查点，然后固定下来。让该适配器与基线在相同的最终测试输入上运行，并保持设置一致。如果应用计划在训练后改用更短的提示词，应单独测量这一变化，不要与控制其他条件不变的适配器比较混在一起，这样才能看清改进来自哪里。

5. 5

   评估实际部署的模型

   合并、量化或更换推理引擎之后，要对实际部署的模型重新进行验收检查。测试应包括长输入、含糊的请求，以及应该保持基座行为的情况。只有目标改进在部署后依然成立，而且回归检查结果仍可接受，才能发布。

语法、任务正确性和风格要分别评分。对于客服模型，JSON 再规整，升级处理决策错了，结果仍然是错的。对于写作模型，回答更流畅却编造了产品卖点，同样属于退步。

报告中应列出作为分母的样本数量和各类别结果，不能只有一个总成功率。精确率衡量预测为某类别的结果有多少是对的；召回率衡量该类别的真实案例有多少被模型找到了。如果大部分样例都是常规账单问题，醒目的平均分就可能掩盖某个数量少、影响却很大的升级处理类别上的失败。既要记录原本失败、现在成功的样例，也要记录原本成功、现在失败的样例。

评估主观风格时，应隐藏输出来自哪个模型，并调整呈现顺序。模型评审可以帮助组织审核，但在将其评分作为发布门槛前，要先用人工判断核对它的决策。是否有用，取决于评分标准，而不是评审模型的解释写得有多流畅。

不要把最终测试集用成第二个验证集。一旦查看失败样例，并据此调整训练方案，这些样例就已经影响了开发。可以将它们保留为回归样例，但下一次最终比较应使用新的、此前未接触的样例。这里没有适用于所有任务的数据集规模规则；关键是评估能否代表应用实际会遇到的决策。

最后，要在实际预期的工作负载下，比较部署系统的延迟和资源使用情况。LoRA 节省参数，并不意味着推理一定加速。保留通过评估的基座与适配器版本，准备可回滚的版本，并在上线后继续监测同样的错误类别。

关于 LoRA，哪些说法被夸大了？

“低成本微调”优化的范围，比“低成本定制”窄得多。 你仍需要审核通过的样例、评估、推理服务和维护。检查点更小，或训练日志显示成功，都不能证明应用效果有所提升。

权重冻结，不代表行为不变。 适配器的目的就是改变模型输出，因此仍需对通用能力、拒答行为和回答质量做回归检查。移除适配器可以恢复基座计算路径；让它持续生效，并不能保证模型在其他问题上的回答不变。

LoRA 不保证达到全量微调的效果。 原始论文在所评估的任务上报告了出色结果。这支持了方法的有效性，但不是一个放之四海而皆准的等价定理。如果经过充分评估的适配器仍不能满足要求，应先调查数据、基座模型和任务本身，不要直接认定扩大训练规模就能解决。

不存在通用的最佳秩、样例数量或 GPU 小时数估算。 模型架构、序列长度、目标模块和实际任务都会改变实验条件。先采用有文档支持的训练方案，再根据验证结果决定下一步调整。

LoRA 微调常见问题

LoRA 微调到底在训练什么？

它训练的是新增的低秩矩阵，原始基座权重保持冻结。学到的适配器会改变基座计算；除非将权重合并，否则推理时仍需要对应的基座模型。

微调已经被证明没用了吗？

不能从一次失败实验或一个基准测试得出一概而论的结论。对于自己的应用，应在留出样例上，将实际可行的最佳提示词基线与训练后的模型比较。如果它没有改善所需行为，就不要上线。

微调要花多少钱？

成本取决于模型、处理的数据量、训练方案和推理服务安排。LoRA 减少了可训练参数，但不会省掉数据准备、评估和托管。先选择受支持的训练与部署路线，再查询该路线当前公布的价格；不存在一个有参考价值的通用单次训练报价。

能举一个微调的例子吗？

把审核通过的客服消息，与正确的类别、升级处理动作和回复格式配对，用这些样例训练模型。样例教会的是反复出现的决策模式；最新客户记录仍需在请求时提供。

现在还会用到微调吗？

会。Together AI、Fireworks AI、Hugging Face PEFT 和 Unsloth 都提供现行训练路线的文档。微调是否适合你，取决于提示词和必要的检索方案实施后，还剩下什么问题。

如何开始做微调？

定义任务指标，建立基线，分别准备训练和评估数据，选择受支持的模型与训练方案，进行训练，用验证集选择方案，再在部署前通过封存的测试集做比较。实际部署的模型也要验证。

PEFT 和 LoRA 是什么关系？

PEFT 指参数高效微调，是一类只训练有限参数的方法。Hugging Face PEFT 同时也是实现这些方法的库。LoRA 是这个方法家族中的一种。

哪些模型可以微调？

应查阅托管服务商或开源训练栈中准确的受支持模型列表，同时核对模型许可证。能否训练、能否提供适配器推理服务，以及能否获取基座权重，需要分别检查。只知道模型系列名称还不够。

微调还可以怎么理解？

在这里，可以理解为任务适配，或在针对性样例上继续训练。提示词工程改变的是推理时提供的指令；微调改变的是模型学到的参数。

下一步：从一个反复出现的错误开始

下周，从正在运行的应用中选出一个反复出现的错误，把它写成明确的验收测试。收集审核通过的样例，先识别并归组相关案例，再划分数据集，然后测量最佳提示词基线。如果基线仍反复出现同一类行为错误，就选择一条有文档支持、且训练结果能够部署的 LoRA 路线。把这些决策想清楚之后，再开始训练。

想获取构建和评估 AI 系统的实用指南，欢迎订阅邮件通讯。