Fine-Tune a Model in IONOS Studio and Get Instant Access Through the Starter Pack — Using One Line of Configuration

Why This Matters

The whole fine tuning pipeline used to be a headache: GPU setup, tokenizer configuration, JSONL formatting, model hosting, and API gateways.

IONOS recently introduced its no code ModelStudio platform, an interface that lets you fine tune large language models without managing GPUs, clusters, or training

infrastructure. At the same time, the IONOS Starter Pack already provides a complete web enabled chatbot environment capable of running any model accessible through the IONOS Model Hub.

Naturally, I wanted to test the full loop myself: fine tune a model inside ModelStudio, deploy it, and then call it from the Starter Pack with a single line of configuration, meaning an environment variable pointing to the model ID.

What follows is the complete journey, from dataset preparation to model training, performance analysis, and final integration.

The process can be broken down into the following stages:

• Dataset preparation
• Model fine tuning in IONOS ModelStudio
• Model testing and evaluation
• Performance and metrics analysis
• Integration with the IONOS Starter Pack

My first experiment was intentionally simple. I generated a synthetic customer support dataset, selected a suitable model, and fine tuned it to answer incoming support emails. The goal was purely to validate the workflow: dataset to ModelStudio to trained model to Playground test.

Once the basic flow proved reliable, I moved to a more serious scenario, building a GDPR compliance assistant. For this, I used a Q and A dataset based on public GDPR question and answer pairs. The raw CSV contained multiple columns, but only the Question and Correct Answer fields were relevant for conversational fine-tuning.

Dataset Preparation

ModelStudio expects JSONL input formatted as conversational exchanges. Each sample was transformed into a three message structure consisting of:

• a system instruction
• a user question
• an assistant answer

A custom Python script called tojsonl.py was used to convert the datasets from their original format into a valid JSON Lines file. This file must pass ModelStudio validation before it can be uploaded, ensuring each record follows the required structure.

IONOS starter pack integration

To close the loop, I wanted to access the fine tuned models through a user friendly chat UI. The Starter Pack was the natural choice. It allows direct interaction with fine tuned models by adding a single configuration line, an environment variable containing the model’s unique ID.

This is not application logic but a configuration step that links your UI to the fine tuned model hosted within IONOS Studio.

Experiment 1: Customer Support Synthetic Data

To warm up, I started with the simplest possible scenario: a synthetic customer support dataset generated directly inside the platform. Fifty examples, nothing ambitious, just enough to test the entire pipeline end to end.

Inside the Dataset tab, the process is straightforward. You click Create Dataset, upload a JSONL file or generate synthetic samples, and ModelStudio automatically validates the structure. Once confirmed, the dataset appears in the table and is ready for training.

As soon as you confirm the uploading or synthesizing, a new dataset entry appears in the table, ready to use.

Next, I switched to the Models tab and clicked Create Model. This opened the training interface where I selected the base model, attached the dataset, and configured the job.

ModelStudio offers several base models including Granite 3.3B Instruct, Qwen 2.5 Instruct, Qwen 3 0.6B, and Qwen 3 1.7B.

I chose Qwen 3 1.7B because it balances compact size with expressive capability, suitable for handling customer emails.

You are also prompted to choose how strongly the model should adapt. Three training styles are available, each optimized for speed, cost, and specialization.

Any modification in Advanced Settings switches the job to a custom configuration.

After clicking Start Training, you land on a live monitoring screen where each stage of the pipeline streams in real time, from dataset preparation to the final epoch.

Once training is complete, the model can be tested using the Play button, which is the little black triangle

You can also assign it as the active background model and observe task outputs.

As expected, it generated coherent and context aware responses.

This step was not meant for production deployment, but to validate the frictionless workflow.

Experiment 2 — Fine‑Tuning a GDPR Compliance Assistant

1. Dataset Selection and Preparation

For the second experiment, I used the Kaggle dataset GDPR Q and A. After inspection, it contained columns such as Question, Correct Answer, Quantized Base, Fine

Tuned Model, and Base Model Answer. Only the Question and Correct Answer fields were required.

A Python conversion script transformed the dataset into JSONL format, wrapping each pair into a system user assistant structure and producing a gdpr.jsonl file ready for upload.

Upload to ModelStudio

