Platform administration
A platform administrator runs the installation itself: the clusters models are served on, the model weights and serving runtimes the platform holds, the tenants it hosts, what they are billed, and the platform-wide settings. Tenant admins run what happens inside one tenant; the platform administrator decides what every tenant can draw on.
Who is a platform administrator
Section titled “Who is a platform administrator”A platform administrator is an account whose sign-in token carries the platform-admin role. It is not one of the five tenant roles and is not granted from Govern › Users: it is given in your identity provider.
- The first one is created at installation. With the built-in identity service, the installation names the first platform administrator’s email address and generates a temporary password for it. See First sign-in.
- Further ones are added in the identity provider, by giving an account the
platform-adminrole. See Identity and sign-in. - A platform administrator reaches every tenant. On a tenant-scoped page, such as Govern › Users or Keys and budgets, a tenant picker chooses which tenant the page acts on.
A tenant admin cannot open any page in the Platform section, and the API refuses the platform’s routes to them with 403, reason platform_only.
The Platform section
Section titled “The Platform section”The console’s rail has two sections. Workspace is the work a tenant does; Platform is shown only to platform administrators.
| Group | Page | What you do there |
|---|---|---|
| Infrastructure | Clusters | Register clusters, put GPU nodes in the serving pool, read GPU telemetry, partition GPUs, connect a cluster’s image registry and bastion |
| Infrastructure | System health | See whether every platform dependency answers, and how often it has over the last 30 days |
| Model serving | Model registry | Import model weights and package them so clusters serve them without internet access |
| Model serving | Runtimes | Add, inspect, recommend and disable the serving runtimes deployments run on |
| Customers | Tenants | Create tenants, grant them capacity on clusters, subscribe them to models |
| Customers | Projects | Create and delete projects, and set each project’s quota on a cluster |
| — | Billing | Price books, negotiated rates, GPU rates, commitments, billing periods and statements |
| — | Settings | Runtime settings, GPU flavors, cloud model providers and backups |
Some platform work is done outside these pages:
- Model catalog. Adding a model to the catalog, removing it, and offering it as LLMaaS happen on Build › Models, where a platform administrator sees the catalog actions tenants do not. See The model catalog and External models.
- Identity, mail and backups of the platform database are installation settings. See Identity and sign-in, Email and Backup and restore.
- Data retention is set through the API. See Data retention.
Setting up a new installation
Section titled “Setting up a new installation”An empty installation opens on Welcome to Olympusx AI, a checklist of what the installation still needs. Each step has a button to the page where it is done and shows Done once the platform counts it. It reads its state from the platform, so closing the browser halfway loses nothing. Explore on my own leaves it; while setup is unfinished, the console’s home page offers it again.
| Step | Where it is done |
|---|---|
| Register a cluster | Clusters. An installation made with the operator registers its own cluster and starts with this step done. |
| Put GPU nodes in the serving pool | Clusters. No node is in the pool until you choose. |
| Create the first tenant | Tenants |
| Seed the model catalog | Build › Models. A production installation starts with an empty catalog: which models the platform could serve is your choice. |
| Offer models as LLMaaS | Build › Models. Nothing is offered by default. |
| Grant a model to a tenant | Tenants |
| Serve a model | Build › Models, on GPU or CPU. A model a cloud provider serves needs no deployment. |
| Issue an API key | Govern › Keys and budgets |
| Publish a price book | Billing. The platform ships example market rates as a draft; making them live is your decision. |
The GPU step blocks serving only where a cluster has GPU nodes: a cluster without them serves on CPU, which needs no node in the pool. Once a cloud provider serves a model in the catalog, the first two steps no longer block, and an installation that serves only through providers completes without a cluster.
What to watch day to day
Section titled “What to watch day to day”- System health for components that are down or degraded. A component down for three samples in a row raises a platform notification.
- Clusters for clusters that are Disconnected or in Error, and for drift in GPU partitioning.
- Billing for periods awaiting issue and commitments due for renewal within 60 days.
- Your own monitoring, for the alerts the platform ships. See Monitoring and alerts.