企业官网建设流程全解析

Soup 新增 Kimi-K2.5 DPO / GRPO 配方：为 ~1T MoE 基座模型补齐 SFT-DPO-GRPO 任务三件套

【免费下载链接】SoupFine-tune LLMs from one YAML. Layer streaming trains an 8B model on a 4 GB laptop GPU.项目地址: https://gitcode.com/GitHub_Trending/soup12/Soup

本篇技术指南介绍 Soup（一个"从单个 YAML 微调大模型"的训练框架）在 0.75.0 版本中新增的kimi-k2.5-dpo与kimi-k2.5-grpo两个开箱即用配方：它们与既有的kimi-k2.5-sft共同构成针对moonshotai/Kimi-K2.5（约 1T 参数 / 32B 激活的 MoE 模型）的 SFT → DPO → GRPO 完整任务三件套。读完本文，你将掌握这两个配方的完整 YAML 结构、每个关键超参数的语义与取值依据、与 Kimi-K2.6 模板的继承关系，以及在大规模 MoE 模型上运行时的多节点 DeepSpeed 前提与数据格式要求。

变更背景：一次补齐任务变体的目录扩展

本次变更记录于 changelog.d/0.75.0/872.added.md（PR #872，对应 Issue #275 / #851，由 @Areen-09 提交），其核心动作是：

为moonshotai/Kimi-K2.5新增开箱即用的kimi-k2.5-dpo和kimi-k2.5-grpo配方，使基座模型的任务三件套（SFT / DPO / GRPO）得以补全。

在此之前，Kimi-K2.5 只有 SFT 形态（随 v0.71.24 发布，即 目录中的kimi-k2.5-sft）。本次新增的 DPO 与 GRPO 配方在 配方目录src/soup_cli/recipes/catalog.py中与 K2.6 对应条目并排注册，模型 ID 固定为moonshotai/Kimi-K2.5，任务分别为dpo与grpo，规模标记为size: "1T"。变更完成后，配方目录总数由167 增至 169（该计数被 tests/test_recipes.py 以len(RECIPES) == 174的方式持续追踪，随后续版本继续演进）。

从 docs/models.md 的模型支持矩阵可以看到，Kimi 系列（Kimi-K2、Kimi-K2.5、Kimi-K2.6）在本仓库中被归入"~1T (MoE)、长上下文 Agentic"这一类目，这也解释了为什么这些配方无一例外地需要多节点 DeepSpeed 才能实际训练。

配方总览：同一基座、三种任务形态

下表汇总了 Kimi-K2.5 家族三个配方在目录中的注册信息（均来自 catalog.py）：

三者共享的 MoE 训练骨架包括：4-bit 量化（quantization: 4bit）、moe_lora: true、gradient_checkpointing: true、max_length: 8192、batch_size: 1配合gradient_accumulation_steps: 16。正如变更说明所述，这些超参数继承自 Kimi-K2.6 模板（kimi-k2.6-dpo/kimi-k2.6-grpo），而非针对 K2.5 单独调优——因为 ~1T 的 MoE 模型需要多节点 DeepSpeed，仓库并未实际训练验证过这两份新配方。

逐字段解析：kimi-k2.5-dpo完整 YAML

以下为目录中kimi-k2.5-dpo配方的完整 YAML 原文，可直接复制使用：

base: moonshotai/Kimi-K2.5 task: dpo data: train: ./data/preference_train.jsonl format: dpo max_length: 8192 training: epochs: 1 lr: 5e-6 batch_size: 1 gradient_accumulation_steps: 16 lora: r: 32 alpha: 64 target_modules: auto quantization: 4bit dpo_beta: 0.1 moe_lora: true moe_aux_loss_coeff: 0.01 gradient_checkpointing: true output: ./output

各字段语义与取值依据如下：

• base/task：基座模型 ID 与任务类型。测试 tests/test_recipes.py 特意在"目录元数据（RecipeMeta.model）"与"YAML 正文（parsed["base"]）"两个独立表面分别断言模型 ID 与任务一致，防止两处漂移。
• data.train：偏好数据文件，格式须为 DPO 形态（chosen / rejected 成对偏好样本），路径指向./data/preference_train.jsonl。
• data.format: dpo：显式声明偏好数据格式，与 DPO 任务配套；data.max_length: 8192对应 Kimi-K2.5 的长上下文能力。
• training.lr: 5e-6：DPO 对齐阶段的学习率显著低于 SFT（1e-5），这是偏好优化阶段的常见做法，避免破坏基座已学知识。
• training.lora: r: 32, alpha: 64：DPO 与 SFT 共享 r32/a64 的 LoRA 秩配置（对应测试test_shares_base_and_size_with_its_sft_sibling中"与 SFT 兄弟配方共享基座与规模"的断言）。
• training.quantization: 4bit：基座以 4-bit 量化加载，配合 LoRA 即 QLoRA 式训练，大幅压缩 ~1T 参数模型的显存/内存占用。
• training.dpo_beta: 0.1：DPO 损失中的 KL 正则系数，控制对参考策略的偏离程度。
• training.moe_lora: true：对 MoE 模型的专家（expert）层施加 LoRA 的关键开关；moe_aux_loss_coeff: 0.01为专家负载均衡辅助损失的权重，是 MoE 训练中防止路由坍缩的标准手段。
• training.gradient_checkpointing: true：以计算换显存，进一步降低 ~1T 模型的可训练门槛。
• batch_size: 1+gradient_accumulation_steps: 16：单卡批大小 1、梯度累积 16 步，等效批大小 16——在无法单机容纳大 batch 时兼顾稳定与显存。

