Is a model registry a deployment?

No. A registry manages model versions and metadata; a deployment makes a selected model usable in an execution environment.

Must every model use a separate network endpoint?

No. Batch or embedded use may be more suitable, although some platforms reserve the term deployment for endpoints.

Can deployment change without retraining?

Yes. Serving code, configuration, resources, and integration can change while learned weights stay the same.

AI Glossary / MLOps and deployment / Intermediate

Model Deployment

Definition

Model deployment is the process of making a trained model available in an operating environment where an application can use it for inference. In the Hopsworks terminology used for this entry's source, a model deployment specifically exposes the model through a network service for client requests. Broader industry usage also includes putting models into batch pipelines and embedded applications.

What it means

A trained model artifact contains the learned capability, but applications also need a way to provide inputs and consume outputs. A deployment connects the artifact with executable serving code, dependencies, configuration, and an interface.
For an online deployment, a client typically submits a request to an endpoint and receives a prediction or generated result. The serving application may validate inputs, obtain features, apply preprocessing, run the model, and format the response.
Keeping a model in a registry is not the same as deploying it. The registry identifies and manages artifacts; the deployment runs an identified model within a particular operational setup. One model version can have several deployments with different resources or configurations.

How it works

Select the model version and its required inference interface. Prepare compatible code and dependencies, including the preprocessing and postprocessing needed to interpret the model correctly.
Configure the target environment and connect the serving application to its required inputs and services. Test representative requests, invalid inputs, resource use, and failure behavior. Then route the intended clients or workload to the deployment through an appropriate release process.
After release, monitor both service behavior and model-related outcomes. Updating a deployment should identify which artifact and configuration changed and how the change can be evaluated or reversed. Capabilities such as autoscaling, access controls, and traffic splitting depend on the chosen infrastructure and its configuration; they are not inherent properties of a model file.

Three practical examples

An online recommendation application can call a deployed ranking model after retrieving the features needed for a request.
An internal classification tool can use a model endpoint shared by several applications, while keeping the model's release process separate from each client's interface.
A deployment test can send the same representative inputs through the candidate serving path and a reference implementation to investigate unexpected differences before wider use.

Think of it this way

Think of placing a specialized instrument into a working laboratory. The instrument needs suitable connections, operating instructions, and a reliable way to receive samples and report results. The analogy explains integration around a capable component. A deployed model additionally depends on software versions, feature definitions, and statistical behavior that require their own checks.

Worked example

Consider an invented online scoring model trained to use two features in this order: recent visits, then days since last visit. Its simple illustrative score is 2 × recent visits - days since last visit.
A client has five recent visits and last visited two days ago. With the correct feature order, the input is [5, 2] and the score is 2 × 5 - 2 = 8.
Suppose the serving integration mistakenly builds the vector in the reverse order, [2, 5]. The same model now returns 2 × 2 - 5 = -1. The endpoint may return a successful technical response, but the prediction is based on an incorrectly interpreted input.
A deployment test should therefore verify field meaning and ordering across the entire path, not merely whether the model loads. A named-field interface can reduce this particular ambiguity, provided the mapping from those names into model inputs is itself correct.
Now imagine two deployments both use the same learned weights. One has the correct preprocessing and one has the reversed mapping. They are operationally different prediction systems despite sharing a model artifact. This demonstrates why a release record should identify serving code and feature schema alongside the model version.

Illustrative case study

In a fictional document-routing project, a team moves its classifier from a notebook into an online endpoint. Initial checks confirm that requests return responses, but representative tests reveal that blank documents are converted into an unexpected default category.
The team defines how empty input should be handled, updates validation, and tests that behavior with the application owner. It records the serving change separately from the unchanged classifier weights.
The case illustrates that deployment quality includes interface behavior around the model. Improving that behavior may require no retraining, yet still materially change the application's results.

Common misconceptions and mistakes

Do not equate uploading an artifact with a complete model deployment. Execution, dependencies, input handling, and application integration still need attention.
Do not assume a platform automatically enables every operational capability it supports. Authentication, scaling, monitoring, and routing require appropriate setup.
Do not assume container packaging guarantees compatibility with every host or accelerator. Test the actual target.
Do not treat matching weights as proof of matching predictions. Preprocessing, feature order, model mode, configuration, and runtime differences may matter. Also, distinguish the broad concept of operationalizing a model from a product's narrower use of deployment to mean an online endpoint.

Business use

Model deployment gives a business application access to a trained capability through a maintainable operating interface. Define expected request volume, response-time needs, input contracts, output interpretation, and support ownership before choosing an implementation.
Track operational measures such as failures and latency alongside evidence about prediction usefulness. A deployment can be technically healthy while producing unsuitable outputs. Clear version records and representative end-to-end tests make it easier to investigate whether a problem comes from the model, serving code, features, or a downstream consumer.

Check your understanding

Two endpoints load identical weights, but one reverses the input-feature order. Are they guaranteed to produce equivalent results?

Answer: No. The model receives different meanings in its input positions, so the complete serving behavior can differ.

Related terms

Deployment
Model Registry
Containerization
model serving
inference endpoint
feature schema
model monitoring
and release management

Learn next

Trace one prediction request from client fields through preprocessing, model execution, and response formatting. Record each version and assumption, then design a test that would reveal a mismatch at each boundary.

Sources

Sources: Hopsworks dictionary, Model Deployment: https://www.hopsworks.ai/dictionary/model-deployment MLflow model-serving documentation, model packaging and deployment concepts: https://mlflow.org/docs/latest/ml/deployment/

Previous: Model-Dependent Transformations Next: Model editing