微调方案选型题

一、选型决策框架

面试中遇到微调方案选型题，使用以下四步法：

1. 明确需求：任务类型、数据量、预算、延迟要求、多任务需求
2. 列出候选方案：全参数微调、LoRA、QLoRA、DoRA、PiSSA
3. 对比分析：从成本、质量、速度、灵活性维度对比
4. 给出推荐：有理有据地推荐具体方案

二、核心对比表

三、典型面试场景

场景 1：垂类领域微调（如医疗问答）

面试话术： "对于医疗问答场景，我推荐 QLoRA 方案。原因：1) 医疗数据通常有限（10K-50K 条），QLoRA 的低秩约束反而有助于防止过拟合；2) 医疗领域需要部署成本控制，QLoRA 单卡即可训练；3) 质量要求高但不需要改变模型的通用能力，QLoRA 冻结基座模型，保留了通用能力。"

具体配置：

• 基座模型：LLaMA 3.1 70B 或 Qwen 2.5 72B
• 量化：4-bit NF4
• LoRA rank=64, alpha=128
• 目标模块：q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj
• 学习率：2e-5，cosine schedule
• 训练 3 epoch

场景 2：多租户 SaaS 平台

面试话术： "多租户场景核心需求是：每个客户有独特的风格和知识，但共享基座能力。我推荐 LoRA + S-LoRA 服务方案。每个客户训练一个独立的 LoRA 适配器，服务端用 S-LoRA 同时管理数千个适配器。好处：1) 共享基座模型节省 GPU；2) 适配器独立更新互不影响；3) 新客户只需训练一个小适配器。"

架构设计：

客户端请求 -> API Gateway -> 路由层（根据 tenant_id 选适配器）
  -> S-LoRA 服务（基座模型 + 动态加载适配器）
  -> 响应返回

场景 3：大规模领域适配

面试话术： "如果领域与预训练数据差异巨大（如古文翻译、小语种），可能需要全参数微调。LoRA 的低秩约束可能不足以捕捉领域分布的变化。但我会先用 QLoRA 做基线实验，如果质量不够再升级到全参数微调。全参数微调时使用 DeepSpeed ZeRO-3 + gradient checkpointing 降低显存。"

场景 4：代码助手微调

面试话术： "代码助手需要高质量的代码理解和生成能力。推荐 QLoRA + 代码数据微调。数据上，使用高质量的代码指令数据（如 Code Alpaca、自造的代码解释数据）。训练时特别关注代码格式的一致性。推理时使用 vLLM 服务 + 前缀缓存（共享系统提示）。"

四、选型决策树

任务是否需要改变模型核心能力？
  ├── 是 -> 全参数微调或 DoRA
  └── 否 -> 资源是否充足？
            ├── 充足 -> LoRA (BF16)
            └── 不足 -> QLoRA (4-bit)
                  └── 是否多任务？
                        ├── 是 -> LoRA + S-LoRA
                        └── 否 -> 单个 QLoRA 适配器

五、常见面试追问

Q: "LoRA 的 rank 怎么选？" "A: rank 越高表达能力越强但参数更多。通常从 r=16 开始实验。简单任务（风格微调）r=8 足够；复杂任务（领域适配）r=32-64；如果 r=64 还不够，考虑全参数微调。"

Q: "LoRA 应该应用在哪些层？" "A: 通常应用于所有线性层（Q/K/V/O + FFN 的 up/down/gate）。有研究表明仅应用于 attention 层也可以，但应用于更多层效果更好。"

Q: "如何评估微调效果？" "A: 三层评测：1) 自动基准（MMLU、HumanEval 等通用能力 + 领域专用测试集）；2) LLM-as-a-Judge 评估目标领域输出质量；3) 人工评估（领域专家打分）。重点是确保微调目标领域提升的同时，通用能力不退化。"