逐字段解析：kimi-k2.5-grpo完整 YAML

GRPO 配方面向推理（reasoning）任务，完整 YAML 如下：

base: moonshotai/Kimi-K2.5 task: grpo data: train: ./data/reasoning_train.jsonl format: auto max_length: 8192 training: epochs: 3 lr: 1e-5 batch_size: 1 gradient_accumulation_steps: 16 lora: r: 16 alpha: 32 target_modules: auto quantization: 4bit grpo_beta: 0.1 num_generations: 4 reward_fn: accuracy moe_lora: true gradient_checkpointing: true output: ./output

与 DPO 配方的差异点及原因：

• training.lora: r: 16, alpha: 32：GRPO 采用更低的 LoRA 秩（r16/a32），与 K2.6 GRPO 模板保持一致——推理优化阶段通常更倾向于轻量约束，避免过度更新。
• training.epochs: 3：GRPO 训练轮数多于 DPO/SFT 的 1 轮，配合多代采样逐步优化推理策略。
• training.grpo_beta: 0.1：GRPO 的 KL 正则系数；num_generations: 4表示每个提示采样 4 条轨迹作为组内基线；reward_fn: accuracy指定以准确率为奖励信号。
• data.format: auto：自动推断推理数据格式，训练文件指向./data/reasoning_train.jsonl。

以上所有字段均被测试 TestKimiK25GrpoRecipe 通过load_config_from_string加载并逐项断言，且与 配方快照tests/fixtures/recipe_config_snapshots.json中的期望配置对齐，可作为修改参数后的回归基准。

任务三件套的验证逻辑

仓库用测试而非训练结果来保证这两个配方的正确性，核心验证点有三类：

1. 模型 ID 双表面锁定：RecipeMeta.model与 YAMLbase:必须同时等于moonshotai/Kimi-K2.5（见 tests/test_recipes.py）。
2. 任务三件套完整性：test_completes_the_task_trio_for_this_base断言同一基座下{"sft", "grpo", "dpo"} <= tasks，即任何一个 Kimi-K2.5 的 SFT/DPO/GRPO 配方缺失都会导致测试失败（tests/test_recipes.py）。
3. 与 SFT 兄弟配方的血缘关系：test_shares_base_and_size_with_its_sft_sibling验证 DPO/GRPO 与 SFT 共享model与size、仅task不同（tests/test_recipes.py）。

此外，tests/test_v07124.py 对这批 Kimi-K2.5/K2.6 大模型配方做了统一回归覆盖（含size == "1T"断言），说明新配方已进入常规测试矩阵。

如何拉取并使用这两个配方

Soup 的配方通过recipes命令族管理，典型使用流程（对应测试中的test_show_and_use_recipe路径）：

# 查看配方的元信息与 YAML 全文 soup recipes show kimi-k2.5-dpo soup recipes show kimi-k2.5-grpo # 将配方写入当前目录的 soup.yaml（--yes 跳过交互确认） soup recipes use kimi-k2.5-dpo --yes soup recipes use kimi-k2.5-grpo --yes

recipes use会把配方正文写入soup.yaml，随后你只需按配方内data.train的路径放置对应格式的偏好/推理数据集，即可进入训练流程。搜索功能（search_recipes）支持按模型关键词与任务类型过滤，例如按kimi关键词即可同时命中这三个 K2.5 配方。

适用前提与明确限制

在真正运行这两个配方之前，有三条必须知悉的边界：

1. 未经过实际训练验证：变更说明明确指出 "The recipes are not trained"，两个配方的全部超参数均从 K2.6 模板继承（inherited），而非针对 K2.5 调优（tuned）。首次使用时应把训练曲线视为超参验证过程，而不是已验证的既定事实。
2. 必须多节点 DeepSpeed：~1T 参数 / 32B 激活的 MoE 规模决定了单机（即使多卡）无法承载，配方描述中统一标注 "Requires multi-node DeepSpeed"。这与仓库中面向 4GB 笔记本 GPU 的 layer streaming 训练路径（见项目整体定位）属于完全不同的算力量级，切勿混用。
3. 许可证提示：配方描述中标注 Kimi-K2.5 采用 Modified MIT 许可，与 K2.6 一致；使用前应自行确认基座模型的许可条款与商用边界。

总结

kimi-k2.5-dpo与kimi-k2.5-grpo的落地，使 Soup 的配方目录在 Kimi-K2.5 这个 ~1T MoE 基座上实现了 SFT / DPO / GRPO 的任务全覆盖：DPO 走 r32/a64 +dpo_beta: 0.1的偏好对齐路线，GRPO 走 r16/a32 + 4 代采样 + accuracy 奖励的推理强化路线，二者共享 4-bit 量化、moe_lora、梯度检查点与 8192 上下文窗口的 MoE 训练骨架。它们与kimi-k2.5-sft、K2.6 全家族配方共同构成了一份可搜索、可复用、可被测试持续守护的大模型对齐配置资产——对于需要在大规模 MoE 基座上启动 DPO/GRPO 实验的团队，这两份配方提供了开箱即用的起点模板。

【免费下载链接】SoupFine-tune LLMs from one YAML. Layer streaming trains an 8B model on a 4 GB laptop GPU.项目地址: https://gitcode.com/GitHub_Trending/soup12/Soup