跳到主要内容

微调(下):PEFT、LoRA 与模型合并

这一章讲三件事: 上一章算出的内存账怎么销——PEFT 用 3% 的可训练参数逼近全量微调,其中 LoRA 成了事实标准; LoRA 的机制、为什么小改就够、怎么配置(选在哪些部件上加、选秩、选 α),以及它带来的部署红利——多 LoRA 与 QLoRA; 另一条省钱路:模型合并——把多个现成模型加加减减拼出新模型,外加两条实操路径和四个超参数。 它在全书的位置:这是第 10 章内存账的解法篇;章末「微调不难、数据难」一句直接引出第 12 章数据集工程。

1. 顶层全景:三招销账

内存账(上一章):13B 全量微调,梯度+优化器状态一项就要 78 GB

├─ 招一:减少可训练参数 ──→ PEFT / LoRA(本章 §2–§5)
├─ 招二:减少每参数字节数 ──→ 量化(上一章)× LoRA = QLoRA(§6)
└─ 招三:干脆不训,组合现成模型 ──→ 模型合并(§7)

图说:三条路的共同目标是书里的一句话——在尽可能小的内存占用下实现良好的性能。

2. 全量微调的账,PEFT 的答案

2.1 7B 全量微调:56 GB 起步

全量微调(可训练参数 = 全部参数)的过程和从头训练几乎一样,唯一区别是起点:训练从随机权重开始,微调从预训练权重开始1。把上一章的账套到 7B 模型上2:

权重(FP16,2 字节): 70 亿 × 2 字节 = 14 GB
梯度 + 优化器状态(Adam): 70 亿 × 3 × 2 字节 = 42 GB
────────────────────────────────────────────
合计(未含激活值): 14 + 42 = 56 GB

对照:消费级 GPU 通常 12–24 GB,高端也只有 48 GB —— 全都装不下

硬凑也有办法:CPU 卸载(放不进 GPU 的部分挪到 CPU 内存,DeepSpeed 是代表),但慢3。更体面的出路是少训一些参数。

2.2 部分微调:想法对,效率低

最直觉的省法是部分微调:10 层网络冻结(保持原样、不参与更新)前 9 层、只训最后一层(靠输出的层更「任务特异」,靠前的层管通用特征)4。但它的参数效率很差:BERTLARGE 要更新约 25% 的参数,才能在 GLUE 基准上追平全量微调5

2.3 PEFT:3% 的参数,99.6% 的效果

PEFT(参数高效微调)的思路换了个方向:不是冻结原有层,而是插入新的小模块只训它们。Houlsby 等(2019)在 BERT 的每个 Transformer 层里插了两个称为适配器的小模块(插进模型的小零件,原模型的其他部分一动不动)6。结果:只用了全量微调 3% 的可训练参数,性能差距不超过 0.4%7

代价与红利各一条8:适配器是额外加的层,推理时多算几步——增加推理延迟;但它通常还样本高效,全量微调要几万到几百万样本才有明显提升,一些 PEFT 方法几千个样本就够。PEFT 技术两大类:基于适配器(往架构里加参数,也叫加法式)和基于软提示(往输入里加可训练的特殊 token——「软」在人读不懂,它是一串连续向量,由反向传播训出来;「硬提示」就是你打的那段人类可读的文字)9。软提示一族的变体(prefix-tuning、P-Tuning、prompt tuning)区别只在插入位置10。哪种最流行?作者数了 huggingface/peft 仓库 1000 多个公开问题:LoRA 占据主导地位11

3. LoRA:把大矩阵拆成两个小矩阵

3.1 主走查:81 个参数怎么变 18 个

LoRA 不加层,所以没有适配器那个推理延迟的缺点;它动的是权重矩阵——就是模型里排成行与列的一大块数——本身:把一个权重矩阵 W 分解成两个小矩阵的乘积,只训这两个小矩阵,训完还能合并回原矩阵12

先看玩具版(书里的原例)13:

低秩分解:9×9 的矩阵有 81 个参数
拆成 9×1 和 1×9 两个矩阵的乘积:9 + 9 = 18 个参数
81 → 18,不到原来的四分之一;代价是近似有损,秩越大保真越多

