LLamaFactory 微调实战

LLamaFactory 微调实战

仓库地址

https://github.com/hiyouga/LlamaFactory?tab=readme-ov-file

本次任务是训练llm 抽取query中的实体

微调种类

llamafactory 目前是支持这些种类的微调

  • 列(Full / Freeze / LoRA / QLoRA / OFT / QOFT):讲的是“怎么更新参数”(参数高效微调 PEFT vs 全量微调)。
  • 行(SFT / Reward Modeling / PPO / DPO / KTO / ORPO / SimPO):讲的是“用什么训练目标/数据形式”(监督、偏好、RL 等)。

怎么更新参数

1) Full-tuning(全量微调)

做法:模型所有参数都更新。
优点

  • 表达能力最强,理论上效果上限最高(尤其是你要强改模型行为/风格/能力时)。
  • 训练/推理代码最简单(不用插 LoRA 模块)。
    缺点
  • 显存、训练成本最高;多卡/ZeRO/FSDP 常见。
  • 容易“灾难性遗忘”,也更容易把模型训歪(数据不够干净时)。
    什么时候用:数据量大、预算足、你想做“真正的模型版本迭代”。

2) Freeze-tuning(冻结主干,只训少量模块)

做法:大部分参数冻结,只训练很少一部分(常见:最后几层、LayerNorm、Adapter、小 head)。
优点

  • 成本低、稳定、不太容易把模型训崩。
    缺点
  • 可塑性有限,效果上限通常不如 LoRA/全量。
    什么时候用:快速适配、资源很紧、或者你只想“轻微对齐/轻微迁移”。

3) LoRA(最常用的 PEFT)

做法:冻结原权重,在注意力/MLP 的线性层旁边加一对低秩矩阵 A,B,只训练这部分“增量”。
优点

  • 性价比极高:显存大幅下降,效果通常接近全量微调(尤其做 SFT / DPO 这类)。
  • 可以为同一个基座模型保存多套 LoRA(切换任务很方便)。
    缺点
  • 仍然需要基座模型以 FP16/BF16 方式加载训练(比 QLoRA 贵)。
    什么时候用:几乎所有“常规微调”默认首选(SFT、DPO、ORPO、SimPO…都很常见)。

4) QLoRA(LoRA + 4bit 量化训练:超省显存)

做法:基座权重量化到 4bit(常见 NF4),仍然只训练 LoRA 参数;计算中用一些技巧保证训练稳定。
优点

  • 显存最省:单卡也能训更大的模型(比如 13B/34B 更现实)。
    缺点
  • 训练更“工程化”:依赖 bitsandbytes / 量化算子,速度可能慢一点,偶尔有数值/兼容坑。
  • 极端情况下效果可能比 LoRA 略差一点点,但很多任务差距不大。
    什么时候用:你想在有限 GPU 上把模型尺寸顶上去——现在非常非常常用

用什么训练目标/数据形式

1) SFT(Supervised Fine-Tuning)

数据:(prompt,response)(prompt, response)(prompt,response) 的标准监督数据(指令-答案)。
在干嘛:最大化参考答案的似然(cross-entropy)。
优点:最简单、最稳、最常用的第一步;能快速让模型“会按指令说话”。
缺点:只能学到“数据里长什么样”,不直接优化偏好/安全/有用性;数据质量决定上限。

一句话:把模型训练成“像数据集里的优秀助教”。


2) Reward Modeling(RM,奖励模型/偏好模型)

数据:偏好对比(同一 prompt 下 A vs B,标哪个更好),或打分数据。
在干嘛:训练一个 r(x,y)去预测“人类更喜欢哪个回答”。
用途:RM 本身不是最终模型,而是给后面的 RL(比如 PPO)提供 reward。
优点:把“人类偏好”变成可优化的标量信号。
缺点:训练/维护一个额外模型;reward 容易被“钻空子”(reward hacking)。

一句话:先学会“怎么评卷”,再用它指导学生练习。


3) PPO Training(经典 RLHF 的 RL 阶段)

