Launching a fine-tuning job
Once you have a ready_for_training dataset (uploaded directly or generated by synthesis), the wizard at /fine-tune/new runs the actual training.
The shortest path: from /datasets, find the row with status ready to train and click Train. The wizard opens with the dataset prefilled.
The wizard, step by step
1. Dataset
Pre-filled if you arrived from a dataset row. Otherwise pick from the dropdown — it lists the datasets on your account that have passed validation, with their example counts, and warns if one is below the recommended 1 000 examples.
Datasets published by other accounts are selectable here too; browse them first in the dataset registry.
If you have nothing suitable yet, you can upload a file without leaving the form. The upload validates in place and is selected when it finishes, so a half-filled configuration is not thrown away just because you needed a dataset.
2. Base model
Two tabs, because there are two places a base model can come from.
Platform models — the text-generation models EcoLink hosts. Weights are already on our storage, so training starts without a download. The wizard shows the memory each one needs.
My model registry — a model you added yourself. Register it once under Registry → Models, and it appears here for every job after that. Two kinds work:
| What you registered | What happens at launch |
|---|---|
| A Hugging Face repository id | Downloaded when the job starts. A large model adds minutes before training begins. Gated and private repositories cannot be used — the download is anonymous. |
| A path to weights on one of your shared file systems | Nothing is downloaded. The file system is attached to the training job read-only, so the run cannot modify the weights it started from. |
Registering is the gate: rather than retyping a model name into every job, you add it once with a name and a licence and pick it from the list.
Weights on a shared file system exist in one region only, so the job runs in that region. If the GPU type you picked is not offered there, the wizard tells you at submit rather than letting the job sit unscheduled. The tab shows which region a model is tied to.
If your registry tab is empty, either you have not registered anything yet, or what you registered is not a text-generation model — image and speech models cannot be fine-tuned here.
3. GPU type and count
Pick a GPU type from the dropdown (the list updates as the platform's catalog changes) and how many to use. The wizard estimates VRAM headroom and decides automatically whether to use 4-bit QLoRA (when the base wouldn't fit in full precision on the chosen GPU). A small banner explains the decision so you know what's happening.
More than one GPU trains the same data in parallel across all of them. It finishes sooner and costs proportionally more per hour, and the estimate accounts for both.
Extra GPUs buy time, not a different result. Your settings keep the same meaning at any GPU count — the batch each optimizer step sees does not change — so a recipe that worked on one GPU behaves the same way on four, only faster. For a typical 1 000-example dataset, one GPU is almost always the right call.
4. LoRA hyperparameters
The wizard splits these into two tiers:
Tier 1 — pick from sane defaults (most users stop here):
| Field | What it does | Sensible default |
|---|---|---|
| Epochs | How many passes over the dataset | 3 |
| Learning rate | Step size during training | 2e-4 (10× a full fine-tuning learning rate, typical for LoRA SFT) |
| LoRA r | Rank of the adapter — capacity vs. size tradeoff | 16 |
| LoRA alpha | Scaling factor for the adapter (usually 2 × r) | 32 |
| Micro batch size | Per-step batch on each GPU | 4 |
Tier 2 — Advanced (collapsible):
| Field | What it does |
|---|---|
| Dropout | Regularization on the adapter; small values 0.0–0.1 |
| Target modules | Which projection layers the adapter modifies (default: q_proj, v_proj) |
| Gradient accumulation | Larger effective batch without more VRAM |
| Max sequence length | Truncate examples longer than this (defaults to base model's context) |
| Save steps | How often to checkpoint mid-epoch |
| Seed | Reproducibility |
If Tier 2 doesn't matter for your case, leave it. The defaults are tuned for the common case (chat-style SFT on a 7B base with a 1k–10k row dataset).
Custom parameters — a JSON box under Advanced, for settings the form does not expose. Paste an object and it is merged over the values above:
{
"training": { "warmup_ratio": 0.05, "optim": "adamw_torch_fused" },
"lora": { "r": 32, "alpha": 64 }
}
Any field you override is marked in the form, so you can see what your JSON changed rather than wondering which value won.
Only settings the trainer understands are accepted; anything else is rejected at submit, naming the key. That is deliberate — a silently ignored setting looks exactly like one that had no effect, and you would only find out after paying for the run. If something you need is missing, ask us to add it rather than working around it.
5. Cost estimate
The wizard computes an estimated total based on:
- The chosen GPU's hourly rate × estimated training seconds (function of dataset size, sequence length, epochs, batch size).
- Fixed overhead constants for image pull, model load, dataset prep, evaluation, and register.
Rendered as a range, not a point. The lower bound assumes everything goes smoothly; the upper bound includes a 30% headroom for variable phases like a cold image pull. Both bounds use the constants the meter actually charges against — so the real bill almost always lands inside the range.
The wizard also shows the balance impact — your account balance now, minus the upper-bound estimate, equals what you'll have left if training maxes out.
6. Approve & Train
Two checks before the job starts:
- Balance gate — if your account balance is less than the upper-bound estimate, the button is disabled. Top up first.
- Region capacity — if the chosen region is out of your GPU type, the button shows the wait. You can pick a different GPU type or wait.
When both are clear, click Approve & Train. The job moves to training, kicks off the GPU pod, and the detail page (/fine-tune/{id}) starts polling for progress.
Configuration templates
Getting a good configuration takes a few attempts, and retyping it is where mistakes come from. When you submit, you have two buttons:
- Submit — run this job.
- Save as template and submit — run it, and keep the settings under a name.
Templates belong to the account, so anyone on your team can load one, adjust a value, and run. Loading a template fills the form; changing anything afterwards is fine — the job records which template it came from and whether it was modified.
Saving happens independently of the run, so a template is kept even if the job itself later fails. Every new account starts with three starters — Fast iteration, Balanced, and Quality — less for the numbers than to show which dials are worth touching first.
Job status reference
The detail page renders a different panel for each state. Quick reference:
| State | What you see |
|---|---|
training | Live loss / step count / steps remaining, refreshed every few seconds |
evaluating | Eval set running. Usually 1–3 minutes |
trained_pending_register → registered | Adapter being registered. Quick — about a second |
paused | "Balance reached zero" banner with a Top up link, plus a Resume button. See Auto-pause |
failed | Error class and last log lines |
cancelled | Stopped by the user; metered GPU time settled. See Cancelling |
Auto-pause when your balance hits zero
Training is metered per-minute against your account balance. If the balance reaches zero mid-training:
- EcoLink charges for the GPU time consumed up to that minute.
- The trainer pod is told to checkpoint and exit gracefully — work in progress is saved, not thrown away.
- The job's status flips to
paused. The meter stops; no further charges accrue. - The detail page shows a "Balance reached zero" banner with a Top up link to the billing page and a disabled Resume button.
To continue from where you left off:
- Top up your balance from
/billing. - Return to the fine-tuning job's detail page. Resume is now clickable.
- Click Resume. EcoLink re-runs the same balance gate (you must have at least the remaining estimated cost), then re-launches the trainer pod from the latest checkpoint. The metering clock starts fresh — the time you spent paused is not billed.
You can also Pause manually at any point: click Pause if you want to free up GPU capacity for something else. Same checkpoint-and-resume flow as the auto-pause.
Cancelling
The Cancel button on the detail page settles whatever GPU time the meter has consumed and stops the job permanently. The adapter file (whatever was checkpointed) stays on EcoLink storage for 30 days in case you want to inspect it; after that it's deleted unless promoted to a registered fine-tuned model.
After registration
When the job lands at registered, the detail page surfaces a Deploy button. That's the next step — attaching the adapter to a model instance so you can call it via the API.
Next steps
- Deploying an adapter
- Balance and transactions — where per-minute charges show up