jingyaogong/minimindPublic

• 此开源项目旨在完全从 0 开始，仅用 3 块钱成本与 2 小时训练时间，即可训练出规模约为 64M 的超小语言模型 MiniMind。
• MiniMind 系列极其轻量，主线最小版本体积约为 GPT-3 的 $\frac{1}{2700}$，力求让普通个人 GPU 也能快速完成训练与复现。
• 项目同时开源了大模型的极简结构与完整训练链路，覆盖 MoE、数据清洗、预训练（Pretrain）、监督微调（SFT）、LoRA、RLHF（DPO）、RLAIF（PPO / GRPO / CISPO）、Tool Use、Agentic RL、自适应思考与模型蒸馏等全过程代码。
• MiniMind 同时拓展了视觉模态模型 MiniMind-V、多模态 Omni 模型 MiniMind-O、扩散语言模型（MiniMind-dLM）、线性模型（MiniMind-Linear），详见 Discussion。
• 项目所有核心算法代码均从 0 使用 PyTorch 原生实现，不依赖第三方库提供的高层抽象接口。
• 这不仅是一个大语言模型全阶段开源复现项目，也是一套面向 LLM 入门与实践的教程。
• 希望此项目能为更多人提供一个可复现、可理解、可扩展的起点，一起感受创造的乐趣，并推动更广泛 AI 社区的进步。

注：本项目基于 Apache 2.0 协议开源，完全免费。“2 小时” 指 SFT 阶段在单张 NVIDIA 3090 上跑完 1 epoch 的实测耗时，“3 块钱” 指对应时段的 GPU 租用成本。

🔗 在线体验 | 🔗 视频介绍

大语言模型（Large Language Model, LLM）的出现，引发了全球范围内对 AI 的空前关注。无论是 ChatGPT、DeepSeek 还是 Qwen，都以惊艳的效果让人真切感受到这场技术浪潮的冲击力。然而，动辄数百亿参数的模型规模，使得它们对个人设备而言不仅难以训练，甚至连部署都显得遥不可及。打开大模型的“黑盒子”，真正去理解其内部运作机制，本应是一件令人心潮澎湃的事。遗憾的是，绝大多数探索最终都止步于使用 LoRA 等技术对现有大模型做少量微调，学习一些新指令或特定任务。这更像是在教牛顿如何使用 21 世纪的智能手机——虽然有趣，却偏离了理解物理本质的初衷。

与此同时，第三方的大模型框架与工具库，如 transformers / trl / peft 等，往往只暴露出高度抽象的接口。只需短短十几行代码，就可以完成“加载模型 + 加载数据集 + 推理 + 强化学习”的全流程训练。这种高效封装固然便利，却也在一定程度上把开发者与底层实现隔离开来，削弱了深入理解 LLM 核心代码的机会。我认为 “用乐高自己拼出一架飞机，远比坐在头等舱里飞行更让人兴奋”，然而更现实的问题是，互联网上充斥着大量付费课程和营销内容，用漏洞百出、一知半解的讲解包装所谓的 AI 教程。正因如此，本项目的初衷就是尽可能降低 LLM 的学习门槛，让每个人都能从理解每一行代码开始，从 0 开始亲手训练一个极小的语言模型。是的，从零开始训练，而不是仅仅停留在推理层面。最低只需不到 3 块钱的服务器成本，就能亲身体验从 0 到 1 构建一个语言模型的全过程。

😊 一起感受创造的乐趣吧！

• 提供完整的 MiniMind-LLM 结构代码（Dense + MoE），当前主线结构对齐 Qwen3 / Qwen3-MoE 生态。
• 提供 Tokenizer 与分词器训练代码，支持 <tool_call>、<tool_response>、<think> 等模板标记。
• 覆盖 Pretrain、SFT、LoRA、RLHF-DPO、RLAIF（PPO / GRPO / CISPO）、Tool Use、Agentic RL、自适应思考与模型蒸馏等完整训练流程。
• 提供全阶段开源数据，覆盖收集、蒸馏、清洗与去重后的高质量数据集。
• 关键训练算法与核心模块均从 0 实现，不依赖第三方框架封装。
• 兼容 transformers、trl、peft 等主流框架，以及 llama.cpp、vllm、ollama 等常用推理引擎与 Llama-Factory 等训练框架。
• 支持单机单卡与单机多卡（DDP、DeepSpeed）训练，支持 wandb / swanlab 可视化与动态启停训练。
• 支持在 C-Eval、C-MMLU、OpenBookQA 等第三方测评集上进行评测，并支持通过 YaRN 实现 RoPE 长文本外推。
• 提供兼容 OpenAI API 协议的极简服务端，便于接入 FastGPT、Open-WebUI 等第三方 Chat UI，并支持 reasoning_content、tool_calls、open_thinking。
• 提供基于 Streamlit 的极简聊天 WebUI，支持思考展示、工具选择与多轮 Tool Call。
• 包含实验性拓展：离散扩散语言模型（dLM）与线性注意力模型（Linear Attention），均可基于主线 AR 模型进行续训。

