DPO实战：基于Qwen的偏好对齐训练全解析

对齐训练这件事，以前在社区里聊起来总绕不开一套“五件套”：SFT、奖励模型、PPO、四个模型同时跑、外加一堆让人失眠的训练超参。我这次用Qwen系列模型完整跑了一遍DPO（Direct Preference Optimization，直接偏好优化），把“不需要奖励模型”这条路线从头到尾验证了一次。DPO的核心思路是用偏好数据对直接调整策略模型，把奖励模型的打分功能隐式揉进策略模型本身的输出概率里，省掉一个完整训练阶段和一大串强化学习环节。这篇文章会把原理、代码、参数调优、踩坑记录全部拆开讲，适合想低成本对齐开源模型的小团队和独立开发者，也适合刚接触RLHF、想知道不训奖励模型到底行不行的读者。

单卡24GB跑7B量级模型LoRA对齐，验证集偏好准确率可以从接近随机水平拉到80%左右，而且整个训练流程比PPO简洁得多。我把整个过程拆成原理、环境、实战、评估、踩坑五个部分，直接照着做就能复现。

1. DPO原理拆解：为什么说“不需要奖励模型”

1.1 传统RLHF的链路，奖励模型为什么是个“笨办法”

传统RLHF大致分三步。第一步是SFT，把基座模型在指令数据上微调，让它学会“说话像个人”。第二步训练奖励模型，人工标注偏好对，让一个打分模型学会区分哪个回答更好。第三步用PPO之类的强化学习算法，让策略模型在奖励模型的反馈下进一步优化。

这个流程的问题我在实操里体会太深了。奖励模型本身就是一个需要单独训练的模型，你得准备一套打分数据、一个验证集、一套训练流程，训练完了还要在强化学习阶段反复调用它推理。到了PPO阶段更麻烦，actor、critic、reward model、ref model四个模型在显存里来回倒腾，任何一个环节数值不稳定都可能导致训练发散。社区里经常有人问“为什么我PPO训练loss炸了”，答案往往不是一个具体原因，而是整个链路上随便一个点出问题都会炸。

这个过程的成本在中小团队场景下非常尴尬。很多时候我们只想让模型“在某类请求上表现更好一点”，不想为一个局部需求搭建一整条RLHF流水线。奖励模型和数据都贵，调PPO更贵，这种“高射炮打蚊子”的感觉驱动了后面很多简化方案的出现。

DPO就是简化思路里最彻底的一种：奖励模型整个砍掉，强化学习环节也砍掉，只保留偏好数据和策略模型本身。

1.2 核心思想：把奖励函数“藏”进策略模型里

DPO能省掉奖励模型，靠的是一个数学上的精妙替换。先看传统做法中奖励模型如何表示偏好：Bradley-Terry模型假设用户比较两个回答A和B时，A胜出的概率等于sigmoid函数作用在“A的奖励分减B的奖励分”上。

P(A > B) = σ( r(A) - r(B) )

在这个假设下，一个足够大的专家团队可以用成对偏好数据把奖励函数r训练出来。DPO的洞察在于：对于一个固定的参考策略π_ref，最优策略π_θ和奖励函数r之间存在一个闭式解关系，简单说就是：

r(x, y) = r_ref(x, y) + β * log( π_θ(y|x) / π_ref(y|x) )

这里r_ref是参考模型对应的隐式奖励，β是控制偏离强度的温度参数，π_θ是当前正在训练的策略模型，π_ref是训练开始前保存的参考模型。这个式子的意义非常直观：如果当前策略模型给某个回答的概率远高于参考模型，那么这个回答在隐式奖励函数里就被打了高分；反过来被压低概率的回答，隐式奖励分就低。

把这个隐式奖励带回Bradley-Terry模型，偏好概率就完全变成了策略模型概率比值的函数。DPO的损失函数长这样：

L_DPO = - E[ log σ( β * log(π_θ(chosen)/π_ref(chosen)) - β * log(π_θ(rejected)/π_ref(rejected)) ) ]

整个损失函数不再出现任何奖励模型。chosen回答的相对概率越高、rejected回答的相对概率越低，模型就学得越好。训练时只需要策略模型和参考模型各自做一次前向推理，算两组对数概率，然后做一次减法再走sigmoid交叉熵，完事。

