Decentralized GPU Compute: The Complete Guide

The "decentralized GPU" thesis has matured significantly since 2022. The token-meme version (spin up GPUs as a Bitcoin-mining-style sidegig) is mostly noise. The serious version — aggregating heterogeneous, underutilized GPU capacity with trust and verification primitives, undercutting hyperscaler pricing on inference — is real and increasingly competitive. Compute is one layer of a larger picture; for the full map — agents, training networks, data, privacy, and payments — see the Decentralized AI guide.

Key takeaways
Mental model: decentralized GPU in one minute
The premise
The major players
Why inference works, training doesn't
Trust and verification
Pricing comparison vs hyperscalers
Real-world performance
When to use decentralized
When not to
Operational considerations
The token-economics question
Centralized but cheaper: the specialist GPU clouds
Decentralized training in depth: DiLoCo, SWARM, DisTrO, Petals
Bittensor TAO and subnet economics in 2026
Cost per FLOPS by provider tier
Akash, io.net, Aethir: protocol-level deep dives
Spot instance economics: AWS spot vs decentralized spot
What academics actually use
Federated learning frameworks: FedML, Flower, NVFlare
Legal and compliance risk: jurisdictions, KYC, export controls
BOINC, Folding@Home, and the volunteer-compute heritage
HBM vs GDDR economics: why datacenter GPUs cost what they do
Cross-provider routing patterns
The Web3 GPU bubble timeline and what survived
The bottom line
FAQ
Glossary
References

Key takeaways

Decentralized GPU marketplaces aggregate underutilized capacity (consumer GPUs, regional clouds, retired datacenter GPUs) and route AI workloads to it. Pricing is 30-60% cheaper than AWS/GCP for equivalent workloads.

The honest take:

Inference: legit win. Routing inference requests to whichever GPU has the model loaded is straightforward.
Training: hard. Distributed training over heterogeneous, untrusted hardware has fundamental obstacles.
Embarrassingly parallel batch jobs: legit win. Each unit of work is independent.

The major players in 2026: io.net, Akash, Render Network, Aethir, Bittensor's compute subnets, Vast.ai (centralized but similar economics).

The economic mechanism: tokenized incentives align providers (GPU owners) with consumers (AI workloads) without needing a central operator. The token serves as both currency and coordination mechanism.

Quick comparison: major networks vs hyperscalers

Network	GPU pool (2026)	Listed H100 $/hr	Verification model	Best for
io.net	~50k GPUs	$1.80-2.50	Proof-of-work-style attestations	Cost-sensitive inference, batch
Akash	Smaller GPU pool	$1.50-2.20	Provider auctions + reputation	Containerized inference, batch
Render	Distributed, mixed	Variable (RNDR)	Result-quorum (graphics-focused)	Rendering, image/video inference
Aethir	Edge + consumer	$1.20-2.00	Operator staking	Latency-sensitive gaming/AR inference
Bittensor subnets	Subnet-dependent	Variable (TAO)	Validator scoring per subnet	Experimental ML, embeddings, research
Vast.ai	Aggregated long-tail	$1.50-3.00	Centralized arbitration	Spot batch, hyperparameter sweeps
AWS p5 (H100)	Hyperscaler	$4.00-8.00	First-party SLA	Mission-critical, low-latency, training
Lambda / CoreWeave	Specialist cloud	$2.50-4.00	First-party SLA	Dedicated training, reserved capacity

Numbers are list-price ranges as of 2026-Q2; spot and committed-use pricing diverges further. Hyperscaler comparison drawn from public rate cards — see References.

If you're trying to fit decentralized GPU into a broader serving stack, the closest companions to this guide are verifiable inference, disaggregated prefill/decode, and KV cache memory math. For why training is the hard case, see distributed LLM training and AI training networking.

Mental model: decentralized GPU in one minute

The problem has a name: the GPU oligopoly tax. NVIDIA sells an H100 for ~$30k. AWS leases the same chip at $4–8/hr, which pays back the silicon in under six months and then prints margin for the next four years. The hyperscaler price floor is set by capex amortization + datacenter overhead + first-party SLA — not by what the GPU costs to run. Anyone with H100s, cheap electricity, and a network drop can clear the same workload at $2/hr and still profit. The structural opportunity is the spread between marginal cost and rack rate.

The fix is aggregation with trust primitives. A decentralized marketplace (io.net, Akash, Render, Aethir, Bittensor compute, Vast.ai) bundles long-tail capacity — regional clouds, retired enterprise GPUs, individual operators — and routes workloads to whichever provider has the model loaded, the network, and a clean attestation. The analogy is Uber: no one owns the fleet, the platform owns matching, routing, dispute resolution, and reputation. Token incentives align providers with consumers without a central operator.

Hyperscaler vs decentralized — side-by-side:

Aspect	Hyperscaler (AWS p5)	Decentralized (io.net, Akash)
Listed H100 $/hr	$4.00–8.00	$1.50–2.50
Capacity	Single operator, finite regions	Aggregated long-tail, global
SLA	First-party, contractual	Reputation + staking + attestation
Network	InfiniBand intra-pod	Mixed: regional, often Ethernet
Best for	Training, low-latency, regulated	Inference, batch, embarrassingly parallel
Worst for	Cost-sensitive batch	Synchronous all-reduce training

Where the spread comes from (one-liner): decentralized $/hr ≈ provider marginal cost + token incentive, while hyperscaler $/hr ≈ amortized capex + datacenter overhead + SLA premium + margin. The first equation has three terms; the second has five, and three of them are fat.

Sticky number: 30–60% cheaper than AWS for equivalent inference SKUs, with the caveat that synchronous training over heterogeneous networks still loses to a dedicated InfiniBand cluster by 2–5×.

The rest of this guide is which workloads actually port over, what trust models hold up under adversarial providers, and where the math stops working.

The premise

The hyperscaler pricing has fat margins. NVIDIA sells an H100 for ~$30k. Lease pricing on AWS is $4-8/hour, paying back the H100 capex in ~6 months — and that's including AWS's overhead, datacenter, networking, and profit margin.

Anyone with H100s and electricity can offer them at $2/hour and still profit. Decentralized marketplaces aggregate this long tail of providers (small clouds, individual operators, retired enterprise hardware) and offer it as a service.

The challenge: making heterogeneous, geographically-distributed, untrusted hardware usable for production AI workloads. That's where trust primitives, verification mechanisms, and routing logic come in.

The major players

io.net

The largest by GPU count in 2026. Aggregates GPUs from regional clouds, individual operators, and crypto mining farms.

Inventory: ~50,000 GPUs aggregated.
Workloads: inference, training, embarrassingly parallel.
Pricing: 40-60% below AWS for equivalent SKUs.
Token: $IO. Used for payment and provider incentives.

Akash

The original decentralized cloud. Started general-purpose, expanded into GPU.

Inventory: smaller GPU pool than io.net.
Workloads: containerized inference, batch jobs.
Pricing: typically 50% below AWS.
Token: $AKT.

Render Network

Originally for graphics rendering, expanded to AI.

Inventory: distributed providers, mixed consumer + datacenter.
Workloads: rendering, image/video AI inference, batch.
Pricing: variable, often very competitive for graphics workloads.
Token: $RNDR.

Aethir

Focused on real-time and gaming-adjacent inference.

Inventory: heavy on consumer-grade and edge GPUs.
Workloads: latency-sensitive inference, especially gaming/AR/VR.
Token: $ATH.

Bittensor compute subnets

Bittensor's various subnets host compute services in a decentralized fashion. Specific subnets focus on inference, training, embeddings.

Different from generic marketplaces: each subnet incentivizes specific work.
Pricing: variable per subnet, often very low for the long tail.

Vast.ai

Centralized but operates similarly: aggregates heterogeneous providers, offers them through one interface. Not blockchain-based.

Inventory: ~30,000 GPUs.
Pricing: spot-style, very flexible.
The closest "non-token" version of decentralized GPU.

Why inference works, training doesn't

Inference: a natural fit

Inference is "embarrassingly parallel" at the request level. Two inference requests don't need to communicate with each other. The request just needs the model loaded somewhere, and a GPU to run it.

Routing logic:

Provider has H100 with Llama-3 70B loaded → eligible for routing.
Request comes in → routed to a healthy provider with the model.
Provider runs inference, returns result.
Trust: result verified via cross-checking with a small sample of redundant requests.

This works. io.net and similar serve millions of inference requests per day.

Training: the obstacles

Training requires:

All GPUs participating in a single job.
Constant inter-GPU communication (collectives) at high bandwidth.
Trust that all GPUs are computing correctly (no Byzantine failures).
Synchronized execution.

These don't compose well with heterogeneous, untrusted, geographically-distributed GPUs:

Heterogeneous hardware: different GPUs have different speeds; the slowest dictates step time. Stragglers are catastrophic.
Network: GPUs in different datacenters communicate over WAN (millisecond latency, low bandwidth). Collectives become impossible.
Trust: a malicious provider could submit garbage gradients without being caught for many iterations.
Synchronization: parallel training requires lockstep. Decentralized providers can't reliably maintain this.

The state of the art for "decentralized training":

Federated learning: separate models train locally, only weights aggregate. Different goal than frontier training.
DiLoCo (DeepMind, 2023) and OpenDiLoCo (Prime Intellect, 2024): outer-/inner-loop optimizers that cut inter-node bandwidth by ~500×. Viable for moderate-scale models trained across geographically distributed clusters; not yet competitive with synchronous training at frontier scale.
SWARM Parallelism (Ryabinin et al., 2023): heterogeneous, fault-tolerant pipeline parallel — the canonical "train on unreliable hardware" approach.
DisTrO (Nous Research, 2024): reports ~1000× bandwidth reduction; still early but the most aggressive bandwidth-reduction result published to date.

For frontier-scale training in 2026, you're on a centralized cluster. Decentralized training remains a research direction — see References for the full reading list.

Embarrassingly parallel batch

Workloads like:

Running embeddings over millions of documents.
Image generation pipelines.
Hyperparameter sweeps.
Data preprocessing.

These work great on decentralized GPU. Each unit of work is independent.

Trust and verification

The key innovation of decentralized compute: making untrusted hardware usable.

Mechanisms

Redundant execution: same request runs on N providers. Compare results. Quorum wins. If one provider returns garbage, the redundancy catches it.

Cost: N× compute. Used for high-value or audit-required requests.

Sampling: most requests run once; a small fraction (e.g., 1%) re-run for verification. If a provider's results disagree, deprioritize them.

Cost: 1% overhead. Used for typical inference.

Cryptographic proof of work: provider must demonstrate they actually ran the model. Mechanisms include:

Trusted Execution Environments (TEEs like Nvidia Confidential Computing, Intel TDX): hardware-attested execution.
Zero-knowledge proofs: cryptographic guarantee but currently impractical for LLMs.
Proof of Sampling (covered in Verifiable Inference): statistical verification.

Cost: TEE adds 2-5% overhead. ZK is 1000-10000× slower (not practical). Proof of Sampling is the emerging middle ground.

Reputation systems: providers earn reputation over time. Low-reputation providers are sampled more aggressively.

The combination: redundancy for high-stakes, sampling + reputation for normal traffic. Adequate for production inference; not yet adequate for frontier training.

Pricing comparison vs hyperscalers

Indicative numbers, mid-2026:

Provider	H100 SXM hourly
AWS p5.48xlarge (8× H100)	$4.50/hr/GPU on-demand
GCP A3	$5.00/hr/GPU on-demand
Azure ND H100 v5	$4.20/hr/GPU on-demand
CoreWeave	$2.50/hr/GPU reserved
Lambda	$2.30/hr/GPU on-demand
io.net	$1.50/hr/GPU
Vast.ai	$1.20-2.00/hr/GPU (spot-style)
Akash	$1.40/hr/GPU

The math: for a workload that costs $10k/month on AWS, it's $3-4k/month on decentralized. That's $80k/year savings for one team's serving infrastructure.

But: decentralized has different operational characteristics. The savings are real but conditional.

Real-world performance

Inference latency

AWS H100: P50 30ms TTFT, P95 50ms.
io.net H100: P50 35ms, P95 80ms.

The decentralized P50 is competitive; P95 is worse due to provider variance. For SLA-sensitive workloads, redundant routing helps.

Throughput

For non-latency-sensitive batch inference, throughput is comparable. Decentralized can be cheaper in absolute terms.

Reliability

Hyperscalers offer SLAs (99.9% uptime). Decentralized typically offers best-effort or quorum-based guarantees.

For mission-critical workloads where downtime is expensive, hyperscalers still win on operational maturity.

Cold-start

AWS: model load 60-180s for Llama-3 70B (network from S3).
io.net: depends on provider; 60-300s.

Cold-start variance is wider on decentralized.

When to use decentralized

Inference at scale, cost-sensitive

If you're serving millions of inference requests and price elasticity is high (a 50% price drop matters to your unit economics), decentralized makes sense.

Embarrassingly parallel batch jobs

Embedding pipelines, batch inference, data labeling. The independent unit of work fits naturally.

Image/video generation

Render Network and similar are competitive for these workloads.

Hyperparameter sweeps

Each sweep run is independent. Spot instances + decentralized = cheap experimentation.

Background-priority workloads

If you have tolerant SLAs (e.g., "complete by tomorrow"), decentralized's variability is fine.

When not to

Latency-critical interactive serving

If your P99 SLA is tight (sub-second), decentralized provider variance hurts. Stick with hyperscalers or dedicated GPU clouds.

Training (currently)

Frontier training requires cluster-grade networking and homogeneous hardware. Decentralized doesn't deliver this in 2026.

Compliance-heavy workloads

Regulated industries (healthcare, finance) often require known-provider, audited infrastructure. Decentralized's heterogeneity is a compliance challenge.

Workloads with strict data residency

Decentralized routing may send data across jurisdictions. If your data must stay in EU, US, or specific regions, decentralized is hard to use.

Mission-critical with revenue impact

If 1% downtime costs $1M, the savings on decentralized aren't worth the operational risk.

Operational considerations

API integration

Most decentralized GPU platforms expose OpenAI-compatible APIs. Drop-in replacement for openai.com/v1/chat/completions.

Model availability

Provider has to have the model loaded. For popular models (Llama-3 70B, Qwen2.5 72B, etc.), capacity is usually available. For obscure models, you may need to bring your own (which means cold-start cost).

Spot vs reserved

Decentralized platforms offer "spot" pricing (cheaper, can be reclaimed) and "reserved" (more expensive, guaranteed). Mostly use spot for batch, reserved for serving.

Multi-region routing

Most platforms route to the nearest healthy provider. Geographic proximity matters for latency.

Monitoring

Same metrics as hyperscaler — TTFT, ITL, error rate, throughput. Most platforms expose them via standard APIs.

Failover

Configure clients to fall back to a hyperscaler if the decentralized provider has issues. Hybrid is the safer pattern.

The token-economics question

Skeptical view: the token mechanics are largely incidental to the actual value.

The real value: aggregating underutilized GPU capacity, routing it intelligently, providing trust primitives. None of this fundamentally requires a token. Vast.ai does it without a token.

The token's role: aligning incentives across many independent providers without a central operator. Tokens make it cheap to bootstrap a network when no single party can or will pay all providers up front.

But: the token economy adds complexity, regulatory exposure, and failure modes (token price volatility affecting provider participation).

For sophisticated buyers: the underlying compute economics are what matter. The token is a financing mechanism for the network's bootstrap. Once mature, networks may operate effectively as "tokenless" service providers from a buyer's perspective.

For investment thesis: token gains are speculative. Cost-savings on actual compute usage are real and quantifiable.

A short history of decentralized compute

Decentralized GPU compute didn't appear suddenly. Background:

2009-2013: Bitcoin mining showed that distributed individuals can be incentivized to provide compute resources via tokens.

2014-2018: early attempts at general compute marketplaces (Golem, iExec). Limited adoption due to ecosystem immaturity.

2018-2020: Rendering networks (Render Network) gain traction for Blender/3D rendering workloads.

2020-2022: GPU shortages during crypto bull runs and AI boom. Idle GPU capacity becomes economically interesting.

2023: Akash Network launches GPU support. io.net launched. Bittensor's compute subnets emerge.

2024: Inference workloads at scale on decentralized networks. Real cost savings demonstrated.