为兼容第三方推理框架llama.cpp、vllm，本次更新需付出一些可观代价。
本次更新不再支持「直接」加载25-04-26以前的旧模型进行推理。
由于Llama位置编码方式与minimind存在区别，导致映射Llama模型后QK值存在差异
minimind2系列旧模型均经过权重映射+（微调训练）QKVO线性层校准恢复而来。
本次更新后将放弃对`minimind-v1`全系列的维护，并在仓库中下线。

# 克隆仓库、安装依赖
git clone --depth 1 https://github.com/jingyaogong/minimind
cd minimind && pip install -r requirements.txt -i https://mirrors.aliyun.com/pypi/simple

在项目根目录：

# 方式1
modelscope download --model gongjy/minimind-3 --local_dir ./minimind-3
# 方式2
git clone https://huggingface.co/jingyaogong/minimind-3

# 方式1：使用 Transformers 格式模型
python eval_llm.py --load_from ./minimind-3
# 方式2：基于 PyTorch 模型（确保./out目录下有对应权重）
python eval_llm.py --load_from ./model --weight full_sft

# 可能需要`python>=3.10`，安装 `pip install streamlit`
# ⚠️ 须先将 transformers 格式模型文件夹复制到 ./scripts/ 目录下（例如：cp -r minimind-3 ./scripts/minimind-3），web_demo 脚本会自动扫描该目录下包含权重文件的子文件夹，如不存在则报错
cd scripts && streamlit run web_demo.py

# ollama
ollama run jingyaogong/minimind-3
# vllm
vllm serve /path/to/model --served-model-name "minimind"

import torch
print(torch.cuda.is_available())

从下文提供的数据集下载链接 下载所需数据文件，并放入 ./dataset 目录

当前默认仅需下载 pretrain_t2t_mini.jsonl 与 sft_t2t_mini.jsonl，即可较快复现 MiniMind Zero 对话模型。 如有更多需求，下文提供多种搭配方案，可根据自身任务目标与 GPU 资源灵活选择。

python train_pretrain.py --from_resume 1
python train_full_sft.py --from_resume 1
# ...

cd trainer && python train_pretrain.py

训练后，将得到 out/pretrain_*.pth 作为输出权重（其中 * 为模型 dimension，默认为 768）

cd trainer && python train_full_sft.py

训练后，将得到 out/full_sft_*.pth 作为输出权重（其中 full 表示全参数微调）

确保待测试的模型 *.pth 文件位于 ./out/ 目录下；也可直接前往此处下载我已训练好的 *.pth 权重。

python eval_llm.py --weight full_sft

--weight 用于指定权重名称前缀，例如 pretrain、full_sft 等；更多参数可直接参考 eval_llm.py

torchrun --nproc_per_node N train_xxx.py

... train_xxx.py --use_wandb

分词器可以粗略理解成 LLM 使用的一本“词典”，负责把自然语言映射成 token id，再把 token id 解码回文本；项目中也提供了train_tokenizer.py作为词表训练示例。不建议重新训练 tokenizer，因为词表和切分规则一旦变化，模型权重、数据格式、推理接口与社区生态的兼容性都会下降，也会削弱模型的传播性。同时，tokenizer 还会影响 PPL 这类按 token 统计的指标，因此跨 tokenizer 比较时，BPB（Bits Per Byte）往往更有参考价值，可参考这篇。 对 MiniMind 这类小模型来说，词表大小还会直接影响 embedding 层和输出层的参数占比，因此保持词表精简通常是更合适的取舍。

MiniMind-3 当前主线预训练数据为 pretrain_t2t.jsonl / pretrain_t2t_mini.jsonl。
这两份数据已经整理成统一的 text -> next token prediction 训练格式，目标是在较小算力下兼顾：

• 文本质量；
• 长度分布；
• 中英混合能力；
• 与后续 SFT / Tool Calling / RLAIF 阶段的模板衔接。

数据来源包括但不限于通用文本语料、对话整理语料、蒸馏补充语料，以及各类宽松开源协议可用的数据集；主线数据会在清洗、去重、长度控制与格式统一后再进入训练。主要来源包括：匠数大模型数据集、Magpie-Align 等公开数据源。

其中：

• pretrain_t2t_mini.jsonl 更适合快速复现；
• pretrain_t2t.jsonl 更适合完整训练 MiniMind-3 主线模型。

文件数据格式为

{"text": "如何才能摆脱拖延症？治愈拖延症并不容易，但以下建议可能有所帮助。"}
{"text": "清晨的阳光透过窗帘洒进房间，桌上的书页被风轻轻翻动。"}
{"text": "Transformer 通过自注意力机制建模上下文关系，是现代大语言模型的重要基础结构。"}

MiniMind-3 当前主线 SFT 数据为 sft_t2t.jsonl / sft_t2t_mini.jsonl。相比更早期的 sft_512 / sft_1024 / sft_2048 方案，当前版本更强调：

• 统一模板；
• 更适合对话 + 思考标签 + Tool Calling 的混合训练；
• 尽量减少数据预处理分叉，降低复现成本。