我在第一次跑通DPO loss时确实有点惊讶，它实现起来就是一个简单的二分类loss，但是梯度方向极其符合直觉：拉高chosen的概率、压低rejected的概率，同时用参考模型限制模型不要跑太远。

1.3 β参数：控制“离参考模型有多远”

DPO里最重要的超参数就是β，从第一个版本到现在，实践者对这个参数的共识度相当高：它本质上是KL正则项的权重。

β大，意味着模型每偏离参考模型一步都要付出很大的“惩罚”，训练结果更保守，偏向于不过度改变模型的行为。β小，模型可以自由地朝着偏好数据的方向冲刺，对齐效果来得快，但更容易出现灾难性遗忘、生成风格突变、甚至输出退化的问题。

我用LoRA跑DPO时，β一般从0.1起步。0.1这个值在开源社区的很多实验里都被验证过，属于一个比较稳健的起点。如果你用的偏好数据质量高、差异明显，可以试着降到0.05获得更强对齐效果；如果数据噪声大或者发现生成开始飘，就提高β到0.3甚至0.5，让模型紧贴着参考模型走。

1.4 DPO和PPO的核心差异对比

不是每条路都要走一遍才知道差别，先看这张对比表，后面实战部分还会反复引用到这个框架。

一句话总结就是，DPO牺牲了一部分“理论上限”，换来了极大的工程便利性。

2. 环境准备与模型选型

2.1 硬件与显存规划

训练DPO对硬件的需求远低于PPO，核心原因是显存里同一时间只需要两个模型的参数。这里要注意，参考模型可以单独加载，也可以复用基础模型权重做一次前向推理然后分离。实际操作里，很多框架例如TRL的DPOTrainer允许传ref_model=None，这样参考模型会复用同一个基础模型，显存占用进一步降低。

以Qwen系列为例，我按显存给出几档实用配置参考。

我自己最常用的是单卡24GB跑Qwen-7B系列加4bit QLoRA。在这个配置下，per_device_train_batch_size设为4、gradient_accumulation_steps设为4、max_length设为1024，显存基本稳定在22GB左右。如果你只有16GB显存，把模型换到Qwen-4B，或者把max_length降到512，同样能跑。

2.2 Qwen系列模型怎么选

所谓“选择Qwen”也蛮有讲究。Qwen系列开源模型在中文场景里生态成熟，tokenizer对中文的切分效率高，指令版本基础能力扎实，这些特性在做中文偏好对齐时优势非常明显。不同任务有不同选择：

• 快速验证流程：直接用Qwen-0.5B或Qwen-1.8B，几分钟就能跑完一个epoch，用来调试数据管道和参数组合。
• 通用对话对齐：Qwen-7B是性价比最高的选择，LoRA+4bit量化单卡可跑，效果已经有比较强的保障。
• 高质量中文任务：如果你预算允许，Qwen-14B在偏好对齐后的综合表现会明显上台阶，但对数据质量的要求也同步提高。

这里提醒一句：如果你用的是Instruct版本，那它本身已经做过一轮指令对齐，DPO是在这个基础上做偏好强化，所以参考模型务必是开始DPO之前那个SFT或Instruct版本的权重，而不是基座版本。这个细节很多人在第一次跑的时候容易搞混。

2.3 LoRA和量化配置

DPO里最常见的参数高效微调组合就是QLoRA：基础模型用4bit加载，可训练模块用LoRA低秩适配。原理上，4bit量化会把基座模型的权重压到4bit精度，显存占用大幅降低，而LoRA的适配器权重保持16bit精度训练。这样既保住了训练质量，又控制了显存开销。

我习惯的LoRA配置如下：

from peft import LoraConfig, prepare_model_for_kbit_training peft_config = LoraConfig( r=8, lora_alpha=16, lora_dropout=0.05, target_modules=[ "q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj" ], bias="none", task_type="CAUSAL_LM", )