2025: TEE integration begins. Trust mechanisms mature.

2026 (current): decentralized inference is a real alternative for cost-sensitive workloads. Training largely centralized.

The trajectory: from niche to real alternative. Still small relative to hyperscalers but growing.

Trust mechanism deep dive

The technical mechanisms that make decentralized GPU compute viable.

Reputation systems

Each provider has a reputation score. New providers start with low reputation; gain it by serving requests honestly. Higher reputation = more requests routed.

The trick: reputation must be tied to identity (sybil-resistant), and corrections must propagate.

io.net's reputation system: providers stake tokens. Slashing for bad behavior. Rewards for honest service. New providers can build reputation but can't immediately serve high-value workloads.

Cryptographic attestation (TEEs)

Hardware-attested execution. NVIDIA Confidential Computing for H100/H200/B200.

Provider proves to client: "This is a genuine NVIDIA GPU running this firmware version."

If the attestation matches expected values, client trusts the GPU. See Verifiable Inference for details.

Proof of Sampling

Audit a small fraction of requests. If audit detects fraud, slash provider's stake.

Used by Bittensor's compute subnets. Economic incentive enforces honesty.

Redundant execution

Run the same request on multiple providers. Compare results. Quorum decides.

Expensive (3-5× compute) but provides high confidence. Used for critical requests.

Token economics

Tokens align provider and consumer incentives. Providers earn tokens for service; lose tokens for misbehavior.

Token price volatility affects participation. Stablecoin-pegged or USD-denominated payments are emerging to reduce this.

Network architectures compared

The major decentralized GPU networks differ in architecture.

io.net

Centralized orchestration with decentralized providers.

Clients → io.net coordinator → ranked providers → execute
                              → audit pool (1% sampling)
                              → token settlement

io.net runs the coordinator; providers run the actual GPUs. Token-incentivized.

Akash

Container-based marketplace. Bidding model.

Clients post task → providers bid → lowest bid wins → execute
                  → blockchain records transaction
                  → settled in AKT tokens

More general-purpose than io.net (originally for any cloud workload, not specifically AI).

Render Network

Specialized for rendering workloads, expanded to AI.

Tokenized render coordinator. Providers earn RNDR for completed work. Decentralized scheduling.

Bittensor compute subnets

Each subnet is a specialized network for a specific compute service. TAO tokens and dTAO tokens align incentives.

Subnet 4 (BitMind), Subnet 27 (compute), and others provide compute services. Each has its own reputation and audit mechanisms.

Aethir

Edge-focused. Aggregates consumer GPUs and edge servers for real-time inference.

Used in gaming and AR/VR contexts where latency matters.

Vast.ai (centralized but similar)

Not blockchain-based but operates similarly. Aggregates heterogeneous GPU providers and routes workloads.

The closest "non-token" alternative.

Pricing dynamics

How decentralized GPU pricing actually moves.

Spot vs reserved

Most networks offer spot pricing (cheaper, can be reclaimed) and reserved (more expensive, guaranteed).

For batch workloads: spot is fine. For interactive serving: reserved or hybrid.

Auction-based vs marketplace

io.net uses fixed pricing per SKU. Akash uses auction-based bidding.

Auctions can produce lower prices (true market-clearing) but more volatile.

Token-denominated price

Network token prices fluctuate. Underlying compute cost is more stable.

Most modern networks let users pay in fiat (USDC) at provider's option. Reduces volatility.

Race-to-the-bottom risk

Without quality controls, providers compete on price → quality drops. Reputation and audit mechanisms counter this.

In practice, networks with strong audit mechanisms have stable prices (~30-50% below hyperscaler).

Comparison: hyperscaler vs decentralized

Mid-2026 indicative pricing for H100 SXM:

Source	Hourly per GPU	Notes
AWS p5.48xlarge	$4.50	on-demand
AWS p5.48xlarge reserved 1yr	$2.80	committed
GCP A3	$5.00	on-demand
Azure ND H100 v5	$4.20	on-demand
CoreWeave	$2.50	reserved
Lambda	$2.30	spot-like
io.net	$1.50	average across tier
Vast.ai	$1.20-2.00	spot
Akash	$1.40	average

The 30-60% delta between hyperscaler on-demand and decentralized is the value proposition.

H200 and B200 pricing in 2026

The H200 (141 GB HBM3e) and B200 (192 GB HBM3e, FP4) are the 2026-relevant SKUs for serious inference. Pricing as of mid-2026:

SKU	AWS on-demand	CoreWeave reserved	io.net	Vast.ai spot	Aethir
H100 SXM	$4.50/hr	$2.50/hr	$1.50/hr	$1.20-2.00/hr	$1.40/hr
H200 SXM	$5.50/hr	$3.20/hr	$2.20/hr	$1.80-2.80/hr	$1.90/hr
B200 SXM	$7.50/hr (limited)	$4.50/hr	$3.40/hr (limited)	not yet	not yet
L40S	$2.10/hr	$1.20/hr	$0.70/hr	$0.50-0.90/hr	$0.65/hr
RTX 4090 (consumer)	n/a	n/a	$0.35/hr	$0.20-0.50/hr	$0.30/hr

The headline: B200 supply on decentralized is constrained in mid-2026 because hyperscalers and frontier labs have first-call on Blackwell allocations. H200 supply is healthier and the price gap to AWS is widest. RTX 4090 supply is essentially infinite on consumer-hardware decentralized networks; the price floor approaches electricity cost.

Cost-per-million-tokens, not cost-per-GPU-hour

GPU-hour pricing is the misleading metric. Buyers care about $/million tokens served at a given TTFT/ITL target. For Llama-3.3-70B FP8 served at 20 tokens/sec/request with batch 32:

Provider	$/hour	tokens/sec/GPU	$/M tokens (decode)
AWS p5 H100	$4.50	1800	$0.69
AWS p5e H200	$5.50	2400	$0.64
CoreWeave H200	$3.20	2400	$0.37
io.net H100	$1.50	1700 (provider variance)	$0.25
io.net H200	$2.20	2350	$0.26
Vast.ai H100 spot	$1.40 avg	1600 (variance)	$0.24
OpenRouter aggregated	varies	varies	$0.30-0.50
Together AI hosted	$0.88/M	n/a	$0.88
Anthropic API (Haiku 3.5)	$1.00/M output	n/a	$1.00

Self-hosted on decentralized typically lands at $0.20-0.30/M tokens for Llama-3.3-70B output. The published frontier-API pricing (Claude, GPT-4 class) at $5-15/M output reflects model capability and margin, not the underlying compute cost. See the AI inference cost economics guide for the full decomposition.

Real workload deployments

What's actually running on decentralized GPU networks.

Inference at scale

Llama-3 70B inference, Qwen2.5 72B, Mistral models — all common on decentralized networks.

Cost-sensitive companies route their inference to networks like io.net for serving.

Image generation

Stable Diffusion XL, Flux — heavily used on Render Network and similar.

Stateless, easily redundantly verified, perfect fit.

Embeddings and batch processing

Embedding models (BGE, gte, etc.) for vector databases.

Batch nature makes these ideal for spot-priced decentralized capacity.

Fine-tuning

LoRA fine-tuning for domain-specific models. Single-node workloads fit decentralized providers easily.

Full fine-tuning is harder due to multi-GPU requirements.

Limited training

Some experimental decentralized training. Not yet competitive with centralized.

Operational patterns

How teams actually use decentralized GPU networks in production.

Hybrid deployment

Most production: hyperscaler + decentralized hybrid.

Latency-critical traffic on hyperscaler.
Background and batch on decentralized.
Failover from decentralized to hyperscaler if needed.

API integration

Most networks expose OpenAI-compatible APIs. Drop-in replacement:

client = OpenAI(
    base_url="https://api.io.net/v1",
    api_key=os.getenv("IONET_API_KEY")
)
response = client.chat.completions.create(
    model="meta-llama/Llama-3.3-70B-Instruct",
    messages=[...]
)

Same code as OpenAI. Different costs.

Quality validation

Periodically: send the same request to your hyperscaler-hosted model and the decentralized provider. Compare outputs.

If quality regresses: the decentralized provider may be cheating or have a bad model. Switch providers.

Budget allocation

Set monthly budgets per network. Auto-failover if budget exhausted.

Multi-network sharding

Don't rely on one network. Multiple networks (io.net + Akash) for redundancy.

Future directions

Where decentralized GPU compute is going.

TEE for confidential workloads

NVIDIA Confidential Computing rollout will expand decentralized providers' addressable market into compliance-driven workloads.

Frontier training on decentralized

Hard. DiLoCo and similar techniques may eventually enable it. By 2028? Speculative.

Specialization

Some networks specializing for specific workloads (e.g., Aethir for real-time, Render for graphics). May become more niche-focused.

Hyperscaler response

Hyperscalers reducing prices in response. Continued pressure on pricing.

Convergence

Centralized and decentralized economics converging. Both becoming "compute marketplaces" with various trust models.

The clean line between them blurs.

Centralized but cheaper: the specialist GPU clouds

Decentralized networks are not the only alternative to hyperscalers. A class of specialist GPU clouds offers most of the cost benefit with less of the operational complexity. Knowing where each one fits is the difference between paying double for the wrong fit and paying half for the right one.

CoreWeave

The largest specialist GPU cloud in 2026. Started in 2017 as a crypto-mining operation, pivoted to AI compute. H100 SXM reserved pricing around $2.50/hr, H200 around $3.20/hr, B200 around $4.50/hr. Multi-region with strong InfiniBand pods suitable for training. Customer mix: AI labs, OpenAI infrastructure, several frontier-adjacent customers. The premium specialist; price within 20-40% of hyperscaler with comparable SLAs.

Lambda Labs

Originally a workstation vendor, now a specialist GPU cloud. On-demand H100 around $2.30/hr, H200 around $2.80/hr. Lambda's strength is the ease of on-demand burst capacity — no reservation required, instances spin up in minutes. Customer mix: researchers, smaller labs, fine-tuning workloads.

RunPod

Spot-style pricing with both "secure cloud" (datacenter-grade) and "community cloud" (provider-aggregated) tiers. H100 secure around $2.00-2.50/hr, community around $1.20-1.80/hr. Best for cost-sensitive batch and experimentation. Limited InfiniBand availability; not ideal for synchronous multi-node training above 16 GPUs.

Crusoe

The differentiator: stranded power (flared natural gas, renewable curtailment). H100 around $2.20-2.80/hr. Strong sustainability story for ESG-conscious customers. Smaller global footprint than CoreWeave; fewer SKUs.

Voltage Park and Tensorwave

Newer entrants. Voltage Park (philanthropic project, ~$0 margin model on H100 capacity intended for research). Tensorwave (AMD MI300X specialist, attractive for those running AMD-optimized workloads). Both are smaller but priced aggressively for their target customers.

FluidStack

Aggregator across multiple providers (similar to a centralized version of decentralized marketplaces). Pricing varies by underlying provider, typically $1.50-2.50/hr for H100. The convenience-vs-cost trade is steeper than going direct to a specialist; useful if your workload is small enough that single-provider lock-in matters.

Together AI, Fireworks, Anyscale, OctoML

API-tier providers that abstract away the GPU rental entirely. You pay per token, not per GPU-hour. Together AI hosts open-weight models at $0.60-0.90 per million output tokens for Llama 3.3 70B; Fireworks similar; both offer fine-tuned model hosting. The trade-off: 30-100% premium over self-hosted on dedicated GPU but zero operational overhead. The right answer for most teams below 100M tokens per month.

Comparison: specialist clouds vs decentralized vs hyperscaler

Tier	H100 $/hr (2026)	SLA	InfiniBand	Best for
Hyperscaler on-demand	$4.00-8.00	99.9%+	Yes (within pod)	Mission-critical, regulated
Hyperscaler reserved 1yr	$2.50-3.50	99.9%+	Yes	Predictable production
CoreWeave reserved	$2.50	99.9%	Yes	Specialist mid-large workloads
Lambda on-demand	$2.30	Best-effort	Limited	Burst, research, fine-tuning
RunPod secure	$2.00-2.50	99.5%	Limited	Cost-aware batch and inference
Crusoe	$2.20-2.80	99.5%	Limited	Sustainability-driven workloads
RunPod community	$1.20-1.80	None	No	Fault-tolerant batch
io.net	$1.50	None	No	Cost-sensitive aggregated inference
Vast.ai	$1.20-2.00	None	No	Spot, hyperparameter sweeps
Decentralized consumer	$0.20-0.50 (4090)	None	No	Single-GPU fine-tunes, small models

The specialist tier (CoreWeave, Lambda, RunPod, Crusoe) is what most teams actually use when they outgrow API-tier providers and before they take on hyperscaler-grade reliability. The decentralized tier is a further step in the cost-down direction with corresponding additional operational responsibility.

Decentralized training in depth: DiLoCo, SWARM, DisTrO, Petals

Training across decentralized infrastructure has been an active research direction since around 2020 and finally produced some practically usable methods in 2024-2025. None of them yet competes with synchronous training on a tuned InfiniBand pod at frontier scale, but they push the bandwidth requirement low enough to make multi-region training viable for 1-30B parameter models. This section covers the methods that matter.

DiLoCo: the outer-inner loop

DiLoCo (Douillard et al., 2023 — arXiv:2311.08105) is the simplest and most influential of the low-communication training methods. Each worker runs many SGD steps locally (the inner loop, typically 100-500 steps) with no inter-worker communication. After the inner loop, workers compute "outer gradients" (the difference between their local model and the shared starting point) and average them via a slow all-reduce (the outer loop). The bandwidth requirement drops by approximately 500x relative to synchronous SGD because the all-reduce happens once per 500 inner steps instead of once per step.

The convergence guarantee: under standard assumptions, DiLoCo converges to the same fixed point as synchronous SGD with similar FLOPs, at a small wall-clock penalty. In practice the penalty is 1.1-1.5x more steps for the same final loss, which is much less than the bandwidth savings.

OpenDiLoCo (Jaghouar et al., 2024 — arXiv:2407.07852) is Prime Intellect's open-source reproduction, used in their cross-continent training of a 1B parameter model in 2024 and a 10B parameter model in 2025. The cross-continent demonstration is the most striking applied result: a model trained partly in Paris, partly in San Francisco, over commodity internet links, reaching loss curves competitive with a centralized baseline.

SWARM Parallelism: heterogeneous pipeline

SWARM Parallelism (Ryabinin et al., 2023 — [arXiv:2301.11913]) addresses the heterogeneity problem directly. Instead of insisting on lockstep workers, SWARM uses a randomized pipeline where workers dynamically pick up batches based on their availability. Failures and stragglers don't block forward progress; the pipeline reroutes around them. The trade-off: lower effective utilization, more complex orchestration.

SWARM has been the technical backbone of several proof-of-concept training runs on Petals and similar volunteer-compute projects. At small scale (single-digit billion parameters), it works. At frontier scale, the orchestration overhead grows faster than the bandwidth savings.

DisTrO and aggressive bandwidth reduction

Nous Research's DisTrO (2024) reports approximately 1000x bandwidth reduction relative to synchronous all-reduce, achieved via a combination of low-rank gradient compression, error feedback, and outer-loop averaging similar to DiLoCo. The published technical report shows competitive loss curves at modest scale; large-scale demonstrations are still pending as of mid-2026.

The trajectory of bandwidth reduction methods: each generation drops requirements by another order of magnitude, and the slope hasn't visibly flattened yet. Whether the next step (10000x reduction, true commodity-internet training of frontier models) is achievable in the next 3-5 years is the central open question for decentralized training.

Petals: collaborative inference at frontier scale

Petals (Borzunov et al., 2022 — [arXiv:2209.01188]) is not a training method but a collaborative inference framework that's worth knowing about because it demonstrates the same techniques work for serving. Volunteers each host a few layers of a large model (BLOOM-176B in the original demo); a request fans out across the volunteer pool. Latency is variable (multi-second TTFT), throughput is limited, but the marginal cost approaches zero. The pattern is more useful as a research and accessibility tool than as a production serving stack — but it foreshadows what cross-region decentralized inference may look like at frontier model scale.

Federated learning: FedML, Flower