再看真模型(同样出自书)14:GPT-3 有 1750 亿参数不假,但 LoRA 论文里,多个任务上只用约 470 万个可训练参数——占全量微调的 0.0027%——就达到与全量微调相当甚至更好的效果。对照上一章 Adam 每参数 3 份存储的账:可训练参数从 1750 亿砍到 470 万,梯度和优化器状态的内存几乎归零。

流程三步15:设秩为 r,把 n×m 的 W 配一对小矩阵 A(n×r)和 B(r×m);训练时 W 冻结、只更新 A 和 B;用时把 A×B 按比例加回 W。这个比例由超参数 α 控制——它决定「学到的修正量」往新权重里掺多少16

3.2 为什么有效:预训练是压缩

「预训练要亿级参数学会的行为,微调怎么几百个小参数就能改?」书里把这个反直觉问题摆到了台面上。多条研究的共同答案:内在维度——模型真正需要调整的维度数远低于参数总数;预训练隐式地把内在维度压低了,而且模型越大、训得越充分,内在维度越低。换句话说,预训练起到了压缩机制的作用,训练得越充分的模型,越容易用少量参数、少量数据微调17

顺着这个逻辑还能倒推出一个结论:既然 LoRA 的好处来自「预训练已经把模型压过」,那么满秩的预训练仍然必要——先充分压缩,后来的小矩阵近似(行话叫低秩分解)才有得近。从头到尾都用小矩阵乘积来训模型(即低秩训练,ReLoRA、GaLore 等是活跃方向)也有人试,但书里明确把它列为未解问题18

4. 怎么配:选矩阵、选秩、选 α

4.1 哪些矩阵加 LoRA

LoRA 最常加在注意力模块的四个矩阵上:查询(Wq)、键(Wk)、值(Wv)、输出投影(Wo)19。预算固定时怎么分配?LoRA 原论文在 GPT-3-175B 上做了对照:把可训练参数预算定在 1800 万(约占总参数 0.01%),三种分法——一个矩阵用秩 8、两个矩阵用秩 4、四个矩阵用秩 2——四个矩阵配秩 2 表现最佳;只选两个时,查询矩阵加值矩阵最好20。后续经验:前馈层也值得加(Databricks 报告加满前馈层提升最显著),但内存受限时优先保注意力层21

4.2 秩与 α

  • 秩 r:许多场景 r 在 4~64 就够;r 增大并不提升性能,甚至可能过拟合。例外存在——Raschka 在自己的任务上 r=256 才最佳,所以别把「4–64」当铁律22;
  • α:控制修正量的贡献比例,实践中 α/r 常在 1∶8 到 8∶1 之间;r 小时 α 可以大些,r 大时反之——最终要靠实验定23

4.3 部署的算术:一个基座,一百个客户

LoRA 的模块化带来两种部署法24:训完把 A、B 合并进 W(推理零开销);或保持分离、推理时现合并(有一点延迟)。单模型用前者;多 LoRA 部署用后者——100 个客户共享同一个基座。这笔账书里算得很清楚25:

假设:基座一个权重矩阵 4096×4096(约 1680 万参数),秩 8
一组适配器 (A,B) = 4096×8×2 = 65,536 个参数

方式一(各自合并):100 个完整模型 = 1680 万 × 100 ≈ 1.68 亿参数
方式二(共享基座):1 个基座 + 100 组适配器 = 1680 万 + 655 万 ≈ 2335 万参数

图说:七个多亿的差距;切换客户时只加载几万参数的小适配器,加载也快。

苹果 2024 年就是这么干的:一个 30 亿参数的基座,配多个 LoRA 适配器分别服务 iPhone 的不同功能,再叠加量化让全部塞进设备端26。适配器本身还能像预训练模型一样公开共享(Hugging Face、AdapterHub)27

LoRA 的缺点照实记:性能通常不及全量微调;实现要懂模型架构——不过主流框架(PEFT、Axolotl、unsloth、LitGPT)都已开箱即用,冷门基座才会真踩坑28

4.4 QLoRA:量化 + LoRA,单卡 48 GB 训 65B

