面经策

什么是全量微调？它有哪些优缺点？ ​

  • 标签：

🏛 业务架构师 ​

全量微调（Full Fine-Tuning）指更新预训练模型的全部参数，是效果上限最高的适配方式。

优点：

  1. 能力上限最高：模型可深度重塑行为，能学会 LoRA 学不动的复杂任务范式（深度领域推理、新的输出结构）；
  2. 知识注入能力最强：配合继续预训练可吸收领域语料（虽然我仍主张事实知识放 RAG）；
  3. 无推理架构负担：训完就是一个完整模型，不需要管理适配器组合。

缺点：

  1. 成本高：7B 模型需 8×80GB 级集群，一次训练数千到上万元；数据需求十万级样本；
  2. 灾难性遗忘风险大：全参数更新，通用能力容易被动摇，必须配回放数据和双评测；
  3. 资产管理负担：每个场景一整份模型（几十 GB），存储、版本、分发、回滚成本都重；
  4. 试错贵：效果不好重训一轮的钱和时间都翻倍。

业务判断：全量微调是"重武器"，只在三种情况下值得动用——基座能力确实不够且已验证 LoRA 天花板；该模型是核心产品、调用量巨大到任何效果提升都值回票价；要做的是"继续预训练"级别的深度领域化（医疗、法律基座）。其余 90% 场景，LoRA 系方案是理性选择。我的原则：先证明简单方法不行，再上复杂手段——每一级复杂度的跃升都应该由前一级的失败数据来批准。

🏗 系统架构师 ​

全量微调 = 解冻并更新模型全部参数，我按"优缺点 + 适用判断"讲：

优点：

  • 效果上限最高：整个参数空间可塑——能注入新知识体系（继续预训练必须全量）、深度重塑行为模式、对齐与原分布差异巨大的任务；
  • 无架构副作用：不需要考虑秩、目标模块这些 LoRA 超参，大数据量下训练动力学更直接。

缺点：

  • 资源重：显存 ≈ 16 bytes/参数（权重+梯度+Adam 状态+fp32 主副本），7B 要 112GB+（多卡）、70B 要 TB 级（集群 + ZeRO/FSDP 分片）；训练时间长，迭代慢；
  • 产物重：每个任务一份完整模型副本（几十~几百 GB），存储、分发、版本管理成本高，无法多任务共享底座；
  • 易灾难性遗忘：必须靠数据混合、小学习率等手段防御；
  • 迭代周期长：一次实验以天计，数据试错吞吐低。

我的适用判断：三条件同时满足才上全量——(1) LoRA + 好数据已到天花板且差距明确；(2) 任务需要注入知识或深度改造（不是格式风格适配）；(3) 有集群算力和工程团队。其余 90% 场景 LoRA/QLoRA 是更理性的选择——微调项目的瓶颈通常是数据质量，不是参数更新比例。

💻 全栈开发专家 ​

全量微调（Full Fine-tuning）：解冻并更新模型全部权重。

优点：

  1. 效果上限最高：容量全开，任务与基座分布差异大时（新领域、新语言、CPT）只有它能拉满；
  2. 能深度重塑行为：不只是「适配」，可以改变模型的知识分布和推理风格；
  3. 不需要推理侧做任何特殊处理（相对 Adapter 类方案），产出就是标准权重。

缺点：

  1. 贵：显存 ≈ 参数量×16 字节，7B 要 100GB+（A100×2 起），70B 要 8 卡以上；训练时间长；
  2. 易灾难性遗忘：必须混通用数据回放、小学习率，调参经验要求高；
  3. 多任务部署笨重：每个任务一份完整权重（7B×N 份 14GB），存储、加载、切换都痛；
  4. 门槛高：分布式训练（DeepSpeed ZeRO-2/3、FSDP）、梯度检查点这些工程配套一个不能少。
bash
deepspeed --num_gpus=8 train.py --deepspeed ds_config_z3.json \
    --learning_rate 1e-5 --bf16

我的判断框架：业务微调默认不碰全量——LoRA/QLoRA 能覆盖 90%+ 需求且便宜一个量级；只有三种情况认真评估全量：继续预训练灌领域知识、任务与基座差异巨大且 PEFT 验证确实不够、以及就是要发领域的基座模型。评估时把「数据准备好了吗」（万级高质量）和「算力预算」放最前面，全量微调失败项目多半输在这两样，而不是技术。