accelerator and rdma_type.
Each SKU has a stable id and a human-readable name that SF Compute assigns at registration. Both the
API and the CLI identify a SKU by its sku_... id.
A SKU is the boundary of fungibility. Two instances with the same SKU run on the same hardware and
are interchangeable. The market prices and allocates them as one supply, and you cannot pin a
specific machine within a SKU. Hardware differences that matter, such as the accelerator, the RDMA
network, the zone, and the machine shape, place nodes in different SKUs.
Each SKU has its own orderbook and its own allocation. An order fills only
against orders on the same SKU. A pool records its allocation as a node-count
schedule per SKU.
A SKU identifies hardware, not how you buy it, so spot and non-spot orders for the same hardware
share one SKU. Some guarantees depend on staying on the same hardware, such as buying more capacity
and keeping your instances running. These hold within one SKU, not across SKUs. An instance pins to
its SKU at create time and never moves to another.
List SKUs
List the registered SKUs and their ids.--verbose to include the region, zone, form factor, RDMA type, and public IPv4 columns.
Get details for one SKU
Get the full property set for a single SKU.Use a SKU
Orders, pool transfers, deployments, procurements, and instances each pin to a single SKU id. Pass it with--instance-sku <id>.
Interactive picker
On commands that pin a SKU (for example,sf orders create), omit --instance-sku. You then pick
from a list of registered SKUs and their properties.