GPU 与模型部署 · C 微调实战
0 / 8 章 ← 首页
贯穿案例 · 一个 14B 模型的一生 序幕 · 在个人电脑跑起来 第二幕 · 变成代码助手 第三幕 · 微调成知识助手 第四幕 · 上线 50 人服务
01

「微调」到底在调什么 —— 不是灌知识，是调行为

想把 14B 变成「懂我们公司业务的助手」，第一反应往往是：把公司文档全喂给它训练一遍？这个直觉大概率是错的，而且错得很贵。

先纠正最大的误区训练 ≠ 灌知识。模型里的知识几乎全部来自预训练（读全网文本读出来的）；微调（SFT）调整的是行为与格式——「它已经会，只是要教会它按你的方式回答」。一句话：微调让它「会考」，不是让它「变聪明」。想让模型记住公司产品的参数细节，更好的工具是 RAG（检索增强）或把文档写进 system prompt，而不是微调。

训练的两大阶段：预训练 → 后训练

顶层分层就两段：预训练（pre-training）从零读全网，产出只会「续写」的底座模型（base）；后训练（post-training）是底座之后一切「行为塑造」的统称——SFT、偏好对齐都归它。继续预训练（CPT）不是并列的第三种，它是预训练的延长线：拿现成底座、继续用「读书」的方式（下一词预测 + 无标注纯文本）喂领域语料，长的是知识，不是行为。查证 2026-09

阶段在做什么后厨比喻典型规模你要付的代价
预训练
厂商的事		从零读全网文本，学语言与世界知识 → 产出底座模型（base，只会续写不会对话）培养一名厨师，从切菜学到满汉全席万亿级 token、数千卡、数月（绝大部分算力花在这）千万~亿美元级，别碰
└ 继续预训练（CPT）：拿现成底座继续「读书」，喂领域语料（代码 / 医疗 / 法律）——学的还是知识，不是行为送资深厨师去进修一个新菜系十亿~千亿 token贵，且容易把通用能力「练偏」（要掺通用数据防遗忘）；通常是厂商 / 平台做
后训练
你的入口		SFT 指令微调（本页主角）：用「指令—回答」对，教「怎么回答」给菜谱加一页「本店摆盘规范」几百~几万条指令对一张消费级卡就可能搞定
└ 偏好对齐（RLHF / DPO）：在多个回答里教它「哪个更好」试菜后打分，调整咸淡千~万对偏好数据流程复杂，通常 SFT 不够再做
这张表从上往下，就是从「厂商」走到「你」上半张（预训练和它的延长线 CPT）是模型厂商和基础平台团队的战场——万亿 token、千卡集群、数月周期，做 AI 应用的程序员碰不到，也不用碰；下半张的后训练（SFT、偏好对齐）才是应用工程师做得起、见效快的入口。本页主角就是 SFT。

数据 > 算法：1000 条精样本的传说

2023 年 Meta 的 LIMA 论文做了个著名实验：只用 1000 条精心挑选/编写的「指令—回答」对，对 LLaMA 65B 做普通 SFT（无 RLHF），效果能对齐到接近 ChatGPT 的水平（人类评估中 43% 的情况不输 GPT-4）。论文把这叫「表面对齐假说」：能力和知识是预训练给的，对齐只是教会它「该用哪副面孔」。查证 2026-09：arXiv:2305.11206

别把传说当定律2024 年起有多篇后续研究（如 arXiv:2410.03717）反驳「仅仅是表面」的说法——对复杂推理任务，数据的量和质量仍然实打实地重要。LIMA 教会我们的是优先级：先把几百条高质量数据做扎实，再谈扩量、换算法、加卡。

好样本 vs 坏样本：一张对照卡

你 500 条数据的质量，决定这次微调是「资产」还是「废卡一下午」。动手前拿这张卡过一遍：

✓ 好样本

  • 来自真实场景：用户真的会这么问（最好从日志里捞）
  • 输入输出成对：回答就是你希望模型学会的样子，直接可用
  • 格式统一：全部过一遍 chat template，别混三种语气
  • 覆盖任务分布：高频问题多、长尾问题也有，难度有梯度
  • 已去重、已脱敏：重复样本放大偏心，敏感信息会背进权重