再压适配器参数量意义不大——适配器内存相对基座微乎其微。QLoRA 的做法是压基座:微调时权重按 4 位格式 NF4 存储(依据:预训练权重近似以 0 为中心的正态分布),计算时临时反量化成 BF16;再配分页(内存吃紧时把数据切成小块,在 CPU 和 GPU 之间自动倒腾)式的优化器29。合计效果:单块 48 GB 的 GPU 微调 650 亿参数的模型——上一章那个要 140 GB 只装权重的规模。产出的 Guanaco-65B 没超过 GPT-4,但在对比评估中比当时的 ChatGPT 更受青睐30。局限:量化和反量化有额外开销,可能拉长训练时间31

5. 模型合并:不训练,也能造模型

5.1 为什么合并

模型合并(model merging)是把多个模型(通常是各自微调过的)组合成一个,目标是 1+1>2:两个各会 60% 任务的模型,合并后可能答对 80%32;或者反向操作——两个小模型合成一个多面手,省部署。它对个人开发者格外友好:不微调的话,没有 GPU 也能做合并33

它还解了多任务微调的两难34:同时微调(一个数据集混所有任务)要更多数据和更久训练;顺序微调(学完 A 学 B)会灾难性遗忘——学新任务时把旧任务忘掉。并行地各训各的、最后合并,两条弯路都避开了。

设备端部署(手机、汽车、手表,内存紧)和联邦学习(各设备用本地数据各训各的,再合并回一个基座)是另外两个主场35

注意区分近亲模型集成:集成只组合模型的输出(一个查询跑三个模型再投票),模型保持各自完整,推理成本按次数翻倍;合并是直接混参数,推理只跑一次36。Hugging Face 榜单前排已经站着不少合并模型37

5.2 求和:模型汤与任务算术

最朴素的合并是把权重直接相加38:

  • 线性组合(平均/加权平均):「模型汤」研究证明,对多个微调模型的全部权重取平均,能提准确率且不增加推理时间39;

  • 任务向量:对同一基座微调出的模型,用「微调模型 − 基座」得到一个向量,它捕捉该任务的本质;于是可以做任务算术——加向量组合能力,减向量去除能力(比如抹掉面部识别这类侵入性功能)40;

  • SLERP(球面插值——按已知值估出中间值的数学操作):把两个向量看作球面上两点,取最短弧上的点作合并结果;一次只能合两个,多了就两两接力41;

  • 剪枝(把任务向量里多数无关紧要的改动清零)后再合:微调改动的参数大多无关紧要,TIES/DARE 等方法保留前 20% 的任务向量参数,性能与保留全部相当;要合的模型越多,这一步越重要,因为单个任务的冗余参数会干扰其他任务42

5.3 层堆叠与拼接

层堆叠(俗称「缝合」)更野:从不同模型各抽几层直接摞成一个新架构。Goliath-120B 从两个 70B 级模型各取 80 层中的 72 层组合而成;它也能把稠密(所有参数都参与每次计算的架构)模型升级成 MoE——复制某些层、加一个路由器(决定每个输入发给哪个副本的部件),Together AI 用这招把六个较弱的开源模型组合出接近 GPT-4o 的性能43模型扩容是它的正经用途之一:SOLAR 10.7B 从一个 32 层模型出发,复制后对 16 个层求和、其余堆叠,得到 48 层的更大模型(32×2−16=48),再续训到目标性能44。至于拼接(参数直接接在一起,秩相加)——书里犹豫再三才收进来,结论是不推荐:不省内存,性能提升也未必抵得了参数成本45

6. 实操:两条路径,四个旋钮

6.1 渐进路径与蒸馏路径

书里引 OpenAI 的最佳实践,给出两条开发路径46:

渐进路径:最便宜最快的模型跑通代码 → 中等模型验证数据质量
(训练损失不随数据下降 = 数据有问题) → 最强模型探性能上限
→ 全系列模型画成本-性能曲线,选最合适的

蒸馏路径:最强模型 + 小数据训出好模型 → 用它生成更多训练数据
→ 用新数据训一个便宜的模型

图说:前者省钱在过程,后者省钱在终点;依据预算与数据现状二选一。

方法选择上:先试 LoRA 这类便宜货,不够再上全量;数据只有几百个样本时,LoRA 往往比全量微调更合适;要部署多个共享基座的模型,LoRA 的多部署优势直接成立47。工具链三档:微调 API(上传数据选模型,最省事但选项少)、微调框架(LLaMA-Factory、unsloth、PEFT、Axolotl、LitGPT)、分布式训练(DeepSpeed、PyTorch Distributed、ColossalAI)48