其数据来源包括但不限于高质量指令跟随数据、公开对话数据、模型蒸馏合成数据，以及协议友好的开源数据集；在进入 t2t 主线前，会统一为当前仓库使用的多轮对话格式。当前主线中也包含大量合成数据，例如本人基于 qwen3-4b 合成的约 10w 条 tool call 数据，以及 qwen3 系列的 reasoning 数据等。其中社区主要来源有：匠数大模型数据集、Magpie-Align、R1-Distill-SFT、COIG、Step-3.5-Flash-SFT 等。公布版本会确保数据来源与处理链路符合对应开源协议的可传递性约束，并遵守 Apache-2.0、CC-BY-NC-2.0 等相关协议要求。

其中：

• sft_t2t_mini.jsonl：适合快速训练对话模型；
• sft_t2t.jsonl：适合完整复现主线版本；
• toolcall 能力已经并入主线 SFT 数据。

所有 SFT 文件数据格式均为（包含对话数据、Tool Use 数据）

{
    "conversations": [
        {"role": "user", "content": "你好"},
        {"role": "assistant", "content": "你好！"},
        {"role": "user", "content": "再见"},
        {"role": "assistant", "content": "再见！"}
    ]
}
{
    "conversations": [
        {"role": "system", "content": "# Tools ...", "tools": "[...]"},
        {"role": "user", "content": "把'你好世界'翻译成english"},
        {"role": "assistant", "content": "", "tool_calls": "[{\"name\":\"translate_text\",\"arguments\":{\"text\":\"你好世界\",\"target_language\":\"english\"}}]"},
        {"role": "tool", "content": "{\"translated_text\":\"Hello World\"}"},
        {"role": "assistant", "content": "Hello World"}
    ]
}

MiniMind 当前主线 RL 数据为 dpo.jsonl。数据抽样自 DPO-En-Zh-20k。

主线中会将这部分样本统一重组为当前仓库使用的偏好学习格式，用于奖励模型或偏好优化阶段训练；其中 chosen 表示更符合偏好的回复，rejected 表示相对较差的回复。

其中 dpo.jsonl 数据格式为

{
  "chosen": [
    {"content": "Q", "role": "user"}, 
    {"content": "good answer", "role": "assistant"}
  ], 
  "rejected": [
    {"content": "Q", "role": "user"}, 
    {"content": "bad answer", "role": "assistant"}
  ]
}

除此之外，其他 RL 数据与 SFT 数据格式保持一致，通常是从 SFT 数据中按总长度和对话轮次筛选得到，并将最后一个 assistant 位置留空，供 rollout 阶段续写使用。

MiniMind训练数据集下载地址： ModelScope | HuggingFace

无需全部clone，可单独下载所需的文件

将下载的数据集文件放到./dataset/目录下（✨为推荐的必须项）

./dataset/
├── agent_rl.jsonl (86MB)
├── agent_rl_math.jsonl (18MB)
├── dpo.jsonl (53MB)
├── pretrain_t2t_mini.jsonl (1.2GB, ✨)
├── pretrain_t2t.jsonl (10GB)
├── rlaif.jsonl (24MB, ✨)
├── sft_t2t_mini.jsonl (1.6GB, ✨)
└── sft_t2t.jsonl (14GB)

MiniMind 主线训练数据组成与推荐组合示意图

minimind-3 Dense 使用 Transformer Decoder-Only 结构，整体配置已经向 Qwen3 生态对齐，方便后续转换到 transformers / llama.cpp / ollama / vllm：

• 采用预标准化（Pre-Norm）+ RMSNorm。
• 使用 SwiGLU 激活函数。
• 使用 RoPE 旋转位置编码，并支持 YaRN 外推。
• q_heads=8、kv_heads=4，max_position_embeddings=32768，rope_theta=1e6。

minimind-3-moe 在相同结构上扩展 MoE 前馈层，实现上兼容 Qwen3-MoE 风格配置（去除 shared expert）。

• 当前默认配置为 4 experts / top-1 routing，用于以更低激活参数获得更高容量。
• Experts 继续增加后，实际耗时往往比同尺寸规模的 dense 模型高非常多，这和 “MoE 推理更快” 放在一起看会有点反直觉，但训练时 token 先按专家分桶、再分别做 forward，原生训练时带来的 kernel 启停和调度开销会急剧变重，这本身是很自然的事情。得靠支持 MoE kernel-fused 的算子库来优化，比如基于 Triton 的自定义 kernel、DeepSpeed-MoE、Megatron-LM 等等。当然，这个项目还是希望保留原生 PyTorch 的普适性，所以这里做的是现实的折中，在当前实现下，4 experts / top-1 这个甜点配置大约只比 dense 模型慢 50% 左右。

minimind-3 系列结构如下图：

修改模型配置见./model/model_minimind.py，参考模型参数版本见下表：

关于 LLM 的参数配置，MobileLLM 对小模型做过一组很有代表性的系统研究。对 MiniMind 这类百M级模型而言，d_model 与 n_layers 的取舍不只是参数分配问题，也会直接影响训练稳定性与最终效果。

