At a glance
- What you get: open models on GPUs assigned to you, scaling down to zero when idle.
- What Rackspace runs: the GPUs, the cluster, the serving runtime, model weights and the gateway.
- What you decide: which models, how they scale, and who can use them.
Deployments on GPUs assigned to you
A deployment is a model you've chosen, running in one of your Tenants. You get your own endpoint, served from GPU capacity assigned to your Organization rather than a pool shared with other customers.
- Create, scale, update, delete. Set a fixed number of replicas, or let a deployment scale with demand, down to zero when idle.
- Watch it run. Each deployment shows its status, logs and metrics in the console. A deployment that is still starting tells callers to retry rather than failing silently.
- Serve adapters. Add fine-tuned adapters to a deployment, and they're served alongside the base model.
- Try it first. The Playground lets you chat with a deployment from the console before you write any code.
The model catalogue
- Rackspace-curated models. Rackspace adds models to the platform catalogue, pinned to an exact version, with deployment settings prepared for the hardware they run on.
- Your own choice of open model. You can add a public model from Hugging Face to a Tenant. Only that Tenant can see and deploy it, and it's marked as customer-managed rather than Rackspace-qualified.
- Chat, embeddings and reranking. The catalogue covers generation, embedding and reranking models.
What "Rackspace runs the infrastructure" covers
| Rackspace runs | You decide |
|---|---|
| GPU servers, the cluster and the platform software | Which models to deploy, and in which Tenant |
| Model serving: the inference runtime, the request router and scale-to-zero | How many replicas each deployment runs, or how it autoscales |
| Fetching, pinning and caching model weights | Which adapters each deployment serves |
| The API gateway, sign-in, metering and the activity trail | Who in your Organization can deploy, call and manage models |
| Rolling updates when a platform model or runtime setting changes | When to retire a deployment |
Availability and support
We commit to 99.9% availability per deployment, with service credits when we miss, and to restoring service within an hour after a serving failure. Every incident has one named owner.