换句话说，模型虽然是逐个 token 进行预测的，但当我们想评价“整条回复在模型看来有多合理”时，就需要把这条回复中每一个 token 的生成概率都结合起来考虑。因此，DPO 公式中写的 ，本质上表示的是模型对整段回答作为一个完整序列的支持程度。

同理，对于较差回答 ，也有：

不过，在实际计算时，如果直接对很多个 token 的概率做连乘，数值会变得非常小，不方便计算，也不利于训练稳定。因此，工程实现中通常不会直接使用原始概率，而是改为计算对数概率（log probability）。根据对数的性质，上面的连乘可以转化为连加：

还需要特别说明一点，这里通常只统计回复部分（completion）的 token，而不会把输入 prompt 本身也作为需要优化的输出一起计入。也就是说， 的含义是：在给定输入  的前提下，模型生成回复  的条件概率。输入  只是条件，而不是被评分的对象。

综合来看，DPO 公式中的  和 ，并不是单独某一个 token 的概率，而是模型对整条优质回复和整条劣质回复的整体支持程度。也正因为如此，DPO 学到的并不是局部某几个 token 的偏好，而是对整段回答质量的一种整体性偏好判断。

参考模型的价值

在 DPO 中，参考模型（reference model）通常就是前面经过 SFT 后得到的模型，并且在后续偏好优化阶段保持冻结，不再参与更新。它的存在并不是为了单独完成某项预测任务，而是为了给当前正在训练的模型提供一个稳定的比较基准。换句话说，DPO 真正关心的，并不是当前模型绝对上是否喜欢某个回答，而是当前模型相对于参考模型，是否更偏向优质回答，同时更远离劣质回答。

这一点非常重要。因为如果没有参考模型，训练目标就会变成单纯地“提高 chosen 的概率、降低 rejected 的概率”。虽然听起来合理，但这样做容易导致模型为了追求偏好优化而发生过大的分布漂移，进而破坏原本已经具备的语言能力、指令跟随能力以及泛化能力。参考模型的作用，正是在偏好优化过程中为当前模型提供一个“锚点”，使模型的更新始终建立在已有能力基础之上，而不是无限制地偏离原始分布。

简单来说所以假如没有参考模型，我们只能判断当前模型在同一个输入下是否更偏向 chosen，而无法判断这种偏向是否相对于原始模型真正有所提升；有了参考模型之后，我们比较的就不再是当前模型的绝对偏好，而是当前模型相对于参考模型的偏好变化。

举个例子，若当前模型对 chosen 和 rejected 的概率分别为 0.4 和 0.2，那么从绝对值看，它确实更偏向 chosen。但如果参考模型对 chosen 和 rejected 的概率分别为 0.1 和 0.2，则说明当前模型显著增强了对 chosen 的支持，属于有效进步；而如果参考模型对 chosen 和 rejected 的概率分别为 0.3 和 0.05，则说明当前模型虽然表面上仍更偏向 chosen，但相较于参考模型，其对 rejected 的支持反而提升得更多，这就不能算作真正朝着偏好优化方向改进。由此可见，参考模型的价值不在于提供一个额外分数，而在于提供一个稳定的比较基线，使我们能够判断模型是否相对于原有能力基础发生了真正有意义的偏好改进。

从这个角度来看，DPO 中参考模型的价值，其实和传统 RLHF 中的 KL 控制 有着非常接近的思想来源。在传统 RLHF 中，模型通常先经过 SFT，随后再通过奖励模型和 PPO 等强化学习算法继续优化。在这个过程中，如果只是一味追求更高的奖励分数，模型就可能逐渐偏离原来的 SFT 分布，出现回答风格失真、语言质量下降甚至奖励投机等问题。因此，RLHF 往往会在目标函数中显式加入一个 KL 惩罚项，用来约束当前策略模型不要离参考策略太远。其形式通常可以写成：

这里的含义是模型一方面希望获得更高的奖励，另一方面又要受到 KL 项的约束，避免与参考模型之间的差异过大。也就是说，在 RLHF 中，参考模型主要承担的是一种分布约束器的角色，它通过 KL 惩罚告诉当前模型：“可以往高奖励方向优化，但不要偏离原来的能力基线太远。”

而在 DPO 中，虽然不再显式写出一个单独的 KL 控制项，但参考模型的思想并没有消失，而是被更紧密地融入到了损失函数内部。DPO 的核心比较项写作：

从形式上看，这里并不是直接比较当前模型对 chosen 和 rejected 的绝对概率，而是在比较当前模型相对于参考模型，对优质回答的支持增强了多少，以及对劣质回答的支持又增强了多少。

因此，DPO 中的参考模型实际上仍然在发挥“约束分布漂移”的作用，只不过这种约束不再是 RLHF 里那种显式的 KL 惩罚，而是转化成了一种相对偏好优化的方式。也就是说，DPO 不再单独告诉模型“你不能离参考模型太远”，而是通过“相对于参考模型的概率比”来隐含地控制更新方向。

因此，可以把两者的关系概括为：

RLHF 中的参考模型主要通过显式 KL 惩罚来限制策略漂移；而 DPO 中的参考模型则通过相对概率比的形式，被直接写进了偏好优化目标之中。

两者虽然实现方式不同，但底层思想是一致的，其都是希望模型在学习人类偏好的同时，尽可能保留原有模型已经具备的语言能力和任务能力，避免因为偏好优化过于激进而“学偏”。

从工程实现上看，这也是 DPO 相比传统 RLHF 的一个重要优势。传统 RLHF 需要单独考虑奖励模型训练、策略优化以及 KL 系数调节等多个环节；而 DPO 则把“偏好优化”和“参考约束”更自然地统一到了同一个损失函数中。这样一来，参考模型不再只是一个训练过程中的附加控制项，而成为了 DPO 数学形式中不可缺少的一部分。

综合来看，参考模型在 DPO 中至少具有三层价值：

1. 它为当前模型提供了一个稳定的能力基线；
2. 它帮助限制模型在偏好优化中的过度漂移；
3. 它使得“偏好学习”能够被写成一个清晰的相对优化目标。

也正因为如此，参考模型并不是 DPO 中一个可有可无的辅助模块，而是整个方法能够成立并保持稳定训练的关键支点之一。

应用场景

那 DPO 最常应用的场景和 RLHF 类似，其通常适用于这样一类场景，即模型本身已经具备基本回答能力，但还需要进一步优化其输出风格、帮助性、稳定性以及与人类偏好的一致性。 换句话说，这类方法更适合放在模型训练流程的后段，用来解决“模型会答之后，如何答得更符合人类预期”这一问题。

从应用类型上看，DPO 比较适合用于开放式对话、通用助手对齐、指令跟随优化、格式约束、风格调优，以及多轮交互和 Agent 场景中的最终收束阶段。在这些任务中，模型面对的往往不是“唯一正确答案”，而是多个都基本可行的回答，因此训练的重点不再只是“能不能答对”，而是“能不能更稳定地生成更符合偏好的结果”。这正是 DPO 擅长处理的问题。

一个很有代表性的例子是 GLM-5。根据其技术报告，GLM-5 的后训练流程采用了一种顺序式强化学习管线，先进行多任务监督微调（Supervised Fine-Tuning, SFT），然后依次进入推理强化学习（Reasoning RL）、智能体强化学习（Agentic RL），最后进入通用强化学习（General RL）。报告中明确写到，这一最后阶段用于“人类风格对齐（human-style alignment）”，也就是说，它的目标是在专项能力训练之后，再进一步优化模型整体的回答风格与通用交互质量。这个位置和目标，与 DPO 常见的应用场景非常接近。