✗ 坏样本

  • 拿文档直接切块：那是 RAG 的料，微调它学不会「回答」
  • 回答互相矛盾：同一问题两个口径，模型学会摇摆
  • 全是同一种问法：过拟合到句式，换个说法就露馅
  • LLM 批量生成不审：错误会以讹传讹，模型学得比你想象的快
  • 灌知识型长文：指望 SFT 记住参数表——记不牢还挤占行为学习
第三幕开演贯穿案例进行到一半：我们的 14B 模型已经在个人电脑跑起来（a 页），也当上了代码助手（b 页）。现在的任务——把它微调成「按公司知识库的回答规范做事」的知识助手。手里素材：客服日志里挑出的 400 条真实问答。硬件预算：一张 RTX 4090。它够吗？先把 02 章的面试题过掉——分清这次微调要解决「知道什么」还是「怎么做」——再去 03 章算训练的账。
✦ 本章通关条件
✓
能向同事解释「微调是调行为不是灌知识」，并说出什么时候该用 RAG 而不是微调
✓
知道 LIMA「1000 条精样本」结论和它的适用边界
02

知识库（RAG）还是微调小模型 —— Agent 岗的高频面试题

「公司文档每周都在变，为什么要用知识库，而不是把这些知识微调进小模型？」——Agent / AI 应用岗面试的高频题。它考的不是背概念，是你能不能为一条真实需求选对工具。

一句话判准（先背这句）知识库（RAG）解决「模型需要知道什么」，微调小模型解决「模型需要稳定地怎么做」。知道什么 = 会变的事实，放外部资料里随查随新；怎么做 = 不变的动作，练进参数里又快又稳。

大白话：活页菜谱 vs 肌肉记忆

延续厨房比喻。知识库像后厨挂一本活页菜谱：客人问「这道菜怎么做」，翻到那页照着答，还能补一句「菜谱第 12 页」——有出处；菜单明天要改，撕掉旧页换新页立刻生效，不用重新培训厨师。微调像把摆盘规范练成肌肉记忆：不用翻书，手起刀落又快又稳，高频出菜不掉链子；但规范一改就得重新培训（重新训练），而且厨师说不出「这个动作是哪次培训学的」——没有出处。

应用场景：谁该干什么

知识库（RAG）承载会更新、需要追溯来源的业务事实：产品文档、企业制度、价格库存、客户资料、项目知识、最新政策。优势是知识更新快——文档变了、更新索引即可，不需要重新训练模型；回答可以带出处、做权限控制，出了错也容易定位（改的是文档，不是模型）。

微调小模型适合高频、稳定、输入输出边界明确的任务：

  • 客服意图分类与工单路由
  • 从合同、发票、病历中抽取固定字段
  • 商品属性标准化、内容审核、风险识别
  • 把自然语言稳定转换为固定 JSON 或工具调用
  • 对检索结果做重排，或把用户问题改写成更适合检索的查询
共同点这些任务不是缺少知识，而是希望模型长期、稳定、低成本地执行一个「业务动作」——动作不常变、输入输出有边界、效果可验证，正好是微调的舒适区。

一张对比表：七个维度

维度知识库 / RAG微调小模型
知识更新快：更新文档和索引即可慢：要重新准备数据、训练、评测
首次投入较低：能快速上线验证较高：数据、训练、评测体系都要建
高频调用成本检索、上下文和模型调用持续产生费用模型足够小时，边际成本通常更低
延迟要检索、拼上下文、再生成直接推理，适合实时高并发
可追溯性强：回答可附引用来源弱：知识压进参数，难解释出处
数据安全私有知识库可做权限隔离可私有部署，但训练数据治理要求更高
适合的任务会更新、要出处的知识问答高频固定动作：分类、抽取、格式化、路由

