Case Studies / Custom Model Fine-Tune
Teaching an open-weight model a behavior prompting could not deliver.
The model needed to behave in one specific, consistent way. No amount of prompting made the base model do it reliably, so JTPCK fine-tuned it: a small LoRA adapter trained on our own GPUs, measured at every stage, then merged, compressed, and served in production.
A note on specifics
For confidentiality reasons, we are keeping the details of the target behavior, the data, and the exact model deliberately vague. The process, the measurements, and the problems we ran into are described as they happened.
The challenge
A specific behavior, every time.
The system needed a model that behaved in a particular way in particular situations, with a particular output shape. A capable open-weight model could do it some of the time when prompted carefully. Some of the time is not good enough for a production pipeline.
Prompting alone did not get there. The behavior had to live in the weights, not in the instructions. That is the narrow case where fine-tuning beats prompting and retrieval, and it is worth being sure you are in it before you start. We cover that call on RAG vs. fine-tuned models.
The process
Measure, train, measure, compress, measure.
-
01
Baseline
Eval suite run on the base model
Target tests fail
-
02
Data
Synthetic examples, generated locally
Every batch inspected
-
03
Train
Small LoRA adapter on a frozen base
Smoke test first
-
04
Compress
Merge, then quantize
Router kept at full precision
-
05
Serve
vLLM on our own hardware
Re-tested before launch
Baseline. Before touching any weights, we wrote down exactly what the new behavior should look like and built an evaluation suite around it with promptfoo. The base model failed the target tests, which is the point: those failures are what the fine-tune has to fix, and now they are on record.
Data. Training examples were generated synthetically on our own GPUs, so nothing left the building and there was no per-token bill. Every batch was inspected by hand for quality and consistency. A bad example teaches bad behavior just as efficiently as a good one teaches good behavior.
Train. The base model was held frozen while a small, narrowly targeted LoRA adapter learned the new behavior. A short smoke-test run caught pipeline mistakes first, and a pristine copy of the base was backed up before the real training run.
Compress. The adapter was merged into the full-precision base and the merged model was quantized to fit the serving hardware.
Serve. The quantized model was evaluated one more time, then put into production behind vLLM.
What we ran into
The surprises were all after training.
1. The adapter could not be applied at serving time.
The plan was to serve the quantized base and load the adapter on top at runtime. The serving engine did not support that for this architecture on a quantized model. Merging the adapter into the full-precision weights first, then quantizing the result, solved it.
2. Quantization ran out of memory.
Training fit comfortably. Quantizing did not. Compressed layers accumulated in system RAM over the long run until the machine was out of headroom. A large swap file got it through. The lesson: plan memory for the quantize step, not just for training.
3. The router had to stay at full precision.
The model is a Mixture-of-Experts, with an internal router that decides which expert handles each token. Quantizing the router along with everything else degrades quality in ways that are hard to trace. It was kept at full precision while the rest of the model was compressed.
4. Calibration data matters.
Quantization is not blind rounding. Sample inputs are run through the model to decide how to compress each layer. We used a sample of the training data, so the compression was tuned to the behavior the model actually has to perform.
The outcome
Failing tests became passing tests, and stayed that way.
At full precision, the fine-tuned model passed the target-behavior tests the base model had failed. Base and fine-tune were compared at the same precision and settings, so the adapter was the only variable.
Learning a new behavior can come at the cost of old ones, so the suite also included general-capability tests and checks on structured tool calling. Those held. After merging and quantizing, the full suite was run again and the model still passed.
It is not perfect, and we would not claim it is. Under adversarial prompts well outside anything it runs into in production, the old behavior can still leak through. Under the conditions it actually runs in, it does what it was trained to do.
Where this applies
When the behavior has to live in the weights.
- Consistent output. A format, tone, or decision pattern the model has to hit every time, not most of the time. AI fine-tuning
- Sensitive data. Training, evaluation, and serving can all happen on hardware you control. On-premise AI
- Not sure it needs a fine-tune? Often it does not. RAG vs. fine-tuned models
The step-by-step process is written up in how we fine-tune open-weight models.
Get started
Need a model that does one thing reliably?
JTPCK fine-tunes and serves open-weight models for businesses in Boston, across New England, and remotely. Tell us what the model needs to do and where your data has to stay.