另一个例子是 Qwen3。Qwen3 的技术报告将后训练划分为四个阶段：Long-CoT Cold Start、Reasoning RL、Thinking Mode Fusion，以及最后的 General RL。报告中明确提到，这一阶段用于广泛增强模型在多种任务下的表现，包括指令跟随、格式跟随、偏好对齐等能力。也就是说，Qwen3 的 General RL 同样承担了“在所有专项能力训练之后，再做通用偏好优化和体验收束”的角色。

虽然根据目前公开资料，我们不能直接断言 GLM-5 的通用强化学习（General RL）或 Qwen3 的通用强化学习（General RL）就等同于标准 DPO。但是从训练阶段的位置和功能来看，GLM-5 与 Qwen3 的 通用强化学习（General RL） 都可以被看作与 DPO 目标高度接近的一类后训练步骤：它们都放在训练流程的后段或末段，用于把模型从“已经具备能力”进一步推向“更符合人类偏好、更稳定、更好用”的状态。

综合来看，DPO 最典型的应用场景，就是出现在模型后训练流程的后段或末段，用来提升模型的通用交互质量、偏好一致性与最终使用体验。GLM-5 和 Qwen3 的 General RL，都可以看作这一思路在当前大模型训练实践中的典型体现。

实操指南

在前面的内容中，我们已经从原理层面理解了 DPO（Direct Preference Optimization）到底在做什么，也知道了它的核心目标并不是单纯“记住某个标准答案”，而是让模型学会面对同一个问题时，更倾向于生成更符合人类偏好的回答。

接下来我们就正式进入实战部分，完整走一遍一次 DPO 训练的基本流程。整个实验将围绕一个开源偏好数据集展开，我们会先从原始数据中筛选出偏好关系明确、回答质量较高的样本，并将其整理成 TRL 中 DPOTrainer 所需要的标准格式；随后，再基于这些数据分别尝试 全量微调 和 QLoRA 参数高效微调 两种训练方式，观察它们在本地环境下的训练表现。

需要说明的是，这里的实验更偏向于一次教学演示型实践。我们的目标并不是在有限数据和有限显存条件下训练出一个能力大幅跃迁的模型，而是帮助大家真正看清楚 DPO 训练的数据应该如何准备、训练参数应当怎样设置、训练日志应该怎么看，以及训练完成后又该如何验证模型是否真的学到了偏好关系。

也就是说，这节实验最重要的意义，不在于“把模型训得多强”，而在于带大家亲手跑通一条完整的 DPO 偏好优化流程。只要把这一套流程真正理解并实践下来，后续无论是更换数据集、扩大训练规模，还是进一步尝试其他偏好优化方法，都会更容易上手。

代码实战

数据集准备

数据集格式

无论是对于 SFT 微调，还是对于后续的强化学习/偏好对齐训练而言，数据集的准备都是决定模型能否顺利训练、以及训练效果是否理想的核心因素之一。在 TRL 中，不同的 Trainer 对应着不同的预期数据格式，因此在正式训练之前，首先需要明确当前所使用的训练器究竟需要什么样的数据结构。

例如，前面介绍过的 SFTTrainer 主要支持 Language Modeling 和 Prompt-Completion 等数据格式；而对于 DPOTrainer 来说，它主要面向的是 Preference（偏好数据集） 格式，并且通常更推荐使用 explicit prompt（显式提示） 的写法。其基本样式如下所示：

# 标准格式
## 显式 prompt（推荐）
preference_example = {"prompt": "The sky is", "chosen": " blue.", "rejected": " green."}

## 隐式 prompt
preference_example = {"chosen": "The sky is blue.", "rejected": "The sky is green."}

# 对话格式
## 显式 prompt（推荐）
preference_example = {
    "prompt": [{"role": "user", "content": "What color is the sky?"}],
    "chosen": [{"role": "assistant", "content": "It is blue."}],
    "rejected": [{"role": "assistant", "content": "It is green."}]
}

## 隐式 prompt
preference_example = {
    "chosen": [
        {"role": "user", "content": "What color is the sky?"},
        {"role": "assistant", "content": "It is blue."}
    ],
    "rejected": [
        {"role": "user", "content": "What color is the sky?"},
        {"role": "assistant", "content": "It is green."}
    ]
}

从上面的示例可以看出，DPO 所使用的偏好数据大致可以分为两类：一类是 标准格式（Standard format），另一类是 对话格式（Conversational format）。

其中，标准格式更适用于传统的文本补全或续写场景；而 对话格式则更贴近当前大语言模型最常见的聊天式交互场景。由于我们这里训练的是面向对话的大语言模型，并且希望模型能够在对话任务中学习我们的偏好，因此显然更适合选择 对话格式。同时，为了让输入结构更加清晰，也为了更方便模型明确区分“提示词”和“回复内容”，这里进一步采用 显式偏好格式 进行组织：

preference_example = {
    "prompt": [
        {"role": "user", "content": "What color is the sky?"}
    ],
    "chosen": [
        {"role": "assistant", "content": "It is blue."}
    ],
    "rejected": [
        {"role": "assistant", "content": "It is green."}
    ]
}

在这个数据结构中，prompt 表示用户输入的问题或指令，chosen 表示人类更偏好的回答，而 rejected 则表示相对不被偏好的回答。表面上看，这只是一个包含三个字段的简单字典；但从训练目标上看，它所承载的信息却比普通的一问一答数据更丰富。因为它不仅告诉模型“可以怎样回答”，更进一步告诉模型：在面对同一个问题时，为什么一个回答比另一个回答更值得被优先选择。

这也恰好与前面提到的 DPO 核心思想形成呼应：DPO 并不是单纯训练模型去复现某个答案文本，而是在训练模型学习一种偏好关系。 它真正关心的，不是让模型死记某一条 chosen 回复本身，而是让模型逐步建立起一种更稳定的生成倾向——在面对同一个 prompt 时，应该更偏向 chosen，而不是 rejected。

数据集选择

在了解完数据集格式后，接下来我们来看看这次我们训练的数据集是什么。在数据集的选择上，这里我们选择了有 ModelScope 官方开源的 DPO 训练数据集 distilabel-intel-orca-dpo-pairs^[1] ：

在明确了 DPOTrainer 所需要的偏好数据格式之后，接下来还需要进一步解决一个更实际的问题，究竟应该选择什么样的数据集，来完成本次 DPO 实战演示。

从训练目标来看，理想的 DPO 数据集至少需要满足几个基本条件：第一，数据本身已经具备较规范的 chosen / rejected 偏好对结构，能够较方便地转换为 TRL 所要求的格式；第二，数据规模不宜过大，否则会明显增加教学演示时的数据处理和训练成本；第三，数据质量应尽量可靠，避免由于偏好标签本身存在较大噪声而影响训练效果。

基于这些考虑，这里选择使用 AI-ModelScope/distilabel-intel-orca-dpo-pairs 作为本次实验的数据来源。该数据集对应的 Hugging Face 版本 argilla/distilabel-intel-orca-dpo-pairs 已经以标准的 chosen、rejected 结构组织好，并明确说明其适用于 preference tuning，因此非常适合作为 DPO 入门实践的数据基础。

进一步来看，这个数据集的优势并不只在于“能用”，更在于它相较于原始 Intel/orca_dpo_pairs 做过额外整理与修正。原始数据集本身大约包含 12k 条样本，而 distilabel 版本则在此基础上重新进行评估与后处理，最终形成约 12.9k 条样本的数据集。更重要的是，数据集作者指出：其中约 2000 对样本需要将原本的 chosen 与 rejected 进行交换，约 4000 对样本则应被视为 tie，即两侧回答质量接近，并不存在非常明确的偏好关系。也就是说，这个版本并不是机械地继承原始偏好标签，而是对偏好关系进行了进一步校正，这使得它更适合用来进行 DPO 训练。

