Multi-Node Instances
The 2X tiers — two GPU instances on two hosts, what they're genuinely good for, and the one thing they can't do.
A multi-node tier (2X) gives you two independent GPU instances, one GPU each, on two separate physical hosts, sold as one line item. You get twice the GPU count for one request, and each member is a normal instance with its own IP, its own SSH access, its own local disk, and its own lifecycle.
Read Single-Node Instances first if you haven't — the layout difference is the whole story here.
The multi-node catalog
CPU cores, memory, and storage are configurable. The hourly rate is to be determined for the requested configuration.
| Tier | Nodes | GPU (total VRAM) | Per host |
|---|---|---|---|
| RTX-3090-2X | 2 | 2× RTX 3090 (48 GB) | 1× RTX 3090 |
| RTX-5090-2X | 2 | 2× RTX 5090 (64 GB) | 1× RTX 5090 |
Contact ANK to discuss configuration and pricing.
The interconnect is the important part
Members talk to each other over the 1 GbE private tenant LAN. That is roughly an order of magnitude slower than the intra-host path a GPU uses to reach its own memory, and slow enough that GPU-to-GPU collectives become the bottleneck rather than the compute.
So, plainly:
- Good fit — anything where each GPU does its own work and they exchange results infrequently: data-parallel training with gradient sync at batch boundaries, sharded or replicated inference, hyperparameter sweeps, two experiments at once, or splitting preprocessing from training.
- Bad fit — tensor parallelism and anything that depends on tight, high-frequency NCCL collectives (
all-reduce,all-gather) across GPUs. Model-parallel splits that need every layer's activation to cross the wire will spend most of their time waiting on the network.
If you need fast GPU-to-GPU communication, the only fast interconnect documented today is the direct 200 GbE link between two DGX Spark nodes — see Connect Two Sparks. The 2X tiers are not that.
A useful rule of thumb: if you can run each member as a standalone job and merge the results afterwards, 2X will serve you well. If your framework needs both GPUs in one torchrun collective group to make progress, it won't.
How the members are sized
CPU cores, memory, and storage can be configured for each request, subject to host capacity. VRAM is spread across two GPUs on separate hosts; it is not one shared memory space.
What you are responsible for
Multi-node tiers are two instances, not a managed cluster. Concretely:
- Two of everything. Two SSH endpoints, two sets of ports and mappings, two environments to keep in sync.
- You do the orchestration.
torchrun, DeepSpeed, Ray, or plain SSH — bring your own launcher. There is no cluster API. - Both members must be available. They are placed independently, so a request completes only when capacity exists for both. Ask ANK to confirm before a deadline — Availability.
- Disk is per member and ephemeral. Each instance has its own configurable disk, deleted with its instance. Don't assume a shared filesystem; replicate or use a storage plan.
Choosing between them
| Situation | Pick |
|---|---|
| Model or batch must fit in one GPU's memory | Single-node, largest VRAM that fits |
| Throughput per rupee on parallel workloads | 2X |
| Two separate workloads or two people | 2X — clean isolation per member |
| Tensor parallelism / frequent collectives | Neither today — talk to ANK |
| Long-context or large-model work needing one memory space | Single-node first, then ask ANK about custom provisioning |
When you contact ANK, say the model, the VRAM it needs, your framework, and whether the GPUs need to be in one collective group — that last detail is what decides whether 2X is the right offer for you.