Settings
Platform › Settings holds what a platform administrator changes for the whole platform while it runs: limits on model calls, the guardrails fail mode, the currency, the log level, the GPU flavor catalog, connections to cloud model providers, and where tenant vector databases are backed up. Everything else about an installation is set when it is installed or upgraded.
Who can open it
Section titled “Who can open it”Platform administrators only. A person’s own preferences, such as language and theme, are on their profile: see Profile and preferences.
What you see
Section titled “What you see”The header, Settings, with “Platform configuration.”, and four tabs: Platform config, GPU flavors, Model providers and Backups.
Platform config
Section titled “Platform config”Three sections.
Runtime settings
Section titled “Runtime settings”These apply immediately, platform-wide, with nothing restarted. A change reaches every control-plane replica within 30 seconds, and the gateway’s routes within 10 seconds after that. Each change is recorded in the audit trail.
| Setting | Default | Range | What it does |
|---|---|---|---|
| Model silence limit (seconds) | 300 | 30 to 3,600 | A model call that sends nothing for this long is stopped: at the gateway, in agent runs, and in the platform’s own calls. A reasoning model streams its thinking, so an answer still arriving is never stopped. A call that does not stream sends nothing until it is done, so for it this is the whole limit. |
| Model call limit (seconds) | 1,800 | 60 to 14,400 | The longest one model call may run through the gateway, for an application, an editor or an agent, and in Playground, Ask and assistants. |
| Security model call limit (seconds) | 600 | 60 to 3,600 | The longest one model call of a Security assessment, merge request review or investigation may run. The job as a whole has its own limit. |
| RAG relevance floor | 0.5 | 0 to 1 | Cosine similarity below which a retrieved chunk does not ground an answer. 0 turns the gate off. A model can carry its own floor in place of this one. |
| Platform currency | USD | ISO 4217 codes | The currency new price books, billing periods and GPU rates are created in. Only a book in it can be made live. |
| Guardrails fail-open | Fail closed | Fail closed or fail open | When a guardrails scan errors: fail closed blocks the turn, fail open lets it through unscanned. |
| Log level | info |
debug, info, warn, error |
The control plane’s log verbosity, on every replica. |
Two of these ask before they apply:
- Changing the platform currency opens Change the platform currency. New price books, billing periods and GPU rates use the new currency, and only a book in it can be made live. Existing books, periods and priced usage keep theirs.
- Setting guardrails to fail open opens Set guardrails to fail open: prompts and answers then pass through unscanned whenever a scan errors, for every tenant on the platform. Fail closed is the default for regulated workloads.
A load balancer or ingress in front of the gateway has its own idle timeout, and it applies first. For calls that do not stream, set it to at least the model silence limit.
Configuration
Section titled “Configuration”The values the installation was configured with, read-only, grouped as Platform, Models & inference, RAG & ingestion, Billing, Guardrails, Observability & logging and Scheduling & workers. They include the environment, the authentication mode, the serving provider and namespace, the reranker model, the schedule timezone, and the intervals of the platform’s background loops such as node discovery and model reconciliation. Change them in the Olympus resource or the chart values: see Configuration.
Secrets
Section titled “Secrets”Whether each secret the installation needs is Configured or Not set, never its value. They include the database connection, the platform’s master key, the Hugging Face token used for gated models, and the guardrails service. They are provisioned through the installation’s secret store.
GPU flavors
Section titled “GPU flavors”A GPU flavor is a card type, whole or one of its MIG profiles. Tenant capacity envelopes, project quotas, GPU rates and commitments are all counted in flavors.
The GPU flavors table: Card, Type (Whole card or the MIG profile), Memory, Cost rate, Source and Enabled, with Search flavors and Add flavor.
| Source | Meaning |
|---|---|
| Seeded | Shipped with Olympusx AI: H100, H200, B200 and B300 with their MIG profiles, and L40S whole. |
| Discovered | Added by discovery from a registered cluster’s hardware. |
| Manual | Added here. |
- Cost rate is a relative weight, not money: it sets how much a model’s tokens weigh against token budgets according to the GPUs its footprint needs. A model’s token weight is the sum of each GPU’s cost rate times its count. 0 (unrated) adds nothing to a model’s weight; a model on unrated GPUs alone counts each token once.
- Enabled off takes the flavor out of service: new deployment plans cannot use it, and a plan that names it is refused. Running deployments are not stopped.
Both save when you leave the field: move focus out of it after typing.
Add a flavor
Section titled “Add a flavor”- Select Add flavor. Add GPU flavor opens.
- Card and profile: the Card, such as
H100, and MIG profile (optional), such as1g.35gb. Leave the profile empty for a whole card. The step lists the profiles the catalog already holds for that card; a card and profile already in the catalog is refused. - Memory and cost: Memory (GiB), what one card or one slice holds, and the Cost rate.
- Review, then select Add.
Projects can hold quota in the flavor from then on. Price it on Billing: a flavor with no GPU rate accrues hours at no charge.
Model providers
Section titled “Model providers”Cloud providers whose models are offered as LLMaaS: OpenAI, Anthropic, Oracle OCI Generative AI, or any OpenAI-compatible endpoint. Their models are imported into the catalog and served by the provider, not deployed. Prompts to them leave your estate and are processed where the provider’s data residency says.
The table: Name, Authentication, Data residency, Status (Connected, Failed, Not tested or Disabled), Models, and the row actions Test connection, Import models, Edit, Disable or Enable, and Delete.
Connect a provider
Section titled “Connect a provider”- Select Add provider. Choose the Provider, give it a Name, and supply its API key and Data residency. The key is sealed and never shown again.
- Select Test connection. It lists the provider’s models, authenticating exactly as inference will.
- Select Import models and pick the models to offer.
Each model becomes a catalog model named <provider name>:<model id> in lower case. A provider named oci imports meta.llama-3.3-70b-instruct as oci:meta.llama-3.3-70b-instruct, and that is the name tenants call.
Name a provider with letters, digits, ., _ and - only. A name with a space imports nothing. A model id containing / cannot be imported from here; register it from Build › Models › External, which replaces the / with -.
Then offer the model, price it and subscribe tenants: see Offer a model to a tenant. Most providers are more easily connected from Build › Models › External, which creates the connection, imports, tests and offers in one dialog: see External models.
Edit changes the connection and rotates its key. Disable stops the gateway routing to the provider’s models until you Enable it again. Delete erases the stored credential, and is refused while catalog models still use the provider: remove them from the catalog first.
Every enabled provider also has a tile in System health.
The control plane needs outbound HTTPS to each provider.
Backups
Section titled “Backups”Vector database backups: where tenants’ vector databases archive. Each database streams its write-ahead log to an S3-compatible bucket and takes a daily base backup, each under its own path beneath the destination, so it can be restored to any point in time. The platform’s own database is backed up separately, at installation: see Backup and restore.
The tab shows which destination is in use: Databases archive to the destination saved here, Databases archive to the destination set at installation, or No destination: tenant vector databases are not backed up. A destination set at installation is shown read-only under Set at installation (read-only), with the Default retention and Default base backup time.
To set or override it:
- Under Override from the console, enter the Destination:
s3://bucketwith an optional prefix, such ass3://olympus-backups/vectordb. - Endpoint: leave empty for AWS S3; for any other S3-compatible store, its S3 endpoint URL.
- Access key ID and Secret access key. Stored encrypted and never shown again; afterwards the key ID shows its last four characters. Leave both blank to keep the saved keys.
- Select Test: it writes and removes one small object, from the control plane. The bucket accepts writes proves the bucket and keys. Each database’s page shows whether its archiving works.
- Select Save destination.
Within a minute every database with backups on picks it up. A destination saved here overrides the one set at installation for every database; Remove falls back to the installation’s, or, with none, every database stops archiving and cannot be restored to any later point.
Tenants turn backups on or off per database, and set retention and the base backup time, on the database’s page. See Vector databases.
Not set in the console
Section titled “Not set in the console”- The gateway’s public address, the OpenAI base URL developers paste into their editors, is derived from the gateway host the installation publishes. Set it at installation (
gateway.publicUrlin the chart) when the gateway is reached some other way, such as through your own load balancer or a path prefix. The code parser’s settings are installation values too. See Configuration. - Data retention windows are set through the API. See Data retention.
- Identity, sign-in and mail are installation settings. See Identity and sign-in and Email.
- NFS sources for knowledge pipelines need a base directory on the control plane, and the share mounted into the control-plane pods: a pipeline’s NFS path is read relative to that directory, and nothing outside it can be reached.
Related
Section titled “Related”- Billing
- Guardrails and Guardrails concepts
- Clusters for discovered GPU hardware