除此之外，该数据集还额外提供了 status、chosen_score、original_chosen、original_rejected 等字段。这些附加信息的价值在于，它不仅方便我们直接训练，也方便我们在教学中进一步说明偏好数据并不是“只要成对就能直接拿来训练”，而是还需要考虑偏好是否足够明确、标签是否可靠、样本是否值得保留。

例如，数据集官方就给出了一个典型过滤方式：去除 tie 样本、保留 chosen_score >= 8 的高质量样本，并剔除部分可能存在污染风险的数据。经过这样的过滤后，样本量会从 12,859 条减少到 5,922 条，但作者指出这种更精炼的数据反而能够带来更好的训练效果。

因此，综合来看，选择 AI-ModelScope/distilabel-intel-orca-dpo-pairs 的原因，并不是因为它一定是所有 DPO 数据集中最强或最全面的一个，而是因为它在格式规范性、数据规模、可操作性以及偏好标签质量之间取得了较好的平衡。对于本节课这样的实战教学场景而言，我们更关注的是先让读者顺利理解 DPO 所依赖的数据结构、掌握基本的数据处理流程，并完成一次可复现的偏好训练实验。从这个角度出发，这个数据集恰好提供了一个较为合适的起点。

数据集下载

在正式使用该数据集之前，首先需要通过以下命令在终端中将其下载到本地：

modelscope download --dataset AI-ModelScope/distilabel-intel-orca-dpo-pairs --local_dir ./data/raw_data

当下载开始后，终端中就会出现熟悉的 ModelScope 标志：

待下载完成后，即可在本地看到对应的数据集文件目录：

在这些文件中，最核心的内容是 raw_data 目录下 data 文件夹中的 train-00000-of-00001.parquet 文件。这个文件中保存的就是已经整理好的 Hugging Face Dataset 格式数据，也就是后续进行 DPO 训练所需要使用的原始偏好样本。

不过，在实际训练过程中，我们通常并不会直接将整份数据集全部用于训练。一方面，受限于本地设备的显存条件，直接使用全量数据往往会带来较大的资源压力；另一方面，从教学演示的角度来看，完整数据集的训练耗时也相对较长，不利于我们快速验证训练流程与观察实验结果。因此，在本次实战中，我们将从原始数据中进一步筛选出一部分质量较高、规模更合适的样本，并在此基础上完成后续的数据清洗与格式处理工作。

数据集清洗

数据查看

在正式进行数据清洗之前，我们可以先对数据集的整体结构做一个初步查看，先弄清楚这个数据集究竟包含哪些字段、每条样本大致是什么样子。可以通过下面的代码完成这一过程：

from datasets import load_dataset

parquet_path = r"D:\微调与部署\DPO\data\raw_data\data\train-00000-of-00001.parquet"

dataset_dict = load_dataset(
    "parquet",
    data_files={"train": parquet_path}
)

train_ds = dataset_dict["train"]

print("总样本数：", len(train_ds))
print("列名：", train_ds.column_names)
print("第一条样本：", train_ds[0])

此时输出的结果如下：

总样本数： 12859
列名： ['system', 'input', 'chosen', 'rejected', 'generations', 'order', 'labelling_model', 'labelling_prompt', 'raw_labelling_response', 'rating', 'rationale', 'status', 'original_chosen', 'original_rejected', 'chosen_score', 'in_gsm8k_train']
第一条样本： {
    "system": "",
    "input": "You will be given a definition of a task first, then some input of the task... Output:",
    "chosen": "[ ... ]",
    "rejected": "Sure, I'd be happy to help! ...",
    "generations": [
        "[ ... ]",
        "Sure, I'd be happy to help! ..."
    ],
    "order": ["chosen", "rejected"],
    "labelling_model": "gpt-4-1106-preview",
    "labelling_prompt": [
        {"role": "system", "content": "..."},
        {"role": "user", "content": "..."}
    ],
    "raw_labelling_response": "...",
    "rating": [9.0, 9.0],
    "rationale": "...",
    "status": "tie",
    "original_chosen": "[ ... ]",
    "original_rejected": " ... ",
    "chosen_score": 9.0,
    "in_gsm8k_train": False
}

从输出结果可以看出，这个数据集总样本数有 12859 条。并且除了保存偏好训练所需的核心内容之外，还附带了不少与样本评审、打分和状态标记相关的辅助信息。其中，真正与后续 DPO 训练最直接相关的，主要是前四个字段：

• system：系统提示词，用于设定模型在当前任务中的角色、语气或整体行为规则。可以把它理解为对模型的“全局说明”。
• input：输入内容，也就是模型需要回答的任务描述和具体问题本身。这个字段往往不仅仅是一句简单提问，还可能包含任务背景、输出要求、格式说明等信息。因此，在后续数据转换时，可以将它理解为偏好训练里的 prompt，也就是模型生成回答时所面对的输入条件。
• chosen：偏好数据中被认为更优的回答。也就是说，在同一个 input 下，标注系统或评审过程认为这个回答整体质量更高，更值得模型学习。
• rejected：偏好数据中相对较差的回答。这里需要特别注意，“较差”并不一定等于“错误”。很多时候，rejected 也可能是基本正确的，只是相比 chosen 来说不够简洁、不够自然、不够符合格式要求，或者在帮助性、准确性、表达质量等方面略逊一筹。

当然，除了这几个核心字段之外，数据集中还有一些元数据对于后续的数据筛选同样非常重要。例如：

• rating：用于记录候选回答的评分结果。通常可以理解为对不同回答质量的量化评价，它有助于我们判断样本中的偏好差异是否足够明显。
• status：用于记录当前样本的状态，例如 tie、unchanged、swapped 等。这个字段很重要，因为它反映了这条样本在后处理或重新评估之后的偏好关系是否发生变化。比如，tie 往往表示两个回答质量接近，偏好关系并不明显。
• chosen_score：表示 chosen 这一回答对应的得分。这个字段可以帮助我们进一步筛选高质量样本，例如只保留那些 chosen_score 较高的数据，从而让训练数据更加可靠。

这些字段虽然不会直接作为模型训练输入，但却能够为后续的数据清洗与筛选提供重要依据。也正因为如此，在真正开始构造训练集之前，先对数据集结构进行一次完整查看，是非常有必要的一步。

数据清除

由于我们这里希望保留的是偏好关系足够明确的样本，因此首先需要对原始数据集做一次初步清洗。在该数据集中，status 为 tie 的样本表示两个候选回答得分一致，也就是说，这类样本并没有体现出足够清晰的偏好差异。对于 DPO 训练而言，这种“优劣不明显”的数据通常价值有限，因此我们可以优先将其去除，仅保留 unchanged 和 swapped 两类样本。

其中，unchanged 表示该样本的偏好顺序与原始数据保持一致；swapped 则表示该样本在重新评估后发现原有优劣顺序存在问题，因此已经完成了对调。无论是哪一种，只要偏好关系已经明确，都可以继续作为后续筛选的候选样本。

我们可以先通过如下代码统计各类 status 的数量分布：

from collections import Counter

status_counter = Counter(train_ds["status"])
print(status_counter)

运行后可以看到，数据集中共有 4009 条样本属于 tie：

Counter({'unchanged': 6884, 'tie': 4009, 'swapped': 1966})

接下来，我们可以使用一个简单的过滤条件，将这部分 tie 样本移除，只保留偏好关系明确的数据：

