You don't need one GPU. You need 32 GPUs that talk to each other like they're in the same rack.

Every DePIN network’s GPU marketing leads with price per GPU-hour. They publish comparison tables showing their H100 rates against AWS, their A100 spot costs against GCP, or their RTX 4090 per-second billing against Azure. Read between the lines and that marketing suggests that cheaper access to hardware is equivalent to actually usable infrastructure.

Well, it isn't that simple. At least not for the workloads that actually matter, like fine-tuning a 70-billion-parameter model, running distributed reinforcement learning across 16 nodes, or training a diffusion model on 100TB of image data. Workloads fail because the GPUs are simply not coordinated very well. When you rent a GPU from a marketplace, you get a machine. When you need orchestration, you need a system. Here’s the thing: most decentralized networks have never built a system that can properly orchestrate GPUs that are truly usable by AI startups and research teams. In this article, we’ll explore GPU rental marketplaces and GPU orchestration layers so that we can grasp the difference between them. In the end, you’ll be able to find the AI infrastructure that delivers what your ML team needs, not a setup that fails before the training run even starts.

How a GPU marketplace really works

A GPU marketplace is, quite simply, a liquidity network. Its job is to match buyers with available compute. 

Akash Network pioneered the model in 2020 with its reverse auction system: providers list capacity, buyers submit bids, and the marketplace routes the winner to a machine. Vast.ai refined it with a consumer-facing UX and transparent pricing. Render Network adapted it for creative GPU workloads. While the mechanics of each might vary (e.g. fixed pricing vs. auction, token-gated vs. credit card) the fundamental architecture is the essentially same.

The marketplace answers one question: Is there a GPU available?

It does not answer quotes like: Can these GPUs communicate at the bandwidth a training job requires? Can they fail over without losing gradient state? Can a job scheduler intelligently route work across them based on real-time utilization and interconnect topology? 

Those are orchestration questions, and marketplace architecture wasn't designed to answer them.

This isn't a criticism of the marketplace model. For a certain class of workloads, a well-priced, instantly available single GPU is exactly what you need like an inference serving for a small model, a one-shot notebook experiment, or a batch transcription job that parallelizes trivially across independent machines. Marketplaces serve these workloads well and will continue to do so. 

The problem is when the infrastructure sale doesn't distinguish between GPU access and infra that can truly handle a distributed workload. Caveat emptor. Buyers who need the latter and get the former spend weeks learning about that difference the hard way.

Inside a multi-node training workload

To understand why orchestration is not optional for serious ML work, walk through what a real training job requires.

The Llama 3.1 70B Fine-Tuning Case

Llama 3.1 70B has 70 billion parameters. In BFloat16 precision, the model weights alone require 140GB of VRAM. A single H100 SXM5 with 80GB of HBM3e memory can't hold the full model. Fine-tuning with gradients and optimizer state requires roughly 3–4x the model weight footprint. Call it 420–560GB of total memory requirement across the training process.

The practical configuration is 8 H100 80GB GPUs per node, using tensor parallelism across the node, with pipeline parallelism across nodes. A standard fine-tuning run on this model uses 4 nodes of 8 GPUs each (32 GPUs total) for a 72-hour job at a batch size and learning rate schedule appropriate for instruction tuning.

Now consider what has to happen at the infrastructure layer for this job to run. 

Memory-coherent tensor parallelism within a node

The 8 GPUs on each node need NVLink or NVSwitch interconnect delivering 600–900GB/s GPU-to-GPU bandwidth. Without this, tensor parallel layers, where a single transformer attention head is split across GPUs, create an all-reduce communication bottleneck that increases training time by 40–60%. No amount of price optimization recovers that throughput loss.

Low-latency gradient synchronization across nodes

At the end of each backward pass, all 32 GPUs run an all-reduce to average gradients across the distributed model. This operation is bandwidth-bound. InfiniBand HDR (200Gbps) or NDR (400Gbps) is the standard interconnect. Ethernet-based RDMA (RoCE) works but requires careful network fabric configuration. Consumer networking, even 10GbE, turns a 4-node gradient sync into a training run that never converges because gradient staleness exceeds acceptable bounds at any reasonable batch size.