关于lora_alpha和r的搭配，社区里最常见的规则是alpha取r的两倍。这个比例并不是拍脑袋定的，它影响LoRA缩放因子的尺度。alpha/r = 2时，新增权重的初始缩放系数适中，训练稳定性比较好。target_modules我建议尽量覆盖全部线性层，而不是只改注意力里的q、v。很多早期LoRA教程只改q_proj和v_proj，但实际对齐任务里我觉得覆盖全线性层效果更稳，因为偏好差异往往体现更多在模型整体行为风格上，而不只局限注意力投影。

4bit量化的BitsAndBytes配置我一般这样设：

from transformers import BitsAndBytesConfig import torch bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_compute_dtype=torch.bfloat16, bnb_4bit_use_double_quant=True, )

注意compute_dtype要和训练时的精度设置保持一致。用bf16还是fp16主要看显卡。30系及以后显卡对bf16支持较好，训练也更稳定；20系及更早建议用fp16。很多人的损失震荡问题根本不在参数，而是精度配置不匹配。

2.4 偏好数据从哪来、怎么构造

DPO的数据格式非常朴素，一条样本就是三件事：prompt、chosen、rejected。

{ "prompt": "写一个50字以内的自我介绍", "chosen": "大家好，我是某开发者，专注开源工具链与实践分享，擅长把复杂的工程问题拆成可落地的步骤。", "rejected": "大家好，我是开发者，我爱写代码，我还喜欢猫，啊对了电脑也挺好的，总之大家多支持吧。" }

数据可以来自公开的偏好数据集，也可以自己构造。公开数据集通常质量不错但领域广泛，适合做通用对齐；自建数据适合做垂直领域对齐。如果你有自己的业务场景，我建议两种混合：拿公开数据打底，加入至少几百条自建的高质量偏好对。

构造偏好对时有几条硬经验。chosen和rejected差异要足够明显，如果两个回答水平接近，模型学到的信号就是噪声。chosen和rejected长度不能悬殊过大，我的训练数据里两者长度比一般控制在1.5倍以内，否则模型很容易学会“长得像更优”，而不是学会内容本身的优劣。还有一点，chosen不要刻意堆砌套话，比如“首先、其次、最后、总之”这种模板堆多了，模型会变得啰嗦空洞。

数据量方面，不要太焦虑。几百条高信噪比的偏好对就能看到效果，1k到10k是常见区间。数据量再往上，收益会边际递减，清洗成本反而明显上升。

3. 实战训练：DPO训练Qwen的完整流程

3.1 依赖安装和模型加载

依赖安装直接看下面这一串命令，建议在干净的虚拟环境里装：

pip install transformers trl peft bitsandbytes accelerate datasets

版本上别追太新，我遇到过TRL更新后接口变化导致代码不兼容的情况。保险起见，先把transformers和trl都升到当前较新的稳定版，再锁版本跑通一次流程。

模型加载部分，以Qwen-7B为例：先用4bit量化配置加载，再调用prepare_model_for_kbit_training，最后套上LoRA。注意tokenizer的pad_token需要手动设置，Qwen的tokenizer默认没有pad_token，不设置的话DPO训练时会把padding的位置也计算进loss里，结果会出现loss忽高忽低跑飞的情况。

from transformers import AutoModelForCausalLM, AutoTokenizer from peft import prepare_model_for_kbit_training, get_peft_model model_id = "Qwen/Qwen2-7B-Instruct" model = AutoModelForCausalLM.from_pretrained( model_id, quantization_config=bnb_config, device_map="auto", trust_remote_code=True, ) tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True) tokenizer.pad_token = tokenizer.eos_token model = prepare_model_for_kbit_training(model) model = get_peft_model(model, peft_config)

实测下来这套组合在单卡24GB上运行稳定。如果是更小的模型，把model_id换成对应规模就行。

3.2 数据预处理：字段映射与长度控制

公开偏好数据集格式五花八门，有的叫“prompt”“chosen”“rejected”，有的字段名完全不同。DPOTrainer需要固定的字段，所以第一步就是做字段重映射。

from datasets import Dataset, load_dataset def format_dpo_sample(example): return { "prompt": example["prompt"], "chosen": example["chosen"], "rejected": example["rejected"], } dataset = load_dataset("your_dataset_name", split="train") dataset = dataset.map(format_dpo_sample, remove_columns=dataset.column_names)