微调小模型的四个前提

  • ① 任务足够窄且稳定：业务目标和输出格式经常变，微调很快过期；像「把商品标题归到指定类目」这样稳定的任务才适合训。
  • ② 调用量足够高：低频任务直接用通用模型或 RAG 更灵活；高频任务才摊得平数据准备、训练、部署和持续评测的成本。
  • ③ 有高质量、可验证的样本闭环：人工纠错、审批结论、用户是否采纳、是否退款、是否转人工——「输入—正确输出—结果验证」缺一不可。
  • ④ 效果可以被明确评测：训练前先定义业务指标——字段抽取准确率、分类 F1、转人工率、审核漏判率、单次处理成本。否则只是在自己的题库上看起来很强。
没有闭环就别训条件③最容易被忽略：不是有一堆历史文本就能训。没有「输入—正确输出—结果验证」的闭环，微调本质上是在把噪声固化进模型。

所以：RAG 通常是业务知识接入的第一选择；小模型微调是业务规模化之后，为高频固定动作做降本增效的手段。

交互 C4 · 需求分流挑战（面试模拟）8 条真实需求 · 选 知识库 RAG / 微调小模型 / 通用大模型
需求 1 / 8
判断依据只有一条：这个需求在解决「知道什么」（会变的事实、要出处），还是「怎么做」（稳定的动作）？拿不准就自问：它需要出处吗？它天天变吗？
进度0 / 8
答对0
判准：知识库 = 会变的事实（要出处）· 微调 = 高频稳定动作（要闭环）· 通用大模型 = 复杂推理与长尾兜底。答对 6 / 8 以上，这道面试题你稳了。

合理的架构：三层分工

业务请求进来 编排层先判断要什么 知识层 · 知识库 / RAG 最新、可引用、受权限控制的业务事实：文档 / 制度 / 价格库存 / 政策 动作层 · 微调小模型 高频标准动作：分类 / 抽取 / 路由 / 查询改写 / 重排 —— 快、稳、便宜 兜底层 · 通用大模型 复杂推理、长尾问题、拿不准的都丢给它
三层不是三选一，是一条流水线：要「事实」查知识层，要「标准动作」交给微调小模型，剩下的难题给通用大模型兜底。
一句话总结（面试可以就答这句）RAG 让 Agent 知道最新事实，微调小模型让 Agent 把高频业务动作做得又快又稳。回到贯穿案例：把 14B 微调成「按公司规范回答」的知识助手，练的正是「怎么做」（回答规范）；它引用的公司知识本身放知识库——「知道什么」不用训。下一章开始算这笔训练的账。
✦ 本章通关条件
✓
能用一句话说清知识库与微调的分工——「知道什么」vs「稳定地怎么做」，并各举两个适配任务
✓
能报出微调的四个前提：任务窄而稳、调用量高、有样本闭环、效果可评测
03

全量训练为什么轮不到你 —— 16 字节/参数的账单

上一章定了方向：微调教的是「怎么做」。动手之前先算一笔账，看清为什么「全量训练」是数据中心的事、不是程序员桌上的事：同一张 24GB 的 4090，跑量化后的 14B 推理绰绰有余（a/b 页已经验证），可一敲下全量训练的命令，几步之内 OOM。显存去哪了？

答案在 a 页埋过伏笔：推理只往前算，训练要反推梯度。为了能反推，三样东西必须全程住在显存里——这正是「改菜谱」和「照菜谱做菜」的区别：照着做，菜谱摊开一页就够；要改写整本书，你得把每一页的改动记录、修订理由、修订历史全部摊在台面上。

每个参数的 16 字节账单

混合精度（BF16 计算）+ AdamW 优化器是当下训练的默认组合，它的显存口径来自 ZeRO 论文（Rajbhandari et al., 2020，查证 2026-09：arXiv:1910.02054）——每个参数约 16 字节，不含激活：

