大模型微调 PEFT vs LLaMA-Factory

大模型微调 PEFT vs LLaMA-Factory:两种微调(SFT)模式深度对比与原理解析

在 LLM(大语言模型)微调的圈子里,开发者通常会接触到两种截然不同的流派:一种是原生代码流,即直接使用 HuggingFace Transformers 和 PEFT 库编写 Python 代码;另一种是框架工具流,以 LLaMA-Factory 为代表的集成化工具。


一、 两种微调模式简介

1. PEFT

核心逻辑:开发者需要自己处理数据清洗、Tokenizer 编码、Label Masking(标签掩码)、模型加载、LoRA 配置挂载以及训练循环。

2. LLaMA-Factory

这是目前工业界和学术界快速迭代的首选。
核心逻辑:将上述繁琐的代码封装成“黑盒”,通过配置驱动(YAML 或 命令行参数)来控制训练。


二、 核心实现流程对比

为了直观对比,我们以 Qwen (通义千问) 模型的 LoRA 微调为例。

1. 数据预处理 (最本质的区别)

PEFT数据预处理:
你需要手动编写函数来处理 Prompt 格式(如 <|im_start|>)和 Loss 计算逻辑(Masking)。

# 摘自微调 Notebook:手动处理对话模板和掩码defpreprocess_multi_turn_qwen(example):# ... 省略部分代码 ...for msg in convs:# 手动添加特殊 Token prefix =f"<|im_start|>{role}\n"# 编码 prefix_ids = tokenizer(prefix, add_special_tokens=False)["input_ids"] content_ids = tokenizer(content, add_special_tokens=False)["input_ids"]# 核心难点:手动控制 Label,-100 表示不计算 Lossif role =="assistant":# 只有机器人的回答计算梯度 turn_labels =[-100]*len(prefix_ids)+ content_ids + suffix_ids else:# 用户和 System 的话不计算梯度 turn_labels =[-100]*len(current_turn_ids)return{"input_ids": input_ids,"labels": labels}

LLaMA-Factory:
不需要关心 input_ids 怎么拼,只需要指定模板名称。

# 命令行参数--template qwen 

原理: 框架内部维护了一套 template 注册表,自动帮你完成了上述 Python 代码中复杂的 Token 拼接和 Label Masking 工作。


2. 模型加载与 LoRA 挂载

PEFT:
需要显式地定义配置,并手动修改模型结构。

from peft import LoraConfig, get_peft_model # 1. 定义配置 config = LoraConfig( task_type=TaskType.CAUSAL_LM, target_modules=["q_proj","k_proj","v_proj","o_proj"], r=8, lora_alpha=16)# 2. 加载基座模型 model = AutoModelForCausalLM.from_pretrained(...)# 3. 挂载 model = get_peft_model(model, config) model.print_trainable_parameters()# 打印参数量

LLaMA-Factory :
参数化配置,自动寻找目标模块。

--finetuning_type lora \--lora_rank8\--lora_alpha16\--lora_target all # 自动识别所有线性层

3. 训练

PEFT:
使用 HF Trainer。如果想用高级功能(如 DeepSpeed、FlashAttention、QLoRA),你需要自己写代码配置 TrainingArgumentsBitsAndBytesConfig,非常容易报错(如 OOM、类型不匹配)。

LLaMA-Factory:
开箱即用。

  • 省显存--flash_attn auto
  • 量化--quantization_bit 4
  • 可视化--plot_loss True
  • 强化学习:直接把 --stage sft 改成 --stage dpo 即可无缝切换算法。

模型微调过程中的关键参数:
1、r ( 秩 ):LoRA采用的低秩分解矩阵,关键的一个参数就是矩阵的秩r, 表示这个矩阵蕴含多少有用的信息。
2、alpha (涉及权重矩阵的更新幅度): alpha/r * BA, 可知alpha可以控制lora微调权重的幅度,可以是r的2倍或者4倍。
3、target_modules ( 微调的模块 ): 一般模型微调,调整的可能只有q_proj、k_proj、v_proj这三个权重矩阵,如果考虑微调FFN层,也可以增加up_proj、down_proj层。当然,如果你在微调过程中,想要实现让非思考模型先思考再输出,可以考虑增加特殊token,如果一旦增加特殊的token之后,一定要调整Emedding层embed_tokens,不然非常可能会输出乱码(采样概率相差不大导致的)。
4、dropout率:避免模型微调训练过拟合。


三、 深度对比总结表

维度PEFTLLaMA-Factory
上手难度⭐⭐⭐⭐ (高)⭐⭐ (低)
灵活性极高 (可修改模型底层前向传播)中等 (受限于框架提供的参数)
数据处理白盒 (完全透明,需手写逻辑)黑盒 (模板化,依赖 preset)
多轮对话需手写复杂的掩码(Mask)逻辑自动处理 user/assistant 掩码
高级特性需手动集成 DeepSpeed/FlashAttn一键开启,集成度高
算法切换SFT转DPO需要重写大量代码修改 --stage 参数即可
Debug难度容易出现 Tensor 形状对齐错误主要是环境依赖报错

四、PEFT与LlamaFactory在Autodl的实现

PEFT:
1、手动提前下载模型,可以提前配置ModelScope的镜像源
2、数据预处理,按照模型的chat模板构造数据集并Tokenization化
3、配置微调的LoRA参数
4、向模型中添加LoRA模块
5、可以通过Swanlab可视化训练过程
参考:PEFT微调

LlamaFactory:
命令行执行:
1、使用modelscope镜像源下载模型

exportUSE_MODELSCOPE_HUB=1

2、使用命令行执行训练,下面是具体参数(DPO,强化学习微调):

