Hi @DBXDeveloper111 ,

A Model Serving endpoint is the “service”: it exposes a REST API and handles autoscaling on serverless compute. You don’t manage clusters for online inference. Each endpoint hosts one or more served entities (models/functions), which you reference and route to by name and version. You configure these in the endpoint’s served_entities section (via UI, REST, SDK, or MLflow Deployments). A separate “service model” is not required. Pre/post‑processing can live inside the model wrapper (MLflow pyfunc) or as a function/agent deployed to Model Serving if you need to orchestrate multiple backends.

• Use multiple endpoints when models have different SLOs, hardware (CPU/GPU), scaling, or blast‑radius needs; endpoints are serverless and autoscale independently.
• Use a single multi‑model endpoint for A/B or canary when models share similar runtimes; split traffic or hit a specific served model path; you can’t mix different model types in one endpoint.
• Add an orchestrator only if a single API call must coordinate multiple models/tools; deploy a simple function/agent on Model Serving and keep the client contract stable.

You only need a separate service layer if you’re coordinating multiple models/tools or enforcing cross‑cutting policies that don’t fit neatly in one model’s code. In that case, deploy an orchestrator function/agent to Model Serving and keep the client contract stable.