Fault tolerance with checkpoint coordination

In a 72-hour run across 32 GPUs, hardware failures are not edge cases. A DRAM ECC error, a PCIe flap, a GPU driver crash — any of these on any of 32 nodes can corrupt the gradient state and waste the entire run if not handled. The right behavior: detect the failure, roll back to the last synchronized checkpoint, reschedule the failed node's work to a healthy replacement, and resume with minimal loss. This requires the scheduler to maintain distributed checkpoint state, monitor node health, and coordinate rollback atomically across the cluster.

Job scheduling across heterogeneous supply

At the scale of a 32-GPU run, you rarely get 32 identical GPUs from a single data center. If you're using decentralized supply, you're spanning geography, latency tiers, and hardware generations. The scheduler needs to know which GPUs are NVLink-connected, which are on the same Layer 2 network segment, and how to form the cluster topology that minimizes the communication cost given the workload's parallelism strategy.

A marketplace lists GPUs. None of this is a marketplace function.

Where the DePIN networks stand

The decentralized compute landscape is oft-considered a competitive field. On price, yes, there is competition. On orchestration, however, there isn’t much competition yet because most of these networks haven't built orchestration.

Akash Network

Akash's architecture is container-first, built on Kubernetes. A workload is a Docker container or set of containers described in Akash's SDL (Stack Definition Language). When you need multiple GPUs on Akash, you request multiple containers and inter-container networking, shared memory, and framework configuration are your problem.

There is no native NVLink support, NCCL-aware scheduling, and no distributed checkpoint coordinator. If you want to run a 4-node FSDP job on Akash, you are assembling the pieces manually by deploying containers, configuring the Ray head node and workers, writing the SSH trust configuration, mounting shared storage, and hoping the providers you won in the auction happen to have GPUs that can communicate at the bandwidth your job requires. The thing is, on Akash's current provider network (~2,000–3,000 total GPUs, predominantly RTX 3090 from individual miners), they often can't.

Akash is no doubt a strong platform for CPU workloads and containerized applications. It is not an ML training infrastructure platform.

Render Network

Render is purpose-built for creative GPU workloads like 3D rendering with Octane, Blender, and Cinema 4D. Its scheduling model is designed around independent render frames, which parallelize trivially. Each GPU gets a frame batch, there's no cross-GPU communication, and a node failure just requeues the affected frames. This is exactly the right design for rendering. It is the wrong design for neural network training, where the computation graph has cross-GPU dependencies at every backward pass.

Render Network has not made a credible move toward distributed ML training infrastructure. That means Render competes on a completely different plane than the orchestration problem.

Aethir

Aethir's positioning is enterprise-grade inference and gaming compute. Its architecture focuses on latency-optimized inference serving and high-density GPU deployment for cloud gaming scenarios. Aethir has made progress on SLA guarantees and enterprise reliability compared to earlier DePIN networks.

But Aethir's story is inference instead of training. The orchestration challenge for inference is materially different: you need low-latency request routing and model replication, not distributed gradient synchronization. Aethir has not articulated an orchestration story for multi-node training workloads and doesn't appear to be pursuing it.

Nosana

Nosana is a CI/CD-focused GPU network built on Robinhood. Its primary use case is GPU-accelerated build pipelines and developer tooling, which is a genuinely underserved market. But CI/CD pipelines are single-node, short-duration, embarrassingly parallel workloads. The cross-node coordination problem simply doesn't arise. Nosana's architecture reflects this, as it's optimized for job queuing and single-node dispatch, not cluster formation.

Orchestration competition

None of these networks are telling an orchestration story because none of them have built an orchestration layer. They compete on price, on token economics, on uptime guarantees, and on niche workload optimization. The orchestration narrative is uncontested.

This orchestration gulf isn't a criticism of the broader DePIN compute movement. Decentralized physical infrastructure networks have made real contributions to permissionless access, provider diversity, and pricing transparency. But DePIN compute as a category has largely stopped at the marketplace layer. Building the orchestration layer on top of distributed, heterogeneous supply is a substantially harder engineering problem, and it's one the market has not yet solved at scale.

GPU orchestration in VOLT's architecture