# 第一步：去掉 tie，只保留明确偏好的样本
dpo_candidate_ds = train_ds.filter(lambda x: x["status"] != "tie")

print("原始总样本数：", len(train_ds))
print("过滤 tie 后样本数：", len(dpo_candidate_ds))

# 再统计一下过滤后的 status 分布
from collections import Counter
print("过滤后的 status 分布：", Counter(dpo_candidate_ds["status"]))

此时返回的结果为：

原始总样本数： 12859
过滤 tie 后样本数： 8850
过滤后的 status 分布： Counter({'unchanged': 6884, 'swapped': 1966})

可以看到，去除 tie 之后，数据集还剩下 8850 条样本。到这一步为止，我们完成的只是第一层过滤，即先剔除偏好关系不明显的数据。接下来，还需要进一步根据回答质量和偏好强度继续筛选。

数据筛选

在完成 tie 样本的清洗之后，接下来就可以进一步根据评分信息对样本进行筛选。根据官方给出的建议，我们通常会优先保留 chosen_score 较高的样本，也就是那些“优选回答本身质量较高”的数据。这里我们先统计一下 chosen_score 的分布情况：

from collections import Counter

score_counter = Counter(x for x in dpo_candidate_ds["chosen_score"] if x is not None)

print("chosen_score 分布：")
for k in sorted(score_counter):
    print(f"{k}: {score_counter[k]}")

print("chosen_score >= 8 的样本数：", sum(v for k, v in score_counter.items() if k >= 8))

输出结果如下：

chosen_score 分布：
1.0: 14
2.0: 69
3.0: 106
4.0: 192
5.0: 737
6.0: 523
7.0: 1237
8.0: 1863
9.0: 1463
10.0: 2646
chosen_score >= 8 的样本数： 5972

从结果可以看出，在过滤后的 8850 条样本中，共有 5972 条样本的 chosen_score 不低于 8 分，说明其中相当一部分样本的优选回答质量是比较高的。

不过，仅仅要求 chosen 得分高还不够。因为对于 DPO 来说，另一个同样重要的问题是：chosen 和 rejected 之间的偏好差距是否足够明显。

如果两个回答的分数非常接近，那么即便 chosen 本身质量不错，这条样本所提供的偏好信号也可能并不强。相反，如果两个回答之间存在较大的分差，就说明这条样本能够更清楚地告诉模型：在面对同一个问题时，哪一种回答更值得优先生成。

基于这一思路，我们可以进一步根据 rating 字段计算两个候选回答之间的绝对分差，并将其记为 margin：

from collections import Counter

def add_margin(example):
    r = example["rating"]
    if r isNone:
        return {"margin": None}
    return {"margin": abs(r[0] - r[1])}

scored_ds = dpo_candidate_ds.map(add_margin)

# 看看 margin 分布
margin_counter = Counter(scored_ds["margin"])
print("margin 分布：")
for k in sorted(margin_counter):
    print(f"{k}: {margin_counter[k]}")
    
print("超过 8 分的样本数：", sum(count for margin, count in margin_counter.items() if margin isnotNoneand margin >= 8))

这里的 margin 可以理解为 chosen 与 rejected 之间的偏好强度。margin 越大，说明两者优劣差异越明显；margin 越小，则说明这条样本的偏好关系越弱。运行结果如下：

margin 分布：
1.0: 2717
2.0: 1948
3.0: 1108
4.0: 756
5.0: 685
6.0: 373
7.0: 207
8.0: 255
9.0: 770
10.0: 31
偏差超过 8 分的样本数： 1056

可以看到，在当前数据中，真正分差达到 8 分及以上的样本只剩下 1056 条。这说明虽然高分样本数量不少，但其中能够提供强偏好信号的样本其实并没有想象中那么多。

因此，接下来我们就可以同时使用这两个条件进行进一步过滤：

1. chosen_score 不低于 8 分，保证优选回答本身质量较高；
2. margin 不低于 8 分，保证 chosen 与 rejected 之间存在足够明显的偏好差异。

对应代码如下：

from collections import Counter

# 第一步质量筛选：高质量 + 明显偏好
quality_ds = scored_ds.filter(
    lambda x: x["chosen_score"] >= 8 and x["margin"] >= 8
)

print("过滤后样本数：", len(quality_ds))
print("status 分布：", Counter(quality_ds["status"]))
print("chosen_score 分布：", Counter(quality_ds["chosen_score"]))
print("margin 分布：", Counter(quality_ds["margin"]))

经过这一步筛选后，最终保留下来的就是同时满足“回答质量高”和“偏好关系明显”这两个条件的样本。由于前面已经统计过 margin >= 8 的样本数量，因此这里最终保留下来的样本数同样为 1056 条：

过滤后样本数： 1056
status 分布： Counter({'unchanged': 989, 'swapped': 67})
chosen_score 分布： Counter({10.0: 980, 9.0: 71, 8.0: 5})
margin 分布： Counter({9.0: 770, 8.0: 255, 10.0: 31})

考虑到本次实验的目标主要是完成一次教学演示，同时也希望尽量控制训练时间和显存消耗，因此这里不再使用全部 1056 条样本，而是从中随机抽取 500 条作为最终的数据集：

shuffled_ds = quality_ds.shuffle(seed=42)
final_500_ds = shuffled_ds.select(range(500))

print("最终选中的样本数：", len(final_500_ds))

返回的结果为：

最终选中的样本数： 500

这样处理之后，数据规模更加适合本地环境下的快速实验，也更便于后续观察训练效果。

实际上，Hugging Face 文档中也对偏好数据集的规模给出了一定的经验性建议：

• 至少准备约 1000 条高质量偏好数据；
• 更推荐使用 10000 条以上、类型更加丰富的数据；
• 与其使用大量低质量样本，不如优先保证少量样本的高质量。
• 为了避免到新场景中效果不佳，建议数据集能够覆盖全部用例并且多样化。

这也说明，在偏好优化任务中，数据质量往往比单纯的数据数量更重要。因此，在本次实验中，我们虽然最终只选取了 500 条样本作为教学演示使用，但这更多是出于本地显存条件和训练耗时控制的考虑。

如果本地设备显存更充足、训练时间也允许，那么更推荐直接使用前面筛选出的 1000 条左右高质量样本 来进行训练。这样不仅能够让模型接触到更多有效的偏好信号，也通常更有助于提升最终的训练效果。

格式调整

到这一步为止，我们已经得到了一份质量较高、偏好关系较为明确的候选数据集。但这部分数据还不能直接用于 qwen3-0.6B 的 DPO 训练，因为其字段组织方式与 TRL 推荐的偏好训练格式还不完全一致。

在前面已经提到过，TRL 推荐使用如下形式来组织偏好数据：

preference_example = {
    "prompt": [
        {"role": "user", "content": "What color is the sky?"}
    ],
    "chosen": [
        {"role": "assistant", "content": "It is blue."}
    ],
    "rejected": [
        {"role": "assistant", "content": "It is green."}
    ]
}

对于当前数据集而言，chosen 和 rejected 两个字段本身已经具备一一对应的内容，因此处理起来相对直接；真正需要额外注意的是 prompt 的构造方式。

这里不能简单地把 input 直接塞进去作为唯一输入，因为部分样本还带有 system 提示词。在这种情况下，我们需要将 system 和 input 一起组织成消息列表：如果 system 非空，就先加入一条 system 消息；然后再将 input 作为 user 消息加入进去。

除此之外，由于原始数据集并没有专门考虑“思考模式”和“非思考模式”的统一格式，而我们这里训练的目标是让模型以 no_think 的方式完成输出，因此还需要进一步补充两项格式约束：

