AI Model Fine-Tuning

Fine-tuned models, when prompting isn’t enough.

We check whether better prompts or RAG solve the problem first. When they don’t, we fine-tune or distill a model on your data — LoRA on Llama, Qwen, Mistral and other open-weight models, or managed tuning on Bedrock, Microsoft Foundry or Google Cloud — and prove it against today’s model on your own evals. Deployed in your cloud.

Where fine-tuning projects stall

Most teams fine-tune too early. Many never measure it.

Fine-tuning fixes format, tone, domain language and cost at volume. It doesn’t teach a model facts that change every week — that’s a retrieval problem. Projects stall when nobody asks these questions first.
If prompting or retrieval wins, we say so and build that instead — with a fixed price and a success metric agreed before we train anything.
  • Have better prompts, examples or RAG been tried and measured?
  • Is there an eval set from your own data that defines “better”?
  • Do you have enough clean examples — or a way to generate and check them?
  • Would a smaller distilled model match the large one on this task?
  • What does each call cost and how long does it take, before and after tuning?
  • Who retrains it when the base model, your data or your rules change?
What we build

Where fine-tuning pays off

Fine-tuning works best on narrow, high-volume tasks with a clear right answer. These are the ones we see most.

Distill a large model into a small one

Use a frontier model’s best outputs to train a smaller open-weight model on one task, so the high-volume path runs cheaper and faster.

We measureCost per 1,000 calls, latency, quality vs. the large model

Domain language & classification

Sort tickets, claims or documents into your own categories, using medical, legal, technical or internal terms a general model keeps getting wrong.

We measureAccuracy per class, error rate on rare classes

Structured output at scale

Extract fields or produce JSON in your exact schema every time, without long prompts packed with examples.

We measureSchema-valid rate, field accuracy, tokens per call

House style & tone

Drafts that sound like your team — support replies, product copy, reports — trained on approved examples and refined with preference tuning.

We measureEdit rate, reviewer preference vs. baseline

Private models

An open-weight model tuned and served inside your own cloud account when data can’t leave your environment.

We measureQuality vs. hosted model, cost per call, throughput

Training pipelines for ML teams

Repeatable training on your cloud — data versioning, GPU scheduling, evals and a model registry — like the pipeline we built for Gulp.ai on AWS.

We measureTraining time, GPU utilization, cost per run

How we fine-tune

From one task to a model you can retrain

Every engagement follows the same four phases. You can stop after any of them and keep everything we built: data, code and models in your accounts.
  1. 01Phase 01

    Assess

    We find out whether fine-tuning is the right tool before anyone pays for GPUs.

    • Task definition and eval set built from your real examples
    • Baselines: today’s model, better prompts, and RAG where relevant
    • Data audit: volume, quality, labels and privacy
    • Cost per call modeled before and after tuning

    DeliverableGo/no-go recommendation and a signed success metric

  2. 02Phase 02

    Proof pilot

    One model, trained on your data, measured against the baselines.

    • Training set curated and versioned; synthetic data checked by people
    • LoRA or QLoRA on open-weight models, or managed tuning in your cloud
    • Distillation or preference tuning (DPO) where the task calls for it
    • Side-by-side evals against the baseline model

    DeliverableWeek-4 readout: quality, latency, cost per call, go/no-go

  3. 03Phase 03

    Production build

    We serve the model reliably and make retraining routine.

    • Serving in your cloud with auto-scaling and cost alerts
    • Evals as CI gates on every new checkpoint
    • Fallback to the base model if quality or latency slips
    • Reproducible training pipeline as code

    DeliverableProduction model, training pipeline and runbook in your accounts

  4. 04Phase 04

    Operate & improve

    Base models improve every few months. Your tuned model should keep earning its place.

    • Weekly evals and drift alerts on live traffic
    • New base models tested against your tuned model
    • Retraining on fresh, reviewed examples
    • Hand-off to your team whenever you’re ready

    DeliverableMonthly report scored against your baseline

What we build with

Base models
LlamaQwenMistralGemmaHosted tuning APIs
Training methods
LoRA / QLoRADistillationDPOSynthetic data
Platforms
Amazon BedrockSageMakerGemini Enterprise Agent PlatformMicrosoft FoundryHugging Face
Serving & evals
vLLMCustom eval suitesLangfuseTerraform

“ForthClover's custom Bedrock AI solution saved us countless hours.”

Partnering with ForthClover to fine-tune our LLM and leveraging Amazon Bedrock has transformed our business. The customized AI solution they developed has dramatically streamlined our analysis process, saving us countless hours of effort. ForthClover's expertise in AI optimization and cloud integration was crucial in delivering a solution that perfectly fits our needs.

Joshua CohenJoshua CohenFounder & CEO, Tubefilter
tubefilter

Case study · Gulp.ai

How we built Gulp.ai’s LLM fine-tuning pipeline on AWS.

  • Improved GPU utilization and reduced training time during model training runs
  • Substantially reduced compute costs through dynamic batch sizing and efficient GPU usage
  • Abstracted infrastructure management so the team could focus on model development
Read the case study
FAQ

Questions we hear on fit calls

Should we fine-tune or use RAG?
They solve different problems. RAG gives a model facts it doesn’t have and stays current as your documents change. Fine-tuning changes how a model behaves: format, tone, domain language, or doing one task well in a smaller model. Many systems use both.
How much data do we need?
For a narrow task, less than most teams expect — quality matters more than volume. We measure how results change as examples are added, so you can see whether collecting more is worth it. If you’re short, a larger model can generate synthetic examples that your experts spot-check.
Will a fine-tuned model be cheaper to run?
Often, when a smaller tuned model replaces a large general one on a high-volume task. We model cost per call before training and measure it on your traffic in the pilot, so the decision rests on real numbers.
Who owns the model?
You do. Training data, code and eval sets live in your accounts, and so do the weights for open-weight models. Models tuned on Bedrock, Microsoft Foundry or Google Cloud stay in your cloud account too.
What happens when a better base model comes out?
We test it against your tuned model on the same eval set. Sometimes the new model wins with a good prompt and you retire the fine-tune; sometimes you retrain on top of it. Either way, it’s a measured decision.
Is our data safe during training?
Training runs in your cloud account, and data only goes to a third party if you choose a hosted tuning service. We mask or remove sensitive fields before anything is used for training.

Not sure fine-tuning is worth it?

Bring one task and a few real examples to a free 45-minute fit call. You leave with a recommendation — prompt, RAG or fine-tune — a rough cost per call, and a straight answer on whether training is worth it.