The generated gdpr.jsonl dataset was uploaded to IONOS AI ModelStudio → Datasets, appearing as “GDPR Q&A — Ready” with 99 samples and text modality.

A brief README was added to describe the dataset’s objective: building a GDPR compliance assistant capable of answering regulation-based questions concisely and accurately.

Upload to ModelStudio

I selected a suitable base model and applied a configuration designed to prevent overfitting while allowing adaptation to legal and compliance terminology. This ensured specialization without rigid memorization.

Once training finished, the model appeared in the Models section and was ready for testing.

Once the training is complete, the model appears in the Models section. You can now see its full details like the model ID, how it improved compared to the base model, and the evaluation score displayed right beside the triangle Play button that opens the testing interface(backgroud). At this stage, your fine-tuned model is fully deployed and ready to try out.

Model Evaluation

The GDPR assistant was tested using unseen compliance scenarios. For example:

A marketing company wants to analyze customer browsing behavior using cookies to personalize ads. Under the GDPR, what legal basis could justify this processing, and what are the key consent requirements?

when clicking on process task you will see the model running

The model responded with structured reasoning referencing Article 6(1)(a) and core consent principles such as freely given, informed, specific, and unambiguous consent. It also mentioned legitimate interest as an alternative. While mostly accurate, deeper legal analysis showed that legitimate interest is rarely acceptable for cookie based advertising under EU law. This confirmed the need for human oversight in regulated domains.

Studio Insights: Performance and Latency

At this stage, it’s natural to start wondering about several important aspects: pricing, training latency (the time required to fine-tune models), and inference latency when testing models both in the interface and through the API.

This section focuses on these points.

First, it’s important to note that the platform is currently in beta and is therefore free to use. More detailed pricing information is expected to be officially published by IONOS in the coming months.

To understand performance and timing, we return to the Jobs section, where we can inspect the different types of tasks that have run — such as training jobs, generation jobs, or standard response requests. These job records allow us to observe the exact duration of each operation and evaluate real attaching latency.

For instance, when training the first synthetic data bot, the process started at 08:51:04 and finished at 08:51:53. This short duration is explained by the fact that only 50 samples were used and the dataset was generated directly by the platform, giving it maximum compatibility. As a result, the fine-tuning process took less than 50 seconds.

In comparison, the Qwen3–1.7B model trained on a 100-sample GDPR Q&A dataset took slightly longer. The job started at 13:59:32 and finished around 14:00:28, making it approximately 8 seconds slower than the synthetic dataset training run — a reasonable increase given the larger dataset and more complex task structure.

Understanding Model Performance Metrics

When diving into the model details inside IONOS ModelStudio, you’ll encounter a few key metrics that help you understand how well your fine-tuned model is performing. The two main ones are the Model Score and the Improvement metric. Together, they tell a clear story about whether your model actually learned something useful.

Improvement Metric

While the Model Score compares your model to randomness, the Improvement metric compares it to the original base model. It shows how much the fine-tuning process actually improved performance over the starting point.

The formula is:

Interpretation:

• Positive value → Your fine-tuned model is better than the base model
• Higher positive value → Stronger improvement
• Negative value → The model performed worse after fine-tuning

This metric is especially important because it answers the real question: was fine-tuning worth it?

Model Score (0–100%)

The Model Score represents how much better your fine-tuned model performs compared to a random baseline. More precisely, it measures the percentage reduction in cross-entropy loss relative to a model that predicts tokens randomly.

The logic behind it is:

Where:

• CE_model is the cross-entropy loss of your fine-tuned model
• CE_random is the loss of a random baseline model, approximated as log(vocab_size)

How to interpret this score:

• 0% → The model performs no better than random token selection
• 50% → The model reduces loss by half compared to random
• 100% → The model achieves zero loss (theoretical perfect prediction)

Perplexity Metric

Perplexity is a measure that describes how uncertain a model is when predicting the next token in a sequence. Conceptually, it reflects how many choices the model is effectively “considering” at each step.

You can think of it as the model’s level of confusion:

the higher the perplexity, the more unsure the model is about what comes next.

The underlying relationship is simple:

How to interpret perplexity values

• A perplexity of 10 means the model is, on average, choosing between about 10 equally likely tokens for each prediction.