当前 minimind-3 主线选择 dim=768, n_layers=8，本质上是一种工程取舍：更浅的网络训练更快，同时 dim 也不至于过小而导致模式崩溃，因此能在训练效率、稳定性与最终效果之间取得相对均衡。

• 时间单位：小时（h）
• 成本单位：人民币（￥）；7￥ ≈ 1 美元
• 3090 租卡单价：约 1.3￥/h（实际价格可自行参考）
• 说明：以下结果为 minimind 模型在单卡 3090 上的经验估算值，用于快速感知训练门槛

基于单卡 NVIDIA 3090，minimind zero 从 0 训练依然可以控制在约 2 小时量级，个人开发者也能较低门槛地快速上手。

若采用更高规格的多卡环境，例如 8x H100，总训练时长还可进一步压缩至分钟级。以尽可能低的门槛实现可复现、可上手、可持续迭代的 LLM 训练体验，这也是 MiniMind 系列一直希望坚持的方向。低成本快速复现并不是噱头，下面保留一个早期的 Zero 风格样例对话供参考：

👶: 请介绍一下自己。
🤖️: 作为人工智能，我没有实际的生活，也没有自我意识，所以没有自己的生活。我被设计成能够帮助用户解答问题、提供信息、进行对话等。我的设计和功能是由计算机科学、机器学习、人工智能技术和算法所构建的，我通过编程和算法实现。

👶: 推荐一些杭州的特色美食吧。
🤖️: 杭州有很多美味的特色美食，比如鸡肉串、鳗鱼头、水煮鱼、豆腐脑等。这些美食都非常美味，有着独特的风味和口感，绝对是值得一试的美食。

👶: 请为我讲解“大语言模型”这个概念。
🤖️: 大语言模型是一种人工智能技术，它使用大量的文本数据来训练模型，然后在不断的迭代中不断优化模型。它的目标是根据输入的数据来生成符合特定需求的文本，这些文本可以是任何你感兴趣的主题。

👶: Introduce the history of the United States, please.
🤖️: 您提到的“Introok's the believeations of theument." 这个名字来源于中国古代的"groty of of the change."

尽管该版本已经具备基础对话能力，但事实知识与泛化效果仍较有限；它更适合作为 Zero 训练路线可行性的早期参考。 Zero 模型权重保存为 full_sft_zero_768.pth（见下文 MiniMind 模型文件链接），如有兴趣可下载体验其对话效果。

所有训练脚本均 cd ./trainer 目录执行

LLM 首先要学会的是先把尽可能多的基础知识和语言规律吸收到参数里。只有这一步打稳了，模型后面才有能力去理解问题、组织表达，并逐步形成像样的生成能力。预训练做的事情，本质上就是让模型先埋头读大量文本，例如 Wiki 百科、新闻、书籍、对话语料等，从中学习事实知识、语言模式以及上下文之间的统计关系。这个阶段通常是“无监督”的：人类不需要逐条告诉模型哪里对、哪里错，而是让它自己从海量文本里总结规律，逐步建立起对世界知识和语言结构的内部表征。 更直白地说，模型在这一阶段的核心目标就是学会高质量地词语接龙。例如输入“秦始皇”，它要能够继续生成“是中国历史上的第一位皇帝”这类符合语义与常识的后续内容。

# 方式1
torchrun --nproc_per_node 1 train_pretrain.py # 1即为单卡训练，可根据硬件情况自行调整 (设置>=2)
# 方式2
python train_pretrain.py

训练后的模型权重文件默认每隔save_interval步保存为:pretrain_*.pth（*为模型具体dimension，每次保存时新文件会覆盖旧文件）

768dim 配置在预训练阶段的 loss 曲线

# 可对预训练结果做简单测试：
python eval_llm.py --weight pretrain

💬: 为什么天空是蓝色的
🧠: 天空之所以看起来是蓝色的，主要是因为太阳光进入大气层后，短波长的蓝光更容易被空气分子散射，因此人眼从各个方向接收到的蓝光会更多。

💬: 解释什么是机器学习
🧠: 机器学习是人工智能的一个重要分支，它通过数据训练模型，使系统能够自动学习规律，并在分类、预测、推荐、自然语言处理等任务中持续改进效果。

SFT 并不只是把模型调成“更会聊天”，它同样可以继续向模型中灌入新的知识、行为模式和回答风格。尤其是像 MiniMind 当前主线这样体量达到 14GB 的 SFT 数据，本身就已经不只是简单的格式对齐，而更接近一种带有 mid training 性质的持续强化过程。 如果把预训练理解为先让模型广泛地读书、积累基础语言能力，那么 SFT 更像是在高质量、更有目标的数据上继续深加工。一方面，它会让模型适应多轮对话、问答、工具调用和思考标签等交互形式；另一方面，它也会继续把特定知识分布、任务模式和助手风格压进参数里。 具体到 MiniMind 里，SFT 阶段会让模型适应当前仓库使用的多轮对话模板。模型会逐渐理解 user / assistant / system / tool 等角色结构，同时进一步强化指令跟随、稳定回复和任务完成能力。 当前训练时会对指令和回答长度做截断控制，主要是为了兼顾显存占用与训练效率；如果后续需要更长上下文，只需要继续准备少量长样本做增量微调即可。在推理时通过启用 YaRN 外推，可以免训练地将上下文长度扩展到 2048 及以上。