• 第一，在用户输入末尾统一追加 /no_think，明确告诉模型当前样本应以非思考模式进行回复；
• 第二，在回答开头统一补上空的思考标签 <think>\n\n</think>\n\n，从而使整个数据集在输出形式上保持一致。

也就是说，我们并不是只做字段改名，而是在完成一次面向目标模型的格式适配。只有在经过这样的转换之后，这份数据集才真正符合我们后续训练所需要的输入结构。对应的转换代码如下：

NO_THINK_SUFFIX = " /no_think"
EMPTY_THINK_PREFIX = "<think>\n\n</think>\n\n"

def build_prompt_messages(system_text, input_text):
    messages = []

    system_text = (system_text or"").strip()
    input_text = (input_text or"").strip()

    if system_text:
        messages.append({
            "role": "system",
            "content": system_text
        })

    messages.append({
        "role": "user",
        "content": input_text + NO_THINK_SUFFIX
    })

    return messages

def build_assistant_message(text):
    text = (text or"").strip()
    return [{
        "role": "assistant",
        "content": EMPTY_THINK_PREFIX + text
    }]

def convert_to_dpo_format(example):
    return {
        "prompt": build_prompt_messages(example["system"], example["input"]),
        "chosen": build_assistant_message(example["chosen"]),
        "rejected": build_assistant_message(example["rejected"]),
    }

converted_ds = final_500_ds.map(
    convert_to_dpo_format,
    remove_columns=final_500_ds.column_names
)

print("转换后样本数：", len(converted_ds))
print("转换后列名：", converted_ds.column_names)

for i in range(1):
    print(f"\n===== 转换后样本 {i} =====")
    print(converted_ds[i])

转换完成后，数据集中的字段被统一整理为 prompt、chosen 和 rejected 三部分，同时所有样本也都被调整为符合 no_think 训练目标的统一格式。这样一来，后续就可以直接用于 DPO 训练了：

转换后样本数： 500
转换后列名： ['chosen', 'rejected', 'prompt']

===== 转换后样本 0 =====
{'chosen': [{'content': "<think>\n\n</think>\n\nThe total percentage of imports that come ... to the article.", 'role': 'assistant'}], 'rejected': [{'content': "<think>\n\n</think>\n\nBased on the information provided in the article...", 'role': 'assistant'}], 'prompt': [{'content': 'You are an AI assistant...', 'role': 'system'}, {'content': 'In 2011, Macaus free-market economy ... Hong Kong, or France? /no_think', 'role': 'user'}]}

数据集划分

在完成格式转换之后，接下来还需要将这 500 条样本划分为训练集和验证集。这样做的目的，是为了在训练完成后能够利用验证集对模型效果进行一个初步观察，而不是只看训练过程本身。

这里的划分方式与前面的实验保持一致，仍然采用 9:1 的比例进行切分：

split_ds = converted_ds.train_test_split(test_size=0.1, seed=42)

train_dpo_ds = split_ds["train"]
eval_dpo_ds = split_ds["test"]

print("总样本数：", len(converted_ds))
print("训练集样本数：", len(train_dpo_ds))
print("验证集样本数：", len(eval_dpo_ds))

输出结果如下：

总样本数： 500
训练集样本数： 450
验证集样本数： 50

也就是说，最终将有 450 条样本用于模型训练，另外 50 条样本用于后续验证。这样的划分方式既能保证训练集规模相对充足，也能保留一部分样本用于简单评估。

数据集保存

在完成切分之后，最后一步就是将处理好的数据集保存到本地。为了兼顾后续训练使用和人工查看的便利性，这里同时采用两种保存方式：

• 一种是保存为 Hugging Face Dataset 格式目录，便于后续直接通过 load_from_disk() 读取；
• 另一种是额外保存为 .jsonl 文件，便于我们直接查看样本内容，或者在需要时做进一步的数据检查与分析。

对应代码如下：

from pathlib import Path
import json

save_dir = Path(r"D:\微调与部署\DPO\data\processed")
save_dir.mkdir(parents=True, exist_ok=True)

train_jsonl_path = save_dir / "train_dpo_no_think_450.jsonl"
eval_jsonl_path = save_dir / "eval_dpo_no_think_50.jsonl"

train_hf_path = save_dir / "train_dpo_no_think_450"
eval_hf_path = save_dir / "eval_dpo_no_think_50"

# 1. 保存 train jsonl
with open(train_jsonl_path, "w", encoding="utf-8") as f:
    for item in train_dpo_ds:
        f.write(json.dumps(item, ensure_ascii=False) + "\n")

# 2. 保存 eval jsonl
with open(eval_jsonl_path, "w", encoding="utf-8") as f:
    for item in eval_dpo_ds:
        f.write(json.dumps(item, ensure_ascii=False) + "\n")

# 3. 保存 HuggingFace Dataset 目录
train_dpo_ds.save_to_disk(str(train_hf_path))
eval_dpo_ds.save_to_disk(str(eval_hf_path))

print("训练集 jsonl：", train_jsonl_path)
print("验证集 jsonl：", eval_jsonl_path)
print("训练集 HF目录：", train_hf_path)
print("验证集 HF目录：", eval_hf_path)
print("训练集样本数：", len(train_dpo_ds))
print("验证集样本数：", len(eval_dpo_ds))

最后就能看到我们保存下的路径了：

训练集 jsonl： D:\微调与部署\DPO\data\processed\train_dpo_no_think_450.jsonl
验证集 jsonl： D:\微调与部署\DPO\data\processed\eval_dpo_no_think_50.jsonl
训练集 HF目录： D:\微调与部署\DPO\data\processed\train_dpo_no_think_450
验证集 HF目录： D:\微调与部署\DPO\data\processed\eval_dpo_no_think_50
训练集样本数： 450
验证集样本数： 50

至此，整个数据准备流程就完成了。我们已经从原始偏好数据出发，依次完成了数据清洗、质量筛选、格式转换、训练/验证集划分以及本地保存等步骤。接下来，就可以在此基础上进一步进行超参数设置，并正式开始模型训练。

超参数准备

在前面的 SFTConfig 中，我们已经介绍过大多数通用训练参数，例如学习率、批大小、梯度累积、训练轮数，以及保存与日志策略等。这些参数在 DPOConfig 中同样存在，因此这里不再重复展开。

对于 DPO 而言，更值得重点关注的是那些与偏好优化机制本身直接相关的参数。换句话说，DPO 的关键并不只是“像普通微调一样把模型继续训练下去”，而是在训练过程中回答这样几个更核心的问题：模型应当以多大的力度朝着人类偏好的方向更新、这种偏好优化具体采用什么样的损失函数形式、参考模型在其中承担什么作用，以及在有限显存条件下如何让训练过程更加稳定可控。

因此，接下来我们重点介绍几个在 DPOConfig 中更具代表性的参数，包括：控制偏好优化强度的 beta，决定损失函数形式的 loss_type，用于处理噪声偏好的 label_smoothing，以及与参考模型计算和训练稳定性密切相关的 precompute_ref_log_probs、reference_free 和 learning_rate 等参数。理解了这些参数，也就基本把握住了 DPO 训练配置中最核心的部分。

beta

beta 是 DPO 中最核心的参数之一。官方文档将其解释为用于控制当前策略模型相对于参考模型的偏离程度。beta 越大，模型越不容易偏离参考模型。在标准 DPO 中，它本质上决定了“偏好优化信号”施加得有多强。TRL 文档中给出的默认值是 0.1，这也是很多入门实验里最常见的起点。

其对应到损失函数的公式中其实就是  的值：