如果模型是chat版本，通常需要在prompt外面加上系统提示词模板。Qwen-7B的对话格式我直接按官方chat模板来拼，不自己脑补一段格式。把system message拼进去之后，chosen和rejected统一使用完整对话格式。

长度控制是DPO训练里最容易忽视的细节。max_prompt_length和max_length是两个不同的概念。max_prompt_length管prompt部分的最大长度，max_length管prompt加上chosen/rejected整个序列的最大长度。因为每条样本实际拼接后会包含chosen和rejected两段，序列会比普通SFT样本长很多。我在7B模型上设置max_prompt_length=512、max_length=1024，既覆盖大多数场景，也控制了显存占用。如果你的数据都是长文本，就需要相应调大，否则后面所有样本都被截断，模型学到的是“头不对尾”的残缺信息。

3.3 核心训练参数逐个拆解

DPO训练参数和普通SFT有不少重合，但有几个关键差异需要单独说明。

beta和learning_rate是整套DPO训练里最需要联动的两个参数。beta给定后，模型对参考模型偏离的“单位成本”就定了，learning_rate决定每一轮更新迈多大步子。我的经验是beta=0.1时learning_rate取1e-5比较舒服；如果beta调到0.05，learning_rate也相应降到5e-6，否则很容易在前期就冲过头。这个联动关系在社区讨论里经常被忽略，但我在实验里反复验证过。

等效batch size的计算方式：per_device_train_batch_size乘上gradient_accumulation_steps再乘上GPU数量。我常用4×4=16的等效batch，效果稳定。batch size对DPO的影响没有SFT那么线性，太大会让对比信号变弱，太小loss波动大，16到32是一个比较舒服的区间。

3.4 开始训练：基于TRL的DPOTrainer

数据准备好之后，整个训练启动代码很短。我直接用TRL的DPOTrainer，它内部已经处理好了preference loss计算，不需要自己手写循环。

from trl import DPOTrainer, DPOConfig dpo_args = DPOConfig( output_dir="./qwen_dpo_output", per_device_train_batch_size=4, gradient_accumulation_steps=4, learning_rate=1e-5, num_train_epochs=2, warmup_ratio=0.1, lr_scheduler_type="cosine", bf16=True, logging_steps=10, save_steps=300, save_total_limit=2, max_length=1024, max_prompt_length=512, remove_unused_columns=False, ) dpo_trainer = DPOTrainer( model=model, ref_model=None, args=dpo_args, beta=0.1, train_dataset=dataset, tokenizer=tokenizer, ) dpo_trainer.train()

这里有一个容易踩的坑：remove_unused_columns务必设为False。因为DPO样本里的prompt、chosen、rejected都是单个长字符串，如果让训练器自动删除未使用列，后续内部处理时字段可能被过滤掉，导致训练直接报错。

训练完成后，LoRA适配器需要保存和合并。我一般先保存LoRA权重做实验记录，再合并一个完整模型用于部署。

dpo_trainer.save_model("./qwen_dpo_lora") merged_model = model.merge_and_unload() merged_model.save_pretrained("./qwen_dpo_merged") tokenizer.save_pretrained("./qwen_dpo_merged")

3.5 训练监控：loss曲线怎么看

DPO的loss和SFT的loss反应不太一样。SFT的loss是生成token的交叉熵，数值上直观；DPO的loss是chosen和rejected对数概率比过sigmoid的损失，数值可能一开始在0.6到0.7附近，然后缓慢下降。7B模型1k条数据、2个epoch、等效batch 16的情况下，loss大致会从0.69降到0.3到0.4之间。

loss不降时先别急着加epoch。我遇到过loss在一个区间波动完全不动的情况，根本原因不是训练时间不够，而是chosen和rejected的输出长度差异过大，模型直接就学会用“长度”这个特征区分了，之后不管怎么训都停在一个高原。检查数据长度分布比调超参重要得多。

loss下降太快也要警惕。如果第一个epoch就降到0.1以下，大概率是过拟合信号，模型已经开始记忆训练数据而非泛化偏好规律。正常训练曲线应该是一个平滑的下降，末端趋于平稳。

4. 效果评估：对齐前后差异怎么量化

4.1 偏好准确率：不训练奖励模型也能算

