Core concepts¶

This page explains the handful of ideas that the rest of Tuneline Studio is built on: pipelines, steps, artifacts, runs, caching, targets and keys.

Pipeline¶

A pipeline is a recipe for producing a model. It is a graph of steps connected by links, drawn on a canvas: data flows in at the top (for example Load dataset and Base model), passes through training and evaluation, and ends with an export or a deployment.

A typical pipeline looks like this:

data → base model → fine-tune (SFT, DPO or GRPO) → evaluation → quality gate → merge / GGUF / Hub → endpoint

You create pipelines on the Pipelines page with New pipeline, either from a template (for example Sanctions alert triage or CPU smoke test) or from a blank canvas. The pipeline is saved automatically as you edit it. See The pipeline editor.

Steps (blocks, nodes)¶

Each box on the canvas is a step. The docs and the app also call them blocks or nodes; they mean the same thing. Tuneline Studio has 24 step types in six categories:

Category	Examples
Data	Load dataset, Clean and dedupe, Format as chat, Format as preference pairs, Format as vision chat, Train / validation / test split, Merge datasets, Generate synthetic data
Model	Base model, Registered model
Train	Fine-tune (SFT), Preference tuning (DPO / ORPO / KTO), Vision fine-tune (SFT), Reinforcement tuning (GRPO)
Evaluate	Evaluate on test set, Benchmarks (lm-eval), Prompt-injection test, Quality gate
Export	Merge adapter, Export GGUF, Publish and register
Deploy	Deploy endpoint, Ollama package, Endpoint smoke test

Every step has:

Typed inputs and outputs. Inputs sit at the top of the box, outputs at the bottom. Each one carries an artifact type, shown by its colour. Some inputs are optional (marked with ? on the canvas).
Settings with sensible defaults, edited in the inspector on the right of the editor.
An id such as sft or eval, used in YAML, logs and quality gate rules.
A runtime: GPU (training, evaluation), CPU (formatting, the quality gate) or network only (downloads, publishing).

The full list of steps and their settings is in the block reference.

Artifact types¶

Everything that flows along a link is an artifact, and every artifact has a type. A link can only connect an output to an input that accepts its type, which is how the editor stops you from, for example, feeding raw rows straight into a training step.

Type	Colour	What it is
Dataset	ochre	Rows loaded from a file, a URL, a golden set or the Hugging Face Hub, before formatting.
ChatDataset	rose	Rows in chat form (`messages`) or prompt/completion form, ready for SFT or evaluation.
PreferenceDataset	orange	A prompt with chosen and rejected answers (DPO, ORPO, SimPO), or prompt, completion and a good/bad label (KTO).
VisionDataset	green	Chat rows with one or more images each, for vision-language models.
Model	teal	A base model, optionally with a LoRA adapter, or a merged fine-tuned model.
EvalReport	violet	Metrics and per-example results from an evaluation.
GGUF	brown	Quantized GGUF files for llama.cpp, Ollama and LM Studio.
Endpoint	slate	A running OpenAI-compatible inference endpoint.

Some steps pass their input type through unchanged. Clean and dedupe, for example, accepts any dataset type and outputs the same type it received. The canvas shows the colour legend under the graph (Artifact types). More detail: Artifact types reference.

Runs and run numbers¶

A run is one execution of a pipeline. When you press Run and then Start run, Tuneline Studio takes a copy of the pipeline as it is at that moment, so later edits never change a run that already happened.