VOLT's positioning — "orchestrates global GPUs into instant clusters" — is a specific technical claim. Sure, we use it in our messaging but it’s not at all a marketing abstraction. Let’s take a look at the substance behind our orchestration architecture.

Ray-native scheduling

VOLT's cluster formation is built around Ray, the distributed execution framework developed at a university's RISE Lab and now production-standard at Uber, Amazon, and Cohere. Ray's actor model gives distributed workloads a first-class abstraction for stateful workers, shared memory, and fault-tolerant task execution.

When you provision a multi-node cluster on VOLT, we don’t serve you a bag of machines. Instead, you get a Ray cluster with a pre-configured head node, registered worker nodes, and the Ray object store initialized for distributed data sharing. A PyTorch Distributed job or a HuggingFace Accelerate run can target this cluster out of the box. You don’t have to bother with manual SSH trust setup, head node IP hunting, and Ray environment configuration.

On VOLT, your team can start its training run on a deadline instead of manually assembling a cluster, which can take 4–8 hours. 

Cluster topology awareness

VOLT's scheduler tracks the physical and network topology of its GPU supply. Before forming a cluster, the scheduler knows which GPUs share an NVLink fabric, which are on the same InfiniBand segment, and what the cross-node latency is between available machines. When a user requests a 4-node H100 cluster optimized for distributed training, the scheduler forms that cluster from GPUs that can actually deliver the interconnect performance the workload requires.

This is not trivial. In a distributed supply network spanning data centers across multiple geographies, naively assigning 32 GPUs without topology awareness can create a cluster where inter-node bandwidth is 10GbE (1.25GB/s) instead of InfiniBand (25GB/s). For a large model training job, that's the difference between a run that converges and a run that gets stuck in communication overhead.

Fault tolerance and checkpoint coordination

VOLT's scheduler monitors node health continuously. If a worker node fails mid-run, the system detects the failure, preserves the gradient checkpoint state from the last synchronization point, and reschedules the failed node's partitions to a healthy replacement — automatically.

This is particularly important for long-horizon training runs. A 72-hour fine-tuning job on 32 GPUs has a meaningful probability of encountering at least one hardware event. The difference between a platform with checkpoint coordination and a marketplace is the difference between recovering from that event in 15 minutes and losing 40 hours of training progress.

The Instant cluster claim: What it requires

When VOLT says clusters deploy in minutes, that requires inventory depth that marketplaces structurally can't match. Akash has ~2,000–3,000 GPUs. If you need 32 H100s, you're competing with every other auction winner for that inventory, which may not be there.

VOLT's extensive GPU network means that when you request 32 H100 SXM5 units, the scheduler has enough supply to find 32 GPUs with compatible interconnect topology, provision them, and hand you a live cluster. The provisioning SLA is under two minutes for standard configurations because the inventory depth makes it possible to serve the request without queuing.

Inventory is a prerequisite for real orchestration. You can't orchestrate supply that isn't there.

Head-to-head: GPU marketplace vs. orchestration on a real AI/ML training run

The clearest way to understand the orchestration gap is to walk a real training job through each model. 

Llama 3.1 70B supervised fine-tuning on a 50,000-sample instruction dataset 

• Configuration: 4-node cluster, 8x H100 80GB per node (32 GPUs total), FSDP with BFloat16, DeepSpeed ZeRO Stage 2, gradient checkpointing enabled, checkpoint every 2 hours. 
• Estimated runtime: 72 hours.

On a GPU marketplace

Step 1: Identify 32 H100s for rent. 

• On Akash, you're running an auction for 8 separate 4-GPU containers and hoping they land on providers with the right hardware. 
• On Vast.ai, you're filtering the marketplace to find 4 providers each offering 8 H100s, checking their latency to each other (which the marketplace doesn't show you), and manually reserving them in parallel before someone else takes them.

Step 2: Configure the cluster. 

• SSH into each node. 
• Install CUDA drivers, NCCL, cuDNN. 
• Configure the Ray head and workers. 
• Set up /etc/hosts or service discovery so the nodes can find each other. 
• Configure SSH trust between nodes. 
• Mount shared storage. 
• Verify NCCL is using InfiniBand (not Ethernet fallback). 
• Run a NCCL all-reduce test to verify bandwidth.

