Compute¶
Compute is part of the experimental method. Accelerator type, runtime, filesystem, and network access can all change what a run can do and whether someone can reproduce it later.
Open Organization settings → Compute to see where experiments can run. Managed on-demand compute needs no setup; Admins and Owners can also connect infrastructure the organization already uses.
For most researchers, the plan is the right place to reason about compute. Organization settings defines the available options, while each plan records the choice made for that experiment.
On-demand compute¶
Managed compute provisions GPUs for the work that needs them and releases those resources afterward. It is a good default for self-contained work that can receive declared inputs and return durable outputs. Billing applies while an experiment holds a GPU.
A Ready card needs no action. Review the planned accelerator, job count, and maximum runtime before launch.
Link a Slurm cluster¶
Choose Link another cluster. It must run Slurm and allow unprivileged container jobs.
Enter:
- a recognizable cluster name
- the SSH login host Silico should dial through
- the account mode: each member uses their own account, or the organization uses one shared account
- at least one absolute cluster data-mount path
- an optional output base for experiment files
Choose Register cluster when the details look right. The first experiment can take up to five minutes to start while Silico prepares the connection.
With per-person accounts, each member adds a key and cluster-side attribution remains personal. With a shared account, jobs use one Unix identity; enforce access and audit boundaries at the cluster. Choose the mode that matches how your infrastructure already handles responsibility, not merely the one with fewer keys.
Native Slurm launch scripts¶
Enable native Slurm launch scripts supports custom multi-node Ray or MPI launchers. Native host code runs outside Silico's container guardrails with the configured POSIX account's Slurm and filesystem authority.
Enable it only after reviewing scheduler, filesystem, network, and accounting implications.
Choose compute for an experiment¶
Before launch, confirm that the compute target can reach the required data mounts, credentials, accelerator capacity, and network endpoints. A small pilot is usually the cheapest way to validate a new path. It can reveal a missing mount or blocked host before a large sweep spends hours waiting or fails after setup.
How files move through compute¶
The compute target changes how jobs receive inputs and where their outputs remain available. This is the main detail to understand when code works in one environment and cannot find its files in another.
On-demand jobs¶
On-demand jobs start with an isolated filesystem. They fetch the inputs declared for that job from durable storage; a file mentioned only in the plan is not attached automatically.
Write files that must survive the job to $SILICO_EXPERIMENT_ARTIFACTS_DIR. Silico copies regular files from that directory back to durable storage when the job finishes. Files written elsewhere are scratch and are deleted with the job, and symlinks are not followed during the copy.
Separate on-demand jobs do not share a filesystem. When a later job depends on an earlier output, the plan must attach the exact stored files as inputs to the later job. Do not rely on a path that happened to exist in a previous job.
Linked clusters¶
Jobs on a linked Slurm cluster use the data mounts configured for that cluster. Large outputs remain in the experiment's durable cluster directory and are not automatically copied into cloud storage.
In both cases, each submitted job receives an immutable snapshot of its code. Editing the experiment after submission changes future jobs, not one that is already queued or running. This keeps an in-flight result tied to the code that actually produced it.
Monitor compute¶
Use an experiment's Compute view for its jobs, accelerators, runtime, and status. Use Organization settings → Cluster usage for organization-wide GPU and storage utilization on connected dedicated infrastructure.
