What Is a Model Endpoint for Enterprise Inference

Quick Answer: A model endpoint is the stable, authenticated address where applications send inference requests to a pinned model version. It is not the notebook that produced the weights, and it is not the GPU by itself. If you cannot name the URL, the hash, the auth, and the rollback, you do not have an endpoint yet.

A model endpoint is a versioned inference interface that accepts authenticated requests, runs a pinned model on allocated compute, and returns outputs under an explicit service level. Teams use it to put a model into a product path. They do not use it as a synonym for “we have GPUs.”

This page defines the object. It is not a serving-framework catalog and not a how-to-choose-a-provider guide. If you already know the definition and need placement or limits, use those operating pages instead.

What objects sit behind the word endpoint?

Callers should depend on the endpoint name and a version pin. They should not depend on a hostname that changes when you move from one GPU to eight. If your app stores a node IP, you built a pet, not an endpoint.

What must be true before you call it production?

Auth is on. Anonymous GPU time becomes a public utility. The schema is documented, including streaming versus non-streaming and the error codes for overload. The model hash is pinned, and a second pin exists for rollback. Logs can reconstruct who called, when, and which version answered, without writing secrets they should not keep.

An SLO exists in user units: availability of the contract, time to first token, or time to complete, depending on the product. GPU SM% is not an SLO. If you cannot say what a caller should do on 429 or 503, the contract is unfinished.

The compute under the endpoint is allocated on purpose. Shared leftover capacity makes the contract a rumor. Exclusive GPUs on private AI infrastructure are how regulated teams keep prompts and weights inside a named boundary while the URL stays stable for applications.

How is an endpoint different from nearby ideas?

Model serving is the discipline and the software. The endpoint is the product-facing object that serving exposes. You can serve in a lab without an endpoint. You should not expose an endpoint without serving discipline.

A batch job that scores a file overnight is inference. It is not an endpoint unless something calls it request by request under a contract. A notebook “predict” cell is not an endpoint even if it uses the same weights. Deployment is the act of moving a version onto the replica set. The endpoint is what remains after that act succeeds.

OpenAI-compatible paths are still endpoints. Compatibility is a schema choice. It does not remove pinning, auth, or rollback. If the compatibility layer hides the hash, you will not know what changed when answers drift.

Who should own the endpoint after launch?

Product owns the contract with callers. Platform owns the replica set, the pins, and the GPU quota. Security owns auth and log retention. Those three names go in the runbook. An endpoint with no owner becomes a ghost URL that still burns cards.

OnePlus Platform, OneSource Cloud's AI orchestration platform, can list the endpoint, the pin, and the quota in one place so ownership is visible. Visibility is not ownership. Someone still has to approve a hash change.

OneSource Cloud hosts exclusive inference in U.S. facilities, including Texas / Richardson, when the endpoint must stay off shared tenancy. Managed AI infrastructure can watch replicas. It does not invent the schema. If the callers are in healthcare or fintech, attach the data-class note to the endpoint record and use healthcare or fintech paths only when those classes are real.

FAQ

Can one model have several endpoints?

Yes. A canary URL, a batch URL, and a low-latency URL can share weights and differ in SLO, auth, or limits. Give them different names. Sharing one URL with hidden flags is how callers disagree about what they called.

Is a model endpoint the same as an API key?

No. The key identifies a caller. The endpoint is the thing being called. One endpoint can have many keys. One key should not point at an unnamed hash that changes under it.

Do we need GPUs to have an endpoint?

You need whatever compute the model requires. Small encoders may sit on CPU. Large decoders usually sit on exclusive GPUs. The definition does not change. The replica set does.

What is the first sign we do not actually have an endpoint?

Nobody can roll back a hash without rebuilding a notebook. Or callers use a raw node IP. Or there is no auth. Any one of those is enough. Add the missing piece before you add traffic.

Does this page tell us which serving framework to use?

No. Framework choice is a later operations decision. The endpoint contract should survive a framework change if the schema and pins stay honest. Do not bake a server brand into the definition.

Summary

A model endpoint is the versioned, authenticated contract in front of a pinned model and its replicas. Serving software, GPUs, and notebooks are supporting objects. Production means auth, pins, rollback, logs, and an SLO in user units.

Keep the URL stable and the hash explicit. Run the replicas on exclusive compute when prompts cannot live on a shared host. OneSource Cloud can provide that GPU boundary. The contract text still belongs to the team whose applications call the name.