Resources
Putting a model into production
A model in production serves decisions continuously. It therefore needs a sized inference service, drift monitoring, a retraining cycle and a running cost known in advance.
What going to production adds
A model exposed as a service receives real-world data, which changes. Its performance is therefore monitored continuously, on indicators compared with those from training: that is drift detection. When the gap crosses a threshold, retraining starts with recent data, and the new model is compared with the old one before switchover. Add to that precise costing: the cost per inference call, multiplied by volume, decides the chosen architecture.
- An inference service sized on the expected call volume
- Drift monitoring, compared with training indicators
- A retraining threshold set before go-live
- A systematic comparison between outgoing and incoming model
- A known cost per call, which makes the architecture trade-off possible
Four operational trade-offs
Local or cloud processing
Call volume, acceptable latency and data sensitivity decide. The calculation comes before the purchase.
Real-time or batch
An overnight batch run costs a fraction of a permanent service, when the decision allows it.
Own model or third-party service
Reversibility is prepared from day one: open exchange formats, data kept on your side.
Retraining frequency
It follows from the observed drift speed, never from a calendar fixed in advance out of habit.
The volume devoted to operations
- hours on industrialisation
- 140
- hours on compute cost
- 100
- hours on language models
- 200
Inference service, drift, retraining, cost.
Sizing, optimisation, local or cloud.
Fine-tuning, evaluation, inference cost.
Go-live questions
How is drift spotted?
By comparing the service's indicators with those measured at training: input distribution, response rate per category, performance on a regularly annotated sample. Crossing the threshold triggers the planned retraining.
Should the previous model be kept?
Yes, and it serves twice: as the comparison point that validates the new one, and as an immediate path back if the switchover reveals a gap. It is the same reasoning as for an application version.
Who operates a model day to day?
The team that operates the rest of the service, with the same logging and monitoring tools. The industrialisation block teaches exactly how to make a model operable by an ordinary operations team.
Explore next
- Data governanceData ownership, life cycle, hosting, retention, reversibility and vendor dependence: framing governance.
- Personal dataPurpose, legal basis, minimisation, retention, security and individual rights: the processing register in practice.
- Industrial site safetyHSE management system, work permits, co-activity, internal audit, leading indicators and safety culture: a site's complete arrangement.
- Assessing a riskHazard, exposure, criticality, risk register and the hierarchy of prevention measures: risk assessment applied to a real workstation.
- Incident investigationFact gathering, causal tree, root causes, action plan and lessons learned: conducting an investigation after an incident or a near miss.
- Cybersecurity reflexesIdentities and permissions, updates, tested backups, network segmentation and awareness: the measures that protect most for the least effort.