Custom AI Model Development
For teams whose AI feature has outgrown a general model. We take an existing model, whether it handles language, search, images or speech, and adapt it to your task, your data and where it has to run. Then we test it against what you use today, on your own test set, before you switch.
Free · You talk to an engineer, not a salesperson
Every engagement starts with a written go/no-go and a baseline score on your task. No training spend until you approve it.
We build and hand over the model. Running it in production is a separate engagement.
We pick the cheapest method that works, and prove it on your task.
What is custom AI model development?
Custom AI model development means adapting an existing pretrained model, one already trained on broad data, so it does one job in your business better than a general model can: more accurately, more cheaply, faster, or inside your own environment. Today it rarely means building a model from scratch. Teams start from an open-weight model, which they can download and run themselves (see open-weight vs proprietary models), or from a provider's managed model, and specialize it with one of three methods: fine-tuning, distillation or embedding fine-tuning. If a vendor is retiring a model you already fine-tuned, see fine-tuned model migration. Can you build your own AI model? Yes. The first question is whether you need to.
When a general model stops being enough
Starting with a frontier model behind an API is usually the right call. These are the situations where it stops being enough:
- “It keeps getting our domain wrong.” Product terms, output formats, policy rules, defect types or regional accents that the general model misses, even with careful prompts.
- “The bill grows with every call.” A narrow, repetitive task such as routing tickets or pulling fields from documents, billed at frontier-model prices millions of times a month.
- “Search keeps finding the wrong passages.” Your RAG assistant answers badly because retrieval doesn't understand your vocabulary.
- “It's too slow, or too big for where it has to run.” A latency target the product can't meet, or a camera, device or on-premises server with limited hardware.
- “Our fine-tuned model is being retired.” OpenAI stops new fine-tuning jobs for all customers on 6 January 2027, and fine-tuned GPT-4o and GPT-4.1 models shut down on 14 January 2027 (OpenAI deprecations page, checked November 2026).
- “This data can't leave our environment.” Customer contracts, residency rules or internal policy rule out sending it to an outside API.
Do you need your own model?
Often you don't. Before we train anything, we check the cheaper fixes, in this order:
| If the problem is… | Try first | Train a model when… |
|---|---|---|
| The model doesn't know your facts | Retrieval (RAG): give it your documents at answer time | The facts are found but the answers still come out in the wrong form |
| Instructions aren't followed | Better prompts and examples | Behaviour still drifts across thousands of calls |
| Speech or vision misses your terms | Your provider's managed customization, e.g. custom vocabulary for speech | You need it in your own environment, or the managed option falls short |
| Cost or latency | Caching, shorter prompts, routing easy calls to a cheaper model | Volume stays high and a smaller model can hold the quality |
Microsoft's own documentation says its base speech model “works well in most speech recognition scenarios”. The same is true of many general models. We tell you in writing whether yours is one of them. If the answer is “don't train”, you keep the evaluation suite and baseline scores we built to reach it.
Not sure where you stand?
Book a free fit call(opens scheduling widget)Bring 10 examples the current model gets wrong.
Three ways to specialize a model
| Method | Use it when | Works on | Go deeper |
|---|---|---|---|
| Fine-tuning: further training on your examples so the model learns a behaviour, usually with a parameter-efficient method such as LoRA | It has to hold your format, terms, policy, defect types or accents | Language, vision, vision-language and speech models | AI model fine-tuning services |
| Distillation: training a small “student” model to copy a large “teacher” on your task | A large model does the job but costs too much or is too slow at your volume | Language and vision models, search rerankers | Model distillation services |
| Embedding fine-tuning: training the model that turns text into searchable numbers | Search or RAG retrieves the wrong passages because it doesn't know your vocabulary | Text and multimodal embedding models, rerankers | Embedding model fine-tuning |
Many projects combine two: fine-tune, then distil into a small language model; or fine-tune the embedding model and the reranker together.
Which models we specialize
| Model type | Typical tasks | What to know first |
|---|---|---|
| Language models (large and small) | Classification, extraction, routing, tool calling, structured output, domain Q&A | If the gap is missing knowledge, retrieval usually beats training |
| Embedding models and rerankers (the second model that re-orders search results) | Search and RAG over documents, tickets, catalogues, contracts | Gains depend on how weak retrieval is today. In Databricks' published test, fine-tuning helped on two of three datasets |
| Vision and vision-language models (models that read images and text together) | Defect detection (AI for manufacturing), reading documents and forms (AI for logistics), image classification | Licences vary: fine-tuned Ultralytics YOLO models used commercially need an Ultralytics Enterprise Licence unless the project is open-sourced |
| Speech models | Transcription with your accents, product names and jargon | Try managed custom vocabulary first. In one study, fine-tuning Whisper cut the word error rate on British dialects from 16.8% to 1.0% (IWSDS 2025) |
| Other foundation models (multimodal, time-series, code) | Case by case | Scoped in the Fit Sprint |
Building a model for a prediction problem instead, such as demand forecasting or a vision model trained from scratch on your own data? That's Machine Learning Engineering.
What changes when it works
Every outcome is measured against your current model, on the same tests, and reported to you before you switch.
- Accuracy on your task, scored on a test set your domain expert approved.
- Lower cost per call, measured on the hardware you'll run it on.
- Faster responses, reported as P50 and P95 latency: the time half of requests beat, and the time 95% beat.
- A model that runs where you need it: your cloud, a private network, on-premises hardware or a device.
- No restart when a better base model ships. You keep the evaluation suite and the pipeline, so you can score the new model and re-train only if it's worth it. Here's how to benchmark a candidate model before you switch.
We don't quote accuracy or savings figures before your baseline exists. Every number in your report comes from your data.
How an engagement runs
Two contracts, six stages, and nothing trains until you've said yes.
Before any contract: a free fit call. An engineer reads what you send and replies. If it's a fit, we talk about your task. You leave with a straight answer: not a fit, a question, or a scope for a Fit Sprint.
Fit Sprint · fixed scope, priced per scope
| Stage | What happens | You get | Your part |
|---|---|---|---|
| 1. Fit | We review the task, your current setup, cost and latency, test the cheaper fixes first, and check data rights and model licences | A fit memo: the method, or “don't train”, plus candidate models, risks and a dated plan | Gate 1: sign go or no-go. No training spend before this |
| 2. Baseline | We build an evaluation suite with your domain expert and score your current model on it | The evaluation suite and baseline report, yours to keep | Approve the bar the new model has to clear |
Build · priced per scope from the fit memo, with change control
| Stage | What happens | You get | Your part |
|---|---|---|---|
| 3. Data | We curate, label and clean examples, mask personal data, and set aside a test set training never sees | A versioned dataset and the script that rebuilds it | Your expert checks label samples |
| 4. Train | We train two or three candidate models where licences allow, in rounds, and score every round | Candidate models and a log of every run | Compute runs on your cloud account |
| 5. Prove | We score the best candidate on the held-out test set, on things it must still do well, and on real production samples, then measure cost and latency on your hardware | An evaluation report, failures included | Accept or reject it (Gate 2) |
| 6. Hand over | We package the model for your runtime, document it, and train your team | Model files, a model card, a retraining runbook and a handover session | Your team re-runs the pipeline once. Then it's done |
Every week you get a written report: what's done, what's next, risks, budget and timeline. Every material decision goes in a decision log, and nothing changes scope without your approval. See how we work.
If the model doesn't clear the bar, you'll know why from the report. We agree whether another round is worth it, and if it isn't, we stop. You keep the evaluation suite, dataset and findings.
After handover, the model is yours to run. When a better base model ships or your data changes, the runbook re-runs the pipeline and the evaluation suite tells you whether the new version is better. If you want us to do it, that's a new, smaller fixed-scope build.
Working to a deadline? OpenAI stops new fine-tuning jobs on 6 January 2027. Tell us on the call and we'll plan backwards from the date. See fine-tuned model migration.
What you can expect
- Whatever we decide: a written decision, plus an evaluation suite and baseline you can use to test any future model.
- If the answer is go: a model that clears the bar you approved, with no regressions you haven't accepted, and its cost per call and latency measured on your hardware.
- What we won't promise: an accuracy or cost figure before your baseline exists, or that your model will beat every model released after it. The pipeline and evaluation suite make it cheap to check when a new one ships.
What you receive
- 01Fit memo: the recommended method, or “don't train” plus the cheaper option; candidate models and their licences; data readiness; cost drivers; risks.
- 02Evaluation suite and baseline report: a test set your expert approved, task metrics, regression checks, your current model's scores.
- 03Training dataset and pipeline: versioned, with personal data handled and a record of where every example came from.
- 04Trained model: weights or adapter, configurations and a log of every training run.
- 05Evaluation report: new model vs current model on task score, regressions, latency, cost per call and known failure cases.
- 06Deployment package and handover: model files for your runtime, a reference serving configuration, a model card, a retraining runbook and a handover session.
A Fit Sprint delivers items 1 and 2. A Build delivers all six. Optional: connecting the model to your product, scoped into the Build.
What we need from you
| From you | Why |
|---|---|
| One defined task, e.g. “route tickets into 14 queues” or “flag scratches on panel images” | A model is specialized, and scored, for a specific job |
| Your current setup and some of its outputs | It's the baseline the new model has to beat |
| Examples (text, images, audio or queries) and the right to train on them | The model learns from them. Quality matters more than volume |
| A domain expert, available every week | They approve labels and the evaluation bar |
| Where the model must run, and your latency and cost targets | They decide model size and packaging |
| A cloud account for training compute, and an owner for the model after handover | Compute stays on your bill; someone keeps the model evaluated once we've gone |
Missing some of this? Working it out is part of the Fit Sprint.
Not included
Hosting and running the model after handover (your team runs it, with the runbook we hand over) · building the RAG system around an embedding model (RAG Development) · a product-wide evaluation programme (AI Evaluation) · training a foundation model from scratch · distilling from a model whose terms forbid it · promising numbers before your baseline exists.
Licences, data and ownership
Is it legal to build your own AI model? Usually yes, but every base model and teacher model comes with terms, and some pass conditions to whatever you build from them:
- Llama 3.3: a model trained on Llama outputs and then distributed or made available must start its name with “Llama”.
- Gemma 1–3: a model distilled from Gemma falls under Gemma's terms and use policy. Gemma 4 is under Apache 2.0.
- OpenAI and Anthropic: their terms restrict using outputs to train competing models.
- Ultralytics YOLO: commercial use of a fine-tuned model needs an Enterprise Licence unless the project is open-sourced.
- Whisper: MIT licence.
We check the candidates in the Fit Sprint and write the conditions into the fit memo, so your legal team reviews them before training starts. This is an engineering review, not legal advice. See which teacher models are allowed.
Your data: training runs in your own cloud account, a private network or on-premises. Personal data is removed or masked before training. We sign a mutual NDA before you share data, and your data is used only to build your model.
Ownership: you own the trained weights or adapters, the datasets and the evaluation suites once the work is paid for. We keep our own reusable tooling. The base model's licence still applies to what you build on it.
How to judge us
Model specialization is a dedicated discipline at Crescent AI. What you can check before you commit: the go/no-go, the evaluation bar you approve and the two gates, all in the contract.
| Question | Crescent AI | Self-serve tuning platform | Generalist AI agency |
|---|---|---|---|
| Decides whether to train | Yes, in a written go/no-go | You decide | Varies |
| Language, embedding, vision and speech models | Yes, one process for all | Usually one or two types | Varies |
| Evaluation built before training | Yes, a bar you approve plus regression checks | You build it | Often mentioned, rarely delivered |
| Licence and teacher-terms review | Yes, at the Fit stage | No | Varies |
| Dataset, evaluations, model and runbook handed over | Yes | Depends on the platform | Varies |
| Best when | You need the decision, the proof and the handover | You have clean data, a metric and an engineer to run training | You need a broad AI application built |
If you have clean labelled data, a clear metric and an engineer who can run training, a self-serve platform may be enough. We'll tell you that on the call.
Who leads this work
Yash Amin, founder of Crescent AI. About Crescent AI
Custom model vs a frontier API
A frontier model behind an API is built for open-ended reasoning across any topic. A specialized model is built for one job. For broad, unpredictable tasks, the frontier API is usually the better tool. For narrow, high-volume, well-defined work, or work that has to stay in your environment, a specialized model can match it on that job at lower cost per call. Many teams run both: a specialized model for routine calls, and the frontier model for the hard cases. The Fit Sprint measures where that line sits for your task. For one example, see running an open model instead of a frontier API.
Common questions
How much does a custom AI model cost?
It's priced per scope. The Fit Sprint and the Build are each scoped to your task: how ready your data is, the method, the model size and where it has to run. You see the scope and its price before you commit to either. Training compute runs on your own cloud account.
How much data do we need, and what if it isn't ready?
Less than most teams expect. For a narrow task it's usually hundreds to a few thousand good examples, not millions, and quality matters more than volume. If your data is scattered, unlabelled or sensitive, the Fit Sprint finds that out and plans the fix before any training is priced. If you don't have enough, the fit memo says so.
Can we talk before we share any data?
Yes. The fit call needs no data, only a description of the task. We sign a mutual NDA before you send examples, or review yours if you prefer, and redacted or synthetic samples are fine at that stage. Your data is used only to build your model, and real training data stays in your own cloud account or environment.
What happens if the model doesn't beat what we have, or we want to stop?
You can stop at either gate. You pay for the work completed up to that point, with no exit fee, and you keep everything delivered so far. If the Build's model doesn't clear the bar you approved, the evaluation report shows why, and we agree whether another round is worth it. If it isn't, we stop, and you keep the evaluation suite, the dataset and the findings.
Won't the next base model make it obsolete?
Sometimes a new model will be good enough without specialization, and you'll be able to check. You keep the evaluation suite and the training pipeline, so when a new base model ships, your team scores it against your current one on the same tests and re-trains only if that pays off. Maintenance is that check, run by your team with the runbook we hand over, or by us as a new, smaller fixed-scope build.
Will it work with our existing systems?
Yes, if we know where it has to run. You name the runtime and hardware in the Fit Sprint, and we package the model for it with a reference serving configuration and measure latency on that hardware. Need it wired into your product as well? We can scope that integration into the Build.
Bring us the task your general model can't quite do.
We'll tell you which method fits, or whether you need one at all, before you spend on training. If specialization looks worth testing, we scope a Fit Sprint that ends in a written go/no-go.
Mutual NDA before you share data · Fixed-scope Fit Sprint · No training spend before your go/no-go
RAG Development · AI Evaluation · AI Security · Machine Learning Engineering