# 方式1
torchrun --nproc_per_node 1 train_full_sft.py
# 方式2
python train_full_sft.py

训练后的模型权重文件默认每隔save_interval步保存为: full_sft_*.pth（*为模型具体dimension，每次保存时新文件会覆盖旧文件）

768dim 配置在 SFT 阶段的 loss 曲线

# 可对SFT结果做简单测试：
python eval_llm.py --weight full_sft

💬: 解释什么是机器学习
🧠: 机器学习是人工智能的核心技术之一，通过算法让计算机从数据中学习规律，并持续改进预测或决策效果，常见应用包括推荐系统、图像识别、语音识别和自然语言处理。

💬: 推荐一些中国的美食
🧠: 例如北京烤鸭、兰州拉面、四川火锅、广东早茶、小笼包和麻婆豆腐等，这些美食分别代表了不同地区的风味特点，也很适合作为了解中国饮食文化的入门选择。

所有训练脚本均 cd ./trainer 目录执行

知识蒸馏大体可以分成黑盒和白盒两类，MiniMind 当前主线两种思路都有涉及，只是侧重点不同。

• 黑盒蒸馏：更常见，也更贴近当前主线的实际做法。严格来说，它本质上仍然是面向教师输出结果的监督微调，也就是基于硬标签继续训练；只是随着 LLM 的流行，这类“对着强模型输出做 FT”的做法也逐渐被广义地归入了蒸馏范畴，因此通常被称为黑盒蒸馏。它重点学习的是答案、风格和行为模式，学生模型只能看到“老师说了什么”，却看不到老师内部是如何做出这个判断的。像 DeepSeek R1、Qwen3 的高质量回答，以及 tool call、reasoning、思维链等数据，都可以看作黑盒蒸馏信号；MiniMind 当前主线 full_sft 数据里，其实已经混入了相当一部分这样的思路。
• 白盒蒸馏：更进一步，不只学习教师给出的最终输出，还去学习教师在 token 分布层面的偏好。相比黑盒蒸馏，它额外利用了教师模型输出层更细粒度的分布信息，因此学生模型学到的不只是“标准答案”，还包括教师在候选 token 之间的相对倾向。对应到 train_distillation.py，当前实现是在已经完成 SFT 的权重基础上，继续用教师模型提供的分布信号来训练学生模型，因此更适合作为理解 MiniMind 蒸馏流程的参考实现。

黑盒蒸馏本质上等价于对 teacher 生成答案做监督微调：

白盒蒸馏则通常在监督损失之外，再额外拟合教师分布：

仓库中提供的 train_distillation.py 更适合作为理解白盒蒸馏流程的参考实现：它完整展示了教师/学生双模型加载、CE + KL 混合损失、温度缩放、MoE 与 dense 组合蒸馏，以及断点续训和分布式训练等关键细节。

# 方式1
torchrun --nproc_per_node 1 train_distillation.py
# 方式2
python train_distillation.py

LoRA 是一种常见的参数高效微调（Parameter-Efficient Fine-Tuning, PEFT）方法。相比全参数微调，它只更新少量新增参数，而保留原始模型主体权重不变，因此训练成本更低，也更适合做垂直场景适配。 它的核心思想是在原有权重矩阵旁引入低秩增量分支，仅训练这部分低秩参数，从而用较小代价完成能力迁移。相关实现可见 model_lora.py 和 train_lora.py，整个流程均为纯手写实现，不依赖第三方封装。

# train_lora.py 在 CPU 上通常也能比较轻快地完成
# 方式1
cd trainer && torchrun --nproc_per_node 1 train_lora.py
# 方式2
cd trainer && python train_lora.py

训练后的模型权重文件默认每隔save_interval步保存为: lora_xxx_*.pth（*为模型具体dimension，每次保存时新文件会覆盖旧文件）

LoRA 很适合处理“如何在尽量保留通用能力的前提下，让模型快速适应私有领域或垂直场景”这类问题。例如基础模型医学知识不足时，就可以在原有模型之上叠加一层面向医疗场景的 LoRA 权重，以较小代价获得更好的领域表现。 通常只需要准备同样的多轮对话格式数据，放置到 lora_xxx.jsonl，再从仓库根目录执行 cd trainer && python train_lora.py，即可得到新的 LoRA 模型权重。

例1：垂域数据

 {"conversations": [{"role": "user", "content": "请问颈椎病的人枕头多高才最好？"}, {"role": "assistant", "content": "颈椎病患者选择枕头的高度应该根据..."}]}
 {"conversations": [{"role": "user", "content": "请问xxx"}, {"role": "assistant", "content": "xxx..."}]}

例2：自我认知数据

 {"conversations": [{"role": "user", "content": "你叫什么名字？"}, {"role": "assistant", "content": "您好，我名叫 MiniMind，是由 Jingyao Gong 开发的人工智能助手。我可以帮助你解决各种问题，包括翻译、推荐内容等等。"}]}
 {"conversations": [{"role": "user", "content": "你是谁"}, {"role": "assistant", "content": "您好，我是 MiniMind，由 Jingyao Gong 创建。我的主要职责是提供准确的回答和帮助。"}]}