数据:prompt(模型自己采样回答),再用 RM 给 reward。
在干嘛:用 PPO 最大化 reward,同时用 KL 约束别偏离原模型太多(稳定训练)。
优点:能直接优化“偏好得分”;在一些场景能带来明显提升。
缺点成本最高、最难调(采样+RL 不稳定);对实现细节很敏感。

一句话:真正“用奖励做强化学习”,但工程最重。

4) DPO/KTO/ORPO/SimPO 偏好优化

DPO(Direct Preference Optimization)— 现在超常用

数据:偏好对 (x,y+,y−)(同一 prompt 下更好/更差)。
在干嘛不训练 RM、不跑 PPO,直接用一个“对比式”的目标让模型更偏向 y+而不是 y−。
优点:实现简单、训练稳定、效果强;很多团队用它替代 PPO。
缺点:仍然依赖高质量偏好数据;对“偏好覆盖面”敏感。

一句话:用“更像好答案、远离差答案”的概率比,直接把模型拉过去。

KTO(偏好优化的另一种口味)

数据:可以用偏好对,也常见“单条回答 + 好/坏标签”(不一定要成对)。
在干嘛:用更简单的方式把“好/坏反馈”变成优化信号(比 DPO 在某些数据形态上更灵活)。
优点:当你只有“这条好/这条不好”的反馈时更方便。
缺点:生态和默认程度不如 DPO;不同实现细节差异较大。

一句话:不强依赖成对比较的偏好优化方案。

ORPO / SimPO(更“轻量”的偏好优化变体)

它们可以理解为:把 SFT 和偏好项合在一个目标里(或者让偏好目标更简洁/更好训)。
优点:训练更省事、更稳,很多时候能拿到接近 DPO 的收益。
缺点:不同论文/实现差异大;不一定在所有任务上都稳赢 DPO。

一句话:更像“带偏好项的 SFT++”。

环境配置

我走的环境是docker

hiyouga/llamafactory:latest

 注意这个docker 拉下来自带llamafactory代码,不过因为权重放本地了所以我还是挂载本地目录了

/workspace/code/LlamaFactory

数据处理

具体看 readme_zh.md 

总之自定义数据记得往 dataset_info 里面塞个

训练参数

lora

--lora_rank

rank (r) 是 LoRA 低秩矩阵的秩,决定 LoRA 的“容量”。

  • LoRA 把一个线性层的权重更新写成:ΔW=BA
    其中 A∈Rr×d, B∈Rd′×r
  • r 越大 → 可学习参数更多 → 更能拟合你的任务,但更占显存、也更容易过拟合。

经验:

  • 轻任务/小数据:r=4/8
  • 多一点规则/结构化输出:r=16 常用
  • 很难的迁移/很大数据:r=32/64 才可能有意义

--lora_alpha 

alpha 是 LoRA 的缩放系数,控制 LoRA 更新幅度。

常见实现里会用一个缩放:

  • alpha 大 → LoRA 更新更“猛”
  • alpha 小 → 更新更“温和”

经验:

  • 经典搭配:alpha = 2*r(比如 r=16 → alpha=32),很常见、也比较稳。
  • 如果你发现模型输出开始乱飘/格式崩:可以减小 alpha 或学习率。

--lora_target

这个决定:LoRA 插到哪些线性层上(也就是你让哪些模块“可塑形”)

注意力层(Attention)

q_proj, k_proj, v_proj:把 hidden 投影成 Q/K/V

o_proj:注意力输出再投影回去

这些层决定模型“怎么注意、注意谁”,对改行为很有效。

前馈层(MLP / FFN)

gate_proj, up_proj, down_proj:对应 LLaMA/Qwen 这类常见的 gated-MLP 结构
MLP 是模型的“计算/表达”主力,占参数也多,给它上 LoRA 通常会更有力。

为什么不建议 lora_target all

all 会把一堆不关键的层也插 LoRA,慢、占用多、还可能不稳

常见默认就是只打在 attention + MLP 这些“最值钱”的线性层

调参技巧

想更准 / 规则更复杂:先加 rank(8 → 16),再看是否要加 alpha

输出格式容易崩:降低 learning_rate 或降低 alpha/r(比如 alpha=16 或 lr 从 5e-5 降到 2e-5)

过拟合(train 好、dev 差):加 dropout(0.05 → 0.1)或减 rank