6.2 四个超参数

书里挑了四个通用且要紧的49:

超参数管什么怎么定
学习率每步参数更新的步长常取预训练结束值 × 0.1~1,在 10⁻⁷~10⁻³ 间试;损失曲线大幅波动 = 太大,稳但降得慢 = 太小
批次大小每步更新用多少条数据小于 8 训练不稳;受内存限制时用梯度累积(多个小批次攒够梯度再更新一次)
epoch 数数据完整过几遍百万级样本 1–2 轮够;几千样本 4–10 轮仍可能提升;训练损失降、验证损失升 = 过拟合,减
提示词损失权重提示词在损失里占的比重推理时提示词是用户给的,模型只需生成响应,所以默认 10%——主要从响应学习

7. 作者的判断与证据

  • 「LoRA 主导 PEFT」(有证据,但方法诚实标注):作者自己统计了 huggingface/peft 仓库 1000 多个公开问题,并把统计假设(用得多才报得多)写在明处。
  • 「参数高效的原因是内在维度低」(有证据,归于他人):引 Li 2018、Aghajanyan 2020、Hu 2021 三篇;书里同时把「满秩预训练是否永远必要」标为未解问题。
  • 「微调本身不难,难的是数据」(作者的行业观察,放在章末):框架已经把训练过程自动化,真正的瓶颈在高质量标注数据——这句话是第 12 章的引子。
  • 「模型合并仍处实验阶段」(作者的谨慎):大部分合并技术缺乏底层理论,书里明确说只做宏观介绍、不押注具体方法。

8. 边界与局限

  • 「PEFT 用 3% 参数达全量 99.6%」来自 BERT 时代的 GLUE 基准;换任务、换模型规模不保证复现。
  • LoRA「性能略逊全量」是定性结论;书里没给系统性的差距数字。
  • Guanaco 的 Elo 对比是 2023 年 5 月的数据,模型换代后不能直接引用。
  • 模型合并(尤其层堆叠)的成果多来自社区实践(Goliath、SOLAR),可解释性弱;书里也只给了宏观方法。
  • 批次大小为何过小就不稳,书里坦言「尚未找到明确解释的资料」——这是原书的坦白,不是我们的省略。

9. 可带走的

  1. 全量微调 7B 就要 56 GB(权重 14 + 梯度与优化器状态 42),超出消费级 GPU——这就是 PEFT 存在的理由;
  2. PEFT 插入小模块只训它们:3% 的参数,性能差距 0.4% 以内;代价是适配器增加推理延迟,样本上也省(几千样本可见效);
  3. LoRA = 把权重矩阵拆成两个小矩阵只训它们(9×9=81 → 9×1+1×9=18),训完可合并回原矩阵,不增加推理延迟;
  4. 它有效是因为内在维度:预训练是压缩,训得越充分,微调要动的越少——所以满秩预训练仍然必要;
  5. 配置经验:预算固定时「更多矩阵 × 更小秩」优于「更少矩阵 × 更大秩」;只选两个矩阵选 Wq+Wv;r 从 4–64 起试,增大不涨甚至过拟合;α/r 常在 1∶8~8∶1;
  6. 多 LoRA 部署:一个基座 + 100 组适配器 = 2335 万参数,对 100 个完整模型的 1.68 亿;切换客户只换几万参数的小文件——苹果在 iPhone 上就这么用;
  7. QLoRA = 4 位基座 + LoRA:单卡 48 GB 微调 65B;代价是量化/反量化开销;
  8. 模型合并是不用 GPU 的造模型法:模型汤(取平均)、任务向量加减(组合能力/去除不良行为)、TIES 剪枝(留前 20% 任务向量)、层堆叠(SOLAR 32 层变 48 层);拼接不推荐;
  9. 多任务别硬同时训也别顺序训(灾难性遗忘)——并行各训再合并;
  10. 超参数四件事:学习率看损失曲线,批次小于 8 不稳(用梯度累积补),样本少就多跑几轮 epoch,提示词损失权重默认 10%。

10. 原文地图

