Skip to main content
Fine-tuning in Pioneer adapts a base model to your specific task and domain using your labeled dataset. You submit a training job through the API, Pioneer handles the compute, and you get back a trained model you can call for inference or download. The whole process is asynchronous — you start the job, then poll until it finishes. Pioneer uses supervised fine-tuning (sft) for all new training jobs. See the LLM fine-tuning guide for dataset formatting and decoder training examples.

​
Training job lifecycle

A training job’s status field moves through several states. The main path is:
1

requested

Your job has been accepted and is queued for execution. Pioneer is allocating compute.
2

running

Training is actively executing on the provider.
3

complete

GPU training finished successfully. Loss metrics are available on the job record (see Polling status and reading metrics), and checkpoints are ready to download or deploy.
4

normalizing / artifact_ready

Intermediate post-training steps — Pioneer is normalizing and packaging the trained artifact. You’ll typically only see these transiently between complete and deployed.
5

deployed

The trained adapter is live on an inference provider and ready to serve requests via model_id.
A job can also end in errored (an error occurred during training), stopped (you gracefully halted it with POST /felix/training-jobs/:id/stop — checkpoints are preserved), terminated (you called POST /felix/training-jobs/:id/terminate, which stops the job and permanently deletes its checkpoints — irreversible), or paused.

​
Key parameters

base_model is required and must match a model-ID or UUID shape — not a free-form string. Omitting it, or sending a malformed value, returns 422. A well-formed value that doesn’t match any model available for training returns 400 instead.

​
Supported training targets

New training jobs support only the following target families: Use GET /base-models?supports_training=true immediately before creating a job. It is the live source of truth for target availability.

​
Starting a training job

The response returns the full job record immediately, including a UUID id and initial status:
Save the id — you’ll use it to poll status, retrieve metrics, and run inference against your trained model.

​
Polling status and reading metrics

Poll the job endpoint until status reaches a terminal value — complete, deployed, errored, stopped, or terminated:
The metrics field always includes loss values once training starts, plus F1/precision/recall/accuracy if a separate evaluation has been run against the resulting model:
To retrieve structured stdout/stderr log lines for the job:
This returns a JSON list of log entries ({id, timestamp, level, message, source}) — it’s a point-in-time fetch, not a live stream. Poll it periodically while the job is running to follow progress.

​
Stopping or terminating a job

To gracefully halt a running job while preserving its checkpoints:
The job status changes to stopped. Checkpoints saved before the stop remain available for deployment or download. To permanently end a job and delete its checkpoints instead, use /terminate:
/terminate stops the provider job if it’s still running and permanently deletes all of its checkpoints. This is irreversible — use /stop instead if you want to keep the checkpoints trained so far.

​
Checkpoints and downloading weights

Pioneer saves checkpoints during training. You can list them at any point after the job starts:
Each checkpoint carries is_best, is_final, and is_deployable flags. You can deploy any deployable checkpoint — not just the final one — to a live inference endpoint:
To download weights instead, request a presigned URL (requires a Pro plan or above — this call returns 403 otherwise):
The response is JSON with a download_url that expires in 1 hour — fetch that URL separately to get the actual file:
You can also use a checkpoint UUID as the base_model value in a new training job to continue training from that checkpoint.

​
Training endpoints summary