evaluation

因为数据比较结构化,所以我就拿acc 来计算的

--do_eval \  # evaluation= True

--eval_strategy steps \ #拿步为单位,否则epoch

--eval_steps 20 \ 

--compute_accuracy true \   #是否计算acc

--val_size 0.1 \  #数据集划分

Read more

前端 SSG:别让你的网站加载速度慢得像蜗牛

前端 SSG:别让你的网站加载速度慢得像蜗牛 毒舌时刻 这网站加载速度慢得能让我泡杯咖啡回来还没好。 各位前端同行,咱们今天聊聊前端 SSG(静态站点生成)。别告诉我你还在使用纯客户端渲染,那感觉就像在没有预加载的情况下开车——能开,但起步慢得要命。 为什么你需要 SSG 最近看到一个项目,每次加载都要重新获取数据,用户体验差。我就想问:你是在做网站还是在做实时应用? 反面教材 // 反面教材:纯客户端渲染 // App.jsx import React, { useState, useEffect } from 'react'; function App() { const [posts, setPosts] = useState([]); const [loading, setLoading] = useState(true); useEffect(() => { async function fetchPosts() { setLoading(

2026年最新全球AI大模型深度研究报告

2026年最新全球AI大模型深度研究报告 文章目录 * 2026年最新全球AI大模型深度研究报告 * 摘要 * 第一章 全球AI大模型发展概况 * 1.1 全球AI发展格局:中美双极引领 * 1.2 市场规模与增长趋势 * 1.3 发展阶段特征 * 第二章 核心技术突破分析 * 2.1 主流大模型最新进展 * 2.1.1 美国阵营 * 2.1.2 中国阵营 * 2.2 核心技术突破方向 * 2.2.1 多模态能力 * 2.2.2 长上下文处理 * 2.2.3 推理能力 * 2.2.4 Agent能力 * 2.2.

AI全栈之路:Cursor+Claude3.7一整套APP原型图UI生成

AI全栈之路:Cursor+Claude3.7一整套APP原型图UI生成

背景 对于大部分工作三年的开发者来说,技术栈不在是瓶颈,从一门语言到另一个门语言,从一个技术栈到另一个技术栈,只需要投入一两周的时间就可以快速入门,从前端、移动端到后端,甚至数据分析,算法,从TS、Java、GO到C++,有了一门技术的基础再学习另一门技术会快很多,很多时候缺乏的是实战了和规模化的用户经验,不过在AI时代,这都不是问题了。 AI IDE(Cursor、trae)可以让我们在只使用自然语言描述需求后快速帮助我们实现对应端的工程代码,还可以帮助我们实现部署。技术上的问题绝大部分都可以通过AI帮助我们解决。卡在我们全栈路上的另一个问题是UI设计稿的问题。对于前端或者移动端开发来讲,尤其是移动端,强依赖设计稿帮我们实现美观的应用。但是从工程师到UI设计师的迁移跨度就太大了,一时半会没有办法快速迁移。目前市面上虽然也有一些生成设计稿的AI工具,但是效果差强人意。本文我们介绍一种“曲线救国”方式的设计稿生成方式,帮助我们快速生成UI设计稿,进一步实现全栈开发运营自己的作品之路。 先上一张效果图: Claude 生成骑行应用H5 Claude直接生成Figma等UI设计稿比

【AI 大模型】LangChain 框架 ① ( LangChain 简介 | LangChain 模块 | LangChain 文档 )

【AI 大模型】LangChain 框架 ① ( LangChain 简介 | LangChain 模块 | LangChain 文档 )

文章目录 * 一、LangChain 简介 * 1、LangChain 概念 * 2、LangChain 定位 * 3、LangChain 开发语言与应用场景 * 4、LangChain 核心组件 * 5、LangChain 学习路径 * 二、LangChain 模块 * 1、模型输入 / 输出 ( Models ) * 2、提示词模板 ( Prompts ) * 3、索引 ( Indexes ) * 4、链 ( Chains ) * 5、记忆 ( Memory ) * 6、代理 ( Agents ) * 7、 工具 ( Tools ) * 8、 文档加载器 ( Document Loaders ) * 9、评估