成分精度字节/参数为什么必须在
权重（工作副本）BF162前向计算用它
梯度BF162反向逐层回填，「往哪边改」
主权重（master copy）FP324BF16 尾数太短，小更新会被舍入吞掉；真正的参数原文
Adam 一阶矩 mFP324梯度的「动量」（近期平均方向）
Adam 二阶矩 vFP324梯度的「方差」（自适应步长）
合计16权重2 + 梯度2 + 主权重4 + m4 + v4
对着算一遍 14BQwen2.5-14B 实际 14.8B 参数：237 GB（= 14.8 × 16，不含激活）。其中权重 29.6 GB、梯度 29.6 GB、优化器状态（主权重+m+v）178 GB。对比一下：H100 80GB 只够零头。这就是「必须多卡或者换方法」的数学根源，不是工程不够努力。

激活：第二个大头

还不止 16 字节。前向的中间结果（激活值）必须留着给反向用——它随 batch × 上下文 × 层数 线性上涨，长上下文时能追平权重本身。按 Megatron 口径（34 × hidden × 层数 × 每 token 字节，量级估算），14B 在 4×1024 tokens 的批次下激活约 34 GB，峰值合计 ≈ 64 GB——一张 80GB H100 单卡连一步都迈不出去。

交互 C1 · 训练显存时间线Qwen2.5-14B · batch 4×1024 tokens · 不开 checkpointing · 数字现场调用 calc.js
点击「下一步」，看一个训练步里显存怎么被吃掉。
237 GB 需求 vs 80 GB H100 —— 全量训练 14B，单卡死刑。出路在 04（LoRA）/ 05（QLoRA）：换方法，而不是加卡。
BF16 权重0 GB
激活（峰值中）0 GB
梯度0 GB
优化器状态0 GB
显存合计0 GB
参照 · H10080 GB
读图色块高度 ∝ 显存：铁锈=权重，灰褐=激活，琥珀=梯度，钢蓝=优化器状态。条形按 236.8 GB 等比缩放，所以优化器一落位就撑爆画面。
账单公式：GPU_CALC.trainBreakdownGB('full')，激活 = activationGB(5120, 48, 4096, false)。量级估算，数据截至 2026-09。

顺带预告：如果开启 gradient checkpointing（微调的标准姿势里默认开），激活从每 token 34 字节降到 2 字节（4×1024 tokens 时 2 GB），代价是慢 20~30%——一笔几乎总是划算的「时间换显存」。

小自测：为什么「显存够装权重」不代表「能训练」？
训练 = 权重(2B) + 梯度(2B) + FP32主权重(4B) + Adam m(4B) + v(4B) = 8 倍于 BF16 推理的权重开销，再叠加随 batch×上下文增长的激活。24GB 装 14B 的 BF16 权重（29.6GB）尚且不够，训练更无从谈起。
延伸视野 · 真要做全量训练：多卡的四种切法（了解即可）

预训练和大规模全量训练属于「训练基础设施工程」——平台团队和模型厂商的日常，应用工程师几乎不会亲手做。面试聊到时，一句话分清它们各自切的是什么：

切法切的是什么一句话特征
DP 数据并行切数据：每卡一整份模型最省心，前提是单卡装得下
TP 张量并行切层内矩阵每层都通信，要 NVLink，一般 ≤8 卡同机
PP 流水线并行切层，分段接力通信最少，有流水线气泡
ZeRO / FSDP切状态：每卡只存 1/N训练侧万金油，对互联最宽容

应用工程师的口诀只有一句：装不下，先换方法（LoRA / QLoRA），而不是加卡。本页主线到此转向——不再追求装下全量训练，而是绕开它。

✦ 本章通关条件
✓
能脱口说出 16 字节账单的五项成分，并解释为什么 14B 全量训练约 237GB
✓
知道激活是第二个大头，随 batch × 上下文 × 层数涨
04

LoRA —— 不重写菜谱，页边贴便利贴

237GB 的账单劝退了单卡全量。但你只是想教它「用我们的格式和口吻回答」——真的需要改全部 148 亿个参数吗？

LoRA 是个什么概念