直观来说，可以把 beta 理解成一根“拉绳”：

• 当 beta 较小的时候，模型会更积极地朝着 chosen 方向移动，也更容易远离原来的 SFT/参考模型；
• 当 beta 较大的时候，模型更新会更保守，更强调“在原有能力基础上微调偏好”，不容易发生过大的分布漂移。

对于我们这小规模 DPO 实验，通常直接从 beta=0.1 开始就可以了。后续如果发现模型变化太猛、输出风格漂移明显，可以尝试适当调大；如果发现偏好学习不明显，再考虑适当调小。

loss_type 与 loss_weights

loss_type 用来指定 DPO 训练所采用的损失函数形式。对于最标准、最经典的 DPO，通常使用的是 loss_type="sigmoid"，这也是 TRL 中的默认设置，对应的正是前面介绍过的标准 DPO 损失函数。

不过，TRL 并不仅仅支持原始 DPO 一种形式，它还额外提供了 hinge、ipo、exo_pair、robust、bco_pair、aot、apo_zero、apo_down、discopop、sft 等多种变体。这也意味着，DPOConfig 并不只是简单实现了一个固定的 DPO 算法，而是统一承载了一整类偏好优化方法。不同的 loss_type，本质上对应着不同的优化目标，也就是说，虽然它们都在学习“让模型更偏向 chosen、远离 rejected”，但具体采用的损失函数形式并不相同。

例如，当 loss_type="hinge" 时，其思路就不再是通过 sigmoid 去平滑建模偏好概率，而更接近于一种 margin loss。它要求模型对 chosen 相对于 rejected 的优势至少超过某个间隔；如果尚未达到这个间隔，就继续产生损失并推动模型更新。其形式可以写为：

可以看到，虽然它仍然围绕 chosen 和 rejected 的相对偏好展开，但具体的优化方式已经和标准 DPO 的 sigmoid 损失不同了。

除此之外，在较新的 TRL 版本中，loss_type 不仅可以写成一个字符串，也可以写成一个列表。这意味着训练时并不一定只优化一种目标，而是可以将多种损失函数组合起来共同训练。此时，与之配套的 loss_weights 就用于指定各个损失项的权重。例如：

loss_type=["sigmoid", "sft"]
loss_weights=[1.0, 1.0]

这组配置的含义并不是“只做 DPO”，而是同时优化偏好损失和监督微调损失，也就是一种 DPO + SFT 联合训练 的思路。这样做的好处在于，模型在学习偏好关系的同时，也能够继续维持一定的生成稳定性与原有输出能力。

不过，对于本节课这样的入门实战来说，并不打算把重点放在这些变体或混合损失上。这里我们仍然选择最基础、也最适合作为起点的配置方式：

loss_type="sigmoid"

也就是说，本节课将先聚焦于最标准的 DPO 训练形式，先把最核心的偏好优化逻辑跑通，再在后续需要时进一步讨论其他损失函数变体或联合训练方法。

label_smoothing

label_smoothing 在 DPO 里不是默认必须调的参数。但它在某些变体中非常重要。这个参数背后的含义是：现实中的偏好数据并不一定完全干净，有些 chosen / rejected 可能存在误标、边界模糊或评审不稳定的情况。此时，适当引入 label_smoothing，相当于告诉模型：“不要把每一条偏好标签都当成百分之百绝对正确。”

不过，对于我们这部分数据集已经经过筛选、而且专门保留了高分高分差样本的数据集来说，通常可以先保持：

label_smoothing=0.0

也就是先按“偏好标签可信”来训练。后续假如我们用的数据集可能不一定准确时可以看情况进行添加。

precompute_ref_log_probs 与 precompute_ref_batch_size

DPO 训练与普通的监督微调有一个很明显的不同点：在训练过程中，它不仅需要计算当前模型对 chosen 和 rejected 的输出概率，还需要同时计算参考模型在相同样本上的输出概率。也正因为如此，参考模型的前向计算会额外带来显存占用和计算开销。

其中，precompute_ref_log_probs 的作用，就是在正式训练开始之前，先将参考模型在训练集和验证集上的 log probability 预先计算并缓存下来。这样一来，后续训练时就不需要反复调用参考模型进行前向计算，从而能够减少重复计算带来的额外开销，并在一定程度上缓解训练阶段的显存压力。

而与之配套的 precompute_ref_batch_size，则用于控制预计算参考模型 log probability 时所使用的批大小。它影响的并不是正式 DPO 训练阶段的 batch size，而是“预计算这一步”一次送入多少条样本。这个参数同样需要结合显存情况来设置：如果设得过大，预计算时依然可能出现显存不足；如果设得过小，虽然更稳妥，但预计算过程也会相对更慢一些。

一般来说，在以下几种情况下，这组参数会尤其值得考虑：

• 参考模型本身较大，前向计算成本较高；
• 本地显存资源比较紧张；
• 数据集规模相对可控，适合提前完成预计算。

当然，这两个参数也并不是在任何场景下都必须开启。因为预计算本身需要额外的时间，同时缓存结果也会带来一定的存储开销。不过，结合本次实验的实际情况来看，我们当前的显存条件相对有限，而数据集规模又不算特别大，因此提前缓存参考模型的 log probability 往往是一个更稳妥的选择。

基于这一点，这里建议将 precompute_ref_log_probs 开启；同时，precompute_ref_batch_size 则应根据显存大小设置为一个相对保守的值，例如：

precompute_ref_log_probs=True
precompute_ref_batch_size=1

其中，precompute_ref_log_probs=True 的作用是启用参考模型概率的预计算与缓存，而 precompute_ref_batch_size=8 则表示在预计算阶段每次使用 1 条样本进行前向计算。这样做的主要目的，并不是改变 DPO 本身的训练逻辑，而是通过提前完成参考模型结果的计算，尽量减轻正式训练阶段的显存压力，使整个训练过程更容易在本地环境下顺利跑通。

reference_free

在标准 DPO 中，参考模型（reference model）扮演着非常重要的角色。它通常就是前面经过 SFT 得到的初始模型，并在后续偏好优化阶段保持冻结不变。而 reference_free 这个参数，控制的就是训练时是否显式使用这份参考模型。

当设置为 reference_free=True 时，训练过程将不再显式依赖一份冻结的参考模型，而是近似地假设参考分布是一个“均匀的、常数式的基准分布”。换句话说，此时模型优化时关注的重点就不再是“相对于参考模型的变化”，而更接近于只根据当前模型自身对 chosen 和 rejected 的偏好差异来学习。

这样做的好处是，训练流程会更简化一些，也不需要再额外维护一份真正的参考模型；但它的代价也很明显，那就是标准 DPO 中最关键的“参考锚点”被弱化了。一旦失去了这个对照基准，模型虽然仍然可以学习偏好关系，但“是在原模型基础上做受约束的偏好优化”这一层含义就不再那么明确了。

也正因为如此，在本节课的实战中，更推荐保持默认设置：

reference_free=False

这样做的原因并不是因为 reference_free=True 一定不能用，而是因为对于入门阶段来说，保留参考模型能够更完整地体现 DPO 的核心思想，也更有利于理解后续损失函数中为什么会同时出现当前模型和参考模型的概率项。

learning_rate

虽然学习率在之前的课程里也有提到过，但在 DPO 训练中，学习率是一个需要特别谨慎设置的超参数。与普通的监督微调相比，DPO 的目标并不是让模型大幅度学习全新的生成模式，而是在原有模型能力的基础上，进一步调整其对 chosen 与 rejected 的偏好关系。也正因为如此，DPO 往往更强调一种保守、稳定的更新方式，以避免模型在偏好优化过程中偏移过快，进而破坏原本已经具备的语言能力、指令跟随能力以及输出稳定性。因此，在实际训练中，DPO 的学习率通常会设置得比 SFT 更低一些，比如设置为 5e-6。

