How a project runs, and what stays with you.
From the first call to the day we leave. Five steps, and a price fixed before any work starts. At the end you have the weights, or the machine they run on, or both. Which of those you need is usually the first thing we settle.
Five steps,
and the data question lands in step two.
We scope by hand, one job at a time. One call usually settles whether a fine-tune helps at all, and that is the cheapest place to find out. If retrieval would do the job, we say so on that call.
Tell us what it has to do
A couple of sentences is enough: what the model should do that the current process does not, roughly how much data there is, and what you have to be able to prove about it afterwards. If none of that is clear yet, working it out is the first thing we do.
Where the data lives, in writing
Before anything else: which machine holds the corpus, who can reach it, whether we work supervised or in isolation, what gets deleted at the end and when. This is the part people actually audit, so it gets written first.
We read the data and say what it is worth
Curation and an eval set come before training. If the corpus is too thin or too noisy for the outcome you want, you hear that in week one, before a month of GPU time goes into it.
Training and evaluation
LoRA, QLoRA or full-weight, on your hardware or ours. The harness is built around your task. You see the scores against baseline as the run goes, not at the end.
Deploy, document, hand over
The model goes onto the machine it will live on, behind your auth and your logging. Then the documentation, the run logs, and a session with whoever will operate it. After that we are done unless you want support.
Everything you need to run it without us.
The weights, yours outright
Safetensors, GGUF or ONNX. You can serve them with nobody's help. There is no licence back to us, and no endpoint of ours sits in the request path.
The whole stack
Container, inference server, pinned package versions and a compose file that comes back up after a reboot. The unremarkable part, already done.
The numbers
The eval harness, the baseline scores and the exact configuration. When somebody asks whether this model is better, the answer is a file rather than a feeling.
The pipeline
Curation scripts, prompt templates and training config. When your corpus doubles next year, you re-run it yourself and diff the scores.
A machine, if you need one
Sized to the model and to the query load, built and burned in under load. Or a spec you take to a supplier of your own.
Standard formats
Open tooling and ordinary files. No proprietary storage layer. Moving the model somewhere else later costs an afternoon, which is the point of owning it.
Three kinds
of engagement.
The method is the same each time. What changes is how much of the machine you already own and how much of the running you want to keep.
Defence, medical, legal and industrial
Work where the data cannot leave the building, and where somebody will eventually ask you to show that it did not. Air-gapped builds, documentation that survives an audit, the weights in your hands. Start a project →
Teams that want their own model
A house style, a domain vocabulary, or a structured output a general model keeps getting wrong. A small model, a specific corpus, and a machine that fits under a desk and costs less than a year of API spend. Discuss a requirement →
Labs, hospitals and universities
Grant-funded work with a data-use agreement attached, or a group that needs the machine more than the model. We scope, build and document. You publish from it. Talk to us →
Before you ask.
What does it cost?
Evaluation is $2,500 and takes two weeks. A fine-tune is $7,500, fixed scope. Model and machine together start at $25,000. Both fixed numbers are fixed before work starts, so the figure in the brief is the figure on the invoice. Anything outside that shape gets a straight estimate in the first reply, inside two working days.
Does our data leave our building?
Only if you decide it should. The default is training on hardware inside your own boundary, with us on it under whatever supervision you specify. Where that is impractical, the machine is isolated and the run logs come to you with the model. We do not train on your data, read past the task, or hand any of it to anyone.
Can you work with an air-gapped machine?
Yes, and it changes the shape of the project. Data goes in on physical media, the model is trained and installed on the machine, and the machine ships with nothing to phone home to. Calendar time goes up because there is no remote debugging. Some work is only allowed in that configuration.
Do we need to own a server already?
No. Some projects start with the machine and the model together. Others start with a model on our hardware, then decide about buying once the query load is a measured number instead of a guess. The second route is usually the cheaper one. See the reference builds →
What happens when you are gone?
The machine keeps serving. Nothing in it depends on us. You hold the weights, the stack, the pipeline and the documentation, and the handover session exists to make your own team self-sufficient. Support is available after that, priced separately. A project that needs us to keep running has not been finished properly.
Do we need to know CUDA?
No. If your team can run a container and read a log, they can operate what we hand over. If nobody on your side wants to, the support arrangement covers it.
Start with the problem.
Tell us what the model has to do and what is in the way. You get a straight answer on whether a fine-tune fits, what it would take, and what it would cost. Two working days, usually the same day.