此时可将【基模 + LoRA 权重】组合使用，从而在保留基础模型通用能力的同时，增强特定领域表现。训练完成后也可以通过 eval_llm.py 做简单测试。

# 注意：weight参数指定基础模型类型，需与train_lora训练时使用的基础模型保持一致
python eval_llm.py  --weight full_sft --lora_weight lora_medical

👶: 我最近经常感到头晕，可能是什么原因？
🤖️: 头晕可能是由于多种原因，包括但不限于：心脏疾病、眼睛损伤、过敏反应、皮肤问题、过敏反应、压力、焦虑、疲劳、药物副作用、性功能障碍或者其他...

python eval_llm.py  --weight full_sft --lora_weight lora_identity

👶: 你和openai是什么关系？
🤖️: 我是 MiniMind，一个由 Jingyao Gong 开发的人工智能助手。我通过自然语言处理和算法训练来与用户进行交互。

PS：如果有更充足的数据，也可以直接做 full_sft 全参微调；不过这通常需要更谨慎地混合通用数据与领域数据，否则很容易因为过拟合垂域样本而损失模型原有的通用性。

LoRA 权重可合并回基础模型并导出为新的完整模型权重，可使用 scripts/convert_model.py 中的 convert_merge_base_lora：

cd scripts && python convert_model.py

2026-03 起，仓库移除了独立的 train_reason.py。
当前版本不再单独维护 reason_*.pth 权重，而是统一通过 chat_template、<think> 标签、open_thinking 开关以及后续 SFT / RLAIF 流程来建模“是否显式输出思考过程”。

当前 toolcall 能力已经并入 sft_t2t / sft_t2t_mini 主线数据，因此通常不再需要额外单独训练一轮 Tool Calling；默认的 full_sft 权重已经具备基础 Tool Call 能力。当前这部分训练数据主要由 qwen3-4b 采样约 10w 条构成，工具列表也主要覆盖约 10 个模拟的自定义工具（例如查询时间、数学计算、获取天气等），因此目前还谈不上明确的泛化能力。其中 Tool Calling 样本统一沿用了 OpenAI 风格的多轮消息格式：

{
  "conversations": [
    {"role": "system", "content": "# Tools ...", "tools": "[...]"},
    {"role": "user", "content": "帮我算一下 256 乘以 37 等于多少"},
    {"role": "assistant", "content": "", "tool_calls": "[{\"name\":\"calculate_math\",\"arguments\":{\"expression\":\"256 * 37\"}}]"},
    {"role": "tool", "content": "{\"result\":\"9472\"}"},
    {"role": "assistant", "content": "256 乘以 37 等于 9472。"}
  ]
}

其中 tools 挂在 system 消息上，tool_calls 挂在 assistant 消息上；训练时再由 chat_template 自动展开为 <tool_call>...</tool_call> 与 <tool_response>...</tool_response> 片段，因此现在可以直接学习原生 tool call 格式。

Tool Calling 的 chat template 已统一支持解析为：

<tool_call>{"name": "...", "arguments": {...}}</tool_call>
<tool_response>{...tool result...}</tool_response>

也可以直接通过 eval_toolcall.py 做简单测试：

python eval_toolcall.py --weight full_sft

💬: 现在几点了？
🧠: <tool_call>{"name": "get_current_time", "arguments": {"timezone": "Asia/Shanghai"}}</tool_call>
📞 [Tool Calling]: get_current_time
✅ [Tool Called]: {"datetime": "2026-03-15 17:18:22", "timezone": "Asia/Shanghai"}
🧠: 现在是2026年3月15日17时18分22秒。

minimind 将显式思考能力统一到了模板层，这也和当前很多主流大模型的模板设计保持一致：

• open_thinking=0：默认注入空的 <think>\n\n</think>，模型更倾向于直接回答；
• open_thinking=1：模板会预先注入 <think> 起始标签，模型再继续输出显式思考过程与最终回答；
• CLI、OpenAI-API、WebUI 三个入口均支持该开关。

更准确地说，目前不再“单独训一个思考模型”，而是把“是否显式思考”下沉到 chat_template。模板层会先预留 <think></think> 这一结构，同一个模型在推理时再通过 open_thinking 动态切换；在训练时，则通过混合空 think、显式 reasoning_content 与 thinking_ratio 采样，让模型逐步见过“该想时想、该直答时直答”的混合模式。

# 测试回答
python eval_llm.py --load_from ./minimind-3 --open_thinking 1

OpenAI-API-SDK 用法：

response = client.chat.completions.create(
    model="minimind",
    messages=[{"role": "user", "content": "你是谁？"}],
    # ...
    extra_body={"chat_template_kwargs": {"open_thinking": True}} # 思考开关
)

注：当前同时开启 Tool Call 与显式思考时，模型通常并不太会稳定地输出思考过程。原因在于现阶段训练数据里还缺少“reasoning 与 tool call 同时存在”的联合蒸馏样本，因此模型尚未充分学会这两种能力的协同表达。