不过，学习率也不能脱离具体训练方式单独来看。若采用全参数训练，由于模型中所有参数都会参与更新，因此学习率通常需要设置得更加保守，一般可以从较小的范围开始尝试；而如果采用的是 LoRA / QLoRA 这类参数高效微调方法，由于真正被更新的只是少量新增参数，因此学习率可以适当提高一些，但整体上仍然建议保持比 SFT 更谨慎的设置。

结合本节课的实验目标来看，我们这里更关注的是完成一次稳定的小规模 DPO 偏好优化，而不是对模型能力进行大幅度改写。因此，学习率更适合从一个偏保守的范围开始设置。如果后续训练过程中出现 loss 波动明显、输出质量下降或者模型回答风格异常偏移等现象，就应优先考虑进一步减小学习率。

也就是说，在 DPO 训练中，学习率的设置原则并不是“越大越快”，而是要尽量在训练稳定性和偏好学习效果之间取得平衡。对于入门实验而言，宁可设置得稍微保守一些，也比因为学习率过大而导致训练不稳定更稳妥。

训练脚本准备

在介绍完 DPO 中几个较为关键的超参数之后，接下来就可以正式进入训练代码部分了。总体来看，DPO 的训练流程与前面介绍过的 SFT 训练并没有本质上的差别，核心步骤仍然包括：准备模型路径、读取数据集、加载 tokenizer、构建模型以及配置训练参数等。真正的区别主要体现在两个方面：一是 DPO 训练通常还需要额外考虑参考模型的处理方式；二是训练参数中会多出一些与偏好优化直接相关的配置项。

全量模型训练脚本

首先来看最基础、也最容易理解的一种方式——全量模型训练。所谓全量训练，指的是在训练过程中直接对模型本体参数进行更新，而不是只训练附加的小规模适配参数。对于理解 DPO 的完整训练流程来说，这种方式最直观，因为它完整保留了“策略模型 + 参考模型 + 偏好优化目标”这一标准结构。

在这一版本的脚本中，我们首先需要完成几项基础准备工作：定义基础模型路径、训练集与验证集路径，以及最终模型输出目录；随后读取前面已经处理好的 DPO 数据集，并加载对应的 tokenizer。由于这里使用的是 Qwen 系列模型，因此还需要保证 pad_token 可用，避免后续在批处理时出现不必要的问题。

接下来最关键的一步，是同时加载两份模型：一份作为当前参与训练的 policy model，另一份作为保持冻结的 reference model。这正是 DPO 与普通 SFT 相比最典型的区别之一。在 SFT 中，我们通常只关心一个模型如何去拟合目标答案；而在 DPO 中，训练时还需要额外保留一个参考模型，作为当前模型进行偏好更新时的比较基准。也正因为如此，在代码层面会看到同时加载 model 和 ref_model 两份模型。

随后，就可以通过 DPOConfig 配置训练所需的各项参数。例如，批大小、梯度累积、训练轮数、学习率调度策略，以及前面已经介绍过的 beta、loss_type、precompute_ref_log_probs 等。这些参数共同决定了 DPO 训练究竟会以怎样的方式进行：既要让模型学习偏好关系，又要尽量控制训练过程中的稳定性与显存消耗。

在完成参数配置之后，使用 DPOTrainer 将模型、参考模型、训练参数、数据集和 tokenizer 组织起来，就可以正式开始训练了。整体来看，这套全量训练脚本最适合用来帮助读者理解 DPO 的标准训练流程，因为它把参考模型、偏好损失以及完整参数更新过程都保留得比较清晰。训练完成后，模型的检查点和相关输出结果会被保存到指定目录中，便于后续继续评估或加载使用。

具体脚本内容如下所示：

import torch
from datasets import load_from_disk
from transformers import AutoModelForCausalLM, AutoTokenizer
from trl import DPOConfig, DPOTrainer

# =========================
# 1. 路径配置
# =========================
model_name_or_path = r"D:\微调与部署\qwen"   # 改成你的基础模型路径
train_dataset_path = r"D:\微调与部署\DPO\data\processed\train_dpo_no_think_450"
eval_dataset_path = r"D:\微调与部署\DPO\data\processed\eval_dpo_no_think_50"
output_dir = r"D:\微调与部署\DPO\outputs\qwen3_dpo_full"

# =========================
# 2. 读取数据集
# =========================
train_dataset = load_from_disk(train_dataset_path)
eval_dataset = load_from_disk(eval_dataset_path)

# =========================
# 3. 加载 tokenizer
# =========================
tokenizer = AutoTokenizer.from_pretrained(
    model_name_or_path,
    trust_remote_code=True
)

# Qwen 一类模型通常需要确保 pad_token 可用
if tokenizer.pad_token isNone:
    tokenizer.pad_token = tokenizer.eos_token

# =========================
# 4. 加载 policy model 和 reference model
#    这是最朴素的 DPO 写法
# =========================
model = AutoModelForCausalLM.from_pretrained(
    model_name_or_path,
    trust_remote_code=True,
    torch_dtype=torch.bfloat16,
    device_map="auto"
)

ref_model = AutoModelForCausalLM.from_pretrained(
    model_name_or_path,
    trust_remote_code=True,
    torch_dtype=torch.bfloat16,
    device_map="auto"
)

# 关闭 cache，训练时更稳一些
model.config.use_cache = False
ref_model.config.use_cache = False
# =========================
# 5. DPO 训练参数
# =========================
training_args = DPOConfig(
    output_dir=output_dir,

    # 基础训练参数
    per_device_train_batch_size=1,
    per_device_eval_batch_size=1,
    gradient_accumulation_steps=8,
    num_train_epochs=1,

    # 学习率
    learning_rate=5e-6,
    lr_scheduler_type="cosine",
    warmup_ratio=0.1,

    # 日志与保存
    logging_steps=5,
    eval_strategy="steps",
    eval_steps=20,
    save_strategy="steps",
    save_steps=20,
    save_total_limit=2,

    # DPO 核心参数
    beta=0.1,
    loss_type="sigmoid",

    # 长度控制
    max_length=512,
    
    # 让训练时不常驻 reference model，节省显存
    precompute_ref_log_probs=True,
    precompute_ref_batch_size=1,
)

# =========================
# 6. 构建 DPOTrainer
# =========================
trainer = DPOTrainer(
    model=model,
    ref_model=ref_model,
    args=training_args,
    train_dataset=train_dataset,
    eval_dataset=eval_dataset,
    processing_class=tokenizer,
)

# =========================
# 7. 开始训练
# =========================
trainer.train()

训练完成后大家就可以在文件夹中看到对应的输出结果：

QLoRA 模型训练

除了直接进行全参数训练之外，在实际使用中，更常见也更实用的一种做法是采用 QLoRA 方式来完成 DPO 微调。这样做的主要原因在于全量训练对显存要求较高，而 QLoRA 通过低比特量化与 LoRA 适配参数训练的结合，可以显著降低资源消耗，使得在本地设备上完成 DPO 训练成为可能。

与前面的全量训练相比，QLoRA 版本的整体流程仍然是相似的：同样需要准备路径、读取数据集、加载 tokenizer，并设置好训练参数。不同之处主要在于模型加载与训练方式的变化。这里不再直接加载完整精度模型，而是先通过 4bit 量化配置对模型进行压缩，然后在此基础上为 k-bit 训练做准备。这样做的目的，是在尽可能保留模型能力的前提下，大幅降低显存占用。