评估DPO效果最直接的方法就是看偏好准确率，思路是把DPO隐式奖励当作一个“伪奖励分”，在验证集上判断模型给chosen打的分是否高于rejected。

具体来说，对验证集每条样本，计算chosen和rejected在策略模型下的对数概率，减去它们在参考模型下的对数概率，差值越大代表模型越偏好这条回答。如果chosen的得分高于rejected，判定为预测正确。

def compute_dpo_reward(model, tokenizer, ref_model, prompt, chosen, rejected, beta=0.1): inputs_chosen = tokenizer(prompt + chosen, return_tensors="pt").to(model.device) inputs_rejected = tokenizer(prompt + rejected, return_tensors="pt").to(model.device) with torch.no_grad(): logprob_chosen = model(**inputs_chosen).logits.log_softmax(-1).sum().item() logprob_rejected = model(**inputs_rejected).logits.log_softmax(-1).sum().item() if ref_model is not None: ref_logprob_chosen = ref_model(**inputs_chosen).logits.log_softmax(-1).sum().item() ref_logprob_rejected = ref_model(**inputs_rejected).logits.log_softmax(-1).sum().item() else: ref_logprob_chosen = ref_logprob_rejected = 0 reward_chosen = beta * (logprob_chosen - ref_logprob_chosen) reward_rejected = beta * (logprob_rejected - ref_logprob_rejected) return reward_chosen, reward_rejected

上面这段代码简化为直接算整句话的对数概率和，实际生产里建议做滑动窗口平均，避免长文本累计概率时数值过小或者长度偏差影响判断。

我跑完一轮效果不错的DPO后，验证集偏好准确率通常能从50%附近升到75%到85%，这个指标快接近一个轻量奖励模型单独训练的准确率水平。如果准确率不到65%，优先检查数据质量和参数设置，而不是盲目加训。

4.2 奖励边际（Reward Margin）

准确率之外，值得同时看的是“奖励边际”，也就是chosen和rejected的隐式奖励差值。这个值反映模型对两类偏好的区分程度有多强。差值为正说明整体学对了方向，差值越大说明区分越鲜明。

我在训练日志里每500步算一次验证集平均奖励边际。正常趋势是逐步上升，然后趋于平稳。如果边际还在涨但生成质量开始变差，说明模型开始“过度拟合偏好”，开始走极端了，此时应该停止训练，而不是等它收敛。

4.3 生成效果实测：看几个真实输出

数字指标再好，最终还得看模型生成的文本。我会固定一组prompt，分别用参考模型和DPO后的模型生成，然后做三件事：看内容是否偏离用户意图，看语气是否变得过于谄媚，看是否产生重复的“正确废话”。

举例来说，给模型一个“如何把蛋糕烤得松软”的问题，对齐前可能给出泛泛而谈的步骤，对齐后应当输出更有条理、更有层次、更直接可执行的回答。如果输出开始满屏“首先我们必须要知道”这种套话，说明偏好数据里的chosen段落套路化太严重，污染了生成风格。

另一个值得留意的失败模式是模型变成“无原则的舔狗”。用户说了一句明显不合理的需求，模型不再指出问题，而是顺着用户的话疯狂附和。这种毛病往往不是因为DPO本身有问题，而是偏好对里chosen全是高顺从回答，没有构造“拒绝不合理请求但保持礼貌”的优质样本。偏好数据里应当留一批这种边界样本，否则模型的边界感会被磨掉。

4.4 附录式检查清单

5. 踩坑记录与调优心得

5.1 β调错的典型症状

β=0.1是常见起点，但我不建议无脑照搬。我在一次实验里把β降到0.01，loss倒是降得飞快，但在通用对话测试里模型明显“性情大变”，说话方式变得机械，回答变得抄近路。后来查原因，偏置数据里手机chosen和rejected的差异太大，低β导致模型在这个差异方向上冲得过头，把原本有价值的多轮能力和表达能力全冲掉了。

反过来，β调得太大比如1.0，训练好几轮loss几乎原地踏步，模型几乎没有学到任何偏好差异。原因也好理解，它被牢牢绑在参考模型身上，每个梯度更新都被KL惩罚抵消掉了。

