Ertas for ML Engineers & Fine-Tuning Practitioners

The Challenge

The open-source fine-tuning ecosystem is powerful but deeply fragmented. Unsloth optimises training speed but has no deployment story. Axolotl provides flexible configuration but requires manual YAML wrangling and offers no experiment tracking. LLaMA-Factory gives you a web UI but locks you into its specific abstractions. Every tool solves one piece of the puzzle brilliantly and ignores the rest, leaving ML engineers to glue together workflows with shell scripts, notebook cells, and folder-naming conventions that inevitably break when a team member joins or a project resumes after two weeks. GPU memory constraints add another layer of friction. An engineer can spend an entire day figuring out the right combination of quantisation, batch size, gradient accumulation, and sequence length to make a training run fit on their available hardware.

The deployment gap is where most fine-tuning projects die. An ML engineer produces a beautiful set of adapter weights in a notebook, achieves strong eval metrics, and then faces the question: now what? Converting to GGUF requires finding the right llama.cpp commit that supports the model architecture. Quantising to the right bit depth requires trial and error across Q4_K_M, Q5_K_M, and Q6_K variants. There is no standard way to track which experiment produced which adapter, which dataset version was used, or how eval metrics compare across runs. When a stakeholder asks "can you reproduce the model from three weeks ago?" the honest answer is usually "probably, if I can find the right notebook and the training data hasn't been overwritten." Without reproducibility and a record of which data and settings produced which model, fine-tuned models rarely make it to production.

The Solution

Ertas Studio puts the pieces ML engineers usually assemble from separate open-source tools into one visual workflow. On the canvas you attach a base model, a dataset, a training config and a LoRA config to a Fine-Tune module, with the settings practitioners expect exposed: learning rate, steps or epochs, batch size and gradient accumulation, optimizer, LoRA rank, alpha, dropout and target modules. Datasets come from a JSONL upload, a Hugging Face import, or Data Craft, Studio's guided dataset builder, where you edit and version examples and track which ones have been approved. Training runs on Ertas's managed cloud GPUs, so there is no quota wrangling or driver debugging, and the training set is uploaded to Ertas for the run.

Parallel runs make sweeps cheap in wall-clock time: duplicate a module, change one knob per copy, and start them all. The Run panel keeps each run's configuration snapshot, final loss, credits used and runtime, and datasets stay stored, so a result from three weeks ago can be traced to its data and settings and trained again. Each finished run shows a few inference samples as a quick coherence check, and real evaluation happens on your own held-out set once you download the model. Export as a Q4_K_M GGUF for llama.cpp, Ollama or LM Studio, as the LoRA adapter, or on paid plans as full safetensors for vLLM and other server runtimes, without hunting for the right llama.cpp commit. Hub lists every model you have trained, and the files are yours to run anywhere with no Ertas dependency at runtime.

Key Features

Example Workflow

An ML engineer at a mid-stage startup is asked to distil GPT-4o's behaviour on the company's core tasks (customer query classification, product recommendation and summarisation) into a compact model for on-device deployment. After confirming the provider's terms allow it, they generate a 50,000-example dataset of GPT-4o outputs on the company's own prompts, set 2,000 examples aside as a test set, and upload the rest to Studio as JSONL. On the canvas they set up a base-model bake-off with Qwen 2.5 3B, Llama 3.2 3B and Phi-4 Mini on identical settings, plus a LoRA rank sweep (8, 16 and 32) on the strongest early candidate, all running in parallel. An early look at the loss curves shows two variants falling clearly behind, so the engineer cancels them and their held credits return to the pool. When the remaining runs finish, the engineer downloads each GGUF and runs the held-out set through all of them with the team's own scoring script, spot-checking outputs in every task category. The winning model ships in the app through llama.cpp, and its run in Studio keeps the configuration and dataset that produced it, so the next retrain starts from a known baseline.