Skip to main content
Training trains a model on a frozen slice of a dataset in your project. You start from a catalog Base model or from one of your own LoRA adapter Model Versions. A free cost estimate validates the inputs. A billed Training Run publishes a Model Version when it completes. The output is a set of model files that you download and deploy yourself. The platform does not host or serve it.

​
Two methods

SFT is the default method in the CLI. Gisting supports only the qwen3-4b and qwen3-8b Base models because it publishes full weights. Both methods can start from a LoRA adapter Model Version in the same project. See Choose a training method for a decision guide.

​
From draft to Model Version

A Training is a project-owned, editable draft. It holds the method, model source, dataset slice, split column, and settings. Its name is 1–120 characters and is unique among active Trainings in the project. You can archive or rename a Training through the HTTP API. Editing a Training does not change an existing Training Run. A cost estimate prepares the selected rows from the frozen slice and validates them. It is either blocked, with issues to fix, or ready, with a maximum charge.
  • A ready estimate expires 24 hours after you request it.
  • A Training can have at most three open estimates. An estimate remains open until it starts a Training Run or expires.
  • One ready estimate starts one Training Run.
  • Editing the Training makes an earlier estimate unusable. Calculate it again.
A Training Run is one immutable execution. It copies the Training configuration when created. Starting it places a hold for the maximum charge on the team balance. See Training cost for estimation, holds, settlement, and no-charge cases. The first Training Run creates a Model named after the Training. Each completed Training Run publishes one immutable Model Version in that Model. Revisions are numbered 1, 2, 3, and so on. Model Version names must be unique within the Model. In the CLI, the default version name is the Training name; pass --version-name after an earlier run has used it.

​
Data

A dataset row is one chat example. This row teaches the model to label a support ticket:
Each selected row must follow these rules:
  • The row has messages and can also have tools.
  • Allowed roles are system, user, assistant, and tool.
  • At least one turn has the user role.
  • The last turn has the assistant role and contains content.
  • System turns appear only before the conversation starts.
  • Consecutive turns cannot have the same role. Tool and system turns are exempt.
  • Every system, user, and tool turn has content. An intermediate assistant turn has content or tool calls.
  • Each tool turn answers a preceding assistant tool call.
  • Every assistant tool call is answered by a later tool turn.
A dataset can come from uploaded JSONL rows that contain messages. It can also keep a conversation in a messages column and the expected answer in a label column. The platform appends that label as the final assistant turn. The CLI can create an empty dataset and append JSONL rows to it:
Uploads append. Running the upload twice adds the rows twice. Both methods read one ready, frozen dataset slice that includes a split column. The split assigns rows to named parts with these roles: Pass --dataset <name-or-id> to prepare the dataset’s split column and freeze a slice named after the Training. If the dataset has no split column, the CLI creates an 80% train, 10% validation, 10% test split. Existing assignments stay in place. Pass --slice <id> instead to reuse a ready slice. Use --split-column to choose among multiple split columns and --parts to select particular train parts; see Dataset selections. To set your own shares or freeze part of a dataset, see Slices and split columns. The slice created by --dataset fixes the rows and field values the Training reads. Later uploads or label changes are not included automatically. Run toloka training update <training> --dataset <dataset> to freeze a new slice, then calculate a new estimate. If the slice supplies no validation rows, the platform holds out 10% of the selected training rows for validation. The cost estimate checks row shape, token length, selection size, batch size, export success, and the estimated time limit. See Training limits and Training errors. For the path from labeled project data to valid training examples, see Prepare training data.

​
Training Run states

Use toloka training status <training-run-id> to check progress, toloka training logs <training-run-id> for sanitized logs, and toloka training metrics <training-run-id> for reported metrics. A Training Run normally moves from queued to running to completed. Other states represent a stop or a billing hold. While status is running, the Progress row can show preparing, queued, pending, training, evaluating, or publishing. Progress queued or pending means the job is waiting for GPU capacity. That wait can take hours, and the job starts automatically when capacity is available. Metrics stop updating when training ends. Output checks, billing, and publication still need to finish before status becomes completed. If metrics report not_configured, the Training Run will not produce metrics. If they report unresolved, check again while the Training Run is running. For a failed run, inspect toloka training logs <training-run-id> and look up the reported error in Training errors.

​
Cancellation and payment holds

Canceling before training starts has no charge. Canceling during training stops the job, charges for billable GPU use up to the approved maximum, and publishes no Model Version. A Training Run canceled while it reserves funds or trains shows stopping until the job stops and billing settles; canceled while preparing data or blocked on funds, it becomes canceled at once. Cancellation is no longer available once output validation starts or while final payment is blocked. The payment window is seven days. If it expires, the Training Run fails with payment_window_expired, cannot resume, and is not charged. Its billing status remains payment_required.

​
Outputs and downloads

An SFT Model Version includes adapter_model.safetensors and adapter_config.json. It can contain additional .json files. It is a LoRA adapter and needs the matching Base model. The Model Version records the Base model ID; the catalog carries the current upstream repository and revision. The adapter configuration may omit the revision. See Pinned revisions and lineage before serving it. A gisting Model Version includes config.json and either model.safetensors or a complete numbered set of model-*.safetensors weight shards. Tokenizer files, merges.txt, and chat_template.jinja are optional. Download a completed Model Version with:
The CLI requests fresh download links and verifies each file’s size and SHA-256. If a link expires, rerun the download command.

​
Ways to work with Training

Project Training is available through:
  • CLI — create and update Trainings, calculate cost, start and control Training Runs, inspect logs and metrics, and download Model Versions
  • Fine-tuning agent runbook — guide a coding agent through an SFT workflow
  • Gisting agent runbook — guide a coding agent through a gisting workflow
  • HTTP API — work with Training, Training Run, Base model, Model, and Model Version resources
In the web app, manage project datasets and team balance. Open Fine-tuning or Prompt gisting to set up a coding agent. If you see Fine-tune lab, it offers a separate web workflow with its own runs and downloads. Use the CLI or HTTP API for project Training.