Step 3: Start the training run. 

• Hope all 32 GPUs stay healthy for 72 hours. 
• If one goes down, recover manually: 
  • Identify the checkpoint
  • Reconfigure the cluster
  • Restart with the recovered state.

Realistic elapsed time before the first training token: 4–8 hours. 

Realistic probability of a clean 72-hour run without manual intervention: low.

On VOLT:

Step 1: Request a 4-node H100 cluster via the API or console. 

• Specify FSDP workload, InfiniBand preferred. 
• VOLT's scheduler finds 4 nodes with compatible topology.

Step 2: Receive cluster credentials in under 2 minutes. 

• Ray is pre-configured. 
• SSH keys are distributed. 
• Shared NVMe storage is mounted.

Step 3: Point your training script at the Ray head node address. 

• Launch.

Elapsed time before the first training token: under 15 minutes. Fault tolerance: automatic. Checkpoint recovery: automatic.

For the workloads that define the frontier of ML development, the differences between GPU marketplaces and orchestration come down to what is usable platform versus what is an expensive science project.

GPU orchestration is your strategic advantage

The GPU marketplace narrative has been so dominant that most buyers don't know to ask the orchestration question. When a CTO evaluates decentralized compute Googles "decentralized GPU," they get pricing tables. They will see Akash, Render, VOLT, and Aethir all listed side by side with per-hour rates. The decision framework defaults to price because that's what the search results surface.

We’re not saying that your CTO shouldn’t ask the question: "which decentralized network has the lowest H100 rate?" We’re simply saying your CTO should ask: "which network can actually orchestrate and run my workload?"

For a CTO whose team needs to fine-tune a 70B model, there are two answers to the second question. In the first, none of the marketplaces can orchestrate without significant manual work. The other answer to the orchestration question is that VOLT can do it, right now, in under 15 minutes.

What to look for when evaluating a decentralised GPU marketplace

If your team is evaluating decentralized compute for ML workloads, the checklist below separates orchestration platforms from marketplaces before you spend a sprint finding out the hard way.

1. Cluster formation – Can the platform provision a multi-node cluster in a single API call? Or does it provision individual machines and leave cluster configuration to you?
2. Interconnect awareness – Does the scheduler place nodes with topology awareness — knowing which GPUs share NVLink, which are on InfiniBand segments? Or does it treat all GPUs as interchangeable?
3. Framework integration – Does the cluster arrive pre-configured for Ray, PyTorch Distributed, or FSDP? Or do you receive bare machines and a password?
4. Fault tolerance – What happens when a GPU fails mid-run? Does the platform recover automatically, or do you get a failed job and a refund?
5. Inventory depth – Can the platform actually fulfill a 32-GPU H100 request without a queue? What's the real available inventory for premium SKUs?
6. Checkpoint coordination – Does the platform handle distributed checkpointing, or is checkpoint management entirely your responsibility?

A platform that answers all six questions in the affirmative is an orchestration layer. 

A platform that answers most of them "you handle that" is a marketplace. 

Price the difference accordingly.

Orchestrate your project’s future with the right foundation

GPU rental is infrastructure access. GPU orchestration is infrastructure that works for the workloads that truly matter in model training, product launches, and inferences. 

Most decentralized GPU networks have built marketplaces. They've done that well with price discovery, permissionless access, and global supply, each of which have made real contributions to the compute landscape. But a marketplace that lists H100s is not the same thing as a platform that can take 32 H100s and make them work as a coherent training cluster.

For teams running experiments, a marketplace might be enough. For teams running production training at model scales that require multi-node coordination—7B, 13B, 70B, and beyond—the orchestration question is the threshold. Everything else is secondary.

VOLT is the only decentralized network that has answered that question with production infrastructure that includes Ray-native scheduling, topology-aware cluster formation, automated fault recovery, and inventory depth sufficient to actually fulfill large cluster requests. Again, price matters. But so does capability. If you don’t have both sorted, it might be the difference between shipping a model or not. 

VOLT Cloud provisions H100 and A100 clusters in under two minutes. Start here.