主题原书章原文位置
全量微调定义第7章text/14-ch07.txt:847(搜「全量微调」)
7B 三笔账 = 56 GB第7章text/14-ch07.txt:856(搜「14 GB」) · text/14-ch07.txt:862(搜「56 GB」)
消费级 GPU 12–24 GB、CPU 卸载第7章text/14-ch07.txt:865(搜「48 GB」) · text/14-ch07.txt:868(搜「CPU卸载」)
部分微调与 25% 参数第7章text/14-ch07.txt:871(搜「任务特异性」) · text/14-ch07.txt:880(搜「25%」)
PEFT 插适配器、3% 与 0.4%第7章text/14-ch07.txt:892(搜「适配器模块」) · text/14-ch07.txt:901(搜「0.4%」)
适配器增加推理延迟、样本高效第7章text/14-ch07.txt:904(搜「推理延迟」) · text/14-ch07.txt:907(搜「几千个样本」)
软提示与硬提示第7章text/14-ch07.txt:925(搜「软提示」) · text/14-ch07.txt:928(搜「人类可读」)
插入位置的差异第7章text/14-ch07.txt:949(搜「插入位置」)
LoRA 主导(issue 统计)第7章text/14-ch07.txt:952(搜「1000多个」) · text/14-ch07.txt:955(搜「LoRA占据主导地位」)
LoRA 不加层、可合并回第7章text/14-ch07.txt:970(搜「不会增加推理延迟」) · text/14-ch07.txt:973(搜「分解为两个较小矩阵」)
秩 r 与 α第7章text/14-ch07.txt:979(搜「秩」) · text/14-ch07.txt:982(搜「超参数α」)
低秩分解 81→18第7章text/14-ch07.txt:1000(搜「81个参数」)
有损近似、秩越大保真越多第7章text/14-ch07.txt:1003(搜「有损」)
GPT-3:470 万参数 0.0027%第7章text/14-ch07.txt:1006(搜「470万」)
内在维度与预训练压缩第7章text/14-ch07.txt:1015(搜「内在维度」)
满秩预训练仍必要第7章text/14-ch07.txt:1030(搜「满秩预训练」)
四个注意力矩阵第7章text/14-ch07.txt:1045(搜「查询矩阵」)
1800 万预算、秩 2 最优、Wq+Wv第7章text/14-ch07.txt:1054(搜「1800万」) · text/14-ch07.txt:1069(搜「秩为2的LoRA表现最佳」)
前馈层也加、注意力优先第7章text/14-ch07.txt:1078(搜「前馈」)
r 取 4–64、增大不提升、Raschka 256、α/r第7章text/14-ch07.txt:1081(搜「4~64」) · text/14-ch07.txt:1089(搜「增大r的值并不会提高」) · text/14-ch07.txt:1090(搜「256」)
两种部署方式第7章text/14-ch07.txt:1099(搜「合并到原始模型」) · text/14-ch07.txt:1102(搜「保持W、A和B分离」)
多 LoRA 部署、100 客户第7章text/14-ch07.txt:1105(搜「多LoRA部署」) · text/14-ch07.txt:1114(搜「100个客户」)
1.68 亿 vs 2335 万第7章text/14-ch07.txt:1120(搜「1.68亿」) · text/14-ch07.txt:1123(搜「2335万」)
切换只加载适配器、苹果 30 亿第7章text/14-ch07.txt:1126(搜「LoRA适配器即可」) · text/14-ch07.txt:1129(搜「30亿」)
适配器共享第7章text/14-ch07.txt:1138(搜「AdapterHub」)
LoRA 的缺点第7章text/14-ch07.txt:1141(搜「LoRA的主要缺点」)
QLoRA:NF4、分页优化器、48 GB 训 65B第7章text/14-ch07.txt:1159(搜「4位存储」) · text/14-ch07.txt:1162(搜「NF4」)
Guanaco、QLoRA 局限第7章text/14-ch07.txt:1165(搜「Guanaco」) · text/14-ch07.txt:1174(搜「反量化」)
模型合并定义、无 GPU 可做第7章text/14-ch07.txt:1188(搜「组合多个模型」) · text/14-ch07.txt:1191(搜「没有GPU」)
60%+60%→80%第7章text/14-ch07.txt:1194(搜「80%的问题」)
同时微调、顺序微调与灾难性遗忘第7章text/14-ch07.txt:1206(搜「同时学习多个技能」) · text/14-ch07.txt:1212(搜「灾难性遗忘」)
设备端、联邦学习第7章text/14-ch07.txt:1218(搜「智能手表」) · text/14-ch07.txt:1229(搜「联邦学习」)
集成 vs 合并第7章text/14-ch07.txt:1232(搜「集成方法」) · text/14-ch07.txt:1241(搜「多次推理调用」)
求和三法总览第7章text/14-ch07.txt:1271(搜「求和」)
模型汤第7章text/14-ch07.txt:1302(搜「模型汤」)
任务向量与任务算术第7章text/14-ch07.txt:1305(搜「任务向量」) · text/14-ch07.txt:1308(搜「任务算术」)
SLERP第7章text/14-ch07.txt:1323(搜「最短路径」) · text/14-ch07.txt:1332(搜「一次只能合并两个」)
TIES 剪枝、保留 20%第7章text/14-ch07.txt:1340(搜「冗余的」) · text/14-ch07.txt:1364(搜「剪枝就越重要」)
层堆叠、Goliath-120B第7章text/14-ch07.txt:1370(搜「层堆叠」) · text/14-ch07.txt:1373(搜「Goliath」)
MoE 稀疏升级、Together AI第7章text/14-ch07.txt:1376(搜「路由器」) · text/14-ch07.txt:1385(搜「六个较弱」)
模型扩容、SOLAR 48 层第7章text/14-ch07.txt:1388(搜「模型扩容」) · text/14-ch07.txt:1397(搜「48」)
拼接不推荐第7章text/14-ch07.txt:1415(搜「拼接」) · text/14-ch07.txt:1429(搜「不推荐使用拼接」)
渐进路径与蒸馏路径第7章text/14-ch07.txt:1452(搜「渐进路径」) · text/14-ch07.txt:1466(搜「数据可能存在问题」) · text/14-ch07.txt:1452(搜「蒸馏路径」)
先 LoRA、几百样本用 LoRA第7章text/14-ch07.txt:1490(搜「可以先尝试LoRA」) · text/14-ch07.txt:1493(搜「几百个样本」)
微调 API 与框架第7章text/14-ch07.txt:1499(搜「微调API」) · text/14-ch07.txt:1502(搜「LLaMA-Factory」) · text/14-ch07.txt:1508(搜「分布式训练」)
学习率:步长比喻与取值第7章text/14-ch07.txt:1517(搜「步长」) · text/14-ch07.txt:1520(搜「0.1~1」)
损失曲线判学习率、学习率调度第7章text/14-ch07.txt:1523(搜「波动很大」) · text/14-ch07.txt:1526(搜「学习率调度」)
批次大小、梯度累积第7章text/14-ch07.txt:1534(搜「批次大小」) · text/14-ch07.txt:1546(搜「梯度累积」)
epoch 与过拟合第7章text/14-ch07.txt:1555(搜「4~10个epoch」) · text/14-ch07.txt:1558(搜「过拟合」)
提示词损失权重默认 10%第7章text/14-ch07.txt:1564(搜「默认为10%」)
小结:微调不难,数据难第7章text/14-ch07.txt:1596(搜「微调本身不难」)