Each run gets a run number (Run #12). Numbers count up across all of your runs, not per pipeline. A run also records where it ran, the GPU, its logs, metrics, evaluation reports, artifacts and, for paid providers, its cost.

A run moves through these statuses:

Run status	Meaning
Queued	Created and waiting to start (for example, waiting for your computer or your notebook).
Launching	Tuneline Studio is starting the job at the provider.
Running	The runner is working through the steps.
Succeeded	Every step finished (or was reused from the cache, or deliberately skipped).
Failed	A step failed, the job stopped, or it could not start. The run page shows why.
Cancelled	You cancelled it, or it reached its time or cost limit.

Step statuses¶

Inside a run, each step has its own status. You see it in colour on the canvas, on the run page and in the live banner above the editor.

Step status	On the canvas	Meaning
queued	grey dot	Waiting for earlier steps.
running	accent border, pulsing dot, progress bar	Working now; the step shows a message such as `step 124/200 · loss 0.438` and a percentage.
succeeded	green	Finished and produced its outputs.
cached	dashed slate-blue border	Nothing changed since an earlier run, so its earlier results were reused.
failed	red	Something went wrong; the message and logs say what.
skipped	faded	Not run because an earlier step failed, or a quality gate stopped the steps after it.
cancelled	faded	Stopped because the run was cancelled.

Caching: reuse cached steps¶

Fine-tuning is expensive, so Tuneline Studio avoids redoing work. Before each step runs, the runner computes a fingerprint from:

the step type and version,
the settings that affect its output,
the fingerprints of everything connected to its inputs,
the content of external inputs (for example the checksum of an uploaded file, or the exact commit of a Hub model).

If an earlier run already produced results with the same fingerprint, the step is marked cached and those results are reused. Change one setting on the training step and only that step and the steps after it run again; the data preparation above it stays cached.

Some things to know:

The option is called Reuse cached steps in the Run dialog, and it is on by default. Turn it off to force every step to run.
Settings that don't change the result, such as the Hugging Face repository name or how often to log, are left out of the fingerprint. Renaming a repository does not retrain a model.
A few steps always run, because their job is to act, not to compute: Quality gate, Publish and register, Deploy endpoint, Ollama package and Endpoint smoke test. The inspector marks them "always runs".
Cached results live in your Hugging Face account (models in your model repositories, intermediate datasets in a private dataset repository named tuneline-cache), so a Hugging Face token is needed for caching to work across machines.

Targets: where a run runs¶

A target is the place where a run executes. You choose it each time you start a run.

Target	Cost	What you need
Modal	Paid per second; the Starter plan includes $30 of compute a month	Modal token ID and secret
RunPod	Paid per second	RunPod API key
Hugging Face Jobs	Paid, billed to your Hugging Face account	Hugging Face token
Kaggle	Free (2× T4 GPUs, about 30 GPU hours a week)	Kaggle API token, phone-verified Kaggle account
Notebook	Free tiers available (Colab, Lightning or any Jupyter)	Nothing: you download a notebook and run it
My computer	Free	A one-time setup of your computer

Details and advice on choosing: Running pipelines and Run on your own computer.

API keys: yours, billed to you¶

Tuneline Studio does not sell compute. Every run uses your own accounts:

GPU time is billed by the provider (Modal, RunPod, Hugging Face) directly to you.
Models, adapters and GGUF files are pushed to your Hugging Face account.
Keys are saved under Settings → API keys, stored encrypted, and the app only ever shows their last four characters.

A Hugging Face token with write access is needed for almost every pipeline. Other keys are needed only for the target you pick or for particular steps; for example, Deploy endpoint needs a RunPod key when it serves on RunPod Serverless. The editor lists the keys a pipeline uses and whether each one is saved. See API keys and security.

Registry¶

The Registry holds every model version you decide to keep, with its scores, model card, stage (Staging, Production or Archived) and lineage: which dataset version and which run produced it, and where it is deployed. The Publish and register step adds a new version automatically at the end of a run. You can also start a new pipeline from a registered model with the Registered model step. See Registry.

Deployments¶

A deployment is a running OpenAI-compatible endpoint for one of your models, on RunPod Serverless, Hugging Face Inference Endpoints or Modal. You can create one from the Deployments page or with the Deploy endpoint step at the end of a pipeline. Endpoints scale down when idle, and you are billed by the provider for the time they run. See Deployments.

Golden sets¶

A golden set is a small, hand-picked collection of example conversations with the answers you expect. You build golden sets in the Playground (for example with Save to golden set on a good answer) and use them in pipelines: Load dataset can read a golden set as its source, so you can evaluate every new model on the same trusted examples. See Playground and Evaluation and quality gates.

How a run works¶

This is what happens between pressing Start run and seeing results.

The studio saves your graph. Any unsaved edits are saved first, so the run uses exactly what you see.
The server compiles a run spec. It checks the pipeline again (every input connected, types match, settings valid), checks that the keys the pipeline and the target need are saved, fills in every default, and stores the result on the run together with a new run number.
The job is launched on the target. For Modal, RunPod, Hugging Face Jobs and Kaggle, Tuneline Studio starts the job with your keys. For Notebook you download a notebook and run it; for My computer your worker picks the run up.
The runner executes the steps. Inside the job, the Tuneline runner installs itself, reads the spec, and works through the steps in order. For each step it first checks the cache, then either reuses earlier results or runs the step.
Status, logs and metrics stream back live. Every couple of seconds the runner reports step statuses, progress messages, log lines and training metrics. The pipeline editor and the run page update as they arrive; you never need to refresh.
Artifacts go to your Hugging Face account. Adapters, merged models and GGUF files are pushed to your account (private by default), and the run's Artifacts tab links to them.

If a step fails, the steps that depend on it are skipped and the run ends as failed. You can fix the problem and run again; thanks to caching, the steps that already succeeded are reused. To follow a run while it happens, see Monitoring runs.