Dataset preparation
Upload JSONL or connect object storage. The platform validates schema, flags malformed records, reports token statistics and refuses to start a job on a broken file.
NXAARA Platform service
Fine-tune a model, prove it is better, then ship it
Model Foundry runs the whole loop: prepare a dataset, tune an open base model on it, score the result against a held-out set, compare it to the version already in production, and publish only if it wins.
The gap between a tuned model and a trustworthy one
Fine-tuning is not the hard part any more. Anybody with a GPU and a weekend can produce a set of adapter weights. The hard part is answering the question your risk officer will ask: how do you know this version is better than the one it replaces, and can you show me?
Model Foundry is built around that question. Every tuning job is tied to a specific dataset version, a specific base model, a recorded set of hyperparameters and a fixed evaluation set. When the job finishes you get a comparison, not just a checkpoint — this version against the previous one, on the same tasks, with the differences visible.
A version that does not beat the incumbent does not get promoted. That sounds obvious, and almost nobody enforces it, which is why so many teams have three models in production and no idea which one is actually best.
Publishing is a deliberate act. A tuned version sits in the registry until somebody with the right role promotes it to an endpoint. Nothing reaches production because a training script happened to finish successfully.
- Open base models — start from a published open-weight model, or from a version you tuned here previously
- Dataset versioning — every job records exactly which dataset version it consumed
- Full and parameter-efficient tuning — LoRA and QLoRA for most work, full fine-tune when the case justifies the cost
- Held-out evaluation — scored against a set the model never saw during training
- Side-by-side comparison — new version against incumbent on identical tasks
- Gated promotion — nothing reaches an endpoint without an explicit, logged approval
Capabilities
What the foundry handles for you
These are the parts of a tuning pipeline that teams usually rebuild from scratch, badly, three times.
Tuning jobs
LoRA, QLoRA or full fine-tuning, with checkpointing, resumable runs and live loss curves. Job configuration is recorded, not remembered.
Evaluation harness
Score against your own held-out set with task-appropriate metrics, plus latency and token cost so quality is never assessed in isolation from what it costs to serve.
Version registry
Every artefact is versioned and traceable back to its base model, dataset version, config and evaluation result. Lineage is not optional metadata here.
Comparison and review
Diff two versions on the same evaluation set. See where the new one improved and, more usefully, where it regressed.
Promotion controls
Promotion to an endpoint requires a role with permission to do it, and the approval is written to an audit log with the evaluation it was based on.
How it works
The tuning loop, end to end
This is a genuine sequence — you cannot evaluate before you train, and you should not promote before you evaluate.
Register a dataset
Upload or connect your training data. It is validated, versioned and split, with the evaluation portion held back.
Pick a base model
Choose an open-weight base sized to your latency and cost budget, or start from a version you tuned earlier.
Configure and run
Choose the tuning method and hyperparameters. Watch loss curves live; the job checkpoints as it goes.
Evaluate
The new version is scored against the held-out set and compared against whatever is currently serving.
Promote or discard
If it wins, promote it to an endpoint with a logged approval. If it does not, it stays in the registry as a recorded negative result.
Choosing a tuning method without wasting a month
The most common expensive mistake is reaching for a full fine-tune when a parameter-efficient method would have been indistinguishable in output and roughly an order of magnitude cheaper to train and to store.
As a working rule: if you are teaching a model a format, a tone, a domain vocabulary or a task structure, LoRA or QLoRA is almost certainly enough. If you are teaching it genuinely new knowledge that was not in the base model's training data at all, and retrieval is not a viable substitute, that is when a full fine-tune starts to earn its cost.
Retrieval deserves a fair hearing before either. A great deal of what teams try to fine-tune into a model is really a knowledge problem, and knowledge problems are usually better solved with a well-built retrieval layer that you can update in an afternoon instead of retraining.
| Tuning methods | LoRA, QLoRA, full fine-tuning |
|---|---|
| Base models | Published open-weight models, validated and listed in the console catalogue |
| Dataset formats | JSONL instruction and chat formats; object storage connection for large corpora |
| Job features | Checkpointing, resume, live loss curves, early stopping |
| Evaluation | Held-out scoring, task metrics, latency and token cost, version-to-version diff |
| Artefacts | Adapter weights or merged weights, exportable and downloadable |
| Lineage | Base model, dataset version, config and evaluation recorded per version |
| Deployment | One step to a serverless, dedicated or private endpoint |
Where it is used
What teams tune for
Domain language and terminology
A general model that keeps using the wrong word for a thing your industry has a specific word for. Cheap to fix with tuning, hard to fix with prompting.
Structured output reliability
Getting valid JSON, a fixed schema or a consistent report format on the first attempt instead of the third, which is where most of your token spend goes.
Arabic and bilingual performance
Base models with weak Gulf Arabic handling can be improved substantially with a well-built dataset, and the improvement is measurable on a held-out set.
FAQ
Common questions
Do you train on my data?
No. Your datasets are used to train your models, inside your project, and for nothing else. We do not use customer data to improve base models, we do not pool it across accounts, and we do not sample it for internal evaluation.
Who owns the tuned model?
You own the tuned artefact and can export it — adapter weights or merged weights. The licence of the underlying open base model still applies to derivative work, and the catalogue shows the licence for each base model before you start a job.
How much data do I actually need?
For format, tone and task-structure work, a few hundred to a few thousand well-constructed examples usually moves the metric more than tens of thousands of mediocre ones. Quality and consistency of labelling beat volume nearly every time. If you are short on examples, Synthetic Data Studio exists partly for this.
Can I bring a model I tuned somewhere else?
Yes, if the licence permits it. You can register external weights, evaluate them against your held-out set on the same harness as everything else, and deploy them to an endpoint.
What if the tuned version is worse than the base model?
Then the evaluation tells you that and you do not promote it. This is a normal and useful outcome, not a failure — the negative result stays in the registry with its config, so the next attempt starts from evidence rather than from memory.
Run one tuning job and read the evaluation
The fastest way to judge the foundry is to tune a small model on a real dataset and look at what the comparison actually tells you.