PyTorch model development
Most teams who ask for a model of their own do not need one, and hearing that early is worth more than a fast start. Where you do need one, PyTorch is where the published research and the ready-made starting points live. The training was never the hard part. Proving the thing works, and keeping it working, is.
01Capabilities
The four times a trained model is still the right answer
This is the page for training a model rather than calling somebody else's, and that distinction is the whole decision. Training commits you to data, to measurement and to maintenance, so it should be chosen deliberately. The delivery side of it is AI and machine learning development.
- Repetition
The same small judgement, thousands of times a day
When one narrow decision gets made constantly, a small trained model usually beats a general-purpose service on both cost and speed, and it can run wherever you need it. Training only a thin layer keeps the cost of getting there modest.
- Pictures
Photographs taken by people at work
Damage and defect spotting, reading labels, counting things. Warehouse and yard photography of the kind behind our warehouse systems work looks nothing like a tidy dataset, and closing that gap is the project rather than a preliminary.
- Prediction
Numbers a person has to act on
Demand, arrival times, pricing and priority, including the automotive and fleet cases where a prediction feeds an operational decision in seconds and somebody has to explain it afterwards to a customer who disagreed.
- Handover
Research code turned into a running service
A notebook that works on one laptop, turned into something with pinned versions, repeatable behaviour, tests, batching and a way back. This is ordinary software engineering, and it is where most model projects quietly stall.
02Fit
Talking you out of training, and when that fails
Training is the expensive answer, so the first job of this table is to send you somewhere cheaper wherever cheaper works. Where it really is the right answer, PyTorch is our default, because the published research, the ready-made starting points and the tooling all live there. Five of the six rows below end somewhere other than a training project with us.
| Your situation | What we recommend |
|---|---|
| A narrow task, examples you own with the answers marked, and volume that pays for it | Train itThe smallest model that clears your number, with the test harness handed over as a deliverable alongside the model itself. |
| You have not yet tried a rented model on the problem | Do that firstA call to the OpenAI API is an experiment you can abandon on Friday. A trained model is an asset you own on Monday and every Monday after. |
| Rows and columns, a few hundred thousand of them, and a business number to hit | Not a neural networkGradient boosting trains in minutes, explains itself to whoever signs off the decisions, and on this shape of data it usually just wins. |
| No examples with the answers marked, and no realistic way to get any | Not a model projectGetting the answers marked and building the data pipeline is the project. Calling it a modelling project spends a quarter finding that out. |
| It has to run on a phone or an embedded board, and the hardware is fixed | Weigh the alternativeThe on-device path here is real and improving, and it is younger, so we weigh it honestly against TensorFlow with LiteRT. |
| Reasoning over documents, or anything open-ended in writing | Different pageTraining a small model to reason is the expensive route to a worse result. Rent one instead, see Claude or Gemini. |
Scope
What we own on model work is the number that decides success and the simple rule it has to beat, a test that cannot cheat, the path into production, and the honest verdict when the model has not earned its place. A model that beats a well-tuned rule by a hair and costs a graphics card to run is a result we would tell you to shelve. unicrew has been building software since 2012, with 100+ senior in-house engineers across six countries, under an ISO 27001:2022 certified information-security management system.
03Delivery
Two steps before anybody trains anything
The order is deliberate. Half of this sequence happens before a single model is trained, and it is the reason these projects either converge or wander for two quarters.
- Agree the number, and the dumb rule it must beatOne measure that decides success, plus the simplest possible rule as the thing to beat. Plenty of proposed models fail to beat a well-tuned rule, and learning that in week one is a win rather than a disappointment.
- Fix the split, then go hunting for cheatingSplit by time or by customer, whichever matches how the model will really be used, and look deliberately for a column that quietly contains the answer. A model that scores brilliantly for that reason is the most common fault we find in inherited work.
- Train the smallest thing that could workStart from a ready-made model, train only a thin layer before touching everything, and stop once the number is cleared. Size is a cost you pay on every single request, forever, long after the training bill is forgotten.
- Ship it behind an interface, then watch the inputsA contract that hides the framework, a period running quietly alongside real traffic, and monitoring on what goes in rather than only on what comes out. Inputs drifting is what kills models silently. It goes through our AI QA and evaluation practice.
04Stack
What a trained model needs around it to ship
The pieces that turn a set of weights into something operable, each with its own page if that is the decision you are actually making.
05Questions
Asked before committing to a model of your own
Six that decide whether this should be a project at all, answered the way we would answer them live.
Yes, and we would ask one thing in return: that the test harness is inside the scope. Supplying somebody to train a model against an undefined target is how you end up with weights nobody trusts. An architect outside the delivery team reviews the design, model and pipeline testing goes through our AI QA and evaluation practice, and capacity is managed teams.
Four things decide it: volume, how fast the answer must come, where the data may sit, and how narrow the task is. Lots of one repetitive judgement, a tight time budget, data that cannot leave, or a task you can describe precisely all push towards training. Low or unpredictable volume, a task that keeps changing, or a need for general knowledge push towards renting. Prove it works rented first.
PyTorch in almost every case, and the reason is ecosystem rather than design. Published research, ready-made starting points and community recipes arrive here first, so you spend less time translating and more on your actual problem. We would only argue for TensorFlow where you already have an estate in it, or where running on a device is the constraint that dominates everything else.
Usually not. Rented capacity covers most training work, including the cheaper interruptible kind for anything that can restart, and owning machines only pays off at a level of use few teams reach. The exception is data that is not allowed onto a public cloud, in which case the hardware decision follows the compliance decision rather than the cost one, and the arithmetic changes completely.
A scoping call with an engineer, and we would rather hear about the decision the model has to support than about the model you have in mind. If you have data, a sample plus a description of how it was collected is worth more than a specification. You get back a written view on whether a model is justified and what it should be held to. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, offered once the first read is done, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer. The rate depends on the seniority mix, so it is quoted rather than listed.
Considering a custom model?
Tell us what decision the model is supposed to make, what data you already have, and how often that decision gets made. You will get an engineer's read on whether training is justified, and the cheaper answer if it is not.