llamafactory-cli train \--stage dpo \--do_train True \--model_name_or_path qwen/Qwen2.5-0.5B-Instruct \--finetuning_type lora \--template qwen \--dataset dpo_zh_demo \--dataset_dir data \--output_dir saves/Qwen2.5-0.5B-Instruct/lora/train_dpo_fix \--cutoff_len1024\--per_device_train_batch_size1\--gradient_accumulation_steps16\--learning_rate 5e-5 \--num_train_epochs3.0\--lr_scheduler_type cosine \--logging_steps5\--save_steps100\--fp16 True \--gradient_checkpointing True \--lora_rank8\--lora_alpha16\--lora_target all \--pref_beta0.1\--plot_loss True \--trust_remote_code True 

3、微调之后需要加载lora微调后的参数和原始权重,进行Chat对话:

llamafactory-cli chat \--model_name_or_path Qwen/Qwen2.5-0.5B-Instruct \--adapter_name_or_path saves/Qwen2.5-0.5B-Instruct/lora/train_dpo_fix \--template qwen \--finetuning_type lora 

五、 结语

LLaMA-Factory 本质上就是一套写得非常健壮、非常全面的“原生代码”

它在底层依然调用了 transformerspeft。对于初学者,建议先用 LLaMA-Factory 跑通全流程,建立信心;当你发现框架无法满足你的魔改需求时,再深入阅读源码或编写自己的 Training Script。

提示:在使用 LLaMA-Factory 时,如果遇到报错,往往是因为环境变量或依赖版本问题(如 CUDA 版本不匹配);而在使用原生代码时,报错通常是因为 Tensor 维度不匹配或显存溢出。

Read more

Magic API:低代码接口开发平台完全指南

Magic API:低代码接口开发平台完全指南

Magic API:低代码接口开发平台完全指南 🌟 你好,我是 励志成为糕手 ! 🌌 在代码的宇宙中,我是那个追逐优雅与性能的星际旅人。 ✨ 每一行代码都是我种下的星光,在逻辑的土壤里生长成璀璨的银河; 🛠️ 每一个算法都是我绘制的星图,指引着数据流动的最短路径; 🔍 每一次调试都是星际对话,用耐心和智慧解开宇宙的谜题。 🚀 准备好开始我们的星际编码之旅了吗? 目录 * Magic API:低代码接口开发平台完全指南 * 摘要 * 1. Magic API概述与核心概念 * 1.1 什么是Magic API * 1.2 Magic API的核心特性 * 1.3 Magic API的设计理念 * 2. Magic API架构设计与组件分析 * 2.1 整体架构概览 * 2.2 API引擎工作原理 * 2.3 脚本引擎与SQL执行机制 * 3. Magic API核心功能实现

AI绘画新玩法:DCT-Net线稿上色,云端GPU双模型协作

AI绘画新玩法:DCT-Net线稿上色,云端GPU双模型协作 你是不是也遇到过这种情况:想把自己的照片变成动漫角色,或者把一段视频转成日漫风格,结果刚跑完卡通化模型,显存就爆了,根本没法继续下一步?尤其是对于做漫画创作的朋友来说,先卡通化再上色是标准工作流,但本地设备往往“卡”在第一步就动弹不得。 别急——今天我要分享一个超实用的AI绘画新玩法:用DCT-Net完成人像卡通化后,无缝衔接线稿提取与自动上色,实现云端双模型协作流水线。整个过程不需要高性能电脑,也不用手动导出导入文件,在ZEEKLOG星图镜像广场提供的预置镜像支持下,一键部署、自动串联、全程GPU加速,真正解决“本地显存不够”的痛点。 这篇文章专为技术小白和内容创作者设计。无论你是想批量生成二次元形象的UP主,还是希望提升效率的漫画助手,都能通过本文快速搭建属于自己的“云端AI画室”。学完之后,你可以: * 理解DCT-Net是什么、能做什么 * 掌握如何在云端部署卡通化+上色双模型流程 * 实现从原始图片到完整彩色动漫图的一键生成 * 避开常见坑点,优化资源使用和输出质量 准备好了吗?我们马上开始!

openclaw多agent对接飞书机器人

本文介绍了基于飞书的多Agent系统架构设计,通过OpenClaw Gateway实现飞书应用与AI Agent的对接。系统采用多Agent架构,每个飞书机器人对应独立的AI Agent,拥有专属的工作空间、知识库和模型配置。         本文可以参考的内容: * 多agent对接单个飞书账号 * openclaw多agent群聊 * 飞书机器人群聊 * 多agent数据隔离 * 多agent单独安装skills         隔离性说明: * 每个 Agent 的模型状态完全独立 * 每个 agent 对应一个飞书机器人 * 每个 agent 的技能单独安装维护 * 模型切换仅对当前会话生效(持久化到 Agent 配置) * 严格隔离:每个 Agent 独立 workspace 和 data 添加新的 agent # 添加agent openclaw agents add finance_agent #openclaw agents add code_agent # 设置身份

【Agent】Claude code辅助verilog编程

【Agent】Claude code辅助verilog编程

摘要:在 2026 年,硬件描述语言(HDL)的开发门槛正在被 AI 重新定义。本文记录了一次硬核挑战:在不查阅任何寄存器手册、不手画状态转移图的情况下,仅凭 Claude Code 辅助,完成了一个包含 UART 通信、协议解析(FSM)及 PWM 控制的完整 FPGA 模块设计与验证。这是一次关于“AI 辅助芯片设计”的真实压力测试。 目录 1. 引言:Verilog 开发者的“中年危机” 2. 项目挑战:从串口到 LED 的全链路设计 3. 开发实录:Claude Code 的 RTL 设计能力 * 3.1