opengrid

What is GPU routing? Compute routing explained

· 4 MIN READ

GPU routing, or compute routing, is a simple idea: instead of picking a GPU cloud and an instance yourself, you describe the job you need run and a router decides where it runs. This post defines GPU routing, walks through how it works, and explains how it differs from the tools GPU buyers use today.

Up front: Opengrid is building a GPU router and is pre-launch. The market view ships first and the routing API is in development. This post explains the category, and where it describes Opengrid, it describes what we are building.

GPU routing, defined

A GPU router takes a description of a job and places it on the provider that best fits it. The description is the job, not the instance:

  • GPU type, like H100 or B200
  • GPU count
  • Region
  • Price ceiling
  • Deadline

As a single request, it might look like this:

POST /v1/route · 8× H100 · US · < $2.50/hr · done within 12 hours

Illustrative request.

The router's job is to turn that into a placement: which provider, which region, at what price. You write the request once. When the market moves, the router changes where the job goes, and your code doesn't change.

How GPU routing works

Routing breaks down into five steps. The buyer only sees the first and the last.

Step What happens
1. Describe GPU type, count, region, price ceiling and deadline. One request.
2. Discover Live prices and availability pulled from every connected provider.
3. Score Options ranked on price, location, reliability and performance.
4. Place The job is provisioned on the winning provider through its own API.
5. Bill One invoice and one dashboard, whichever provider ran it.

The Discover step is why a router needs a live view of the market. You can't pick the best option without knowing what every option costs and whether it is available right now.

Why GPU routing matters now

Two things make routing more useful today than it would have been a few years ago.

Prices move fast. AWS cut its H100 on-demand price by 44% in a single announcement in June 2025. One-year H100 contract prices then rose about 40% between October 2025 and March 2026 (SemiAnalysis). The right provider this quarter can be the wrong one next quarter. More in how fast GPU rental prices move.

Switching is expensive. Moving to a new provider means a new account and contract, a new API and tooling, a new bill to reconcile, and re-testing who is reliable. So teams pick once and overpay for as long as they stay. A router removes the switching cost, because the switch happens behind one API.

How routing differs from today's tools

Several kinds of tools sit near GPU routing. Each solves part of the problem.

Tool type What it does Where it stops
Aggregators One API and console across many GPU clouds You still pick the instance yourself
Orchestrators Run jobs across clouds Run on cloud accounts you already hold. No marketplace, no price discovery
Marketplaces Sell GPU time from a pool of supply Each sells its own pool. Not cross-provider
Indices Publish a reference price for GPU compute Publish a price. Place no workloads
GPU router Takes a job description and places it across providers Opengrid is building this. Pre-launch

Aggregators come closest, since they already put many clouds behind one API. The difference is the decision. With an aggregator, you choose. With a router, you describe the job and the router chooses. For a detailed example, see Shadeform vs Opengrid, or the full comparison of GPU cloud aggregators and marketplaces.

The OpenRouter analogy

The same pattern has already worked one layer up. OpenRouter put every LLM behind one API: developers send a request, and OpenRouter forwards it to a model, with one bill at the end. It went from a $547M Series A valuation in June 2025 to a reported $7B+ acquisition by Stripe in August 2026.

GPU routing applies that idea to the compute underneath. Instead of developers and model labs, it sits between AI teams and GPU clouds. Read more in OpenRouter for GPUs.

Why reliability data matters

Price is easy to compare. Reliability isn't. SemiAnalysis's ClusterMAX 2.0 grades GPU clouds from Platinum down to Underperforming. It tracks 209 GPU clouds, and only one is rated Platinum.

That makes the Score step hard. A router that ranks only on list price will send jobs to the cheapest provider, whether or not that provider delivers. Reliability data has to come from somewhere, and the best source is real jobs: did the GPUs arrive, did the job finish, did it hit the deadline. A router collects that data as a side effect of placing work. Over time, every routed job makes the next routing decision better.

Where Opengrid fits

Opengrid is building GPU routing in three layers, in order. The first is a live view of pricing, availability, capacity and regions across providers. Next comes routing: one API key with every GPU cloud behind it. Later, real routed jobs produce real transaction prices for every GPU and region.

Opengrid is pre-launch. Join the waitlist to be in the first group we let in.

Frequently asked questions

What is GPU routing?

GPU routing means describing a compute job (GPU type, count, region, price ceiling and deadline) and letting a router place it on the GPU cloud that best fits on price, availability, location and reliability, instead of choosing a provider and instance yourself.

How is GPU routing different from a GPU cloud aggregator?

An aggregator gives you one API and console across many GPU clouds, but you still pick the instance yourself. A router takes a job description and makes the placement decision for you.

Is there an OpenRouter for GPUs?

OpenRouter puts every LLM behind one API. The same layer for GPU clouds is still being built. Opengrid is building it, and is pre-launch; the routing API is in development.