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

Llama 3-8B-Instruct 在昇腾 NPU 上的 SGLang 性能实测

Llama 3-8B-Instruct 在昇腾 NPU 上的 SGLang 性能实测

1.引言 随着大模型在各类智能应用中的广泛应用,高效的推理硬件成为关键瓶颈。昇腾 NPU(Ascend Neural Processing Unit)凭借其高算力、低能耗以及对 SGLang 的深度优化,能够显著提升大模型推理性能。本文以 Llama 3-8B-Instruct 为例,通过在昇腾 NPU 上的实测,展示其在吞吐量、延迟和资源利用方面的优势,并探索可行的优化策略,为开发者在今后的开发中提供可参考的案例。 在本篇文章中我们会使用到Gitcode的Notebook来进行实战,GitCode Notebook 提供了开箱即用的云端开发环境,支持 Python、SGLang 及昇腾 NPU 相关依赖,无需本地复杂环境配置即可直接运行代码和进行实验。对于没有硬件平台的小伙伴来说是非常便利的。 GitCode Notebook使用链接:https://gitcode.com/user/m0_49476241/notebook。 2.实验环境与准备 2.

RAG 五大应用场景(三)企业级 Code RAG 与代码库 Copilot 深度架构指南

RAG 五大应用场景(三)企业级 Code RAG 与代码库 Copilot 深度架构指南

文章目录 * 1. 引言:为什么你的代码助手总是“差点意思”?——一场凌晨 2 点的生产力惨案 * 2. 核心洞察:代码是图,不是文本 —— 为什么传统切分必“翻车”? * 2.1 “文本刀法”的三大原罪 * 1. 语义连贯性被物理斩断(Semantic Decapitation) * 2. 噪声泛滥与上下文窗口的极度浪费(Context Pollution) * 3. 依赖缺失:硬伤中的硬伤(Missing Dependencies) * 3. 技术范式转移:引入 Tree-sitter 与 AST 结构化索引 * 3.1 降维打击的武器:Tree-sitter * 3.2 节点元数据(Metadata)建模:构建代码知识图谱 * 3.3

【全网最全・保姆级】Stable Diffusion WebUI Windows 部署 + 全套报错终极解决方案

大家好,我是在部署 SD WebUI 过程中把几乎所有坑都踩了一遍的选手,从 Git 报错、模块缺失、依赖冲突到虚拟环境异常,全部踩完。今天把完整安装流程 + 我遇到的所有真实错误 + 一行一解全部整理出来,写成一篇能直接发 ZEEKLOG 的完整文章。 一、前言 Stable Diffusion WebUI 是目前 AI 绘画最主流的本地部署工具,但 Windows 环境下因为 Python 版本、虚拟环境、Git 仓库、依赖包、CLIP 编译 等问题,90% 的新手都会启动失败。本文包含: * 标准 Windows 一键部署流程 * 我真实遇到的 10+ 种报错 * 每一种报错的 原因 + 直接复制可用的命令 * 最终测试出图提示词(

Claude Code 的完美平替:OpenCode + GitHub Copilot(顶级模型+最优价格)

引言:Claude 虽好,但你真的能用上吗? 在当前席卷全球的“Vibe Coding”浪潮中,Anthropic 推出的 Claude 系列模型 + 终端工具 Claude Code,凭借极强的逻辑推理能力,成为了开发者眼中的“白月光”。但现实是残酷的:对于中国开发者而言,账号随时被封、海外信用卡支付遭拒、API 额度受限以及复杂的网络环境,构成了一道难以逾越的门槛。 虽然最近国产编程模型不断发力,Claude Code + GLM-4.7 的表现非常出色,但面对复杂问题,Claude系列模型依然完胜。难道我们只能眼馋Claude全家桶的编程体验吗? 作为一名追求极致生产力的开发者,我发现了一个绝佳的完美替代方案:OpenCode + GitHub Copilot。这个组合不仅能让你享受如 GLM-4.7 一样的性价比,还能更方便的使用 Claude 的顶级模型。 Claude Code 的开源平替:OpenCode