MLOps Consulting: Models Into Production

The modelling was never the hard part

Most machine learning projects do not fail at the modelling stage. A competent team gets a model to hit its target. The failure happens in the year afterwards, quietly, in three places.

If two of the three below describe your situation, the bottleneck is operational rather than scientific, and more data science will not fix it.

Nobody can rebuild the model that is running

A model is in production and no one can say, from records alone, which data and which code produced it. The notebook has moved on, the dataset has been appended to, and the person who trained it remembers roughly what they did.

This is survivable until someone asks a question you must answer: a regulator, a customer, or your own team trying to work out why last month was worse. At that point an unreproducible model is not an asset, it is a liability you are still paying to run.

Accuracy decays and you hear about it from a customer

Models degrade because the world moves. New suppliers, new equipment, a changed process, a different camera angle. None of it announces itself.

Without drift monitoring the first signal is a complaint, and by then the model has been wrong for weeks. Worse, the people downstream have usually noticed before you did and have quietly started ignoring the output, which means the system is already dead and still costing money.

Getting to production takes longer than building it did

Retraining is a person rather than a pipeline, and that person has other work. Moving a model from a notebook to the plant takes a quarter. Models at the edge need a site visit to update.

The cost is not the delay itself. It is that the cycle time determines how often you can afford to improve anything, so a slow path to production caps the value of every model you will ever build.

What the engagement covers

We build the path from data to a monitored deployment, and then hand it over. In practice that means five things, in this order:

Reproducible training. Versioned data, versioned code, versioned models, so any deployed model can be rebuilt from its record.
Automated deployment. A model reaches its target, cloud, plant server or edge device, through a pipeline rather than a person.
Monitoring that means something. Input drift, output distribution and business metrics, with thresholds your operators agreed to, not defaults.
Retraining triggers. Defined conditions under which a model is retrained, evaluated against the incumbent, and promoted or rejected.
Explainability on the record. SHAP, LRP or LIME output attached to decisions where a regulator or a customer may ask.

The stack we work in

Open frameworks, so the pipeline outlives the engagement and your team can operate it without us:

Orchestration and training: Kubeflow, Argo Workflows, Kubernetes.
Tracking and registry: MLflow and model registries, with data versioning alongside.
Edge delivery: KubeEdge, EdgeX Foundry, Fledge, with ROS 2 where robots are involved.
Privacy-preserving training: TensorFlow Federated and PySyft, where data cannot be pooled.
Industrial integration: OPC UA and Modbus into existing DCS, PLC and SCADA.

If you already run something that works, we keep it. Replacing a functioning tool to match our preferences is billable time that buys you nothing.

Three shapes an engagement takes

Typical engagements, with the scope fixed before each one starts
Shape	When it fits	Output	Duration
Audit	You have models and a suspicion that the operations around them are the problem	Written assessment, architecture sketch, prioritised gaps, go or no-go	About 2 weeks
Pipeline build	One model matters enough to industrialise properly	Reproducible training, automated deployment, monitoring, handover docs	8-12 weeks
Operate and extend	The first pipeline works and the rest of the portfolio should follow	Additional models onboarded, your team trained to run it	Ongoing, as needed

What we will argue against

Some of the work clients ask for is work we will tell them not to buy. A platform migration before there is a single model worth migrating. A feature store for three features. Retraining on a schedule when nothing about the process changes month to month. A dashboard nobody has agreed to look at.

The audit exists partly to say these things in writing, before there is a budget defending them.

Questions we get asked

Do you replace our data science team?

No. We work alongside it. The usual split is that your team owns the models and the domain, and we own the path from a training run to a monitored deployment. Handover documentation is part of the engagement, because a pipeline only your consultant can operate is a liability.

We are on a single cloud. Does that matter?

Not much. The tools we use run on managed Kubernetes anywhere, and on your own hardware. We avoid provider-specific services where an open equivalent exists, so that the pipeline you end up with is portable.

Our model works. Why would we need MLOps consulting?

You may not. The question is what happens in six months: whether anyone will notice if accuracy drops, whether you could reproduce today's model from today's data, and how long a retrained version takes to reach production. If those answers are comfortable, keep your money.

Can this run without sending data to a cloud provider?

Yes. On-premise and air-gapped deployments are normal in the plants we work in. Where several sites cannot pool data at all, federated learning trains a shared model without the raw data leaving each site.

How do you charge?

Fixed scope and fixed price per stage: the audit, then the pilot, then any roll-out. You approve each stage before it starts, with the written output of the previous one in hand.

MLOps consulting: models that survive contact with production

Describe one stuck model