The Marketplace Model

Two-sided markets, GPU edition

A two-sided marketplace has two distinct user groups whose value to each other increases with platform liquidity. Classic examples: eBay (buyers and sellers), Airbnb (hosts and guests), Uber (drivers and riders).

Vast's two sides:

• Providers — owners of GPU hardware. Could be a person with a gaming rig, a small datacenter operator, a former-crypto-mining farm, a research lab with idle hardware, or a small business with rack space.
• Clients — people and organizations that want to run compute on a GPU. ML researchers, indie AI builders, students, small companies, the occasional enterprise.

The platform's job is to match them efficiently. The price is determined by the market, not set by Vast. Vast takes a percentage on each match. This is the marketplace business in one paragraph.

How this differs from a cloud

Walk through the differences carefully — they're not intuitive if your mental model is AWS or CoreWeave.

Every row of that table is a strategic implication. Variable quality means Vast needs strong trust/ranking. No SLAs means enterprise customers shy away. Low capital intensity means the business can be profitable at modest scale. Fast supply scaling means Vast benefits enormously from the supply-glut conditions that follow GPU-generation rollovers.

The Airbnb comparison

The most useful mental model for Vast is Airbnb for GPUs. The analogies are strong:

• Hosts (providers) have a physical asset they're underutilizing. They list it on the platform. The platform helps match them with people who want the asset.
• Quality varies across hosts. The platform manages this through ratings, ranking, and trust signals — not through owning the underlying real estate.
• The platform takes a transactional cut, not a markup. Hosts set their own prices (within platform-suggested ranges).
• Some hosts are professionalized (small property management companies / colo operators); some are individuals (single-property hosts / single-GPU listers).
• The platform's defensibility is in the network — the supply corpus and the trust/ranking system.

The comparison illuminates the strategic terrain. Just as Airbnb fundamentally doesn't compete with Marriott on the same axes (consistency, brand-standard rooms, business-travel programs), Vast fundamentally doesn't compete with CoreWeave on the same axes (uptime SLAs, dedicated VPCs, enterprise contract vehicles). They serve different segments.

The disanalogies matter too. Real estate doesn't depreciate the way GPUs do. Real estate doesn't have weekly performance benchmark updates the way GPUs do (every new model release). The travel demand cycle is slow; the GPU demand cycle is fast. So the analogy is useful but breaks at the edges.

Marketplace mechanics

The mechanical flow:

1. Provider lists an instance. They run Vast's host software on their machine. The software registers the machine's specs (GPU model, count, CPU, RAM, disk, bandwidth) with Vast's central system.
2. Provider sets a price. They either pick from Vast's pricing guidance or set their own. They specify whether the instance is offered as on-demand only or also as interruptible.
3. Client searches. The client uses the Vast web UI, CLI, or API to filter for GPUs matching their needs (model, RAM, bandwidth, price ceiling, etc.).
4. Client rents. The client either takes an on-demand instance at the listed price or places a bid on an interruptible instance.
5. Compute happens. The client SSHs into the instance or runs their containerized job. Vast meters usage by the hour (or by the second, internally).
6. Vast takes its cut. The client is billed; Vast keeps its take-rate and pays the provider the rest.
7. Rating + reputation. Performance signals (uptime, bandwidth, benchmark scores) flow back into Vast's ranking system; future buyers see the updated metrics.

The whole flow runs without human intervention from Vast in the typical case. The marketplace is self-serve on both sides.

Take-rate economics

Vast's revenue is its take-rate times gross marketplace volume (GMV). The exact take-rate is not officially published; industry sources put it in a range that's competitive for marketplaces — somewhere between 15% and 30% of the transaction value, varying by tier, payment method, and provider quality.

This is materially lower than the gross-margin lift a traditional cloud takes on raw GPUs (where the price-to-cost ratio is often 3-10x). The marketplace model trades margin per transaction for volume — more transactions, lower margin each — and avoids the capital cost of owning the hardware.

At scale, the math works because marketplace operations are O(1) per transaction — software-driven, no incremental cost to onboard the n-th GPU once the platform is built. A traditional cloud has to keep buying GPUs and building datacenters to grow; Vast just recruits providers.

Liquidity & matchmaking

The key health metric for any marketplace is liquidity — at any given moment, can a demand-side user find supply matching their needs? At any given moment, can a supply-side provider find a renter?

Vast's liquidity is strong in some segments and thin in others:

• Consumer GPUs (RTX 3090, 4090): deep supply. You can usually find dozens of instances at competitive prices any time.
• A100s: good supply. Several hundred typically listed.
• H100s: moderate supply. Available but thinner than A100s; pricing can spike during demand surges.
• H200, B200: sparse — these are newer cards and providers haven't deployed them at scale yet on the marketplace.
• Multi-node training (8+ GPUs with NVLink/IB): rare. Some providers offer it; most don't.

The liquidity profile is one reason Vast is great for single-node training and inference but weak for large distributed training. The marketplace doesn't have the high-end multi-node fleets that CoreWeave or Crusoe assemble.

Disputes & trust

What happens when something goes wrong?

• Instance dies mid-job. The client doesn't pay for the dead time; the host's reliability score drops. Vast doesn't compensate the client beyond credits in some cases.
• Performance below benchmark. The DLPerf score and other live signals flag this. Clients can rate the host; recurring bad hosts get demoted in search ranking and eventually removed.
• Host accesses client data. This is the deepest trust concern. The architectural mitigations (instance isolation, no host-side filesystem access by default) help, but customers who handle sensitive data should treat Vast as untrusted-by-default — encrypt at rest, don't store credentials in the image, etc.
• Client abuses the instance. Mining on a non-mining provider, hosting illegal content, etc. The host can report; Vast can ban accounts.

The dispute system is mostly automated. Vast's small headcount means human-mediated dispute resolution is rare — the system has to handle the bulk of cases automatically through rating signals and platform rules.

Takeaway

The marketplace model is the load-bearing fact about Vast. Everything else in this guide derives from it:

• Why Vast is cheap: marketplace pricing, not cloud markup.
• Why Vast can scale fast: recruit providers, don't buy GPUs.
• Why Vast struggles with enterprise: no SLAs, no compliance certifications across the marketplace.
• Why Vast is hard to disrupt directly: the supply corpus is the moat.
• Why Vast can be profitable at modest revenue: marketplace operations are cheap to run.

The next chapter goes deep on the supply side — who lists GPUs on Vast and why.