Models and deployments

A model in Olympusx AI passes through four states, and each is a separate decision by a separate person: it is in the catalog, it is offered, it is granted to a tenant, and it is deployed for that tenant. This page explains each step, why they are separate, and how models that a cloud provider serves fit in.

The four steps

Step	Who decides	What it means
In the catalog	Platform admin	The platform knows the model: its weights are packaged in your registry, or a connected provider serves it. The catalog is shared by every tenant. See Model registry.
Offered	Platform admin	The platform makes the model available to tenants, as LLMaaS, with a token weight for budgets and a price in the price book. What a platform offers is a commercial decision.
Granted	Platform admin	One tenant is subscribed to the model, with optional daily and monthly model budgets. From then on the tenant’s keys may name it.
Deployed	Tenant admin	A model server for that tenant runs the model in one of the tenant’s project namespaces, on a cluster where the tenant holds capacity.

The gateway answers a request only when every step holds for the caller’s tenant. A tenant that is granted a model with no deployment gets 404 model_not_deployed; a tenant that has a deployment of a model it is no longer granted gets 403 model_not_granted.

Why the steps are separate

Weights in, before anyone can use them. Bringing weights into an air-gapped network is a platform decision with a security review behind it. The catalog records what arrived and where it came from.
Selling is not running. Offering a model does not consume a GPU; deploying one does. The platform decides what is for sale; the tenant decides what to run on the capacity it was given.
Capacity is the tenant’s to spend. A deployment draws on the tenant’s capacity envelope on that cluster, and the platform refuses a deployment that would not fit. A deployment never draws on a token budget.

Deployments

A deployment is one model, served for one tenant, in one project namespace on one cluster.

GPU or CPU. A deployment runs on GPU nodes in the serving pool, on a whole GPU or a partition of one, or on CPU nodes. Before you deploy, Olympusx AI checks that the model’s weights and working memory fit the hardware you chose, and says what does not fit.
The runtime is the platform’s choice. Platform administrators choose which serving runtimes the platform offers and which one is recommended for each kind of model. Tenants do not pick runtime images. See Runtimes.
The tenant’s network rules apply. The model server runs under the project’s quota and network policies.
The key never reaches it. The gateway strips the caller’s Olympusx AI key before forwarding a request. The model server sees only the request.

See Deploy a model.

Kinds of models

Kind	What it does	How it is called
LLM	Generates text, and calls tools if the model supports it	`POST /v1/chat/completions` or `/v1/completions`
Embedding	Turns text into vectors, for knowledge collections and search	`POST /v1/embeddings`
Reranker	Scores documents against a query, to order retrieved passages	The reranking endpoint, see Embeddings and reranking

The catalog records two capabilities that decide where a model can be used: whether it can call tools, which an agent with tools or skills needs, and its context window.

External models

A platform administrator can connect a cloud model provider (OpenAI, Anthropic, Oracle OCI Generative AI, or any OpenAI-compatible endpoint) and register its models in the catalog. An external model is offered and granted like any other, and needs no deployment: granting it is enough.

The gateway authenticates, budgets, scans and meters a call to an external model exactly as it does a local one, then calls the provider with the platform’s credential. The tenant’s key is never sent to the provider.

See External models.