Case Study: chat-dpo

This cookbook is positioned as an "eval-first DPO experiment handling chat-quality preference pairs." This page gathers the cookbook's key facts and the corresponding approach on MinT Enterprise in one place.

Goal

Given chosen / rejected preference pairs, train a LoRA that makes the model favor the chosen style. The benchmark is a held-out set of paired preferences, not a generative benchmark with external raters — evaluation is self-contained within the training machine.

Recipe parameters

Lifecycle order

The three-step lifecycle stated on the cookbook page:

uv sync → --dry-run → --eval-only → train

• uv sync: install dependencies.
• --dry-run: dry-run the data path to confirm the tokenizer / flattening / loss computation all work.
• --eval-only: run eval without training to get the baseline eval_pair_accuracy.
• Train: run the actual training loop with periodic evaluation.

For more fine-grained runnable commands and script filenames, the cookbook page points to the upstream README.

The corresponding approach on MinT

DPO on MinT is implemented with forward_backward_custom + a custom preference loss. Selecting the DPO Recipe in the console automatically wires up this path; the panel's suggested hyperparameters are rank=32 / 5 epochs / lr=1e-4 / bs=8.

Enterprise differences

This cookbook has exactly the same structure on Community and Enterprise — migration is just switching MINT_BASE_URL and MINT_API_KEY (see Migrate from Community). On Enterprise you can additionally:

• Upgrade the base model to Qwen/Qwen3-30B-A3B-Instruct-2507 or an Enterprise-only model (GLM-5 / Kimi-K2, etc.) — see Supported Models.
• Save a checkpoint after training: it is stated that "each checkpoint carries metadata (Recipe, data version, hyperparameters, eval scores) for easy traceability."
• Run both training and inference on a dedicated compute pool, without sharing scheduling with other tenants.