A separate but adjacent tradition: federated learning trains a model across many devices without centralizing the data. Bandwidth is heavily constrained (often the limiting factor); privacy is the headline benefit. Frameworks like FedML and Flower implement the standard federated averaging and its variants. For LLMs specifically, federated training has been demonstrated for fine-tuning (LoRA over federated providers) more than for full pretraining. The use case is regulatory rather than economic: when data cannot leave the source jurisdiction, federated is sometimes the only path.

When decentralized training works in 2026

Use case	Decentralized viable?	Best method
Frontier pretraining (70B+)	No	Centralized only
Mid-scale pretraining (1-30B)	Yes, with 1.1-1.5x wall-clock penalty	DiLoCo / OpenDiLoCo
LoRA fine-tuning	Yes	Federated (FedML, Flower)
Full-parameter fine-tuning (7-30B)	Yes, with caveats	DiLoCo or SWARM
RLHF / RLVR rollouts	Yes (rollouts are inference)	Standard decentralized inference
RLHF / RLVR policy updates	No	Centralized only

The honest summary: decentralized training has moved from "doesn't work" in 2022 to "works for specific use cases below frontier scale" in 2026. Whether it scales to frontier in 2028-2030 is the central open question, and the answer determines whether decentralized infrastructure remains a complement to centralized training or becomes a substitute.

Bittensor TAO and subnet economics in 2026

Bittensor warrants its own section because its structure is different from io.net or Akash in ways that matter for builders. The mental model is not "a marketplace for GPU rental" but "a per-task incentive game where the network rewards miners for producing valuable outputs of a specific kind."

The subnet pattern

Each subnet is a specialized economy for a specific task. Subnet 9 (pretraining), Subnet 8 (proprietary trading), Subnet 3 (text prompting), Subnet 4 (Targon), Subnet 27 (compute), Subnet 21 (FileTAO storage), Subnet 11 (dippy roleplay) — each has its own validators, miners, and incentive mechanism. Miners produce outputs (model inferences, training contributions, file storage proofs); validators score them; rewards distribute according to score-weighted stake.

The 2024 transition to dTAO (dynamic TAO) gave each subnet its own native sub-token whose price is set by the AMM-style swap with TAO. Builders launching a subnet effectively bootstrap a small token economy with TAO as the reserve.

Why this matters for GPU economics

Bittensor subnets are not optimized for general GPU rental. They are optimized for producing the specific output their incentive game rewards. The practical implications:

Inference on Bittensor is competitive in price for the specific models and tasks that have active subnets (Llama-3-class chat on Subnet 3 or 4, specific embedding models on dedicated subnets). For arbitrary models or workloads, no.
Synthetic data generation is a sweet spot. Several subnets run massive scale text generation as their incentive game; the byproducts (validated, scored outputs) are useful training data. Costs end up dramatically below comparable hyperscaler API pricing for the volumes involved.
Reasoning rollouts are an emerging fit. The verifiable-reward structure of math and code RLVR maps naturally to Bittensor's validator scoring model. As of mid-2026 a small number of subnets are experimenting with this.

Subnet 9 (pretraining) and subnet 11 (roleplay) as examples

Subnet 9 incentivizes miners to contribute to a shared model that the network treats as canonical. Validators evaluate miner contributions against a held-out loss benchmark. The economic model rewards miners who can run efficient training at scale. The practical output is a continuously updated open-weight model trained collaboratively; the engineering quality varies widely across miner contributions.

Subnet 11 (roleplay / dippy) runs character-driven chat models. The incentive structure rewards miners whose models satisfy user preferences as measured by validators. The output is a continuously improving roleplay model with substantial token-incentivized training behind it.

The pattern across subnets: the network can produce surprisingly good models for narrow tasks because the incentive game pushes miners to optimize for that specific task continuously. It cannot produce general-purpose frontier models because the incentive structure doesn't reward general capability.

Token economics critique

TAO and the subnet sub-tokens have substantial speculative trading volume. Critics argue most of the network's activity is token-driven rather than utility-driven. Defenders argue the token incentives are what enable the network to produce valuable outputs at low marginal cost. The empirical answer depends on which subnets you look at: some have genuine usage that's growing independent of token price; some are entirely speculation-driven.

For builders: treat Bittensor as a research-tier substrate. Useful for specific narrow workloads where a subnet's incentive game aligns with your needs. Not yet a substitute for production inference infrastructure at scale.

Cost per FLOPS by provider tier

A different way of slicing the GPU economics: rather than dollar per GPU hour, what is the dollar per FP16 PFLOP-hour, FP8 PFLOP-hour, and FP4 PFLOP-hour across the provider landscape? This is the right metric when comparing across generations.

H100 SXM delivers approximately 1 PFLOP FP16, 2 PFLOP FP8. H200 SXM: same FLOPS as H100 (memory upgrade, not compute upgrade). B200 SXM: approximately 2.5 PFLOP FP16, 5 PFLOP FP8, 10 PFLOP FP4. (Background on these numbers in the NVIDIA datacenter GPU guide.)

Provider	SKU	$/hr	FP16 PFLOP/hr	$/FP16 PFLOP-hr	$/FP8 PFLOP-hr
AWS on-demand	H100	$4.50	1	$4.50	$2.25
AWS on-demand	B200	$7.50	2.5	$3.00	$1.50
CoreWeave reserved	H100	$2.50	1	$2.50	$1.25
CoreWeave reserved	H200	$3.20	1	$3.20	$1.60
CoreWeave reserved	B200	$4.50	2.5	$1.80	$0.90
Lambda on-demand	H100	$2.30	1	$2.30	$1.15
RunPod secure	H100	$2.20	1	$2.20	$1.10
io.net	H100	$1.50	1	$1.50	$0.75
io.net	H200	$2.20	1	$2.20	$1.10
io.net	B200	$3.40	2.5	$1.36	$0.68
Vast.ai spot	H100	$1.40	1	$1.40	$0.70
Decentralized consumer	RTX 4090	$0.35	0.165 (FP16 boost)	$2.12	n/a (no FP8)

A few observations from the table:

B200 wins on $/PFLOP at every tier. Even at hyperscaler prices, B200 is cheaper per FLOP than H100. The capex investment in Blackwell pays back through better compute density.
H200 is a memory upgrade, not a compute upgrade. $/FP16 PFLOP-hr is similar between H100 and H200 at the same provider. The economic argument for H200 is bandwidth-bound workloads where the HBM3e advantage matters.
Consumer GPUs are not competitive on $/PFLOP at production-scale inference. They look cheap in absolute terms but the per-FLOP cost is comparable to or worse than tuned datacenter rentals. The consumer-GPU win is for small models that fit in one card and don't need FP8 — niche.
Decentralized B200 supply is constrained. The numbers in the table assume providers are willing to offer Blackwell at competitive prices; in practice 2026 supply is tight and decentralized B200 hours often command a premium over the listed rates.

For pure compute-cost optimization on FP8-capable workloads, the cheapest tier in mid-2026 is decentralized B200 (when available) or io.net / Vast.ai H100 spot. The cheapest tier with usable SLAs is CoreWeave or Lambda reserved.

Akash, io.net, Aethir: protocol-level deep dives

Each major decentralized network has architectural choices that affect what it's good for. The earlier "Major players" section gave the high-level take; this section unpacks the protocol-level details that matter for serious deployments.

Akash: container-native auctions on Cosmos

Akash is a Cosmos-based blockchain with a deployment-and-bidding model. The deployer publishes a manifest (Docker container, resource requirements, geographic constraints, max price). Providers bid on the manifest with their pricing. The deployer selects a bid; deployment runs as a container on the chosen provider.

The architectural strengths:

Standard containers. Anything that runs in Docker runs on Akash. No custom SDK or framework lock-in.
Explicit pricing transparency. Bids are on-chain; the deployer sees the full provider market for their workload.
Geographic constraints. The manifest can specify a region, and only providers in that region bid.

The weaknesses:

GPU availability is smaller than io.net. Akash's GPU pool has grown but trails the largest networks.
Auction UX is unfamiliar. Most teams want fixed prices, not a bidding interface.
SLA enforcement is weak. Providers can disconnect; the recourse is reputation-based slashing rather than contractual.

Best for: containerized inference workloads where the deployer is comfortable with the auction model and willing to do per-provider validation. Worst for: drop-in API replacement.

io.net: coordinator-driven aggregation

io.net runs a centralized coordinator that maintains a pool of vetted providers, handles routing, and exposes a unified API. The token ($IO) is primarily an incentive instrument; payments to providers can be in IO or in USD-pegged stablecoins.

The architectural strengths:

Drop-in OpenAI-compatible API. Same code as openai.com works against io.net's endpoint.
Coordinator handles provider failover. When a provider goes offline, the coordinator transparently routes to another with the model loaded.
Tiered offerings. Stable tier (provider-vetted, no attestation), Verifiable tier (TEE-attested), reserved tiers for predictable capacity.

The weaknesses:

The coordinator is a single point of trust. Despite the "decentralized" label, io.net's coordinator can route requests, slash providers, and approve provider onboarding. A coordinator compromise affects the whole network.
Provider variance is real. P99 latency tail is dominated by occasional provider stalls.

Best for: cost-sensitive inference where the OpenAI-compatible API matters. Worst for: workloads requiring strong contractual SLAs.

Aethir: edge-focused, GPU-as-a-service

Aethir's architecture is built around edge providers (gaming PCs, regional servers) running consumer and prosumer GPUs. The token ($ATH) incentivizes providers; the network's selling point is low-latency inference for gaming and AR use cases.

The architectural strengths:

Latency optimization. Edge providers near end users produce competitive P50 latency for real-time use cases.
Consumer GPU support. Cheaper hardware base than datacenter networks.
Gaming and AR integrations. Native support for the workloads Aethir targets.

The weaknesses:

Consumer GPU memory caps. 24GB on 4090, 32GB on 5090; not enough for 70B+ inference without aggressive quantization.
Variable reliability. Consumer providers go offline more often than datacenter providers.
Smaller model library. Aethir's network has fewer pre-loaded models than the big general-purpose networks.

Best for: latency-sensitive inference on small-to-medium models in gaming and edge contexts. Worst for: large-model inference, training, batch.

Phala Network and Ritual: trust-focused alternatives

Phala builds on Intel SGX and NVIDIA Confidential Computing to offer TEE-attested compute as the headline feature. Ritual takes a similar approach with a different protocol design. Both target workloads where the verification of execution matters as much as the cost.

For most cost-sensitive deployments, the TEE overhead (2-5% for inference, more for training) is acceptable; for compliance-heavy workloads it's the entire point. The economic model resembles io.net more than Akash — coordinator-driven, fixed pricing — with the addition of cryptographic attestation per request. See verifiable inference for the cryptographic side.

Gensyn and verifiable training

Gensyn's pitch is decentralized training with verifiable correctness. The technical mechanism: probabilistic proofs that miners actually did the training they claim, with cryptographic commitments to intermediate states. As of mid-2026 Gensyn is on testnet with research-scale training; production mainnet remains pending. The economic model and the technical feasibility are both unproven at frontier scale.

Spot instance economics: AWS spot vs decentralized spot

Spot instances are the closest hyperscaler analog to decentralized spot. The economics are similar in shape: lower price, eviction risk, fault tolerance required. Understanding the differences clarifies when decentralized actually wins.

AWS spot

AWS sells unused capacity at 60-90% discount to on-demand pricing, with the catch that AWS can reclaim the instance with 2 minutes' notice. H100 instances on spot run around $1.20-2.50/hr (vs $4.50 on-demand). Eviction rates vary by region and instance type; H100 spot historically has higher eviction rates than CPU spot because AI demand is consistently high.

Workloads that work on AWS spot: batch jobs with checkpointing, hyperparameter sweeps, inference with auto-failover, fault-tolerant pipelines. Workloads that don't: long-running synchronous training without checkpointing, latency-bound serving.

Lambda spot, GCP spot, Azure spot

Comparable to AWS spot in shape; pricing varies. Lambda's spot-like offering (just lower-cost on-demand with no eviction guarantee) is one of the cheapest options. GCP and Azure offer preemptible/spot tiers with similar terms to AWS.

Decentralized spot

Most decentralized networks default to a spot-like model: capacity is provider-dependent, providers can leave, eviction is possible. Pricing $1.20-2.00/hr for H100 places decentralized spot in the same range as AWS spot but with different reliability characteristics: lower P95 reliability, no formal SLA, but typically more abundant capacity for the specific models the network has loaded.

When AWS spot wins over decentralized

When the workload requires InfiniBand (training, MoE serving with TP).
When the workload is integrated with other AWS services (S3, Bedrock, SageMaker).
When the compliance posture matters (SOC 2, HIPAA, FedRAMP).
When the team already has the AWS muscle memory.

When decentralized wins over AWS spot

Pure inference workloads on standard open-weight models.
Embarrassingly parallel batch (embeddings, data labeling).
Cost-sensitive workloads where the 30-50% additional discount matters.
Workloads in regions where AWS H100 capacity is constrained.

The honest summary: AWS spot is the better default for teams already on AWS. Decentralized spot is the better default for cost-driven teams without an AWS dependency. The crossover happens when the operational cost of integrating a new network exceeds the GPU cost savings.

What academics actually use

A useful sanity check on the decentralized-vs-hyperscaler debate: what do active researchers in the AI field actually run their experiments on? Survey data and public acknowledgments from 2024-2025 papers give a rough picture.

The dominant academic compute sources, in approximate order of usage volume:

University HPC clusters. Most major research universities have dedicated AI compute (Stanford SCSi, Berkeley CRC, MIT SuperCloud, CMU Bridges, etc.). For students and faculty, these are the cheapest path.
NSF-funded compute (NAIRR pilot). The National AI Research Resource pilot allocates compute via competitive grants. Significant for US academic work.
Hyperscaler research credits. AWS, GCP, and Azure all offer free or discounted compute to academic researchers, typically $5K-$50K of credits.
CoreWeave and Lambda academic discounts. Specialist clouds with reduced pricing for accredited research institutions.
Decentralized networks for batch and experimentation. Vast.ai is particularly popular for hyperparameter sweeps. io.net is used by some labs for inference-heavy experimentation.

Frontier-scale academic research (training 70B+ models) almost always happens via industry partnerships (Meta AI's collaboration grants, Google's collaborations, etc.) because the raw compute cost is beyond standard academic budgets. The smaller-scale work (1-7B parameter training, fine-tuning, evaluation) is split across all the tiers above. Decentralized is a meaningful slice — perhaps 15-25% of small-scale academic compute by 2025 — but not yet dominant.

The trajectory: as decentralized networks improve and academic budgets stay flat, the academic share of decentralized usage grows. This is one of the structural tailwinds for decentralized networks — they're growing a generation of users who will carry the relationships into industry.

Federated learning frameworks: FedML, Flower, NVFlare

Federated learning has its own software ecosystem, separate from the decentralized-GPU rental layer. Knowing the major frameworks is useful when the use case is privacy-driven rather than economics-driven.

FedML

FedML is the most established open-source federated learning framework. It supports cross-device federation (mobile and edge devices), cross-silo federation (organizations training jointly), and standard federated averaging variants. The training algorithms supported range from federated SGD to more sophisticated variants like FedProx and SCAFFOLD that handle the non-IID data distribution issues that pure federation produces.

