Skip to main content

GPU Splitting

GPU splitting lets a single node serve multiple customers at once — each renting an integer subset of GPUs. It increases utilization and lets you price flexibly.

Host prerequisite: Docker storage​

GPU splitting requires Docker to enforce a per-container storage limit. Check your host with the one-command probe in Docker Storage Setup. If it fails, the same page migrates the host to overlay2 + XFS, which is the supported way to get there. The Edit button only unlocks once preflight passes. (The same requirement will extend to every node in the near future, so the work is not GPU-splitting specific.)

Enable GPU splitting in the portal​

After the host meets the prerequisites:

  1. Open the node's details page in the Provider Portal.
  2. Find the GPU Splitting panel — an Edit button appears once preflight passes.
  3. Set the minimum GPU count per rental — at least 1, and no more than the node's total GPU count. On flagship nodes it must be below the total to count for the idle payout (see below).

Customers can then rent any integer count between your minimum and the node's total. To disable splitting, clear the minimum — only allowed when no pod is currently using a partial allocation.

Pods on a split node cannot reach each other​

Two customers' pods on one node share the node's Docker daemon. The validator keeps them apart on the network: the first time it starts a pod on a node it creates a Docker bridge network named lium-rentals with inter-container communication turned off, and every pod it starts afterwards runs on that network. It does this on every node it rents on, split or not; on a whole-node rental it changes nothing. A pod can still be reached through its published ports and can still reach the internet; it cannot open a connection to another pod's address on the node.

docker network inspect lium-rentals --format '{{.Driver}} {{.Options}}'
# bridge map[com.docker.network.bridge.enable_icc:false]

Leave the network alone. If it is missing the validator recreates it on the next pod start. If a network of that name exists on the node but is not a bridge with com.docker.network.bridge.enable_icc=false, the validator refuses to start pods on the node until it is removed (docker network rm lium-rentals, once no container uses it); the command above is how you check. Pods started before the network existed stay on the default bridge until they end, and two of those can still reach each other there; Docker does not let a pod on the default bridge reach one on lium-rentals.

One thing the shared network does not hide: Docker's built-in DNS on a user-defined network resolves the addresses on it to container names, so a pod can learn that a neighbour exists and its container name (pod_<pod id>). The id opens nothing on the neighbour itself — SSH and its other ports stay closed — and the pod's logs and lifecycle need the owning account.

When splitting actually helps​

More renters can match your node. A meaningful share of customers want a single GPU, and an 8-GPU node without splitting is invisible to that segment. Widening the pool of renters that can match your node usually raises utilization on multi-GPU hosts.

On flagship nodes it protects the idle payout. An 8× H200, B200, or B300 node must offer GPU splitting, GPU Profiling (ncu), or run inside an attested confidential VM to earn the unrented incentive while idle. Splitting counts only when the minimum GPU count per rental is set below the node's total — a minimum equal to the full node size is a whole-host rental in practice and does not qualify.

Your minimum split count also gives the validator a second GPU-count tier for your idle node. The unrented incentive is paid per (GPU model, GPU count) tier, and each tier has its own rate and its own capacity cap. Your minimum names a second tier the validator can rate the node against while it is idle:

  • If your GPU count has no priced tier, splitting is what makes the node eligible at all. Only some GPU counts are priced — today 1 and 8. A 4-GPU node earns 0 from the idle pool; the same node with a minimum split count of 1 is rated in the 1-GPU tier and earns.
  • If your GPU-count tier is over its capacity cap, the node can be rated against your minimum-split tier instead — but only when the node's whole GPU count fits in that tier's free capacity. Being moved means no cap dilution for that cycle.

Both incentive effects apply while the node has free GPUs. A partial rental does not switch them off: the rented GPUs earn rental fees plus the rented pool, and the GPUs still free are scored as an ordinary idle candidate, rated at your minimum-split tier. The free GPUs must still pass the usual idle rules to earn — your own Default Job on the node, a spot tier, too little disk, or a price above the limit sets that part to 0, exactly as on a fully idle node. Splitting never changes your rental price or your rental fees, and on single-GPU nodes it has no effect.

Open ports for every GPU you split into. Every pod needs at least 3 open ports, and a split node is rented in bundles of your minimum split count. Size the range for one pod per bundle:

  • Open at least 3 × (GPU count ÷ minimum split count) ports, rounding the division up when it does not come out even.
  • For an 8-GPU node that means 24 ports with a minimum of 1, 12 with a minimum of 2, and 9 with a minimum of 3 (8 ÷ 3 rounds up to 3).
  • Set the node's RENTING_PORT_RANGE at least that wide, then restart the executor. The new range counts only after the restart.

If the range is too narrow, the node runs out of ports before it runs out of GPUs: once fewer than 3 ports are free, the GPUs still free cannot be rented. Idle pay on them is not cut for it.

For the exact tier rules, an example, and the log line the validator writes when it moves a node, see Subnet emission → When your GPU-count tier is full.