Introducing Elastic InfiniBand Partitions#

Today we're releasing Elastic InfiniBand Partitions on SF Compute: isolated RDMA networks that you create, name, and manage yourself, for any group of instances in your workspace.

Distributed training lives or dies on the interconnect. The workers in a job need to exchange gradients over InfiniBand, and nothing else should be on that network with them. As teams run more jobs side by side (a pretraining run, a fine-tune, an eval sweep), they need a clear, self-serve way to decide which machines can reach which. Partitions give you that control directly from the CLI and API.

Getting started#

Elastic InfiniBand Partitions are in public preview. Enable the preview for your account:

sf preview set infiniband-preview=true

If self-enrollment isn't available for your account, contact us and we'll get you set up.

Find InfiniBand-capable hardware and note its region and zone:

sf availability --rdma-type infiniband

Create a pool and buy two nodes to experiment with:

sf pools create --name training-cluster
 
sf orders create --side buy --pool training-cluster --count 2 \
  --start now --duration 7d \
  --max-rate 20.00 --sku "$IB_SKU"

Create a partition in the same location:

sf infiniband-partitions create --name training --region europe-north1 --zone a

Creating a partition doesn't create instances or buy compute. It just sets up the network.

Then attach instances when you create them:

sf instances create \
  --pool training-cluster \
  --sku "$IB_SKU" \
  --image "$IB_IMAGE" \
  --cloud-init ./init.yaml \
  --name worker-1 \
  --infiniband-partition training

Repeat for each worker. Every instance created with --infiniband-partition training joins the same isolated network. SF Compute public images ship without a password or SSH key, so use --cloud-init to add your SSH public key.

Buy exactly the cluster you need, when you need it#

Elastic networking matters most when your compute is elastic too. On SF Compute, you don't commit to a fixed cluster for a year. You buy compute time into a pool for exactly the nodes and time window you need, and draw whatever shape of compute fits your work.

Those two test nodes are enough to debug your code and tune your setup. When you're ready for your hero run, reserve the full cluster for just the days it needs. You can book it ahead of time, so the capacity and price are locked in before the run starts. Add --quote first to see the price without placing the order:

sf orders create --side buy --pool training-cluster --count 64 \
  --start "oct 12" --duration 5d \
  --max-rate 20.00 --sku "$IB_SKU" --quote

When the time arrives, create instances into the same partition as your test nodes. They join your existing workers over InfiniBand as soon as they come up.

Sell the whole window, not just leftover hours#

Most clouds give you two options: pay on-demand prices, or commit to a reservation and eat the cost if your plans change. SF Compute gives you a third. Anything you own, you can sell back on the market, including time that hasn't started yet.

That matters because the risk in a big reservation isn't a few idle hours at the end. It's the whole window. Your data pipeline slips a week, or a smaller ablation changes your plans, and suddenly you're holding a 64-node block you won't use. On SF Compute you're not stuck with it. You can list the entire future window on the orderbook while there's still time for buyers to find it:

sf orders create --side sell --pool training-cluster --count 64 \
  --start "oct 12" --duration 5d \
  --min-rate 15.00 --sku "$IB_SKU" \
  --allow-standing

Or sell just the part you don't need. If the run finishes a day early, sell the last day:

sf orders create --side sell --pool training-cluster --count 64 \
  --start "oct 16" --duration 24h \
  --min-rate 15.00 --sku "$IB_SKU" \
  --allow-standing

You can sell any slice of time you own, from the end of a reservation to a gap in the middle. Sell orders fill partially by default, so buyers can take pieces of a large block, and you keep the time until a buyer purchases it. That turns a reservation from a bet you have to win into a position you can adjust. Booking your hero run early costs you far less when you know you can exit if plans change.

The result is a cluster that follows your workload instead of the other way around, so you can spend your budget on the throughput you actually use.

Managing partitions#

List partitions in your workspace, or across every workspace you can read:

sf infiniband-partitions list
sf infiniband-partitions list --all

See which instances are attached to a partition:

sf infiniband-partitions instances training

When a job is finished, terminate its instances and delete the partition:

sf infiniband-partitions delete training

Every command supports --json and --no-input, so partitions fit cleanly into scripts and CI. sf ib-partitions works as a shorter alias.

How it works#

RDMA lets machines read and write each other's memory directly, which is what makes InfiniBand fast and what makes a shared, flat fabric risky. Many GPU providers offer InfiniBand without isolating customers from each other. On SF Compute, every customer's traffic is isolated.

Partitions are enforced by the fabric itself. SF Compute programs membership centrally through NVIDIA UFM, and the switches and adapters check every packet in hardware. Traffic from outside your partition never reaches your instances, and because membership is set by the platform, there's no way to join a partition from inside a machine. Only people with permission in your workspace can attach instances to it.

Available in the API#

Everything in the CLI is also available through the SF Compute API, with filtering by workspace, availability zone, fabric, or partition ID. The API lives under /preview/v2 during the preview and may change before it becomes stable. See the API reference for details.

We'd love to hear how you're using partitions. Update your CLI and run sf infiniband-partitions --help to get started.