在 LLM 的后训练实践中，常见的强化学习路径主要有两条：

1. 基于人类反馈的强化学习 (Reinforcement Learning from Human Feedback, RLHF)

• 通过人类对模型输出的偏好进行评价来训练模型，使其生成更符合人类价值观和偏好的内容。

2. 基于AI反馈的强化学习 (Reinforcement Learning from AI Feedback, RLAIF)

• 使用AI模型或其他可自动验证的机制来提供反馈，而不直接依赖人类标注。
• 这里的“AI feedback”在广义上也可以扩展到规则奖励、Ground Truth 校验、代码解释器、环境反馈等自动化信号。

二者本质上都属于利用某种形式的"反馈"来优化模型行为的强化学习范式。

不过在具体实践里，它们并不只是反馈来源不同：奖励是否可验证、是否连续、是否依赖环境交互、是否延迟到整轮结算，都会直接影响训练形态与工程实现。

在介绍实现具体算法之前，我先以个人理解的极简视角，阐述所有Policy Optimization (PO)算法的统一共性。

说到底，这里讨论的 PO 算法都只是在优化一个期望：

$$\mathcal{J}_{PO} = \mathbb{E}_{q \sim P(Q),, o \sim \pi_\theta(\cdot \mid q)} \left[ \underbrace{\Phi(r_t, A_t)}_{\text{策略目标}} - \underbrace{h(\text{KL}_t)}_{\text{正则项}} \right]$$

训练时，只需最小化负目标函数，即：

$$\mathcal{L}_{PO} = -\mathcal{J}_{PO}$$

这个框架只包含三个核心组件：

• 策略项 $\Phi(r_t, A_t)$: 如何结合概率比 $r_t$ 和优势 $A_t$ 更新策略
• 优势项 $A_t$: 如何计算优势，这很重要！大模型算对定积分也不足为奇，小模型回答对加减法优势通常都是正的
• 正则项 $h(\text{KL}_t)$: 如何约束变化幅度 $\text{KL}_t$, 既防止跑偏又防止管的太死

不同的xxPO算法本质上只是对这三个组件的不同设计的实例化！

在前面的训练步骤中，模型已经具备了基本的对话能力，但是这样的能力完全基于单词接龙，缺少正反样例的激励。 模型此时尚未知什么回答是好的，什么是差的。希望它能够更符合人的偏好，降低让人类不满意答案的产生概率。 这个过程就像是让模型参加新的培训，从优秀员工的作为例子，消极员工作为反例，学习如何更好地回复。

直接偏好优化（DPO）算法，损失为：

$$\mathcal{L}_{DPO} = -\mathbb{E}\left[\log \sigma\left(\beta \left[\log \frac{\pi_\theta(y_w|x)}{\pi_{ref}(y_w|x)} - \log \frac{\pi_\theta(y_l|x)}{\pi_{ref}(y_l|x)}\right]\right)\right]$$

其中：

• 策略项: $f(r_t) = \log r_w - \log r_l$ (对比chosen vs rejected的概率比)
• 优势项: $g(A_t)$ = 无显式优势项（通过偏好对比隐式体现）
• 正则项: $h(\text{KL}_t)$ = 隐含在 $\beta$ 中 (控制偏离参考模型程度)

特别地，

• DPO从PPO带KL约束的目标推导出对偏好对的解析训练目标，直接最大化"chosen优于rejected"的对数几率；无需同步训练Reward/Value模型。DPO只需跑actor与ref两个模型，显存占用低、收敛稳定、实现简单。
• 训练范式：off‑policy，使用静态偏好数据集，可反复多轮epoch；Ref模型固定（预先缓存输出）。
• DPO的局限在于不做在线探索，更多用于"偏好/安全"的人类价值对齐；对"能不能做对题"的智力能力提升有限（当然这也取决于数据集，大规模收集正反样本并人类评估很困难）。

# 方式1
torchrun --nproc_per_node 1 train_dpo.py
# 方式2
python train_dpo.py

训练后的模型权重文件默认每隔save_interval步保存为: dpo_*.pth（*为模型具体dimension，每次保存时新文件会覆盖旧文件）

稍微花篇幅解释一下，我还是更想把这一节叫作 RLAIF，虽然严格来说，这个命名并不完全准确。像 RLVR 这类依赖可验证奖励的路线，本身有相对独立的脉络，很难被简单并进狭义的 AI feedback 里。 但如果把“AI”理解得稍微宽一点，我又觉得这个名字并非完全说不通：奖励既可以来自奖励模型、judge model 这类显式的智能体，也可以来自规则函数、Ground Truth校验、工具调用结果、环境返回状态这类可自动获得的信号。规则足够复杂、符号系统足够丰富时，它们和“智能反馈”之间的边界，本来就未必那么泾渭分明。 因此这一章更想讨论的，其实是 LLM 在 SFT 之后，借助各种非人工、可自动获得的反馈信号继续做强化学习优化的方法。比如数学题答案是否正确、工具调用执行代码能否通过测试用例、推理过程是否符合格式...都可以自动化判断。 对于单轮可验证任务，这类反馈往往更接近“即时打分”；而在 Agentic RL 场景中，奖励则更常表现为多步交互后的延迟结算，甚至直接来自环境本身。 它们共同的特点通常都是On-Policy与可扩展性强——不需要昂贵的人工标注，可以生成海量训练样本，让模型在在线大量试错中快速进化。