• A perplexity of 1 means the model is fully confident and predicts the next token with certainty.

• Higher values indicate greater uncertainty and weaker predictive performance.

It’s important to note that perplexity is not an absolute score. Its meaning depends heavily on:

• The type of task

• The structure of the data

• The linguistic complexity of the domain

In other words, a “good” perplexity for legal text may still be a “poor” one for simpler conversational data. The metric is most useful when comparing models trained on the same task and dataset, rather than across unrelated domains.

Model Pricing

since the studio is still in beta what we are listing here is the price table of inference models in the AI MODEL HUB

Integrating it in te start pack

The final step was the easiest one. The Starter Pack already supports model selection via a dropdown. Adding the fine‑tuned model required only one new entry in the model configuration list .

First, if you don’t already have the IONOS Starter Pack, you can find it here: Starter Pack.

Follow the instructions provided here in the documentation to clone the repository and configure your backend/.env file, which is where all your environment variables will be stored.

Once this is in place, you will be able to use the Starter Pack and gain direct access to your fine-tuned models.

To make your fine-tuned models available inside the app, the process is intentionally simple. Navigate to the backend/.env file you just created and add the four required environment variables corresponding to your Studio models. The full process of creating these environment variables and retrieving their values from IONOS Studio is explained step-by-step here: studio docs, and what you will need to add to the code is juts the MODEL ID you can find here in the studio under your model name(refer to the following screenshot)

Finally, make sure backend/main.py contains the mapping that allows the backend to expose your fine-tuned models to the frontend and display them in the model selection dropdown. For example, if you want qwen-gdpr will find a dictionary where model names are defined.

This is where you simply add the name you want to appear in the interface and link it to the environment variable that stores your model’s UUID.

For example, if you want qwen-gdpr to appear in the dropdown, and you stored its UUID in the .env file under STUDIO_MODEL_QWEN_GDPR, this is the only change required before restarting your server and using your fine-tuned model normally.

What happens here is simple: you assign a human-readable name to your model and connect it to the environment variable that holds its official IONOS Studio Model ID (UUID).

In practice, this means the name shown in the interface points directly to the variable that contains the real model identifier used by the backend.

For example, the model name granite-gdpr is mapped to the environment variable STUDIO_MODEL_GRANITE_GDPR, which stores the actual UUID of the fine-tuned model.

The pattern looks like this:

That’s it. Once saved and the server is restarted, the model will instantly appear in the dropdown and be ready for use.

after restarting your server you can see your model listed in the IONOS Studio drop down in the left, the app opens by default on the IONOS Model Hub dropdown but when u click on the second one in the

direct test in the deployed version

I added many other models

Conclusion

IONOS ModelStudio changes the meaning of fine tuning in practice. What once required complex infrastructure and careful GPU orchestration is now a structured and accessible workflow that moves smoothly from dataset preparation to training, evaluation, and deployment.

Across both experiments, the synthetic customer support bot and the GDPR compliance assistant, a consistent pattern emerged. No code fine tuning is not a novelty.

It is operational, measurable, and directly usable. Training transparency, intelligible metrics, and immediate deployment turn experimentation into deployment with minimal friction.

This shifts the focus away from infrastructure concerns and toward intelligent design, dataset quality, and real world validation. Teams can iterate faster, refine earlier, and build domain specific systems without the traditional overhead.

As ModelStudio evolves and pricing becomes formalized, its true value will be judged by how quickly ideas transition from concept to deployed intelligence. That speed, combined with clarity and control, defines its impact.

Fine tuning is no longer a technical burden. It is now a strategic capability

Resources and New Datasets:

I added multiple models to our studio dropdown, those models are named after the dataset used to finetune them
you can find the datasets here with other one I ma planning to add as soon as possible, you can also take the step and that before me

ShareGPT Vicuna (unfiltered)

MultiWOZ 2.2 (task-oriented dialogues)

DialogSum (dialogue summarization)

Stanford Alpaca (instruction tuning)

OpenAssistant Conversations (full human–LLM chat)

Dolly-15k (Databricks instruction tuning)

UltraChat (two-round conversational QA)

NaturalConv (long multi-turn conversations)

Anthropic HH-RLHF (helpful & harmless conversations)

OpenHermes-2.5 Training Dataset