在完成量化模型加载后，还需要进一步配置 LoRA 参数。也就是说，此时真正参与训练的并不是原始模型的全部参数，而是插入到模型线性层中的一小部分可训练适配参数。这样做的好处非常明显，一方面，显存占用会显著下降；另一方面，训练速度通常也会更加可控。对于本节课这种以教学演示为主的实验场景来说，QLoRA 往往是更具有现实可操作性的方案。

在训练参数设置上，QLoRA 版本也会与全量训练略有区别。例如，为了进一步节省显存，通常会启用梯度检查点；同时，由于训练的只是少量适配参数，学习率往往可以设置得比全量训练略高一些。此外，在这个版本中，ref_model 不再单独显式加载，而是由 Trainer 以初始策略模型作为参考，这也是参数高效微调场景中较常见的一种写法。

总体来看，QLoRA 版本的代码虽然在工程配置上比全量训练稍复杂一些，但它更贴近实际开发中的常见做法。尤其是在本地显存有限的情况下，QLoRA 能够显著降低 DPO 训练门槛，使得偏好优化不再只是高算力环境下才能完成的任务。训练结束后，同样会在输出目录中生成对应的模型文件与检查点，便于后续继续使用和测试。

具体的脚本设置如下所示：

import torch
from datasets import load_from_disk
from transformers import AutoTokenizer, AutoModelForCausalLM, BitsAndBytesConfig
from peft import LoraConfig, prepare_model_for_kbit_training
from trl import DPOConfig, DPOTrainer

# =========================
# 1. 路径配置
# =========================
model_name_or_path = r"D:\微调与部署\qwen"   # 改成你的基础模型路径
train_dataset_path = r"D:\微调与部署\DPO\data\processed\train_dpo_no_think_450"
eval_dataset_path = r"D:\微调与部署\DPO\data\processed\eval_dpo_no_think_50"
output_dir = r"D:\微调与部署\DPO\outputs\qwen3_dpo_qlora"

# =========================
# 2. 读取数据集
# =========================
train_dataset = load_from_disk(train_dataset_path)
eval_dataset = load_from_disk(eval_dataset_path)

# =========================
# 3. tokenizer
# =========================
tokenizer = AutoTokenizer.from_pretrained(
    model_name_or_path,
    trust_remote_code=True,
    use_fast=False,
)

if tokenizer.pad_token isNone:
    tokenizer.pad_token = tokenizer.eos_token

# =========================
# 4. 4bit 量化配置（QLoRA）
# =========================
bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_use_double_quant=True,
    bnb_4bit_compute_dtype=torch.bfloat16,
)

# =========================
# 5. 加载量化模型
# =========================
model = AutoModelForCausalLM.from_pretrained(
    model_name_or_path,
    trust_remote_code=True,
    quantization_config=bnb_config,
    device_map="auto",
)

model.config.use_cache = False

# 为 k-bit 训练做准备
model = prepare_model_for_kbit_training(model)

# =========================
# 6. LoRA 配置
#    QLoRA 风格建议 target_modules="all-linear"
# =========================
peft_config = LoraConfig(
    r=8,                     # 6GB 显存先保守一点
    lora_alpha=16,
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
    target_modules="all-linear",
)

# =========================
# 7. DPO 训练参数
# =========================
training_args = DPOConfig(
    output_dir=output_dir,

    # 小显存核心参数
    per_device_train_batch_size=1,
    per_device_eval_batch_size=1,
    gradient_accumulation_steps=8,
    gradient_checkpointing=True,
    
    # 训练轮数
    num_train_epochs=1,

    # LoRA 训练学习率可略高一些
    learning_rate=1e-5,
    lr_scheduler_type="cosine",
    warmup_steps=0.1,

    # 日志 / 验证 / 保存
    logging_steps=5,
    eval_strategy="steps",
    eval_steps=20,
    save_strategy="steps",
    save_steps=20,
    save_total_limit=2,

    # DPO 核心
    beta=0.1,
    loss_type="sigmoid",

    # 长度可以适度增加，QLoRA 训练时通常不会爆显存
    max_length=1024,

    # 让训练时不常驻 reference model，节省显存
    precompute_ref_log_probs=True,
    precompute_ref_batch_size=1,
)

# =========================
# 8. DPOTrainer
#    ref_model=None：让 Trainer 使用初始 policy 作为 reference
# =========================
trainer = DPOTrainer(
    model=model,
    ref_model=None,
    args=training_args,
    train_dataset=train_dataset,
    eval_dataset=eval_dataset,
    processing_class=tokenizer,
    peft_config=peft_config,
)

# =========================
# 9. 开始训练
# =========================
trainer.train()

训练完后我们同样可以看到对应的模型文件：

训练过程

全量模型

从这次全量 DPO 微调的训练日志来看，整体训练过程是比较正常且有效的。模型在训练过程中逐步学会了更明显地区分 chosen 与 rejected，也就是说，偏好优化确实起到了作用。虽然中间个别 step 会有一定波动，但从总体趋势上看，关键指标大多在朝着较好的方向发展。

{'loss': '0.6829', 'grad_norm': '146', 'learning_rate': '3.333e-06', 'entropy': 'nan', 'num_tokens': '3.742e+04', 'logits/chosen': '-2.176', 'logits/rejected': '-2.543', 'mean_token_accuracy': '0.6143', 'rewards/chosen': '-0.0184', 'rewards/rejected': '-0.04012', 'rewards/accuracies': '0.325', 'rewards/margins': '0.02172', 'logps/chosen': '-116.6', 'logps/rejected': '-223.3', 'epoch': '0.08889'}
...
{'eval_loss': '0.3418', 'eval_runtime': '94.85', 'eval_samples_per_second': '0.527', 'eval_steps_per_second': '0.527', 'eval_entropy': 'nan', 'eval_num_tokens': '2.739e+05', 'eval_logits/chosen': '-2.295', 'eval_logits/rejected': '-2.405', 'eval_mean_token_accuracy': '0.7018', 'eval_rewards/chosen': '-0.8888', 'eval_rewards/rejected': '-2.682', 'eval_rewards/accuracies': '0.8', 'eval_rewards/margins': '1.794', 'eval_logps/chosen': '-165.1', 'eval_logps/rejected': '-275.8', 'epoch': '0.7111'}
...
{'loss': '0.3594', 'grad_norm': '55.25', 'learning_rate': '4.257e-08', 'entropy': 'nan', 'num_tokens': '3.776e+05', 'logits/chosen': '-2.438', 'logits/rejected': '-2.569', 'mean_token_accuracy': '0.6791', 'rewards/chosen': '-0.9492', 'rewards/rejected': '-2.772', 'rewards/accuracies': '0.825', 'rewards/margins': '1.823', 'logps/chosen': '-231.9', 'logps/rejected': '-293.4', 'epoch': '0.9778'}
{'train_runtime': '3519', 'train_samples_per_second': '0.128', 'train_steps_per_second': '0.016', 'train_loss': '0.4387', 'entropy': '0.5963', 'num_tokens': '3.845e+05', 'logits/chosen': '-2.749', 'logits/rejected': '-2.81', 'mean_token_accuracy': '0.8045', 'rewards/chosen': '-1.056', 'rewards/rejected': '-2.601', 'rewards/accuracies': '0.8', 'rewards/margins': '1.546', 'logps/chosen': '-125.7', 'logps/rejected': '-296.1', 'epoch': '1'}
100%|███████████████████████████████████████████████████████████████████████████████████████████████████████████████| 57/57 [58:38<00:00, 61.73s/it]