先用大白话说清楚：LoRA 不是一种模型，是一种「不动原模型」的微调方法。全量微调要把整个模型重训一遍（14B 就是 148 亿个参数全部更新）；LoRA 反着来——把原模型整个冻住，只在旁边新挂一小块可训练的参数，训练时只更新这一小块。训完的产物不是完整模型，而是一个几十到几百 MB 的「补丁文件」，社区叫它 LoRA adapter（模型站上供人下载的各种 LoRA 就是它）。对应本章标题的比喻：全量微调是重写整本菜谱，LoRA 是菜谱一页不改、在页边贴便利贴——原书永久保留，便利贴随时可撕可换。

  • 名字拆解：LoRA = Low-Rank Adaptation，低秩适配。Adaptation（适配）= 让模型适应你的任务；Low-Rank（低秩）= 改动量用「两个瘦矩阵的乘积」来表达——凭什么敢这么省，下一节讲。
  • 底座与补丁的关系：底座（base）不变，补丁（adapter）即插即拔。推理时可以把补丁合并进权重（部署时和普通模型没区别），也可以保持底座不动、按请求挂不同任务的补丁——一个底座服务多个场景。
  • 程序员为什么爱它：显存账单断崖式下降（14B 从 237GB 掉到本章后面的 33GB），48GB 卡舒适；分享和回滚只需拷补丁文件，不用动 29.6GB 的底座。下一章 QLoRA 再把它压进 24GB 卡。

低秩假设：改动其实很小

LoRA（Hu et al., 2021，查证 2026-09：arXiv:2106.09685）的出发点是一个实验发现：微调时权重的「改变量」是低秩的——看起来要动整个矩阵，实际改动集中在一个低维子空间里（相关结论可追溯至 Aghajanyan et al., 2020 的本征维度研究）。既然如此，别动原矩阵 W，只在旁边挂一对瘦矩阵 A、B（秩 r 很小，如 8~32），用它们的乘积 BA 当「改动量」：

W 冻结主干 只读 · 2 字节/参数 不进优化器，不存梯度 A (d×r) B (r×d) 秩 r = 8~32，很瘦 只有这一对矩阵进优化器（吃 16 字节账单） W + BA 推理时合并 × α/r 缩放后加回主干
LoRA：全量是重写整本菜谱，LoRA 是在页边贴便利贴 —— 书还是那本书

显存账立刻变了

关键在于优化器状态只跟着「可训练参数」走。冻结主干按推理精度（BF16，2 字节/参数）放着只读；可训练的 LoRA 增量通常只占参数量的 0.1%~1%（本手册按挂满线性层、r≈16 的 0.5% 口径算）。14B 的账变成：

成分全量 SFTLoRA说明
冻结主干—（全在训）29.6 GBBF16 只读，2 字节/参数
可训练参数14.8B0.074B（0.5%）LoRA 的 A、B 矩阵
增量梯度+优化器207 GB1.2 GB只随 0.074B 参数走（2+4+4+4 字节）
激活（4×1024 tok，ckpt 开）2 GB2 GB反向照算，激活省不了太多
合计237 GB33 GB调 trainBreakdownGB('lora') 现场算
判定33 GB → 48GB 卡舒适（占用约七成）；24GB 卡装不下——光 BF16 主干就要 29.6GB，已超 24GB 的可用上限。所以「24GB 跑 14B LoRA」的教程，要么实际开的是 8-bit 主干，要么就是 QLoRA（下一章）。

rank 与 alpha 的直觉

  • rank r：便利贴的「信息容量」。任务越接近模型已会的东西，r 越小越够用——论文里 r=4 起步就常常够；社区常用 8~32，r 拉大不会明显变聪明，只会让可训练参数和过拟合风险变大。查证 2026-09：LoRA 论文 + Unsloth 指南
  • alpha：便利贴字迹的「浓淡」。增量乘 α/r 后加回主干；实践里常取 α = r 或 2r，先固定 α=r、只调 r 是省心开局。
  • target_modules：便利贴贴在哪几页。只挂注意力层最省；挂上 MLP 线性层效果常更好、可训练参数也更多（本手册 0.5% 口径即「挂满线性层」）。
✦ 本章通关条件
✓
能解释「为什么 LoRA 的优化器状态可以忽略」——因为只随 0.1%~1% 的可训练参数走
✓
知道 14B LoRA ≈ 33GB：48GB 舒适、24GB 装不下 BF16 主干
05