Footnotes

  1. 出处:「第7章」第 847 段(text/14-ch07.txt:847,搜「全量微调」)与第 850 段(text/14-ch07.txt:850,搜「随机初始化」)。

  2. 出处:「第7章」第 856 段(text/14-ch07.txt:856,搜「14 GB」)、第 859 段(text/14-ch07.txt:859,搜「42 GB」)与第 862 段(text/14-ch07.txt:862,搜「56 GB」)。

  3. 出处:「第7章」第 865 段(text/14-ch07.txt:865,搜「48 GB」)与第 868 段(text/14-ch07.txt:868,搜「CPU卸载」)。

  4. 出处:「第7章」第 871 段(text/14-ch07.txt:871,搜「任务特异性」)与第 876 段(text/14-ch07.txt:876,搜「冻结前9层」;若定位失败搜「部分微调」)。

  5. 出处:「第7章」第 880 段(text/14-ch07.txt:880,搜「25%」)。

  6. 出处:「第7章」第 892 段(text/14-ch07.txt:892,搜「适配器模块」)与第 901 段(text/14-ch07.txt:901,搜「保持模型的原始参数不变」)。

  7. 出处:「第7章」第 901 段(text/14-ch07.txt:901,搜「0.4%」)。

  8. 出处:「第7章」第 904 段(text/14-ch07.txt:904,搜「推理延迟」)与第 907 段(text/14-ch07.txt:907,搜「几千个样本」)。

  9. 出处:「第7章」第 916 段(text/14-ch07.txt:916,搜「基于适配器」)与第 925 段(text/14-ch07.txt:925,搜「软提示」)、第 928 段(text/14-ch07.txt:928,搜「人类可读」)。

  10. 出处:「第7章」第 948 段(text/14-ch07.txt:948,搜「prefix-tuning」)与第 949 段(text/14-ch07.txt:949,搜「插入位置」)。

  11. 出处:「第7章」第 952 段(text/14-ch07.txt:952,搜「1000多个」)与第 955 段(text/14-ch07.txt:955,搜「LoRA占据主导地位」)。

  12. 出处:「第7章」第 970 段(text/14-ch07.txt:970,搜「不会增加推理延迟」)与第 973 段(text/14-ch07.txt:973,搜「分解为两个较小矩阵」)。

  13. 出处:「第7章」第 1000 段(text/14-ch07.txt:1000,搜「81个参数」)与第 1003 段(text/14-ch07.txt:1003,搜「有损」)。

  14. 出处:「第7章」第 1006 段(text/14-ch07.txt:1006,搜「470万」)。

  15. 出处:「第7章」第 976 段(text/14-ch07.txt:976,搜「n×m」)与第 979 段(text/14-ch07.txt:979,搜「秩」)、第 988 段(text/14-ch07.txt:988,搜「仅更新矩阵A和B」)。

  16. 出处:「第7章」第 982 段(text/14-ch07.txt:982,搜「超参数α」)。

  17. 出处:「第7章」第 1009 段(text/14-ch07.txt:1009,搜「参数高效性为什么」;若定位失败搜「理所当然」)与第 1015 段(text/14-ch07.txt:1015,搜「内在维度」)。

  18. 出处:「第7章」第 1018 段(text/14-ch07.txt:1018,搜「低秩预训练」)与第 1030 段(text/14-ch07.txt:1030,搜「满秩预训练」)。

  19. 出处:「第7章」第 1045 段(text/14-ch07.txt:1045,搜「查询矩阵」)。

  20. 出处:「第7章」第 1054 段(text/14-ch07.txt:1054,搜「1800万」)与第 1069 段(text/14-ch07.txt:1069,搜「秩为2的LoRA表现最佳」)。

  21. 出处:「第7章」第 1078 段(text/14-ch07.txt:1078,搜「前馈」)。

  22. 出处:「第7章」第 1081 段(text/14-ch07.txt:1081,搜「4~64」)、第 1089 段(text/14-ch07.txt:1089,搜「增大r的值并不会提高」)与第 1090 段(text/14-ch07.txt:1090,搜「256」)。

  23. 出处:「第7章」第 1090 段(text/14-ch07.txt:1090,搜「1∶8」)。

  24. 出处:「第7章」第 1096 段(text/14-ch07.txt:1096,搜「两种方式」;若定位失败搜「部署经过LoRA微调的模型」)、第 1099 段(text/14-ch07.txt:1099,搜「合并到原始模型」)与第 1105 段(text/14-ch07.txt:1105,搜「多LoRA部署」)。

  25. 出处:「第7章」第 1114 段(text/14-ch07.txt:1114,搜「100个客户」)、第 1117 段(text/14-ch07.txt:1117,搜「1680万」)、第 1120 段(text/14-ch07.txt:1120,搜「1.68亿」)与第 1123 段(text/14-ch07.txt:1123,搜「2335万」)。

  26. 出处:「第7章」第 1126 段(text/14-ch07.txt:1126,搜「LoRA适配器即可」)与第 1129 段(text/14-ch07.txt:1129,搜「30亿」)。

  27. 出处:「第7章」第 1138 段(text/14-ch07.txt:1138,搜「AdapterHub」)。

  28. 出处:「第7章」第 1141 段(text/14-ch07.txt:1141,搜「LoRA的主要缺点」)。

  29. 出处:「第7章」第 1144 段(text/14-ch07.txt:1144,搜「微乎其微」)、第 1158 段(text/14-ch07.txt:1158,搜「QLoRA」)与第 1162 段(text/14-ch07.txt:1162,搜「NF4」)。

  30. 出处:「第7章」第 1162 段(text/14-ch07.txt:1162,搜「48 GB」;若定位失败搜「650亿」)与第 1165 段(text/14-ch07.txt:1165,搜「Guanaco」)。

  31. 出处:「第7章」第 1174 段(text/14-ch07.txt:1174,搜「反量化」)。

  32. 出处:「第7章」第 1194 段(text/14-ch07.txt:1194,搜「80%的问题」)。

  33. 出处:「第7章」第 1191 段(text/14-ch07.txt:1191,搜「没有GPU」)。

  34. 出处:「第7章」第 1206 段(text/14-ch07.txt:1206,搜「同时学习多个技能」)、第 1212 段(text/14-ch07.txt:1212,搜「灾难性遗忘」)与第 1215 段(text/14-ch07.txt:1215,搜「风险更低」)。

  35. 出处:「第7章」第 1218 段(text/14-ch07.txt:1218,搜「智能手表」)与第 1229 段(text/14-ch07.txt:1229,搜「联邦学习」)。

  36. 出处:「第7章」第 1232 段(text/14-ch07.txt:1232,搜「集成方法」)与第 1241 段(text/14-ch07.txt:1241,搜「多次推理调用」)。

  37. 出处:「第7章」第 1244 段(text/14-ch07.txt:1244,搜「Open LLM Leaderboard」;若定位失败搜「合并模型」)。

  38. 出处:「第7章」第 1268 段(text/14-ch07.txt:1268,搜「求和」;若定位失败搜「权重相加」)与第 1271 段(text/14-ch07.txt:1271,搜「线性组合」)。

  39. 出处:「第7章」第 1302 段(text/14-ch07.txt:1302,搜「模型汤」)。

  40. 出处:「第7章」第 1305 段(text/14-ch07.txt:1305,搜「任务向量」)与第 1308 段(text/14-ch07.txt:1308,搜「任务算术」)。

  41. 出处:「第7章」第 1317 段(text/14-ch07.txt:1317,搜「SLERP」)与第 1332 段(text/14-ch07.txt:1332,搜「一次只能合并两个」)。

  42. 出处:「第7章」第 1340 段(text/14-ch07.txt:1340,搜「冗余的」)、第 1350 段(text/14-ch07.txt:1350,搜「20%」)与第 1364 段(text/14-ch07.txt:1364,搜「剪枝就越重要」)。

  43. 出处:「第7章」第 1370 段(text/14-ch07.txt:1370,搜「层堆叠」)、第 1373 段(text/14-ch07.txt:1373,搜「Goliath」)、第 1376 段(text/14-ch07.txt:1376,搜「路由器」)与第 1385 段(text/14-ch07.txt:1385,搜「六个较弱」)。

  44. 出处:「第7章」第 1388 段(text/14-ch07.txt:1388,搜「模型扩容」)与第 1397 段(text/14-ch07.txt:1397,搜「48」)。

  45. 出处:「第7章」第 1415 段(text/14-ch07.txt:1415,搜「拼接」)与第 1429 段(text/14-ch07.txt:1429,搜「不推荐使用拼接」)。

  46. 出处:「第7章」第 1452 段(text/14-ch07.txt:1452,搜「渐进路径」)、第 1466 段(text/14-ch07.txt:1466,搜「数据可能存在问题」)与第 1452 段(text/14-ch07.txt:1452,搜「蒸馏路径」)。

  47. 出处:「第7章」第 1490 段(text/14-ch07.txt:1490,搜「可以先尝试LoRA」)与第 1493 段(text/14-ch07.txt:1493,搜「几百个样本」)、第 1496 段(text/14-ch07.txt:1496,搜「多个完整的模型实例」)。

  48. 出处:「第7章」第 1499 段(text/14-ch07.txt:1499,搜「微调API」)、第 1502 段(text/14-ch07.txt:1502,搜「LLaMA-Factory」)与第 1508 段(text/14-ch07.txt:1508,搜「分布式训练」)。

  49. 出处:「第7章」第 1517 段(text/14-ch07.txt:1517,搜「步长」)、第 1534 段(text/14-ch07.txt:1534,搜「批次大小」)、第 1552 段(text/14-ch07.txt:1552,搜「epoch」)与第 1564 段(text/14-ch07.txt:1564,搜「默认为10%」)。