大模型微调的成本大头从来不是训练脚本，而是显存和算力。全参微调一个 7B 模型，显存需求通常在 80GB 量级，这直接把大多数团队挡在门外。LoRA 的价值，是用极小的可训练参数量把这道门槛降下来。但任何一个"省"的设计都会在别处付出代价，这篇按架构分层，把它换来的东西和付出的东西都摆出来。
参数架构：用低秩分解近似权重增量
全参微调要更新的是每一层权重矩阵的全部元素。显存由三部分构成：模型权重本身、梯度，以及优化器状态。以 7B 为例，fp16 权重约 14GB，但 Adam 要为每个参数额外保存两份 fp32 状态，叠上梯度后总量会到 80GB 级别。
LoRA 的假设是：微调真正需要的改变量 ΔW 是低秩的。于是它冻结 W₀，把增量分解成两个小矩阵的乘积：
ΔW = B A, 前向：h = W₀x + (α / r) · B A x
A 为 r×k、B 为 d×r，r 远小于 d、k。可训练参数从 d·k 降到 r·(d+k)，7B 上占比通常在 1% 以内。
这个设计还顺手解决了一个工程稳定性问题：B 零初始化、A 随机初始化，训练起点 ΔW = 0，注入后模型行为与原模型完全一致，避免了"接上新模块就崩"的问题。
代价：低秩是一种假设，不是定理。当目标任务需要对模型行为做大范围改写时，r 需要开得很大，LoRA 的省显存优势会被侵蚀，这时反而不如直接全参微调或换更激进的方案。
训练架构：秩与缩放系数的耦合
秩 r 是这套架构的核心旋钮，它决定了两个小矩阵之间那条"腰"的粗细，直接映射到可训练参数量。规模量级上：
- 全参微调：80GB 以上
- LoRA，r=8：约 16GB
- LoRA，r=16：约 18GB
- LoRA，r=64：约 24GB
- QLoRA（4bit 底座）：约 8GB
从 r=8 到 r=64，显存只涨了约 8GB，但能表达的变化幅度差异很大。选型上有一个比较稳的经验分档：只调整输出风格与格式，r=8 足够；一般领域适应，r=16 是较稳妥的起点；样本规模上万、需要同时承载多任务，才考虑 32 或 64。
容易被忽略的是 alpha。它在公式里是缩放系数，实际生效的是 α/r 这个比值。如果只增大 r 而不动 alpha，比值下降，等效于削弱了增量分支的表达能力——参数变多了，实际学到的却更弱。工程上常见做法是令 α = r（缩放为 1）或 α = 2r；也有研究（rsLoRA，2023）主张用 α/√r 做秩稳定缩放。这个比值没有全局最优解，必须按模型和任务实测定。
部署架构：两种形态，对应两种成本结构
LoRA 的部署有两种形态，本质是"推理延迟"和"运维复杂度"之间的取舍。
合并形态：由于 B·A 与 W₀ 同形状，可直接相加生成新权重。合并后模型结构与原始模型一致，推理阶段没有任何额外计算。适合单一固定任务、对延迟敏感的线上服务。这是 LoRA 相对 Adapter、Prefix Tuning 等方案的关键优势——后者的附加模块在推理时始终参与计算，必然带来延迟。
多适配器形态：不合并时，每个任务的适配器是独立小文件，通常几十 MB，底座只加载一份，按任务动态切换。一个底座挂三五个适配器，总增量可能不到 100MB；若给每个任务各自维护一个完整模型，显存占用会成倍上升。vLLM 等推理引擎已支持多 LoRA 的动态加载与淘汰，切换开销在几十毫秒级。代价是路由与版本管理变得复杂，这条成本从显存转移到了工程侧。
成本架构：训练成本下降，数据成本上升
LoRA 把训练成本压到"单卡 + 几十分钟"后，项目的瓶颈往往发生转移：训练不再是难点，那几百到一两千条干净样本的标注、审核、复核才是。选型时如果只算 GPU 账单，很容易低估后者。
同时有两个常见误区要避开：
- "参数量少所以不过拟合"不成立。LoRA 一样会过拟合，小数据配大 r 尤其明显，还会出现灾难性遗忘。缓解手段包括在训练集中掺入通用对话样本。
- "训完即上线"不可取。验收必须双向：新能力是否达标，旧能力是否退化。只看前者，很容易上线后才发现通用能力被牺牲。此外，验证集要独立于训练集，训练与推理的输入格式必须一致。
落地建议：先判断"知不知道"，再决定"训不训"
一个实用的决策框架是区分模型的两类缺口：
- 不知道：属于知识。制度、报价、库存、政策这类信息会变，且要求可溯源。把知识写进权重，等于固化一个会过期的答案，更新一次就要重训一次——这类需求应该交给检索增强（RAG）或提示词，而不是微调。
- 不会说：属于行为。输出格式固定、语气统一、不确定时必须规范拒答——这些靠提示词难以稳定约束，才是 LoRA 微调的适用场景。
因此推荐的顺序是：先打磨提示词 → 提示词顶不住的格式化 / 风格化需求 → 再上 LoRA。另外，若模型能力只能通过厂商 API 调用、拿不到权重，微调这条路在架构上就不成立。
在实际平台上落地时，可以把底座与数据集放在对象存储（如 OSS），训练任务跑在 PAI 等托管平台，产出的适配器文件再回存对象存储，用版本号管理。这样底座权重不需要在本地反复搬运，也便于回滚与审计。
小结
LoRA 是一套"用可控的精度让步，换取显存与部署灵活性"的架构。它的边界很清晰：适合调整模型的行为方式，不适合承载会变化的知识。改口吻，别改知识；先把提示词顶住，顶不住的那部分，才是 LoRA 该干的活。