QLoRA —— NF4 存放，BF16 计算，24GB 卡的主战场

LoRA 把 237GB 砍到 33GB，但主干那 29.6GB 还是超了 24GB 卡的门槛。最后一刀砍向主干：存的时候压缩，算的时候还原。

三招

  • ① NF4 存主干：4-bit NormalFloat，专为「权重服从正态分布」设计的信息论最优 4-bit 类型——每参数 0.5 字节，14B 主干从 29.6GB 压到 7.4GB（b 页的「口袋本菜谱」思路，只是这次是给训练用的）。
  • ② 反量化计算：反向穿过冻结层时，把 NF4 权重临时反量化成 BF16 再参与矩阵乘——保证数值上是 16-bit 精度的训练。论文结论：质量不掉档。
  • ③ Paged Optimizers：优化器状态显存吃紧时，借 NVIDIA 统一内存把状态页临时挪到 CPU 内存，避免梯度尖峰时刻 OOM 崩溃。
论文原话级主张查证 2026-09：arXiv:2305.14314QLoRA 让 65B 模型在单张 48GB 卡上完成微调，质量追平 16-bit 全量微调；配套的 Double Quantization 把量化常数本身再量化，65B 上再省约 3GB（每参数约 0.4 bit）。Guanaco 模型即由单卡 24 小时 QLoRA 训出。

14B 的账：10~14GB 区间

QLoRA 口径重算（batch 4×1024、checkpointing 开）：主干 NF4 7.4GB + LoRA 增量与优化器 ≈1.2GB + 激活 ≈2GB = 合计 10.6 GB。上下文或 batch 加大时向 14GB 靠——所以经验区间是 10~14GB：16GB 卡能跑，24GB 卡舒适。

方法主干14B 合计（4×1024，ckpt）16GB 卡24GB 卡48GB 卡
全量 SFTBF16 在训237 GB❌❌❌
LoRABF16 冻结33 GB❌❌✓ 舒适
QLoRANF4 冻结10.6 GB✓ 能跑✓ 舒适✓ 富余
代价是什么速度。每次穿过冻结层都要反量化，QLoRA 的有效吞吐通常只有 LoRA 的五到六成（量级，工具实现差异大）。省下的钱是显存，付出的是墙钟时间——这正是「一张 4090 过夜」而不是「一下午」的原因。

第三幕落地：4090 上的过夜计划

  • 数据：客服日志精选 400 条（c1 的对照卡已过检），8:2 切出 80 条做验证集。
  • 配置：QLoRA（NF4 主干）+ r=16、α=16、lr 2e-4、3 epoch、batch 有效 16（小 batch × gradient accumulation）。查证 2026-09：Unsloth 推荐 LoRA/QLoRA 起步 lr=2e-4、1~3 epoch
  • 时间量级：4090 上每个 epoch 约 0.5~1 小时（量级粗估，取决于上下文长度与工具），3 epoch 两三小时收工——「过夜」是留给人肉检查数据的富余。
  • checkpoint 挑选规则：每个 epoch 存一档，按验证集 loss 挑，不是拿最后一个；留 2~3 个低 loss 候选，人工各抽 20 题盲评再定稿。
  • 交付：选定 adapter 后两种走法——合并回主干出完整模型，或保留 4-bit 主干 + LoRA 运行（省显存，交给 b 页的部署章）。
小自测：QLoRA 里哪些部分是 4-bit，哪些是 16-bit？
存的是 4-bit：冻结主干用 NF4（0.5 字节/参数）。算的是 16-bit：前向/反向时反量化成 BF16 参与计算，LoRA 增量与优化器状态也照旧走 16-bit 口径。「4-bit 存放、16-bit 计算」八个字就是 QLoRA。
✦ 本章通关条件
✓
能说出 QLoRA 三招：NF4 存、反量化 BF16 算、paged optimizer
✓
能给 14B 定方案：24GB 卡 = QLoRA + 几百条样本 + 1~3 epoch，按验证 loss 挑 checkpoint
06

训练显存沙盘 —— 同一个模型的三种命运

