SFT with LoRA
Preview · Requires a qualified exact model and runtime. A draft, guide or saved configuration does not establish execution or serving availability.
Train adapter weights from reviewed demonstrations.
Supervised fine-tuning (SFT) teaches a model from desired answers. LoRA specifies which parameters are learned: a small adapter updates the effective model while the original checkpoint stays frozen. The managed SFT path uses a qualified single-GPU LoRA runtime; choosing SFT does not enable arbitrary full-weight training or every checkpoint size.
For example, train a support model to return your exact answer structure from reviewed examples, then evaluate unfamiliar support requests separately.
Set up the experiment
Open Experiments, choose New → SFT / LoRA and follow the tabs. An experiment opened from a Model already has its model selected.
| Tab | What to provide |
|---|---|
| Model | The exact compatible starting checkpoint and an experiment name. |
| Data | A sealed reviewed supervised batch and the separate evaluation inputs requested by the setup. Use the existing Dataset import/review controls. |
| Settings | Supported LoRA/training parameters, compute and maximum spend. Optional expert fields remain in Advanced settings. |
| Review | The resolved inputs and preparation, followed by explicit Start. |
Each training task needs a training split, expected output and exactly one approved matching demonstration. Dataset instructions become system instructions; the task's JSON input becomes the user payload. The reviewed assistant response is JSON text matching the expected output. Do not substitute a grader score or an unreviewed generated answer for a demonstration.
For example, a task can use input {"ticket":"My order arrived damaged"} and
expected output {"action":"replace","reply":"Please send a photo of the damage."}.
The approved demonstration contains that output as JSON text. These are task
fields, not a complete Dataset-import request; use Dataset authoring to create,
review and seal the records. Privileged context, referenced assets and other
unprojected resources are not accepted by this text-only training path.
Choose settings
Start with a small reviewed batch and a short run. Learning rate and optimizer steps change how strongly the adapter fits those examples. Sequence limits must fit the actual framed input and target; an arbitrary truncation can change the supervision. LoRA rank and modules must match the supported runtime. A GRPO-capable worker's numeric rank attestation alone does not establish its separate supervised-training capability.
Review, run and recover
Use Review → Prepare review to resolve the exact inputs, compatible runtime and maximum spend. Inspect the retained preparation before approving Start. Opening the editor, changing tabs and saving a draft do not start paid compute. Preparing a run is separate from starting it.
If a response is lost, reopen the same experiment and retained execution before retrying. Preserve its operation identity and revision; creating a second run can duplicate work and charges. Use the existing refresh, retry or cancellation controls. Cancellation is a request: follow the execution through cleanup and inspect remaining capacity and funding before treating it as finished.
Runtime discovery is authoritative. A selectable action or saved configuration does not prove that a checkpoint/image/GPU combination is qualified. Unsupported combinations cannot start simply because sufficient credits are available.
Save and serve
After a successful execution with verified artifacts, choose Save Model. The saved version retains its exact base, modification and artifact identity. Saving is separate from allocating serving capacity. Open the saved Model, review compatible serving and approve activation explicitly. Use Stop and verify released capacity when finished.
Measure a baseline and candidate on the same held-out tasks and grader versions. Training loss, successful export and a working endpoint do not establish better answers. Keep runtime correctness and task quality as separate checks.
API, SDK and harness
Use training hosted-prepare-experiment, hosted-start, execution status and
artifacts, then hosted-save-model. Serving uses the saved version's supported
Model-serving operations. Continued/merged/residual adapter modes depend on the
actual starting Model and method capability; a saved adapter does not authorize
all continuation modes.
Use the official CLI with your configured account and workspace. Run
openpond training --help and the selected command's help for the current
request schema; start from the SDK's typed draft/request builders rather than
inventing an unversioned JSON payload. Web, API, TypeScript/Python SDKs and the
CLI retain the same preparation, execution and Model identities. Paid Start and
serving activation require explicit approval; a harness should retain these
identities for recovery.