结论很简单：小β出效果快但风险高，大β安全但效果慢。调参时看loss曲线的同时，一定同步看生成样例，不要只看指标。

5.2 偏好数据的“垃圾进垃圾出”

DPO对数据质量的敏感程度比SFT高得多。SFT时代数据烂一点模型顶多是学到噪声，DPO时代数据烂一点模型可能直接学歪。我踩过的坑包括但不限于：chosen和rejected里都包含事实错误，模型学会了在两个错误答案里选“错得更有自信”的那个；chosen总是更长且包含重复论述，模型把长度当成了质量；rejected里包含明显恶意倾向但又被模型顺带学了一些语气，导致生成风格变得僵硬。

清洗偏好对时有一个高效的粗筛思路：先用规则筛掉chosen和rejected完全同质的样本，再用一个轻量质量模型打一次分，把两个回答得分差异很小的样本丢掉。粗筛之后再做人工抽检，重点检查长度比和语气差异。

5.3 过拟合与灾难性遗忘

DPO训练epoch数不需要多。我试过用同样的数据跑1个epoch、2个epoch、4个epoch。2个epoch效果最好；4个epoch验证集偏好准确率还在涨，但通用能力明显掉，模型对见过的偏好对回答得头头是道，遇到没见过的提问就变得词不达意。

灾难性遗忘的缓解有几种实操手段。第一，把SFT阶段的数据按一定比例混进DPO样本，让模型在往偏好方向走的同时保留通用能力。第二，把更大规模的通用指令数据做成prompt-only样本，也就是chosen和rejected都是通用回答，这样梯度更新方向相互抵消，模型就不会在通用能力上大幅漂移。第三，调高β，收紧模型的自由活动范围。

我自己用得最多的是在DPO数据里混入20%左右的SFT指令数据，效果稳定，通用能力几乎没有明显退化。

5.4 LoRA target_modules选型

刚开始实验时我只在注意力层的q_proj和v_proj上挂LoRA，训练速度很快，但偏好准确率提升幅度不大。后来把target_modules扩展到所有线性层，包括上下投影和gate投影，偏好准确率明显上了一个台阶。代价是训练时间长了约30%到40%，但换来更充分的对齐效果，这个成本是值得的。

如果你显存余量不多，还可以尝试把lora_dropout从0.05降到0.0，训练速度会快一点，但过拟合风险同步上升。数据量小、epoch少的时候影响不大，数据量大就要谨慎。

5.5 DPO loss为负或者特别小，别慌

第一次跑DPO的人看到loss为负常常以为自己代码写错了。我解释一下：DPO loss内部计算的是log ratio差分的数值，换算到最终交叉熵时这是一个优化目标的值，本身没有“必须为正”的约束。训练早期loss在0.6到0.7很正常，训练后期降到0.2甚至更低也不代表训练成功。关键看验证集上的偏好准确率和生成效果，不要被绝对值带偏。

还有一个容易误判的现象：loss曲线下降很漂亮，但偏好准确率不涨。这种情况通常是数据量太小或chosen和rejected差异太小，模型学不出区分规则。加数据比调超参更容易解决问题。

这块后续还能怎么扩展

DPO这个方向还能往几个方向延伸。最直接的扩展是多轮迭代DPO：第一轮DPO做完后，用新的模型重新生成chosen和rejected，再跑一轮，效果可以再上一个台阶，前提是每次都要重新构造高质量偏好对。另一种扩展是DPO和SFT混合训练，把通用能力和偏好对齐做在同一个训练阶段里，省一次完整微调流程。还有分支去做多偏好维度DPO，把“有用性”和“安全性”拆成两个维度分别做偏好优化。

从我个人的实际体验看，DPO最值钱的贡献是让“对齐”这个原本需要一整支强化学习团队才能做的事，降低到单个开发者拿一块消费级显卡就能完成。它当然不是银弹：数据质量不足时它比SFT更容易放大噪声，beta调不好时它可能把一个好模型带偏。但它的工程简洁性和调试透明度，实在让人回不去PPO那套流程了。如果你正准备做开源模型的中文对齐实验，拿Qwen加DPO起步，先跑通流程，再逐步打磨数据和参数，这个路径大概率不会让你失望。