原理讲完，把它装进一台「沙盘」：选模型 × 选方法 × 拨开关，看显存账单、卡判定和训练时长怎么联动。重点体验切方法的那一下——全量 ❌ → LoRA ⚠️ → QLoRA ✅。

交互 C2 · 训练显存沙盘全部账单调用 calc.js · 数据截至 2026-09
主干（LoRA/QLoRA 冻结存放）权重+梯度（全量时全部在此格）优化器状态激活剩余（相对所选卡）
显存需求合计—
判定（可用含 5% 系统余量）—
可训练参数占比—
相对训练速度—
≈ 每 epoch（4090 口径）—
剧情预设 →

trainBreakdownGB + activationGB + verdict 现场计算；速度/时长为量级粗估（全量=1.0、LoRA≈0.9、QLoRA≈0.5；ckpt 再 ×0.75；MFU 0.35 的 4090 参照），非精确基准。
✦ 本章通关条件
✓
亲手把 14B 从全量切到 QLoRA，说清 237GB → 10.6GB 里每一项怎么变小的
✓
知道 70B 即使 QLoRA 也要 ~46GB：48GB 勉强、80GB 舒适
07

终极测验 —— 五题出师

5 题验收。答对 4 题，你就有底气在评审会上对「上四张 A100 全量微调」的方案说不，也对「把公司文档全喂给模型微调」的需求说不。

FINAL EXAM · FINE-TUNING0 / 5
✦ 本章通关条件
✓
测验拿到 4 / 5 以上
08

参考资料 · References

本页所有账单由目录下 calc.js 统一计算（四页共享，避免 a/c/d 数字打架）。以下论文与文档为口径出处，链接核对于 2026-09。

论文

  • LoRA: Low-Rank Adaptation of Large Language Models — Hu et al., 2021 · 低秩假设、r/α 口径 · arXiv:2106.09685 查证 2026-09
  • QLoRA: Efficient Finetuning of Quantized LLMs — Dettmers et al., 2023 · 65B 单卡 48GB、NF4、Double Quantization（约省 0.4 bit/参数）、Paged Optimizers · arXiv:2305.14314 查证 2026-09
  • ZeRO: Memory Optimizations Toward Training Trillion Parameter Models — Rajbhandari et al., 2020 · 混合精度 + Adam 每参数 16 字节的出处（2+2+4+4+4）· arXiv:1910.02054 查证 2026-09
  • FSDP / PyTorch ZeRO 系列 — Zhao et al., 2023 · arXiv:2304.11277 查证 2026-09
  • LIMA: Less Is More for Alignment — Zhou et al., 2023 · 1000 条精样本 + 表面对齐假说 · arXiv:2305.11206 查证 2026-09
  • Intrinsic Dimensionality Explains the Effectiveness of Language Model Fine-Tuning — Aghajanyan et al., 2020 · 低秩假设的前身 · arXiv:2012.13255 查证 2026-09
  • （反方观点）Revisiting the Superficial Alignment Hypothesis — 2024 · 对齐不止是学格式 · arXiv:2410.03717 查证 2026-09
  • RAG: Retrieval-Augmented Generation — Lewis et al., 2020 · 「知识放外部检索、不进参数」路线的出处（02 章选型框架的原型）· arXiv:2005.11401 查证 2026-09

文档与工具（2026 年微调三件套的一句话定位）

  • Unsloth — 重写内核，单卡速度与显存效率首选；其LoRA 超参指南是 lr 2e-4 / 1~3 epoch 建议的出处 查证 2026-09
  • LLaMA-Factory — WebUI 工作流友好，适合不写代码的微调（内部可挂 Unsloth 后端）· GitHub 查证 2026-09
  • Axolotl — YAML 驱动、多卡/分布式配置可复现性强 · GitHub 查证 2026-09
  • Hugging Face PEFT（LoRA/QLoRA 官方实现）· huggingface.co/docs/peft；TRL（SFT/DPO Trainer）· huggingface.co/docs/trl 查证 2026-09
  • bitsandbytes（NF4 / 8-bit optimizer 的实现库）· huggingface.co/docs/bitsandbytes 查证 2026-09