Skip to main content
The Train tab turns a praisonai-train fine-tune into a form, a live loss chart, and a run history — all against your local engine.
The Train tab is a desktop wrapper around the praisonai-train llm CLI. The engine writes a config.yaml, spawns python -m praisonai_train llm --config <run_dir>/config.yaml as its own process group, and reports on it live.

​
Quick Start

1

Open the Train tab

Click Train in the sidebar. The app remembers your last-picked view, so it reopens where you left off. The one exception is a launch where the engine still needs setup or has failed — the app forces Chat while the wizard/banner is on screen, and returns to your saved view once the engine is healthy (PraisonAI #4471).
2

Pick a model and dataset

Defaults are unsloth/Meta-Llama-3.1-8B-Instruct-bnb-4bit on yahma/alpaca-cleaned — leave them to try a first run.
3

Click Start training

The button becomes Training…. A live loss chart appears and the log auto-follows.
4

Close the lid — come back

Reopen the app; the Train tab reattaches to the running job and repopulates step, loss, elapsed, and log.

​
How It Works

The engine runs one job at a time and keeps its progress in a replayable ring buffer, so closing the window never loses a run. The engine parses two line shapes from the trainer’s output: a step / total tqdm bar and the {'loss': ..., 'learning_rate': ..., 'epoch': ...} dict trl prints each logging step. Everything else is shown verbatim in the log pane.
The full log is persisted to <PRAISONAI_DESKTOP_HOME>/runs/<run_id>/train.log (UTF-8, errors="replace", flushed per line so it is readable while the run is live), and the config is written next to it as config.yaml (JSON if PyYAML is missing). See Data & Privacy for where PRAISONAI_DESKTOP_HOME points.

​
Reconnect & resync

Opening the tab after a gap replays from your cursor; a long run that overflowed the ring buffer tells you so rather than silently skipping output.

​
Choosing a method

method picks the trainer. sft works with the default dataset; the rest need differently-shaped data, named in the per-method hint under the dropdown.
grpo is rejected before any download with a 400 — it needs reward_funcs this form does not collect. Run it from the command line instead.

​
Configuration

The form posts a config object to /train/start. Basic fields are always visible; LoRA and quantization live in the Advanced panel.
Before writing config.yaml, the engine pins these so a desktop run stays local:
Publishing is opt-in from the CLI — see Train → Publishing.

​
Environment variables

Point the app at a matched CUDA/torch environment without touching the engine’s venv:
Launch the app after exporting it, and the engine spawns the trainer from that venv.

​
Common Patterns

First fine-tune. Open Train, keep the defaults, click Start. Watch the loss drop as the log follows; the model saves to outputs/. Interrupted run. Close the lid mid-training. Hours later, reopen the app — the Train tab reattaches, the loss chart repopulates from history, and the run finishes. Second start while one is running. Forget a run is going and click Start again — the UI surfaces the engine’s 409 message and re-enables the button. The live run is not disturbed. Stop. Click Stop; the run and all its dataloader workers die together. The status pill turns cancelled and the log tail is preserved.

​
Reference

Every route lives on the local engine (127.0.0.1, no auth — the app’s existing design for every route). SSE event kinds: start, state, log, progress, metric, end, plus resync when history was evicted past your cursor. Run summary shape: {id, state, step, total, started, ended, error, elapsed, last_loss}. state is one of running, done, failed, cancelled, stopping.

​
Best Practices

max_steps is omitted when 0 (“no cap”). Set a small value like 10 for a fast smoke test, then raise or remove it once the pipeline is green.
The engine refuses a second run rather than queueing. Stop the live run (or let it finish) before starting another — a 409 names the blocking run id.
Preference methods (dpo, orpo, kto, cpo) and reward need differently-shaped datasets. The hint under the dropdown names the required columns; the CLI pages have the full shape.
praisonai-train pulls torch and unsloth. Keep those in a matched CUDA venv and point the engine at it with PRAISONAI_TRAIN_CMD — the desktop engine itself stays stdlib-only.

Chat & Streaming

Messages, streaming events, and tool cards in the Desktop app

Data & Privacy

Where runs live and what PRAISONAI_DESKTOP_HOME controls

Train (CLI)

The praisonai-train llm command this tab wraps

Preference Tuning

DPO, ORPO, and KTO dataset shapes and options