MiniMind 着手实现2+N种基本+前沿的RLAIF方法：

• PPO、GRPO 被大规模验证的经典RL算法
• N种前沿RL算法（不定期以Exp性质更新）

1️⃣ 数据集准备 (必须)

当前主线使用 rlaif.jsonl 作为 RLAIF 训练数据，体量约 20MB，比早期 rlaif-mini.jsonl 更完整，更适合直接验证 PPO / GRPO / CISPO 的训练效果。

数据格式与 SFT 一致，但 assistant 字段不需要真实内容，因为训练过程中完全由 $\Pi$ 策略模型实时采样生成。因此形如：

{
    "conversations": [
        {"role": "user", "content": "请解释一下什么是光合作用？"},
        {"role": "assistant", "content": "无"}
    ]
}

RLAIF的训练过程中，模型会基于user的问题生成1或多个候选回答，然后由奖励函数/模型对回答打分， 分数高的回答会被鼓励（增加 $\Pi$ 策略概率），分数低的回答会被抑制（降低 $\Pi$ 策略概率）。这个"打分->调整"的循环就是强化学习的核心。

2️⃣ 奖励机制准备 (必须)

RLAIF训练需要某种可计算的奖励信号；它可以来自奖励模型，也可以来自规则函数、Ground Truth 校验或环境反馈。MiniMind 当前默认演示的是 Reward Model 路线。

此处选取小型且高质量的 InternLM2-1.8B-Reward (ModelScope | HuggingFace) 作为基础奖励模型。

下载奖励模型后需要放置在minimind项目的同级目录下，推荐结构如下：

root/
├── minimind/                    # MiniMind项目
│   ├── model/
│   └── ...
└── internlm2-1_8b-reward/       # 奖励模型
    ├── config.json
    ├── model.safetensors
    └── ...

PPO 是 2017 年 OpenAI 提出的非常经典的强化学习算法，也是 LLM RL 领域最常见的基线方法之一。

PPO损失： $$\mathcal{L}_{PPO} = -\mathbb{E}\left[\min(r_t \cdot A_t, \text{clip}(r_t, 1-\varepsilon, 1+\varepsilon) \cdot A_t)\right] + \beta \cdot \mathbb{E}[\text{KL}]$$

其中：

• 策略项: $f(r_t) = \min(r_t, \text{clip}(r_t, 1-\varepsilon, 1+\varepsilon))$ (裁剪概率比防止更新过激)
• 优势项: $A_t$ 通常由Critic网络估计，也可以使用GAE进行计算
• 正则项: $h(\text{KL}_t) = \beta \cdot \mathbb{E}[\text{KL}]$ (全局KL散度约束)

对比DPO而言，

• DPO (Off-Policy)：训练数据是静态偏好对（chosen vs rejected），可以反复使用同一批数据训练多个 epoch，像传统监督学习一样。数据效率高、成本低，且无需 Reward Model。
• PPO (On-Policy)：必须用当前策略实时采样新数据，旧策略数据只能有限复用，否则就会出现 distribution shift。虽然 importance sampling 和 clip 允许轻微偏移，但本质上仍要求数据来自较新的策略。数据效率更低，但更适合探索式学习。

简单来说：

• 前者按离线预定的「好/坏标准」学习；
• 后者则基于最新 policy 在线采样并实时纠偏。

MiniMind 的 PPO 实现包含 Actor（生成回答）、Critic（评估回答价值）以及完整的 GAE（Generalized Advantage Estimation）优势函数计算。

训练方式：

# 方式1
torchrun --nproc_per_node N train_ppo.py
# 方式2
python train_ppo.py

训练后的模型权重文件默认每隔save_interval步保存为: ppo_actor_*.pth（*为模型具体dimension）

MiniMind 在 PPO 训练阶段的优化走势

从训练曲线可以看出，PPO存在reward提升缓慢的问题。私以为这主要源于PPO双网络联合优化方法：Critic需要逐步收敛以准确估计价值函数，而Actor的策略更新依赖Critic提供的优势估计，两者相互依赖形成复杂的优化过程。训练初期Critic估计不准会影响Actor梯度方向，导致整体收敛缓慢。此外，PPO 需要同时维护两个网络，在当前实现下显存占用约为单网络方法的 1.5–2 倍。

2025 年初，随着 DeepSeek-R1 火爆出圈，来自 DeepSeekMath 论文的 GRPO 也迅速进入主流视野，一度成为最受关注的 RL 算法之一。不过 AI 领域向来迭代极快。时至今日，GRPO 更多已经演变成各类 XXPO 变体（如 DAPO、GSPO、CISPO 等）的共同基线。一句话概括它的核心创新，就是“分组相对价值估计”。

GRPO损失：