Saturn Cloud

Saturn Cloud is a control plane for AI Infrastructure & Development. It installs on graphics-processing-unit (GPU) capacity an operator already runs and gives that operator’s customers managed training jobs, interactive workspaces, and AI Model Serving & Inference. The operator keeps the hardware, the capacity contract, and the bare-metal vendor. Saturn Cloud is the console, the scheduler-facing layer, and the meter.

Key Capabilities

• Workspaces: A Jupyter server opens JupyterLab on a central-processing-unit (CPU) or GPU machine. The user sets disk size, instance size, a container image, and startup packages through Conda, pip, or apt. Attached Git repositories clone when the resource starts. SSH can be enabled. A Dask cluster attached to the server uses the same image. Hosted Pro and Enterprise accounts can shut the server off after an idle interval.
• Token Factory fine-tuning: A job takes an allow-listed base model, a dataset in ready status, and hyperparameters: learning rate, epochs, effective batch size, maximum sequence length, and optional LoRA rank and alpha. The user does not supply a training script or an image. The platform renders the trainer configuration, picks a micro-batch that fits the GPU, and runs distributed training on a multi-GPU instance without extra settings. Status moves through pending, running, stopping, stopped, completed, and error. A completed job registers one checkpoint. A failed job registers none. The job view shows training and evaluation loss, learning rate, throughput, and GPU use, and it does not echo environment variables or the image.
• Serving: A user can start a deployment with vLLM, a GPU instance, and the saturn-python-llm image. Token Factory also specifies an inference endpoint that mounts a checkpoint read-only, loads it, and exposes a stable HTTP address with a health check. Create parameters in the API are instance size, optional fp8 or int8 quantization, and route visibility of org or owner. The endpoint documentation describes this as the intended serving path and tells the operator to confirm it in that installation’s release notes. While an endpoint is running it holds the GPU whether or not requests arrive, and the checkpoint cannot be reclaimed until every endpoint using it has stopped. The metrics view tracks request rate, latency, time to first token, token throughput, and GPU use.
• Operator clusters: Through the bare-metal-as-a-service API, Saturn Cloud provisions servers, virtual machines, a Kubernetes cluster, or a Slurm cluster for a tenant. The product site describes each customer as a separate cluster, with its own InfiniBand P_Key and its own storage namespace on VAST Data, Weka, or an existing filesystem. Schedulers, etcd, and admission webhooks are not shared across tenants. Named bare-metal partners include Mirantis k0rdent, Red Hat OpenShift, and Rafay.
• Metering: GPU-hours are tagged with user, project, and tenant. The operator site describes per-token metering for inference on the same pipeline, with chargeback and export through an API and a Snowflake view. Contract terms for committed, on-demand, and reserved use are applied in that billing path.

Audience & Use Cases

• Audience: GPU-cloud and neocloud operators who already hold hardware, and the data scientists and application teams who then train and call models on that installation.
• Use Case: An operator stands the control plane up on existing Kubernetes or bare metal, white-labels the console on the operator’s domain, and lets a customer submit a fine-tuning job or open a Jupyter workspace. A finished checkpoint is what a later inference endpoint serves. Install is documented for Amazon Web Services, Google Cloud, Microsoft Azure, Oracle Cloud, Nebius, and Crusoe, and as a Terraform plus Helm operator on the operator’s own cluster.

Technical Specifications

• Install: On the Crusoe reference layout, Terraform creates the cluster and node groups and installs saturn-helm-operator, which reconciles platform components into Helm releases. Core services in that layout are Atlas (API and PostgreSQL), an auth server that issues RS256 JSON Web Tokens, Traefik ingress, an SSH proxy, and a cluster autoscaler. Logging and metrics use Fluent Bit and Prometheus.
• Identity: Enterprise single sign-on connects through Auth0 to an identity provider. The Okta guide uses OpenID Connect with the openid, email, profile, and groups scopes. Group membership can drive entitlements. Sign-in authenticates only. A user still needs an invite. Automatic provisioning of every identity-provider user is not the default.
• GPUs: The console lists NVIDIA Hopper and Blackwell sizes, including H100, H200, and B200. Hourly rates are published with those sizes. The sample team invoice on the marketing page is an illustration, not a measured customer bill.
• Endpoint caveat: Confirm Token Factory inference-endpoint availability against the release notes for the installation. Direct vLLM deployments and fine-tuning jobs are documented as user workflows without that caveat.