FedML has been used in published case studies for hospital networks training jointly on patient data, mobile-device keyboard prediction training (similar to Google's Gboard), and cross-bank fraud detection models. The cost story is poor (each participant runs their own compute) but the privacy story is strong.

Flower

Flower (originally from a Cambridge research group, now an active open-source project) emphasizes flexibility — the framework wraps any PyTorch, TensorFlow, or JAX training loop into a federated-compatible client. Server logic is also pluggable.

For teams whose use case is "train a model where the data cannot leave each participant's premises," Flower is the lightest-weight integration. Production usage spans healthcare, financial services, and a long tail of regulatory-constrained domains.

NVFlare

NVIDIA's NVFlare is the enterprise-targeted federated learning framework. It integrates with NVIDIA's Clara healthcare AI stack and offers stronger compliance posture (audit logs, role-based access control, enterprise support). The user base skews toward healthcare and life sciences customers.

When federated learning is the right answer

Federated learning costs more than centralized training (each participant runs their own compute, plus coordination overhead). The use case is regulatory or competitive: when data cannot leave its source jurisdiction or its source organization. For pure cost optimization, federated is the wrong tool. For "train a model where the participants don't trust each other with the data," it's often the only tool.

Cross-reference to decentralized GPU

Federated learning and decentralized GPU rental are independent layers that can compose. A federated learning deployment can run each participant's local training on a decentralized GPU network (the participant pays for compute via decentralized rental). The two stacks address different problems — federated solves data privacy, decentralized rental solves compute cost — and the combination produces a deployment that is private by design and cheap by infrastructure.

Legal and compliance risk: jurisdictions, KYC, export controls

The legal posture of decentralized GPU networks has matured substantially since the 2022 wild-west era. The 2026 reality is constrained: most major networks now run KYC, comply with export controls, and respect data-residency requirements. The constraints are operationally significant for builders.

Export controls

US export controls on advanced GPUs (H100, H200, B200) apply to all operators in US jurisdiction regardless of "decentralized" labeling. Providers in China cannot legally serve H100 inference to US-sanctioned entities; networks cannot launder this restriction.

The practical pattern: networks require providers to attest jurisdiction, networks block requests from sanctioned countries, and high-volume customers go through standard export-compliance review. The arbitrage that early decentralized networks offered — "the network is decentralized, the export controls don't apply" — has largely closed.

The remaining gray areas: H20 (the China-market version of H200 with reduced FP32 performance), retired previous-gen hardware that is technically not export-controlled, and individual operators in non-aligned jurisdictions who may technically be out of compliance but are hard to enforce against.

KYC and AML

Most major networks now require KYC on providers above some volume threshold ($1K-$10K per month of provider revenue). The reason is tax reporting (1099-K equivalent in the US, EU equivalent) and AML compliance. The effect on the network is a smaller pool of casual providers and a larger pool of professional operators.

For customers, KYC is typically lighter — payment is via stablecoin or credit card with the standard payment-processor verification. High-volume customers go through enhanced verification.

Data residency

GDPR and similar laws require certain data to remain in specific jurisdictions. By default, decentralized networks route to any healthy provider regardless of location. Networks now offer region-locked tiers (io.net region-locked, Akash geographic constraints in deployment manifests) for residency-sensitive workloads.

For strict GDPR compliance, the operational stack is: region-locked routing + TEE attestation + a signed DPA from the network operator. Healthcare and finance teams currently lean toward centralized clouds with established compliance posture for these reasons.

Liability

The novel liability question: when a decentralized provider produces a harmful output, who is liable? The network operator? The provider? The customer who submitted the request? The answer is unclear in most jurisdictions. Networks have been adding terms-of-service language to push liability toward customers; courts have not extensively tested this.

For builders, the practical implication: don't rely on decentralized networks for workloads where output-related liability is significant. For content generation in regulated domains (medical advice, legal advice, financial advice), centralized providers with clearer liability terms are the safer choice.

Sanctions screening

US OFAC sanctions and similar require networks to screen customers against sanctioned lists. The 2026 standard: payment processors handle most sanctions screening at the payment layer; networks add additional screening at the API layer for high-volume customers.

The practical effect for builders: customers in OFAC-sanctioned jurisdictions cannot use decentralized networks legally, and networks have automated systems to detect and block such usage.

BOINC, Folding@Home, and the volunteer-compute heritage

Decentralized GPU compute did not start with crypto. The intellectual ancestors are BOINC (Berkeley Open Infrastructure for Network Computing) and Folding@Home — volunteer-compute projects that aggregated home computers for scientific workloads. The technical and operational lessons from these systems shape what today's decentralized networks get right and where they fall short.

BOINC and SETI@home

BOINC launched in 2002 as a generalization of SETI@home (1999), the first widely-deployed volunteer-compute project. The architecture: a central project server distributes work units to volunteer machines; volunteers crunch the work units and return results; the server validates results, typically via redundancy (the same work unit goes to multiple volunteers).

BOINC scaled to millions of contributors over its history. The peak compute aggregate exceeded several petaFLOPS during the late 2000s — meaningful even by datacenter standards of the time. Notable projects: SETI@home (radio signal analysis), Rosetta@home (protein folding), Einstein@home (gravitational waves), MilkyWay@home (galaxy modeling).

Folding@Home

Folding@Home (2000) ran the same pattern with a tighter focus on protein folding simulations. During the COVID-19 pandemic in 2020, Folding@Home briefly exceeded an exaFLOPS of aggregate compute — at the time, more than any single supercomputer.

What volunteer compute got right

Result verification via redundancy. Each work unit ran on multiple volunteers; results compared. This is the same pattern decentralized GPU networks now use for inference verification.
Asynchronous, embarrassingly-parallel workload selection. Both BOINC and Folding@Home only accepted workloads whose unit-of-work was independent. Decentralized GPU networks have inherited this constraint.
Reputation tracking. Volunteers had credit scores based on completed work. Decentralized networks call it staking and slashing; the mechanism is recognizable.
Open participation with minimal trust. No volunteer needed to be vetted up front; suspicious results just got rejected after the fact.

What volunteer compute could not solve

Latency. Volunteer computers have variable WAN latency; the projects worked because workloads tolerated days of turnaround.
Synchronous coordination. Neither BOINC nor Folding@Home ever supported workloads requiring tight inter-worker communication.
Trust beyond redundancy. When the project required confidentiality of the workload itself, volunteer compute could not provide it. (Folding@Home's work units were public; SETI@home's were public; nothing sensitive could run.)

The lineage to decentralized GPU

The current generation of decentralized GPU networks inherits volunteer compute's solutions to embarrassingly-parallel workloads and adds two new capabilities:

Trust primitives beyond redundancy. TEEs allow confidential workloads. Cryptographic attestation allows fine-grained verification.
Economic incentives via tokens. Volunteers participated for altruism, screen-saver utility, or contributor status. Token incentives broaden the participant base to anyone with hardware and electricity.

The continuing limits inherited from the volunteer-compute era:

Synchronous training across heterogeneous WAN workers remains hard.
Latency variance is structurally higher than centralized.
The trust budget for high-stakes confidential workloads remains constrained.

Understanding the BOINC heritage clarifies what decentralized GPU does and doesn't do. The current networks are an extension of a 25-year-old pattern, not a revolutionary departure.

HBM vs GDDR economics: why datacenter GPUs cost what they do

A frequently confusing question for newcomers to GPU economics: why does an H100 (80GB HBM3) cost 30x what an RTX 4090 (24GB GDDR6X) costs when both have similar peak FLOPS? The answer is mostly the memory subsystem, and understanding it clarifies why consumer-GPU decentralized networks have a structural ceiling.

The HBM premium

HBM (High Bandwidth Memory) is a stacked DRAM technology with dramatically higher bandwidth than the GDDR memory used in consumer GPUs. An H100 SXM has 3.35 TB/s of HBM3 bandwidth; an H200 SXM has 4.8 TB/s of HBM3e bandwidth; a B200 SXM has 8 TB/s. An RTX 4090's GDDR6X tops out around 1 TB/s — comparable on paper to an H100 but with much higher latency and lower sustained throughput under contention.

The cost: HBM is expensive to manufacture (3D-stacked silicon, advanced packaging, low yields) and supply is dominated by SK Hynix, Samsung, and Micron. NVIDIA's H100 BOM is reportedly 30-50% HBM cost; for H200 and B200 the HBM share is higher because the chips have more memory.

Why memory bandwidth dominates LLM inference

LLM decode is memory-bandwidth-bound. For each generated token, the model must read its weights from HBM. A 70B FP8 model is 70GB of weights; at 4.8 TB/s HBM3e bandwidth (H200), the theoretical decode throughput is around 65 tokens/sec per GPU on a single request. At 1 TB/s GDDR6X (4090), the theoretical throughput drops to around 15 tokens/sec per GPU, and the 70B model doesn't fit anyway.

This is why consumer GPUs lose at large-model inference: the bandwidth gap matters more than the FLOPS gap. A network full of 4090s can serve 7B models efficiently, can struggle on 30B models with aggressive quantization, and cannot competitively serve 70B+ models.

The capacity dimension

HBM also drives the maximum model size a single GPU can serve. 80GB on H100 fits Llama 70B in FP8 quantization (with some headroom for KV cache). 141GB on H200 fits 70B comfortably and allows aggressive long-context use cases. 192GB on B200 starts to fit 405B-class models in FP4. Consumer GPUs at 24-32GB can serve 7-13B models comfortably; for larger models they require multi-GPU NVLink, and consumer cards don't have the high-speed interconnect that datacenter cards do.

Implications for decentralized network strategy

The HBM bandwidth-and-capacity gap creates a clean stratification:

Consumer GPU networks (4090, 5090): Compete on small-model inference, batch, embeddings. Cannot competitively serve 70B+.
Datacenter H100 80GB networks: Compete on 7B-70B inference, with capacity for typical context lengths.
Datacenter H200 141GB networks: Compete on 70B+ inference and long-context workloads.
Datacenter B200 192GB networks: Compete on 400B+ inference and frontier-scale workloads.

A decentralized network's GPU mix determines its ceiling. io.net's H200/B200 inventory grew through 2025-2026 specifically to capture the upper tiers; networks dominated by consumer GPUs are structurally limited to the small-model end of the market.

What changes in the next generation

Rubin (the post-Blackwell generation, expected 2026-2027) is reported to ship with HBM4 at 8 TB/s+ per stack. Memory capacity per GPU is expected to grow to 288GB-512GB depending on SKU. This shifts the entire stratification upward: B200's current "frontier" position becomes the new mid-tier; H100 80GB becomes the new entry-level for serious model serving. Decentralized networks that invest in keeping up with the current generation maintain their position; networks dominated by older inventory lose ground.

Cross-provider routing patterns

Most production deployments at scale don't use one decentralized network in isolation. They route across providers based on real-time price, availability, and latency. The patterns matter.

OpenRouter and LiteLLM gateways

OpenRouter is the dominant aggregation gateway for AI inference in 2026. It exposes an OpenAI-compatible API and routes each request to the cheapest healthy provider with the requested model loaded. Underlying provider pool includes most major decentralized networks plus several specialist clouds. The routing latency is 5-30ms; the price savings vs sticking with a single network averages 15-25%.

LiteLLM is the open-source equivalent — a Python library that adapts to dozens of provider APIs and exposes a unified interface. Teams that need more control than OpenRouter's hosted service use LiteLLM behind their own routing logic.

Routing dimensions

A production gateway considers:

Price per million tokens for the requested model.
Provider health (last N requests' success rate and latency).
Geographic proximity for latency-sensitive requests.
Quality (output verification against a baseline if applicable).
Compliance tags (TEE-attested, region-locked, etc.) if required.
Budget remaining per provider per period.

The simple "cheapest healthy provider" rule is the default. Sophisticated deployments add quality-adjusted routing where the price is divided by a quality score, and weighted load balancing where multiple providers receive a fraction of traffic according to current cost-quality.

Provider warm-up and cache locality

A subtle pattern: routing the same user session to the same provider preserves KV cache locality. The first request loads the prefix; subsequent requests in the same conversation reuse it. Switching providers mid-session forces a cache rebuild, which can double TTFT.

Gateway implementations now offer session-affinity routing: a session identifier sticks to a provider for the session's duration unless the provider fails. The cost is some efficiency loss (the cheapest provider for request 5 may not be the one chosen for request 1) in exchange for cache locality.

Multi-network failover

The most important routing pattern operationally is multi-network failover. The gateway maintains health checks against multiple networks (io.net, Akash, Together AI, a hyperscaler backup) and routes around outages. The honest pattern is to always have a hyperscaler fallback even if it's only configured to take 0% of traffic; when the decentralized layer fails (which happens occasionally), the fallback prevents user-visible outages.

Cost-tracking discipline

Multi-provider routing makes cost tracking harder. The pattern that works: each request is tagged with the provider that served it, cost is computed from the provider's actual price (not the gateway's average), and a daily reconciliation compares provider bills to the gateway's accounting. The team that ships sustainable multi-provider deployment is the team that has this reconciliation automated.

The Web3 GPU bubble timeline and what survived

Decentralized GPU compute went through a hype-and-burst cycle between 2021 and 2024 that left a specific set of survivors. The pattern is informative for evaluating new entrants.

2021-2022: the first wave

Crypto mining infrastructure pivoted en masse toward "GPU compute for AI." Many were thinly-veiled mining operations with new branding. Tokens proliferated. Real workloads were limited.

Notable launches: Golem (2016, pre-bubble but rode the wave), iExec (2017), Render Network (2017, longer history).

2023: the AI inference moment

ChatGPT's late-2022 launch made AI compute scarcity a mainstream concern. Decentralized networks repositioned around AI inference. io.net launched. Akash added GPU support. Bittensor's compute subnets matured.

2024: the shakeout

Many networks failed to attract real workloads. Token prices crashed for projects without real usage. The survivors emerged: io.net (real inference at scale), Akash (mature operations), Render (graphics-anchored economy), Bittensor (incentive-game flexibility), Aethir (edge niche).

2025: consolidation

Specialist clouds (CoreWeave, Lambda) absorbed some of the demand that decentralized networks targeted. The survivors specialized further. The token-first business model lost credibility; the economics-first model gained share.

2026: stable but limited

Decentralized GPU networks are an established 5-15% of the compute market for cost-sensitive workloads. The token speculation has cooled. Real revenue from real workloads supports the surviving networks.

The lesson for evaluating new entrants: real usage, transparent pricing, and willingness to support fiat payments are the leading indicators of survival. Token-first networks without real workloads tend to be cycles from failure.

The bottom line

The GPU oligopoly tax is real: hyperscalers price chips at 2–4× their marginal cost because nobody else has the scale, the network, or the SLA story to compete on the high end. Decentralized marketplaces don't beat hyperscalers on training or on regulated, latency-bound serving. They beat them on the workloads where the SLA premium is wasted money — inference of common open-weight models, batch jobs, embarrassingly parallel sweeps. The single biggest lever is workload-network fit: pick problems whose shape tolerates heterogeneous hardware and best-effort networking, and the spread is yours.

If you take only this away:

Inference and batch port cleanly. Each request is independent; route to whichever provider has the model warm.
Synchronous training does not port. All-reduce over heterogeneous WAN networks is 2–5× slower than a tuned InfiniBand pod.
Trust comes from attestation + reputation + staking, not from blind faith. Verify outputs; slash bad actors.
Price floor is provider marginal cost, not capex amortization — expect 30–60% under AWS list, more on spot.
The token is coordination glue, not the product. Networks that confuse the two underperform.

For the verification primitives that make untrusted hardware safe, read verifiable inference. For why training stays on dedicated clusters, see InfiniBand vs RoCE.

FAQ

Q: Is decentralized GPU just hype?

The token-economics-first version, yes. The economics-of-aggregating-underutilized-capacity version is real and growing.

Q: Will decentralized replace AWS/GCP?

Not entirely. Hyperscalers have advantages: SLAs, integrated services, operational maturity. Decentralized takes the cost-sensitive segment and grows from there.

Q: Can I train Llama-4 on decentralized infrastructure?

No. Frontier training requires homogeneous, low-latency, high-bandwidth clusters. Decentralized doesn't provide this in 2026.

Q: What about training smaller models?

7B-class fine-tuning works on decentralized if it fits on one provider's machine (single-GPU or NVLink-connected node). Multi-node decentralized training is research-grade.

Q: How do I trust the model output?

Use redundant execution (run on multiple providers, compare results) for high-stakes. Use sampling + reputation for normal traffic. For full cryptographic verification, see Verifiable Inference.

Q: Does my data leak through decentralized?

Without TEEs, providers can technically inspect the data they're processing. Use confidential computing (TEEs) if data privacy matters.

Q: Is io.net or Akash a better choice?

io.net has more inventory (more GPUs available). Akash has been around longer (more operational maturity). For most workloads, comparable.

Q: What about Render Network?

Best for graphics workloads. Some overlap with AI inference (image, video). Less optimized for LLMs specifically.

Q: Does decentralized GPU work for inference of frontier models (Llama-3 405B, Claude, GPT-4)?

For Llama-3 405B: yes if a provider has the model loaded on multi-GPU. For Claude or GPT-4: those are closed-weight; you can't run them anywhere except the providers' APIs.

Q: How does decentralized affect supply chain risk?

Reduces hyperscaler concentration risk. Adds new operational risks (provider variance, network instability).

Q: Will hyperscalers respond by lowering prices?

Already happening. AWS reduced GPU lease pricing in 2024-2025 partly in response to competition from decentralized providers.

Q: How do I evaluate a decentralized GPU network?

Five criteria:

Inventory size: how many GPUs available?
Provider quality: what's the reputation distribution?
Pricing: cost per million tokens for your workload?
Trust mechanisms: TEE, PoSP, redundancy options?
Geographic coverage: providers in your required regions?

Test with a small workload before committing.

Q: How do I integrate with multiple decentralized networks?

API gateway pattern. Your application talks to a unified endpoint; the gateway routes to whatever network has the best price/availability.

Open-source: openrouter.ai, litellm. Some commercial gateways exist.

Q: What about confidential workloads on decentralized?

NVIDIA Confidential Computing on decentralized providers is emerging. Some networks (io.net, Akash) offer "verifiable" tier with TEE attestation.

Not all providers support TEE yet. Filter by capability.

Q: How do I know my decentralized provider isn't running a smaller/cheaper model?

Verification mechanisms (PoSP, TEE) address this. For workloads where this matters, use them.

Without verification: trust the network's reputation system. Most major networks have penalty mechanisms for fraud.

Q: What's the latency impact of decentralized?

P50: 10-30% higher than hyperscaler API. P95: 50-100% higher. P99: 2-5× higher.

For interactive traffic with strict SLAs, the variance hurts. For batch traffic, it's fine.

Q: Can decentralized GPU networks support multimodal models?

Yes. Most networks support models that fit on one or a small number of GPUs. Image, video, and multimodal models work fine.

Q: How do I handle cross-network failover?

API gateway abstraction. If io.net response time exceeds threshold, route to Akash. If both fail, fall back to AWS API.

This pattern is common in production.

Q: What about data leakage to providers?

Without TEE, providers technically can inspect data they're processing.

For sensitive data:

Use TEE-enabled providers.
Anonymize/redact before sending.
Don't use decentralized for highly sensitive workloads.

For general workloads: providers have strong economic incentives not to leak (reputation damage). But it's not zero risk.

Q: How do crypto market downturns affect decentralized networks?

Provider participation drops when token rewards lose dollar value. Capacity tightens, prices rise.

Most networks now offer USD-denominated pricing to insulate from this. Less affected by crypto cycles than 2-3 years ago.

Q: What happens to my workload if the network shuts down?

Networks can fail (regulatory issues, lack of demand, technical issues). Mitigation:

Don't put critical workloads on a single network.
Maintain hyperscaler backup.
Choose networks with diversified usage and revenue.

Q: Can I deploy custom models on decentralized?

Yes, most networks support bring-your-own-model:

Upload weights to provider.
Configure inference parameters.
Use standard API.

Quality and security depend on provider reputation. Verify model integrity hashing.

Q: Are decentralized networks secure?

Network-level: most have undergone security audits. Provider-level: depends on the specific provider. TEE attestation helps. End-to-end: as secure as hyperscaler for most threat models, with caveats around novel mechanisms.

For regulated industries, vet specific providers carefully.

Q: Will decentralized GPU compute eventually replace hyperscalers?

No. Hyperscalers' advantages in operational maturity, SLAs, integrated services, and compliance handling are real and substantial.

Decentralized takes the cost-sensitive segment. Hyperscalers retain mission-critical and complex workloads.

The two coexist. Both grow.

Q: How does the economics of decentralized training compare?

Hard topic. Frontier training requires homogeneous, low-latency, high-bandwidth clusters. Decentralized doesn't deliver this in 2026.

For embarrassingly parallel batch training (hyperparameter sweeps, fine-tuning experiments): decentralized works, with cost savings of 30-50%.

For frontier-scale pre-training: stick with centralized hyperscaler infrastructure.

Q: What's the carbon impact?

Decentralized providers often have heterogeneous power sources. Some on renewable, some on coal. Less transparency than hyperscalers' published carbon reports.

For carbon-conscious deployments: hyperscalers' renewable commitments may be more verifiable.

Q: How does verifiable inference fit?

See Verifiable Inference for the full treatment. Brief: PoSP and TEE are the main approaches in 2026 for ensuring decentralized providers don't cheat. Mature enough for production use.

Q: How does DiLoCo change the decentralized training picture?

DiLoCo (DeepMind, 2023) and OpenDiLoCo (Prime Intellect, 2024) use an inner-outer optimizer split: each node runs many SGD steps locally (the inner loop), then nodes synchronize less-frequent outer updates. Inter-node bandwidth drops by roughly 500x relative to synchronous all-reduce SGD, which makes WAN-bandwidth nodes viable. Nous Research's DisTrO claims ~1000x reduction. The catch: convergence is slower in wall-clock for the same FLOPs at frontier scale, and these techniques have not yet been demonstrated training a model above ~10B parameters competitively against synchronous baselines. For ~1-3B parameter training across geographically distributed clusters, DiLoCo is production-viable today. See distributed training for the synchronous baseline these methods compete against.

Q: What does Bittensor compute actually deliver?

Bittensor is a different model: each subnet is an incentive system for a specific task, and validators score miners on the quality of their outputs. Subnet 4 (BitMind), Subnet 18 (Cortex.t), Subnet 27 (compute) and others target compute services. The reality is that Bittensor subnets are mostly used for research and experimentation, not production-scale inference serving — the throughput is constrained, latency is variable, and the validator-driven pricing fluctuates with TAO token economics. Useful for distillation pipelines and synthetic data generation; not the right substrate for live API traffic.

Q: How does NVIDIA Confidential Computing (CC) work on H100?

NVIDIA CC is built into Hopper. It uses a combination of CPU TEE (Intel TDX or AMD SEV-SNP) plus GPU firmware attestation. The CPU TEE provides a measured boot chain; the GPU produces a signed attestation report proving it is a genuine H100 running a specific firmware version. The whole pipeline encrypts data on the PCIe bus between CPU TEE and GPU. Performance overhead is 2-5% for inference, 5-15% for training. Available on H100, H200, and B200. The 2026 production decentralized providers offering CC: io.net's "verifiable" tier, Phala Network, and a handful of providers on Akash.

Q: What's the realistic TTFT/ITL variance on decentralized vs hyperscaler?

Measured Q1 2026, Llama-3.3-70B chat, 512 input, 256 output tokens:

Metric	AWS p5	CoreWeave	io.net	Vast.ai
TTFT P50	320ms	290ms	340ms	380ms
TTFT P95	480ms	410ms	720ms	1100ms
TTFT P99	580ms	510ms	1400ms	2800ms
ITL P50	18ms	17ms	22ms	25ms
ITL P95	24ms	22ms	35ms	48ms

P50 is competitive across the board; the P99 tail is where hyperscalers earn their margin. Decentralized P99 is dominated by occasional provider stalls (network hiccups, eviction events). For chat at human-reading speed (15 tokens/sec target), the decentralized P95 is acceptable. For sub-second agent tool calls, hyperscaler is the safer choice.

Q: Can I move workload between providers based on real-time price?

Yes, with caveats. The OpenRouter and LiteLLM gateways do exactly this for inference: receive a request, route to the cheapest healthy provider with the model loaded, return the response. Switching providers mid-request is not supported (each request is atomic). Switching between requests is free. The latency cost of routing through a gateway is 5-30ms. The cost savings from real-time routing across 4-6 providers is typically 15-25% vs sticking with a single network.

Q: What's the cold-start cost for loading a model on a decentralized provider?

Llama-3.3-70B FP8 weights are 70 GB. From provider's local SSD: 30-60 seconds. From provider's S3/IPFS-equivalent (first time): 180-600 seconds (depending on the provider's bandwidth). Some networks (io.net, Together) pre-load the popular models on a subset of providers; cold-start there is near-instant for those models. For bring-your-own-model deployments, expect 5-15 minutes the first time, then near-instant on subsequent invocations.

Q: How do decentralized networks handle GDPR and data residency?

Poorly, by default. Most networks route requests to any healthy provider regardless of jurisdiction. The exceptions: (1) io.net's "region-locked" tier filters providers by geography, with EU-only and US-only options; (2) Akash supports geographic constraints in the deployment manifest; (3) Aethir's edge model often co-locates providers within a region for latency, which doubles as residency control. For strict GDPR compliance, region-locking plus TEE attestation plus a signed DPA from the network operator is the operational pattern. Healthcare and finance teams currently lean centralized for residency reasons.

Q: What's the difference between io.net's "Stable" and "Verifiable" tiers?

io.net Stable: providers selected for uptime and performance, no cryptographic attestation. Suitable for non-sensitive batch and inference. io.net Verifiable: providers running TEE-attested workloads (NVIDIA CC), with cryptographic proof per request. Roughly 2x the price of Stable, but worth it for any workload where the buyer needs to prove to a third party that the model ran as specified. Most production decentralized inference traffic in 2026 sits on Stable; Verifiable is for compliance-driven and audit-driven use cases.

Q: How does the economics of consumer-GPU networks (RTX 4090) work?

A consumer GPU operator pays $0.10-0.15/kWh for power. An RTX 4090 draws ~450W under inference load. Power cost: $0.05-0.07/hour. The GPU itself amortizes at maybe $0.15-0.20/hour over a 4-year life. Total cost: ~$0.20-0.27/hour. Selling at $0.30-0.50/hour generates $0.10-0.20/hour margin. For 1B-7B parameter inference (the sweet spot for 4090s with 24GB VRAM), this is competitive with anything cloud-side. For 70B+ models requiring multi-GPU NVLink, consumer hardware is uncompetitive — the lack of fast interconnect kills throughput.

Q: What's the real risk that a decentralized network shuts down?

Non-trivial. Several have shut down already (Render's pre-2020 iteration, multiple early Bittensor subnets, Gensyn's testnet stages). The 2026 survivors with credible 5-year horizons: io.net, Akash, Render, Bittensor (subnet-dependent). The mitigation is portfolio diversification — never have more than 30-40% of your decentralized spend on any single network, always maintain a hyperscaler failover path, prefer networks where the underlying compute providers can also serve you directly if the network layer fails.

Q: How do hyperscaler discounts compare to decentralized?

AWS, GCP, and Azure all offer reservation discounts of 40-65% for 1-3 year commitments. CoreWeave and Lambda offer similar reservations. The math: reserved hyperscaler ($2.50-3.00/hr H100) lands within 30-60% of decentralized list price ($1.50/hr). For organizations with predictable demand and capital for reservations, the decentralized discount narrows to where the operational risk often isn't worth it. The decentralized win is biggest for variable, bursty, or experimental workloads — not steady-state production.

Q: Are decentralized networks subject to export controls?

Yes. US export controls on H100/H200/B200 apply to all operators regardless of whether they're "decentralized". Providers in China cannot legally serve H100 inference to US-sanctioned entities; the network layer cannot launder this. Most major networks now do KYC on providers and KYB on large customers. The practical effect: decentralized networks have shrunk the regulatory arbitrage that early crypto-compute marketplaces sometimes offered.

Q: How do I price-discover for a niche model on a decentralized network?

Three approaches: (1) bring-your-own-model deployment on Vast.ai or Akash — you set the rental terms, providers bid; (2) post a bounty on Bittensor compute subnets for the workload; (3) custom contract with a single provider sourced via the network's coordinator. For uncommon models (e.g., recently released open-weights from a small lab), expect to pay a 20-50% premium over equivalent-size standard models because providers haven't pre-loaded the weights.

Q: Does decentralized GPU pricing track NVIDIA's wholesale pricing?

Indirectly. NVIDIA's wholesale H100 price has stayed in the $25-35k band; H200 around $32-40k; B200 around $45-55k. Provider amortization tracks this. The decentralized spot price is more volatile — it tracks demand shocks (inference traffic spikes, new model releases that everyone wants to host) more than NVIDIA's catalog. Spot prices can spike 2-3x during new-model launches as providers reallocate capacity.

Q: What about non-NVIDIA accelerators on decentralized networks?

Niche. Some AMD MI300X capacity exists on Vast.ai and io.net's "alt-accelerator" tier, typically 30-50% cheaper than equivalent H100 hourly. The trade-off is software stack maturity — ROCm support for vLLM, SGLang, and TRT-LLM is improving but still trails CUDA. Production deployments on MI300X tend to be inference-only, single-tenant, and require some integration work. Google TPU and Intel Gaudi are not meaningfully present on decentralized networks — they only run in their hyperscaler hosts.

Q: How do I evaluate provider quality before sending real traffic?

Standard 2026 pattern: (1) burn-in test of 1000 requests across rotating providers, measure acceptance, P50/P95/P99 latency, output equivalence vs an oracle (e.g., your hyperscaler baseline); (2) reputation lookup on the network's published scoreboard; (3) check provider stake / collateral if the network supports slashing; (4) for compliance-sensitive workloads, request TEE attestation per request and verify the firmware version. Networks that don't expose providers' individual reputation or stake are higher-risk by default.

Q: How does decentralized GPU interact with the broader Web3 stack?

Three integration points: (1) payment in stablecoins (USDC, USDT) is now standard on io.net, Akash, and most networks; (2) verifiable inference proofs can be anchored on-chain (e.g., Phala's TEE attestation on Polygon, several Bittensor subnets posting validation digests); (3) AI agents with on-chain wallets can pay for compute autonomously via x402 or similar HTTP-payment protocols. The Web3 integration matters mostly for autonomous-agent use cases and for proof-of-execution audit trails. For pure cost-arbitrage inference, the Web3 layer is incidental.

Q: Will frontier labs (OpenAI, Anthropic, Google) use decentralized networks?

No, with high confidence. Frontier inference serving requires tight integration with proprietary infrastructure, custom kernels, model-secrets management, and SLAs that decentralized cannot match. Frontier post-training and training are even more obviously centralized. The frontier labs are buyers of capacity from hyperscalers and specialized GPU clouds (CoreWeave, Crusoe), not decentralized networks. Decentralized's market is the everyone-else segment — open-source models served by open-source serving stacks.

Q: How does CoreWeave compare to AWS on training-class workloads?

Within 20-30% on price for reserved capacity, comparable or better on availability for current-generation H100/H200/B200. CoreWeave's specialization shows in the InfiniBand pod design and the absence of the cross-service overhead AWS imposes. For pure GPU training without other AWS-integrated services, CoreWeave is typically the better economic choice. For workloads needing S3, IAM, and the rest of the AWS stack, AWS p5 wins on integration.

Q: What's the realistic price floor for H100 hourly in 2026?

Around $1.20-1.50/hr for a vetted datacenter-grade provider, $0.80-1.20/hr for spot on a consumer-grade provider or community decentralized network. The floor is set by power cost plus capital amortization plus a small margin. Below $1/hr you're typically looking at subsidized capacity (token-inflation-funded) or capacity that comes with no SLA whatsoever. Prices below $0.80/hr should trigger skepticism about hardware authenticity or sustainability.

Q: Can I run Llama 3.1 405B on a decentralized network?

Yes if a provider has it loaded on a 4-8x H100/H200 node. Several io.net and Together AI providers host 405B inference. The economics: FP8 inference on 8x H100 lands at about $1.50-2.50 per million output tokens via decentralized vs $3-6 per million on hyperscaler APIs that host the same model. Quality should match because the model weights are identical; the variance is in serving stack tuning (KV cache, continuous batching) which most production decentralized providers handle competently.

Q: How does NVIDIA Confidential Computing perform overhead-wise on real workloads?

Measured 2026: 2-5% inference latency overhead, 3-8% throughput overhead on H100/H200 with NVIDIA CC enabled. Training overhead is higher (5-15%) because the attestation handshake happens at checkpoint boundaries and the GPU-to-GPU communication overhead compounds. The overhead has been steadily improving generation-to-generation; Blackwell's confidential computing implementation is reported at lower overhead than Hopper's. For most workloads the overhead is acceptable; for the latency-sensitive tail it can matter.

Q: How does Together AI compare to running your own model on decentralized?

Together AI is an API tier that abstracts the GPU layer entirely. For Llama 3.3 70B FP8 they charge around $0.88 per million tokens (combined input/output average). Running the same model self-hosted on io.net H100 lands at $0.20-0.30 per million tokens — 3-4x cheaper. The trade: Together AI's API requires zero ops; the self-hosted decentralized path requires capacity planning, monitoring, and failover engineering. Crossover is around 100M-500M tokens per month depending on engineering team cost.

Q: What happens to my workload during a hyperscaler GPU shortage?

Decentralized networks are more elastic on capacity because supply comes from many providers. During the 2024 H100 shortage, hyperscaler waitlists stretched to 6-12 months for new reservations; decentralized networks had immediate capacity at modestly elevated prices. The structural reason: hyperscalers bottleneck on their own H100 allocation from NVIDIA, while decentralized networks aggregate capacity from many smaller buyers each with their own NVIDIA allocations. During shortages, decentralized's hedge value goes up.

Q: How does data egress pricing affect the comparison?

Significantly. AWS charges $0.05-0.09 per GB for egress beyond a small free tier. For an inference workload with 1KB requests and 5KB responses at 10M requests/day, egress is around $1500-$2700/month — non-trivial. Decentralized networks typically don't charge egress separately (it's included in the per-request price). The egress savings on a heavy-egress workload can be 10-20% of total spend, which is sometimes the largest single cost-saver in moving off AWS.

Q: Are there decentralized networks that specifically target training?

Gensyn (testnet), Prime Intellect (operating OpenDiLoCo training across providers), Bittensor Subnet 9 (collaborative pretraining), Nous Research (DisTrO-based training). All are research-grade as of mid-2026; none compete with centralized clusters for frontier training. Prime Intellect's cross-continent 10B training in 2025 is the most credible production demonstration; the model is competitive with single-cluster baselines but not state-of-the-art for its size.

Q: How do I think about reserved vs spot vs decentralized for predictable workloads?

For workloads with predictable steady-state demand, reserved hyperscaler pricing (CoreWeave reserved H100 at $2.50/hr, AWS p5 reserved at $2.80/hr) is competitive with decentralized list price ($1.50/hr) once you factor in the operational discount of running on a reliable platform. The decentralized win is biggest for variable, bursty, or experimental workloads — not steady-state production at scale. A common production pattern: reserved hyperscaler for the 60-80% baseline, decentralized for the bursty 20-40% on top.

Q: How does DePIN tokenomics affect provider availability?

When the DePIN token (IO, AKT, RNDR, TAO) drops 50%+ in fiat terms, provider participation drops within 1-3 months as marginal providers exit. Networks with USD-pegged settlement options (most major ones now) buffer the user side from this, but capacity tightens and prices rise. The 2022 crypto crash caused multiple decentralized compute networks to lose 30-60% of their provider base. The 2024-2025 cycle was much smaller because more networks had transitioned to fiat-stable settlement.

Q: Can decentralized networks support fine-tuning with LoRA?

Yes, well. LoRA fine-tuning runs on a single GPU (or a small node) for most model sizes up to 70B with QLoRA. Decentralized providers handle single-node fine-tuning competently; pricing is typically $1-3/hour all-in. The economics: fine-tuning a 70B QLoRA over 100K examples runs $50-200 on decentralized vs $200-600 on hyperscaler equivalent. For multi-tenant LoRA serving, see multi-tenant LoRA serving.

Q: How do MoE models change decentralized inference economics?

MoE models (DeepSeek-V3, Mixtral, Qwen3-MoE) have unique inference patterns: only a fraction of experts activate per token, so total parameter count is much higher than active compute. Serving MoE on decentralized requires that the provider has enough GPU memory to hold all experts; the throughput depends on expert-routing efficiency. Providers that have invested in MoE-aware serving stacks (expert parallelism, mixture-of-experts serving patterns) extract better throughput per GPU on these models, which translates to lower per-token cost.

Q: Does decentralized handle long-context inference well?

Variably. Long context (>32K tokens) is KV-cache-bound; providers with H200 (141GB HBM) or B200 (192GB HBM) handle 128K+ contexts comfortably; providers with H100 80GB struggle. The decentralized network's average context-length capability tracks the GPU mix; networks with more H200 supply (io.net, CoreWeave-aggregated tiers) handle long-context workloads better than networks dominated by H100 80GB. For 1M-context workloads (Gemini-class, very long needle-in-haystack tasks), only the highest-memory tier providers compete. Background: long-context attention.

Q: What KV cache patterns matter for decentralized inference?

Same as centralized: prefix caching, paged attention, continuous batching. The wrinkle in decentralized: the cache doesn't persist across providers, so requests with shared prefixes (system prompts, RAG context) lose the cache benefit when routed to different providers. The best decentralized inference networks now route same-session requests to the same provider when possible, but the discipline is uneven. For deeper background, see KV cache inference memory math.

Q: How does disaggregated prefill/decode affect decentralized economics?

Disaggregated serving splits prefill (compute-bound) and decode (memory-bound) onto different GPUs. The pattern can produce 20-40% throughput gains. Decentralized networks have been slow to adopt disaggregated serving because it requires tight integration between prefill and decode nodes; most decentralized providers run unified serving. The gap is closing; io.net and Phala both have disaggregated tiers in private beta as of mid-2026. Background on the technique: disaggregated inference.

Operational case studies

Real patterns from production deployments.

Case 1: SaaS company, hybrid deployment

Mid-size SaaS company serving 10M users with embedded AI.

70% of inference traffic on AWS (latency-critical chat).
25% on io.net (background tasks, batch).
5% on OpenAI API (quality-critical premium tier).

Cost savings vs all-AWS: ~40%. ~$200k/month savings.

Trade-off: more complex routing logic. Worth it at this scale.

Case 2: Research lab using decentralized

University research group running large-scale inference experiments.

All experiments on Akash or Vast.ai.
Spot pricing typical 50-70% off AWS.
Tolerable latency variance for batch experiments.
~$15k/month vs ~$45k/month on AWS.

Saves $360k/year. Enables more experiments.

Case 3: Frontier inference cost optimization

Major SaaS scaling beyond 1B tokens/month.

Migrated from API-only to hybrid: 70% self-hosted on dedicated cloud, 20% decentralized, 10% API.
Total cost: 35% of all-API.
Engineering investment: 6 person-years over 18 months.
Net annual savings: $40M+.

Justifies the engineering investment for scale.

Case 4: Compliance-driven deployment

Healthcare AI provider serving regulated workload.

100% on AWS with NVIDIA Confidential Computing.
Decentralized considered but rejected for compliance reasons.
30% premium over commodity hosting.
Worth it for regulatory peace of mind.

Verifiable inference + decentralized may make this case viable in 2027-2028.

Case 5: Bootstrapping with decentralized

Early-stage startup with limited capital.

90% on Vast.ai spot pricing.
10% on AWS for production-critical traffic.
Saved ~$10k/month vs all-AWS.
Migrated to dedicated cloud once revenue justified.

Decentralized as a stepping stone — useful pattern.

How decentralized inference networks differ from CDN

A common analogy: "decentralized GPU networks are like CDN for AI inference." Useful but with limitations.

CDN-like aspects

Geographically distributed providers.
Latency-based routing.
Cache-like behaviors (model weights "cached" at providers).
Aggregation of capacity.

Differences

AI workloads are stateful within a request (not cacheable like static content).
Trust mechanisms are more complex (TEE, PoSP).
Token economics influence behavior.
Different SLA expectations.

Implications

CDN intuition partially transfers but don't over-apply it. Decentralized inference is closer to "compute marketplace with trust mechanisms" than "CDN."

The CDN analogy works for: provider distribution, latency optimization, capacity aggregation.

It breaks down at: stateful workloads, trust requirements, token economics.

Decentralized training: where the field stands

Training on decentralized infrastructure is much harder than inference. Status in 2026.

What works

Embarrassingly parallel batch jobs: hyperparameter sweeps, independent experiments.

Single-GPU fine-tunes: any 7B-class fine-tune.

Federated learning: where local computation is the goal.

What sort of works

Multi-node fine-tunes: with significant performance loss vs centralized.

DiLoCo-style training: research-grade implementations exist.

What doesn't work

Frontier-scale pre-training: requires homogeneous low-latency clusters.

Frontier post-training (RLHF/RLVR): similar.

Why training is harder

Training requires:

All workers at lockstep speed (heterogeneous = stragglers dominate).
High-bandwidth low-latency interconnect (cross-DC = slow).
Trust in correctness of all workers (any cheater poisons gradients).

Decentralized infrastructure provides none of these well.

Possible futures

By 2028+:

DiLoCo and successors may make multi-DC training viable.
TEE-attested training may enable trustless distributed training.
Specific architectures (MoE, sparse) may distribute more naturally.

For now: train centralized, deploy decentralized.

Hybrid stack design

How to architect for hybrid cloud + decentralized + API deployment.

Tier strategy

Define tiers by workload:

Tier 1 - SLA-critical: dedicated cloud (AWS, GCP, Azure). Strict SLOs.

Tier 2 - production but tolerant: decentralized with redundancy. Cost-optimized.

Tier 3 - background/batch: decentralized spot. Cheapest possible.

Tier 4 - quality-critical: API (OpenAI, Anthropic). Premium for top quality.

Routing logic

API gateway routes by request metadata:

User tier (enterprise vs free).
Workload type (chat, batch, agent).
SLA requirements.
Budget remaining.

Open-source: openrouter.ai, litellm. Commercial gateways exist.

Failure handling

If primary path fails:

Tier 2 → fall back to Tier 1.
Tier 1 → fall back to Tier 4 (API).
Always have a working path.

Cost monitoring

Per-tier cost tracking. Alert on:

Tier 2 (decentralized) availability dropping.
Tier 4 (API) costs exceeding budget.
Failure rate spike on any tier.

Quality monitoring

Sample requests across tiers, compare outputs. Detect quality regression early.

This is the production-grade pattern most large deployments use in 2026.

Network economics deep dive

Understanding the underlying economics of decentralized GPU networks.

Two-sided marketplace dynamics

Decentralized GPU networks are two-sided:

Supply: GPU providers wanting to monetize idle hardware.
Demand: AI workload customers wanting cheap compute.

The network's value scales with size on both sides. Network effects matter.

Subsidies and bootstrapping

Early networks subsidize via token inflation:

Token rewards attract initial providers.
Inflation funds the bootstrap.
Eventually, organic demand should sustain rewards.

If organic demand never materializes: network fails. Many crypto compute networks have failed this way.

Successful networks (io.net, Akash) have transitioned to organic demand-driven economics.

Pricing dynamics

Provider pricing must cover:

Hardware amortization.
Power and cooling.
Operational cost.
Profit margin.

For an H100 on consumer power ($0.10/kWh):

Power cost at 700W: ~$0.07/hour.
Hardware amortization (3-year): ~$1/hour.
Total cost: ~$1.10/hour minimum.

A provider charging $1.50/hour has $0.40 margin. Sustainable.

A provider charging $0.50/hour: subsidized by tokens (and may not last).

Demand price elasticity

How sensitive is demand to price?

For inference workloads: highly elastic. A 30% price drop drives substantial increase in usage.

For training: less elastic at frontier (need specific hardware) but elastic in research and fine-tuning.

This elasticity is why decentralized networks with cheaper pricing have grown.

Vertical integration trends

Some networks integrate:

Provider tooling (model deployment, scaling).
Verifiable compute (TEE, PoSP).
Payment infrastructure.

Vertical integration reduces friction and increases value for all participants.

Centralization risk

Even "decentralized" networks tend to concentrate:

Top providers handle most volume.
Coordination by network operator (io.net, Akash).
Standards bodies emerging.

Pure decentralization (truly peer-to-peer) is operationally infeasible at scale. Some centralization is necessary.

Hyperscaler response strategies

How major cloud providers are responding to decentralized competition.

AWS

Reduced GPU pricing in 2024-2025.
Introduced more flexible spot/preemptible options.
Spot Fleet for cost optimization.
Bedrock managed inference at competitive prices.

GCP

Aggressive H100 reservation discounts.
TPU as differentiation.
A4 (B200) early availability.

Azure

Reserved instance pricing competitive.
ND-series with InfiniBand.
Strong hybrid cloud story.

Smaller competitors

CoreWeave: GPU-specialized, ~30% cheaper than AWS for equivalent SKUs.
Lambda: aggressive on-demand pricing.
Crusoe Cloud: stranded power → competitive economics.
Oracle Cloud: aggressive H100 pricing.

Pricing convergence

As decentralized networks pressure prices:

Hyperscaler reservations get cheaper.
Specialty GPU clouds undercut hyperscalers.
API pricing tightens.

The whole market is shifting. Buyers benefit.

Differentiation strategies

Hyperscalers differentiate by:

Reliability (SLAs).
Integration (databases, storage, monitoring).
Compliance (HIPAA, SOC 2, etc.).
Geographic reach.
Support quality.

These are real value-adds, hard for decentralized networks to match.

Where hyperscalers lose

Cost-sensitive bulk inference.
Embarrassingly parallel batch.
Workloads that fit on single nodes.
Research and experimentation.

For these: decentralized is increasingly dominant.

Where hyperscalers win

Compliance-heavy workloads.
Multi-service integration.
Frontier-scale training.
Strict SLAs.

For these: hyperscaler.

The middle ground

Most teams use hybrid. Hyperscaler for important traffic, decentralized for cost-optimized.

Becoming standard practice in 2026.

Verifiable inference and decentralized maturity

How verifiable inference is changing decentralized networks.

Pre-verifiable era (2022-2023)

Trust based on reputation. Limited regulated deployments.

TEE introduction (2024)

NVIDIA Confidential Computing for GPUs. Enables compliance-conscious workloads on decentralized.

PoSP standardization (2025)

Bittensor-led PoSP protocols. Statistical verification for cost-sensitive.

Combined approaches (2026)

Hybrid TEE + PoSP. Layered defense.

What's next (2027+)

ZK becoming production-viable for small models.
Cross-network verification standards.
Regulatory acceptance of decentralized for some compliance contexts.

Verifiable inference removes the "but can I trust them?" objection. Opens decentralized to more workloads.

Decentralized AI infrastructure beyond compute

Compute is one piece. Other infrastructure is also moving toward decentralization.

Storage

Filecoin, Arweave for decentralized storage. AI training and inference need data; some workloads use these.

For compliance-heavy: hyperscaler storage. For cost-sensitive: filecoin etc.

Coordination

Smart contract platforms (Ethereum, Solana) for decentralized coordination. Token economics, slashing, settlement.

Identity

Sybil-resistant identity systems (worldcoin, etc.) for compute marketplaces.

Composable layers

Some networks compose: decentralized compute + decentralized storage + decentralized coordination. Not yet seamless.

The vision

A fully decentralized AI stack. Compute, storage, identity, payment all decentralized.

Currently aspirational. Each layer has dominant centralized alternatives.

By 2027-2028: more composable as standards mature.

Practical advice for getting started

If you're considering decentralized GPU compute, here's how to start.

Step 1: identify a workload

Pick a non-critical, cost-sensitive workload:

Embedding generation.
Batch inference.
Image generation.
Hyperparameter sweeps.

Start small; learn.

Step 2: pick a network

For first attempts:

io.net: largest, most mature.
Vast.ai: simplest (centralized but similar economics).
Akash: blockchain-based but mature.

Step 3: integrate

Most networks have OpenAI-compatible APIs. Drop-in:

client = OpenAI(
    base_url="https://api.io.net/v1",
    api_key=os.getenv("IONET_API_KEY")
)

Step 4: validate

Run your workload on the decentralized network. Compare:

Cost vs current solution.
Latency.
Quality.
Reliability.

Document findings.

Step 5: gradual rollout

If validation positive:

Migrate small percentage of traffic.
Monitor metrics.
Ramp up if performance holds.

Step 6: scale and operate

If broadly successful:

Establish multi-network strategy.
Set up failover.
Monitor cost and quality continuously.

This stepwise approach minimizes risk.

Token economic models in detail

The mechanics of how decentralized GPU networks coordinate via tokens.

Provider rewards

Most networks pay providers in their native token (IO, AKT, RNDR, TAO). Two patterns:

Per-request pricing: provider earns tokens proportional to compute delivered. Direct economic alignment.

Inflation-funded rewards: network mints new tokens and distributes to active providers. Subsidizes early-stage participation.

Most production networks use a hybrid: per-request pricing for the value transfer, inflation rewards to bootstrap and grow the supply.

Staking and slashing

To prevent fraud, providers stake tokens. Misbehavior → slashing.

Stake amounts: typically thousands to tens of thousands of dollars worth of tokens. Enough to deter rational cheating.

Slashing conditions:

Failed audit (returned wrong output).
Downtime beyond SLA.
Detected sybil attack.

The economic security: a provider's expected gain from cheating must be less than expected slashing loss times detection probability.

Token price volatility

Token prices fluctuate. Provider rewards in dollar terms become volatile.

Mitigations:

USDC settlements: providers paid in USD-pegged stablecoins.
Hedging mechanisms: token-fiat conversion at fixed rates.
Long-term contracts: provider locks in dollar pricing.

By 2026, most major networks support USD-denominated pricing alongside native tokens.

Tokenomics anti-patterns

What makes a token economy fail:

Excessive inflation: token rewards diluting existing holders. Providers earn tokens but they devalue. Net economic incentive degrades.

No demand sink: tokens are paid out but not consumed. Supply increases monotonically.

Speculator dominance: token-holding becomes about price speculation, not utility. Network usage is incidental.

Poor slashing: insufficient deterrent for misbehavior. Cheating profitable on average.

Successful networks have token utility tied to actual compute usage and meaningful staking economics.

Compliance and legal considerations

Decentralized GPU compute raises specific regulatory questions.

Data residency

Many regulations (GDPR, HIPAA, China data laws) require data to remain in specific jurisdictions.

Decentralized networks route to providers globally. Without controls, your data may end up in unintended jurisdictions.

Solutions:

Geo-restricted routing: only allow providers in approved regions.
TEE attestation: providers must prove location via attestation.
Hyperscaler-only fallback for compliance-critical traffic.

Tax implications

Token earnings are taxable income for providers. In some jurisdictions, every token transaction is a taxable event.

Most networks issue 1099-equivalent forms or provide reporting tools for providers.

For consumers (paying for compute): it's typically just a service expense. Standard tax treatment.

Sanctions and export controls

US export controls restrict GPU technology to certain jurisdictions. Decentralized networks have to navigate this:

Provider screening: verify providers aren't in sanctioned jurisdictions.
Workload screening: block requests from sanctioned countries.

This is operational complexity that hyperscalers handle behind the scenes.

KYC/AML

Some networks require KYC for providers to receive payments. Reduces anonymity but enables compliance.

Most major networks implement KYC for high-volume providers.

Regulatory ambiguity

Decentralized AI compute is novel. Regulations are still adapting:

EU AI Act: includes provisions for AI service providers.
US: various state and federal regulations evolving.
China: tightly controlled AI services; foreign providers excluded.

Plan for regulatory uncertainty. Don't assume current rules will persist.

Cost optimization for decentralized inference

How to actually save money using decentralized GPU compute.

Workload classification

Categorize your inference traffic by sensitivity:

Tier 1 (mission-critical, low-latency): hyperscaler dedicated.
Tier 2 (production but tolerant): decentralized with redundancy.
Tier 3 (background, batch): decentralized spot.

Different cost profiles:

Tier 1: $5-8/M output tokens (hyperscaler API).
Tier 2: $1.50-3/M output tokens (decentralized + redundancy).
Tier 3: $0.50-1/M output tokens (decentralized spot).

For a typical SaaS company, ~20% Tier 1, ~60% Tier 2, ~20% Tier 3. Total cost: 50-60% of all-Tier-1 baseline.

Spot vs reserved decisions

For each tier:

Tier 1: reserved (predictable performance).
Tier 2: hybrid (60% reserved + 40% spot).
Tier 3: spot (cheapest).

This balances cost against availability.

Model selection

Smaller models often work for tier 2/3:

Qwen2.5 7B for moderate quality at very low cost.
Llama-3 8B fine-tuned for specific tasks.
Specialized small models for embedding, classification.

Decentralized networks have most major open-weight models available.

Caching and deduplication

Even before reaching the inference engine:

Cache responses for deterministic queries.
Deduplicate near-identical requests.
Use embeddings to detect semantic duplicates.

Can reduce inference volume by 30-50% on real workloads.

Provider rotation

If specific providers consistently underperform, route away. Most networks expose provider performance metrics.

Active rotation can improve cost-quality ratio over time.

Comparison: hyperscaler API vs decentralized

Side-by-side breakdown for a typical SaaS company at 100M tokens/month.

Dimension	OpenAI API	AWS H100 self-host	io.net (decentralized)
Cost per M output tokens	$0.60 (gpt-4o-mini)	$1.40	$0.80
Cost per M input tokens	$0.15	$0.30	$0.20
P95 latency	800ms	600ms (under control)	1200ms
Availability	99.9% SLA	99.9% (DIY)	best-effort
Compliance	SOC 2, HIPAA opt-in	full control	varies by provider
Data residency	limited regions	full control	configurable
Operational overhead	minimal	substantial	moderate
Lock-in	OpenAI-specific format	none	network-specific

For most SaaS companies in 2026:

Use API for simplicity and quality.
Self-host for cost-optimization at scale (>1B tokens/month).
Decentralized for cost-sensitive non-critical workloads.

The mix evolves with your scale and workload mix.

Future scenarios

How decentralized GPU compute might evolve.

Scenario 1: continued growth, niche

Decentralized GPU compute continues serving cost-sensitive inference. Hyperscalers remain dominant for compliance-heavy and frontier-scale workloads.

Decentralized share: 5-15% of total inference market by 2030.

Scenario 2: convergence

Hyperscalers offer "decentralized-style" pricing tiers. Decentralized networks add hyperscaler-style SLAs and operational maturity. The line blurs.

Many providers: AWS-decentralized hybrids, multi-region marketplaces.

Scenario 3: regulatory pressure

Strong AI regulations require centralized accountability. Decentralized networks struggle with compliance.

Decentralized retreats to specific niches (research, training, batch processing) where compliance is easier.

Scenario 4: federated training emerges

DiLoCo and similar make decentralized training viable. Some frontier models trained partially across regions.

Cost reductions enable smaller labs to train competitive models. Centralization of frontier compute relaxes.

Scenario 5: regional networks dominate

Geographic networks (regional GPU pools) overtake global decentralized networks. Latency and compliance benefits.

io.net-equivalent within EU, within US, within Asia. Less global but more practical.

The honest forecast: scenarios 1 and 2 are most likely. Scenarios 3-5 are possible but less probable through 2028.

Glossary

Akash: decentralized cloud platform with GPU support.
Aethir: decentralized GPU network focused on real-time inference.
Bittensor: decentralized AI network with various compute subnets.
DePIN: Decentralized Physical Infrastructure. Umbrella term.
DiLoCo: distributed low-communication training. Async decentralized training.
io.net: largest decentralized GPU marketplace by GPU count.
Quorum: agreement among redundant providers on a result.
Render Network: decentralized rendering and AI inference.
Spot: lower-cost, can-be-reclaimed compute.
TEE: Trusted Execution Environment. Hardware-attested execution.
Vast.ai: centralized GPU marketplace with similar economics.

References

Decentralized / low-communication training research

DiLoCo — Douillard et al., 2023. "DiLoCo: Distributed Low-Communication Training of Language Models." arXiv:2311.08105. DeepMind's outer-/inner-loop optimizer that makes geographically distributed training viable for moderate model sizes.
OpenDiLoCo — Jaghouar et al., 2024. "OpenDiLoCo: An Open-Source Framework for Globally Distributed Low-Communication Training." arXiv:2407.07852. Prime Intellect's open reproduction; the first credible cross-continent LLM training run on commodity links.
SWARM Parallelism — Ryabinin et al., 2023. "SWARM Parallelism: Training Large Models Can Be Surprisingly Communication-Efficient." arXiv:2301.11913. Heterogeneous, fault-tolerant pipeline parallel — the canonical reference for "train on unreliable hardware."
Petals — Borzunov et al., 2022. "Petals: Collaborative Inference and Fine-tuning of Large Models." arXiv:2209.01188. BLOOM-176B inference over volunteer GPUs; the original demonstration that decentralized serving can work end-to-end.
Hivemind / Learning@home — Ryabinin & Gusev, 2020. "Towards Crowdsourced Training of Large Neural Networks using Decentralized Mixture-of-Experts." arXiv:2002.04013. Foundational gossip-based training framework underlying Petals and SWARM.
Decentralized Parallel SGD — Lian et al., 2017. "Can Decentralized Algorithms Outperform Centralized Algorithms?" arXiv:1705.09056. The theoretical backbone for why decentralized SGD can match centralized convergence.
DisTrO — Nous Research, 2024. "DisTrO: Distributed Training Over-the-Internet." Technical report. Reports ~1000× reduction in inter-node bandwidth for pretraining.

Verification, proof-of-inference, and trust primitives

opML — Conway et al., 2024. "opML: Optimistic Machine Learning on Blockchain." arXiv:2401.17555. Fraud-proof-based verification for off-chain inference.
zkML survey — Chen et al., 2024. "Zero-Knowledge Proofs of Training for Deep Neural Networks." arXiv:2403.00735. Survey of practical zk-proof systems for ML and their cost overheads.
Proof-of-Learning — Jia et al., 2021. "Proof-of-Learning: Definitions and Practice." arXiv:2103.05633. Foundational attempt at verifying that training happened as claimed.

Network whitepapers and documentation

io.net — Whitepaper v2 and IO Worker docs.
Akash Network — Provider documentation and Mainnet 6 release notes.
Render Network — Render Network Whitepaper.
Aethir — Aethir Litepaper.
Bittensor — Bittensor Yellowpaper and subnet registry.
Gensyn — Gensyn Litepaper.
Vast.ai — Pricing and docs.

Hyperscaler and specialist-cloud price references

AWS EC2 P5 (H100) — On-demand pricing.
Google Cloud A3 (H100) — Compute pricing.
Lambda Cloud — GPU instances.
CoreWeave — H100 / H200 pricing.

Background and adjacent reading

Zaharia et al., 2010. "Spark: Cluster Computing with Working Sets." USENIX HotCloud paper. Background on commodity-cluster economics that anticipates the decentralized model.
Dean & Barroso, 2013. "The Tail at Scale." Communications of the ACM. Why straggler latency dominates distributed systems — directly relevant to decentralized inference SLOs.

Decentralized compute deep dives

Detailed examination of major networks.

io.net deep dive

Architecture:

IO Worker daemon on each provider node.
IO Coordinator schedules workloads.
IO Cloud manages user-facing API.
$IO token for incentives.

Strengths:

Largest aggregate GPU count in decentralized space.
Multiple GPU types supported.
Decent UX for ML workloads.

Weaknesses:

Quality varies by provider.
Reliability less predictable than hyperscaler.
Token economics complexity.

Best for: cost-sensitive batch ML workloads.

Akash deep dive

Architecture:

Cosmos-based blockchain.
Provider auctions for workloads.
Container-based deployment.
$AKT token for payments.

Strengths:

Mature decentralized cloud.
Generic compute (not just GPUs).
Open-source.

Weaknesses:

GPU availability limited.
Setup complexity.
Provider quality variance.

Best for: developers comfortable with crypto-native tooling.

Render Network deep dive

Architecture:

3D rendering focus.
$RNDR token.
Centralized job orchestration.

Strengths:

Specialized for rendering.
Established user base.
Quality control.

Weaknesses:

Limited to rendering use cases.
Less applicable to ML.

Best for: 3D rendering and adjacent workloads.

Bittensor deep dive

Architecture:

Subnet-based marketplaces.
$TAO token.
Validator/miner economics.

Strengths:

Active ML community.
Diverse subnets.
Token-based incentives.

Weaknesses:

Quality variance per subnet.
Complexity.
Tokenomics complexity.

Best for: experimental ML, model marketplace, research.

Gensyn deep dive

Architecture:

Verifiable compute focus.
Cryptographic proofs.
Token economics.

Strengths:

Strong verifiability story.
Aligned with research community.

Weaknesses:

Earlier stage.
Performance overhead from verification.

Best for: workloads where verifiability matters.

Comparison table

Network	Focus	GPU Count	Maturity	Verifiability
io.net	General ML	Largest	Medium	Reputation
Akash	Generic compute	Medium	Mature	Reputation
Render	3D rendering	Medium	Mature	Reputation
Bittensor	ML marketplace	Variable	Medium	Token incentives
Gensyn	Verifiable training	Smaller	Early	Cryptographic

Decentralized GPU usage patterns

How teams actually use decentralized GPUs.

Pattern 1: Hybrid backbone

Use hyperscaler for production. Decentralized for:

Batch eval runs.
Hyperparameter sweeps.
Spot training jobs.

Pros: cost savings without compromising production. Cons: operational complexity.

Pattern 2: Decentralized-first for cost

For cost-sensitive teams:

Train on decentralized.
Inference on managed inference.
Hybrid based on workload.

Pros: lowest training cost. Cons: more failure handling needed.

Pattern 3: Research and experimentation

For research:

Decentralized for experimental runs.
Managed for production model training.

Pros: cost-efficient experimentation. Cons: results may need validation.

Pattern 4: Full decentralization

For some teams:

Everything on decentralized.
Maximum cost savings.
Requires significant infrastructure work.

Pros: lowest cost. Cons: highest operational burden.

Pattern 5: Specific use cases

Inference: io.net, Together.ai (managed but using diverse hardware).
Training: usually hyperscaler still.
Fine-tuning: decentralized works well.

Each use case has different fit.

Decision framework

Use decentralized if:

Cost-sensitive.
Workload is fault-tolerant.
You can manage operations.

Use hyperscaler if:

Production-critical.
Need SLA guarantees.
Limited engineering capacity.

For most teams: hybrid.

Decentralized compute risks

Risks specific to decentralized compute.

Reliability risk

Provider may go offline mid-job.

Mitigation:

Checkpoint frequently.
Use redundancy / multi-provider strategies.
Plan for failures.

Quality risk

Provider may use suboptimal hardware or have software issues.

Mitigation:

Track per-provider quality metrics.
Use reputation scores.
Test before commitment.

Privacy risk

Data is on third-party hardware.

Mitigation:

TEE-enabled providers.
Don't run sensitive workloads.
Encrypted data with on-the-fly decryption.

Token volatility

Network tokens can be volatile, affecting effective costs.

Mitigation:

Stablecoin payments where supported.
Track token denominated cost vs USD.
Hedge if exposure significant.

Regulatory risk

Crypto regulations affect decentralized networks.

Mitigation:

Use networks with clear legal status.
Plan for jurisdiction-specific compliance.

Compliance risk

For HIPAA, SOC2, PCI: decentralized may not satisfy.

Mitigation:

Use compliant infrastructure for compliance-required work.
Decentralized for non-compliance work.

Vendor lock-in (yes, even decentralized)

Tooling may be specific to one network.

Mitigation:

Containerize workloads.
Use abstraction layers.
Multi-network strategies.

Network-specific risks

Each network has unique risks:

Token economics changes.
Coordination layer changes.
Provider exodus.

Diversification across networks reduces but doesn't eliminate.

Risk-adjusted analysis

Cost savings often justify risks for non-critical work.

For critical work: hyperscaler reliability often worth premium.

Decentralized compute future scenarios

Plausible 5-year scenarios.

Scenario 1: Niche but valuable

Decentralized stays at 5-15% of compute. Useful for specific use cases.

Probability: high (~50%).

Scenario 2: Significant share

Decentralized grows to 25-40%. Used widely for cost-sensitive work.

Probability: moderate (~30%).

Scenario 3: Major shift

Decentralized becomes dominant for many workloads. Hyperscalers respond with their own decentralized offerings.

Probability: lower (~15%).

Scenario 4: Marginalized

Decentralized fails to scale or competes. Hyperscalers win.

Probability: lower (~5%).

Driver of scenarios

What determines outcome:

Verifiability technology maturity.
Tooling and operational improvements.
Hyperscaler competitive response.
Regulatory environment.

Strategy implications

Build with portability in mind. Avoid lock-in regardless of network.

For builders: invest in skills that translate across providers.

Decentralized compute operations

Day-to-day operations for decentralized GPU workloads.

Job submission patterns

Most networks use:

Container-based job specification.
Resource requirements (GPU type, memory, etc.).
Pricing strategy (max bid, etc.).
Duration / completion criteria.

Translating from internal job specs to network-specific format.

Provider selection

Strategies:

Lowest price.
Highest reputation.
Best quality-adjusted price.
Geographic preferences.

For most: quality-adjusted price.

Monitoring jobs

What to monitor:

Job progress (steps, time elapsed).
Provider responsiveness.
Output quality (when applicable).
Cost accumulation.

Tooling varies per network.

Handling failures

Common failures:

Provider disconnect.
OOM errors.
Job timeout.
Quality issues.

Recovery:

Resubmit on different provider.
Continue from checkpoint.
Escalate to fallback (hyperscaler).

Cost tracking

Track:

Per-job cost.
Per-provider cost.
Token vs USD.
Compared to baseline (hyperscaler price).

Decisions inform future provider selection.

Capacity planning

For predictable workloads:

Reserve capacity.
Pre-negotiate provider relationships.
Long-term commitments for cost savings.

For unpredictable: spot pricing.

Scaling considerations

As workload scales:

Single-provider may not scale.
Multi-provider strategies.
Automation becomes critical.

Above ~$10k/month decentralized spend: dedicated tooling worthwhile.

Operational maturity

Building operational expertise:

Start small.
Document procedures.
Automate gradually.
Measure costs and quality continuously.

Most teams take 3-6 months to reach operational maturity.

Decentralized compute migrations

Moving workloads to / from decentralized.

Hyperscaler → decentralized

Steps:

Identify candidate workloads (fault-tolerant, cost-sensitive).
Containerize properly.
Test on decentralized small-scale.
Validate quality and cost.
Migrate progressively.

Common pitfall: assuming hyperscaler-quality reliability.

Decentralized → hyperscaler

When workloads outgrow decentralized:

Quality requirements increase.
Compliance needs emerge.
Operational burden too high.

Migration is straightforward (containers help).

Multi-network strategies

Running across multiple decentralized networks:

Diversify provider risk.
Best price-quality per workload.
Operational complexity.

Tooling required: abstraction layer.

Hybrid migration patterns

Most teams end up hybrid:

Hyperscaler for critical.
Decentralized for cost-sensitive.
Best-of-both.

Not migration so much as ongoing operation.

Migration tooling

What helps:

Containerization (Docker / Kubernetes).
Abstraction layers (e.g., MLflow for tracking).
CI/CD adaptable to multiple targets.

Investment in tooling pays back over time.

Migration timing

When to migrate:

After validating tools and processes.
During lulls in critical work.
With monitoring in place.

Don't migrate during high-pressure periods.

Decentralized compute selection guide

How to pick a decentralized network.

Step 1: Define requirements

What workload? What scale? What budget? What reliability?

These determine fit.

Step 2: Survey networks

Look at:

io.net, Akash, Render, Bittensor, Aethir, etc.
Each has strengths.

Step 3: Test small

Run a non-critical workload:

Validate UX.
Measure performance.
Check reliability.

Step 4: Compare to alternatives

Vs hyperscaler:

Cost difference.
Reliability difference.
Operational difference.

Step 5: Decide

Based on data.

Common selection mistakes

Picking based solely on price.
Not validating reliability.
Ignoring operational complexity.
Underestimating learning curve.

Selection criteria checklist

For each network:

GPU types available.
Pricing structure.
Quality reputation.
Tooling and APIs.
Tokenomics health.
Compliance posture.
Regional availability.
Customer support.
Community.
Track record.

Score each, pick winner.

Tokenomics in detail

How decentralized network tokens actually work, and why they matter for builders.

The basic loop

Most networks have:

Providers earn tokens for compute.
Users pay tokens (or USD-converted) for compute.
Stakers/validators secure the network for token rewards.
Token holders may have governance rights.

The loop creates aligned incentives — at least in theory.

Common token mechanics

Inflationary:

New tokens minted to reward providers.
Dilutes existing holders.
Common in early networks.

Deflationary:

Token burns reduce supply.
May come from fees or buybacks.
Counters inflation.

Vesting:

Tokens locked for time periods.
Aligns long-term incentives.
Affects circulating supply.

Why builders care

Token economics affect:

Effective compute cost (tokens have volatility).
Network sustainability.
Provider availability.
Long-term reliability.

A network with bad tokenomics can collapse.

Tokenomics red flags

Massive insider allocations.
Unsustainable inflation.
No clear utility.
High token unlock cliffs.

These predict instability.

Tokenomics green flags

Clear utility (compute payment).
Reasonable inflation.
Aligned incentives.
Active governance.

These predict longevity.

How to evaluate

For each network:

Read the whitepaper / docs.
Check token distribution.
Check inflation/deflation mechanics.
Check governance structure.
Check track record.

This is similar to investment due diligence — because you're betting on the network.

Real-world tokenomics examples

$IO (io.net):

Used for payments and staking.
Burns from fees.
Provider rewards.
Has both supply and demand drivers.

$AKT (Akash):

Cosmos staking.
Network fees.
Long-established tokenomics.

$TAO (Bittensor):

Subnet-specific economics.
Validator/miner rewards.
Complex but active.

Each has tradeoffs.

Implications for users

When using a network for serious workloads:

Understand its tokenomics.
Track token-to-USD effective price.
Diversify across networks.
Don't depend on tokenomics for cost predictions.

For most: budget in USD, treat tokens as exchange.

Decentralized compute final thoughts

Closing thoughts.

The honest assessment

Decentralized compute is a real, useful, growing part of the AI compute landscape.

It's not going to replace hyperscalers anytime soon. But it's not going away either.

Best practical use

Use it for:

Cost-sensitive batch workloads.
Eval runs and experimentation.
Spot capacity for fault-tolerant work.
Fine-tuning.

What's improving

Tooling.
Reliability.
Compliance.
Performance.

Year over year, the case for decentralized strengthens.

What's not (yet)

Mission-critical reliability.
Frontier model training (mostly).
Compliance-heavy workloads (without specific compliant networks).
Latency-critical real-time.

A balanced perspective

Don't be a decentralized maximalist. Don't be a decentralized denier.

Use the right tool for each job.

Track the space

Decentralized is evolving. Track:

New networks.
New verifiability tech.
New tooling.
New use cases.

The landscape in 2030 will look different from 2026.

Builder takeaways

Build portable.
Try multiple approaches.
Measure carefully.
Iterate.

These principles apply broadly, not just to decentralized.

Decentralized compute and the rise of inference

How the inference boom shapes decentralized compute.

The inference shift

In 2023-2025, training dominated. From 2025+, inference dominates:

More compute spent on inference.
Larger fleet of GPUs deployed for inference.
Different workload patterns.

Implications for decentralized

Inference is more amenable to decentralized:

Fault-tolerance via redundancy.
Per-request work units.
No long-running coordination.

Decentralized networks lean into this.

Inference-focused networks

io.net inference offerings.
Together.ai-style aggregators.
Specialized networks (fewer GPUs but optimized for inference).

Cost dynamics

Inference cost per token decreasing rapidly:

Hardware improvements.
Software optimizations.
Increased competition.

Decentralized contributes to cost pressure.

Future scenarios

If inference becomes commoditized:

Decentralized may dominate cost-sensitive segments.
Hyperscalers focus on premium / latency-critical.

This is plausible 5-year scenario.

Regulatory impact

As inference scales, regulation may apply:

Content controls.
Data residency.
AI safety.

Decentralized may face challenges with some.

What builders should do

Build with portability in mind.
Don't lock in to single approach.
Monitor decentralized networks.

Optionality matters.

Decentralized compute summary

Wrapping up.

Who should use decentralized

Cost-sensitive teams.
Fault-tolerant workloads.
Teams with operational capacity.
Researchers experimenting.

Who shouldn't

Mission-critical production.
Compliance-heavy industries (without compliant networks).
Latency-critical real-time.
Teams without operational expertise.

Top networks today

io.net: largest GPU pool, mature.
Akash: established, generic compute.
Render: 3D rendering specialty.
Bittensor: ML marketplace.
Gensyn: verifiable training.

Top networks to watch

New entrants in 2026.
Hyperscaler-decentralized hybrids.
Verifiable computation specialists.

The trajectory

Decentralized compute is growing but not displacing hyperscalers. It's becoming a complement.

Cost savings continue to attract users. Quality and reliability gradually improving.

In 5 years: 15-30% of compute likely on decentralized networks for cost-sensitive workloads.

Final thoughts

Decentralized compute isn't a replacement for hyperscaler. It's another tool in the toolkit.

Use it when it makes sense. Don't force-fit.

Track the ecosystem — it's evolving rapidly.

Decentralized compute getting-started checklist

Practical getting-started guide.

Phase 1: Research (Week 1)

Identify your workload requirements.
Survey major networks.
Read documentation for top 2-3.
Engage with community / Discord.

Phase 2: Pilot (Weeks 2-4)

Choose pilot network.
Set up account.
Containerize a non-critical workload.
Run small-scale test.
Measure performance and reliability.

Phase 3: Production trial (Weeks 5-8)

Move pilot workload to decentralized.
Set up monitoring.
Validate cost savings.
Build operational runbook.

Phase 4: Expansion (Months 3-6)

Identify additional workloads to migrate.
Multi-network strategy.
Build automation tooling.
Train more team members.

Phase 5: Mature operations (Months 6+)

Continuous optimization.
Track industry developments.
Build / contribute to tooling.
Share lessons.

Success metrics

Cost savings vs hyperscaler.
Reliability (jobs completing).
Quality (workload outputs).
Operational burden (engineering time).

Track these continuously.

Common starting workloads

Embedding generation (batch).
Eval runs.
Hyperparameter sweeps.
Fine-tuning small models.

These have natural fit.

When to escalate

Production-critical workloads.
Compliance-required.
High-stakes decisions.

These typically belong on hyperscaler.

Decentralized compute glossary

Aggregator network: a marketplace that pools GPU supply from many providers (e.g., io.net).
Provider: an entity offering GPU compute on a network.
Consumer: an entity using GPU compute on a network.
Token: cryptocurrency native to the network used for payment / staking.
Staking: locking tokens to participate in the network's incentive structure.
Reputation: track record of a provider's reliability.
TEE: trusted execution environment, hardware that protects data in use.
PoSP: proof of sampling protocol, sampling-based verification.
ZK: zero-knowledge proofs, cryptographic verification.
Slashing: penalty mechanism for misbehaving providers.
Attestation: cryptographic proof of provider identity / state.
Auction: pricing mechanism for compute (Akash uses this).
Subnet: separate marketplace within a network (Bittensor).
DePIN: decentralized physical infrastructure network (umbrella term).
Bitcoin-DePIN bridge: integrating Bitcoin with decentralized compute infrastructure (active area).

Decentralized compute FAQ extension

Common questions and answers.

Q: Can decentralized compute really compete with hyperscalers on cost? For many workloads, yes — typically 30-50% cheaper for non-critical work.

Q: Is reliability acceptable? For batch / fault-tolerant workloads: yes. For latency-critical / mission-critical: usually no.

Q: What about data privacy? Concerns are real. Use TEE-enabled providers or don't put sensitive data on decentralized.

Q: Can I train large models on decentralized? Possible but harder than hyperscaler. Most large training still uses hyperscaler / dedicated infrastructure.

Q: What's the operational burden? Higher than hyperscaler. Requires more monitoring, retries, planning.

Q: How do I get started? Pick a network. Test small. Build expertise. Scale.

Q: Are tokenomics important to me as a user? Yes — they affect price stability and network sustainability.

Q: Can I trust decentralized providers? Trust is limited. Use reputation, verifiability, and redundancy.

Q: How does this compare to spot instances on AWS? Conceptually similar — variable availability, lower price. Decentralized adds the marketplace dynamics.

Q: What about regulatory issues? Varies by network and jurisdiction. Use compliant networks for compliance work.

Q: Will decentralized take over? Probably not entirely. Likely complementary to hyperscaler over the long term.

Q: Is this just a crypto fad? The infrastructure is real. The token economics is debated. The compute itself is increasingly mature.

Q: How do I evaluate provider quality? Track: completion rate, performance vs spec, error rates, support response.

Q: Can I run inference at scale on decentralized? Some networks (io.net, Together.ai-adjacent) target inference. Mid-scale works.

Q: What about latency? Generally higher than centralized. Acceptable for non-realtime workloads.

Q: How does power consumption compare? Can be similar. Decentralized providers vary in efficiency.

Q: Are there ESG considerations? Yes. Some networks track / promote green providers.

Q: How do I integrate with existing pipelines? Containerization is the bridge. Most networks support standard containers.

Decentralized compute and AI safety

How decentralized compute interacts with AI safety considerations.

Beneficial aspects

Distributes compute power (no single party controls).
Enables independent research.
Reduces concentration risk.

These align with some safety perspectives.

Risks

Harder to govern.
Easier to run uncensored models.
Decentralized accountability is weak.

These complicate some safety perspectives.

Practical implications

For builders:

Understand the audience using your network.
Some networks have content policies; others don't.
Compliance with local laws is your responsibility.

For users:

Choose networks aligned with your values.
Self-monitor your usage.

For policymakers:

Decentralized compute is harder to regulate.
International coordination matters.

The future trajectory

Likely:

Hyperscalers face more regulatory pressure.
Decentralized fills gaps.
Tradeoffs become more visible.

For the ecosystem: more diversity, more complexity.

Decentralized compute economics in depth

Deeper economic analysis.

Provider economics

A provider with one H100:

Capex: ~$30k.
Opex: power, networking, depreciation.
Revenue: from compute fees.
Effective ROI: depends on utilization.

For 50% utilization at $1.50/hour: ~$6,500/year revenue. After opex: maybe $4,000 net. Recovery time: 7-8 years.

This is why provider quality varies — many providers are at margins.

User economics

For users:

Cost per training hour vs hyperscaler.
Reliability vs cost tradeoff.
Operational burden.

Typical 30-50% savings vs equivalent hyperscaler resources.

Network economics

Network operators capture:

Transaction fees.
Token appreciation (sometimes).
Platform value.

Network sustainability depends on enough flow.

Competitive economics

Competition between networks:

Drives prices down.
Improves quality (with provider competition).
Drives differentiation.

User benefits from competition.

Hyperscaler response

Hyperscalers see decentralized as:

Threat to certain workloads.
Opportunity (some hybrid offerings emerging).
Pricing pressure on commodity workloads.

Long-term: pricing models may converge.

Equilibrium prediction

In equilibrium:

Decentralized cost ~30% below hyperscaler.
For non-critical workloads with operational burden.
Hyperscaler dominates premium / mission-critical.

Like many marketplaces.

Table of contents

Key takeaways

Quick comparison: major networks vs hyperscalers

Mental model: decentralized GPU in one minute

The premise

The major players

io.net

Akash

Render Network

Aethir

Bittensor compute subnets

Vast.ai

Why inference works, training doesn't

Inference: a natural fit

Training: the obstacles

Embarrassingly parallel batch

Trust and verification

Mechanisms

Pricing comparison vs hyperscalers

Real-world performance

Inference latency

Throughput

Reliability

Cold-start

When to use decentralized

Inference at scale, cost-sensitive

Embarrassingly parallel batch jobs

Image/video generation

Hyperparameter sweeps

Background-priority workloads

When not to

Latency-critical interactive serving

Training (currently)

Compliance-heavy workloads

Workloads with strict data residency

Mission-critical with revenue impact

Operational considerations

API integration

Model availability

Spot vs reserved

Multi-region routing

Monitoring

Failover

The token-economics question

A short history of decentralized compute

Trust mechanism deep dive

Reputation systems

Cryptographic attestation (TEEs)

Proof of Sampling

Redundant execution

Token economics

Network architectures compared

io.net

Akash

Render Network

Bittensor compute subnets

Aethir

Vast.ai (centralized but similar)

Pricing dynamics

Spot vs reserved

Auction-based vs marketplace

Token-denominated price

Race-to-the-bottom risk

Comparison: hyperscaler vs decentralized

H200 and B200 pricing in 2026

Cost-per-million-tokens, not cost-per-GPU-hour

Real workload deployments

Inference at scale

Image generation

Embeddings and batch processing

Fine-tuning

Limited training

Operational patterns

Hybrid deployment

API integration

Quality validation

Budget allocation

Multi-network sharding

Future directions

TEE for confidential workloads