Scientific computing and research

Run simulation, analysis, and research workloads on Quake AI. You operate job schedulers, simulation binaries, and result stores; Quake AI provides CPU-only Compute, Block Storage, Object Storage, private networking, and optional self-managed Kubernetes. Quake AI flavors are AMD EPYC with no GPU option, which fits CPU-bound simulation and post-processing; see the compute FAQ for flavor details.

What this is for#

Research teams run batch simulation, analysis, and post-processing on infrastructure with predictable cost and no per-gigabyte data-transfer charges. Quake AI provides CPU compute for workers, Block Storage for scratch, and object storage for inputs and results; you operate the scheduler, simulation binaries, and result stores. The outcome is a self-operated CPU batch environment, deployable from validated OpenTofu templates and their companion tutorials.

Reference architecture#

Download diagram: SVG, PNG, and PDF.

The base is the Render farm worker template: a scheduler or login node and CPU batch workers behind a floating IP. The S3 Storage with ACLs template adds the bucket for input decks and result archives. Attach Block Storage scratch volumes to the workers as needed, and a Kubernetes cluster is the alternative when you schedule batch work on a self-managed cluster.

1. Researchers. Researchers and automation submit jobs to a scheduler or login node.

2. Scheduler or login node. A Compute instance runs the job scheduler (Slurm, PBS, or a workflow engine) or a login node. The Render farm worker template provisions the scheduler node and workers together; a Simple VM is the alternative for a standalone runner or login host.

3. Batch compute workers. Simulation and analysis jobs run on the Compute workers, optionally orchestrated on a self-managed Kubernetes cluster from the Kubernetes cluster template.

4. Scratch storage. Working data and intermediate files use Block Storage volumes attached to the workers.

5. Inputs and results. Input decks, mesh files, reference datasets, and result archives live in S3-compatible Object Storage.

Services involved#

Get started#

• Simple VM template and its deploy tutorial: single-instance OpenTofu pattern for standalone simulation runners or login nodes.
• Kubernetes cluster template and its deploy tutorial: self-managed cluster for batch jobs you deploy with manifests, operators, or workflow engines.
• Upload objects to Object Storage: stage input decks, checkpoints, and result archives in the bucket your template provisions.
• OpenTofu template library: browse validated IaC starting points for VM and cluster layouts.

Estimate the cost#

Migrating an existing scientific computing / HPC-style workload?#

Move a simulation, analysis, or research pipeline that already runs on AWS EC2 and S3, Azure VMs and Blob, Google Compute Engine and Cloud Storage, Slurm or Kubernetes batch queues on Amazon EKS, or another hyperscaler fleet. The outcome is the same workloads on Quake AI CPU compute with input datasets, job definitions, and result stores cut over in a controlled order.

Follow this cutover path. Each step links an existing migration page; this section composes those pages into a workload-shaped sequence rather than duplicating their steps.

1. Map your source provider. Start with the concept-translation page for your current cloud: Coming from AWS, Coming from Azure, Coming from GCP, Coming from DigitalOcean, or Coming from Hetzner.

2. Stand up the target shape on Quake AI. Pick the greenfield template that matches how you run jobs after migration: Simple VM for dedicated runners or a small login plus worker layout, or Kubernetes cluster when you schedule batch work on a self-managed cluster.

3. Move compute workloads. Rebuild or migrate simulation nodes and batch workers with Migrate from EC2 (or the matching compute migration page for your source provider). For Kubernetes-hosted batch services, follow Migrate from EKS.

4. Move object and dataset data. Sync input decks, mesh files, reference genomes, and checkpoint objects with Migrate from S3 (or the matching object migration page for your source provider).

5. Cut over job submission and result access. Stage the Quake AI scheduler or API endpoint on a private hostname or an API gateway with a floating IP, run validation jobs against migrated inputs, then switch researchers and automation to the new submission URL and result-store base path.

Workload-specific cutover callouts#

• Large dataset transfer. Plan bandwidth and resume behavior for multi-terabyte inputs and archives. Use the object migration page's sync tooling, validate checksums on a sample of files, and keep read access to the source bucket until downstream jobs finish on Quake AI.
• Job scheduler and runner rebuild. Slurm, PBS, Airflow, Argo Workflows, or custom runners rarely lift verbatim across clouds. Recreate queues, resource limits, and container images on the target template, then replay a representative job mix before you retire the source cluster.
• Result store endpoint move. Update job scripts, notebooks, and CI pipelines to write and read from the Quake AI Object Storage endpoint and paths you provisioned. Confirm permissions, lifecycle rules, and any signed-URL behavior match what downstream analysis expects.
• CPU-only workloads. CPU-bound simulation, preprocessing, and post-processing fit Quake AI (compute FAQ). GPU-accelerated simulation or training that requires CUDA at production scale needs accelerators outside this flavor catalog.

Considerations and limits#

• You operate the scheduler and binaries. Quake AI provides compute, network, and storage; the scheduler, simulation software, and result stores are yours under the shared responsibility model.
• CPU-only compute. Compute is AMD EPYC with no GPU option (compute FAQ). CPU-bound simulation and post-processing fit; CUDA workloads need a different hosting path.
• Flat egress. Quake AI applies a no-egress-fee policy for outbound transfer, which suits large result-set downloads.
• Three US regions. All current regions are in the United States.
• No managed HPC scheduler. Slurm, PBS, or workflow engines run on Compute you operate; Quake AI has no managed batch-queue service.
• Compliance posture. Quake AI holds SOC 2 Type I and Type II attestations and SOC 3. See Compliance and certifications for the platform scope.