Pillar
Serverless compute across multiple providers.
How does compute work on Onrup?
You choose a GPU class and a scaling mode. Capacity is acquired when work exists and released when it does not, sourced across multiple providers rather than one. There is no cluster to provision, no instance to keep alive, and nothing to reserve in advance.
A class, not a machine
A GPU class is a family of interchangeable accelerators with the same memory capacity and comparable throughput, priced as one unit. That is the level at which a decision actually gets made: does the model fit, how fast will it run, what does it cost per hour.
Selecting a class rather than a specific card is what allows capacity to be found wherever it exists. It is also why the rate card has 13 rows rather than several hundred — you are choosing between meaningfully different options, not between inventory listings.
Why several providers rather than one
Availability from any single vendor is correlated with everyone else’s demand on that vendor. Sourcing across several decorrelates it, which matters most at exactly the moment it is hardest — when demand is high everywhere and a single-vendor queue becomes a wait of hours rather than minutes.
It also means the rate you pay is not tied to one vendor’s list price. Our published training rates start at $0.09 per GPU-hour, and on directly comparable H100 capacity we are well under the published rates of the managed platforms in this market.
What we do not publish is which providers, how capacity is selected between them, or how the platform is deployed. That is not evasiveness about anything a customer experiences — every guarantee that affects you is on this site, with numbers. It is the same reason your own infrastructure diagrams are not on your website.
Training and serving are different shapes
A training run is a bounded job. It starts, finishes and releases capacity, and holding a GPU between runs is pure waste — so serverless is simply the correct model for it, with no trade to consider.
Serving is a choice. An endpoint can hold at least one replica resident, which costs continuously and never makes anyone wait, or it can release capacity when idle, which costs nothing and pays a cold start on the first request after a quiet period. The rule is whether a human is waiting for the response.
Interruption is survivable
Capacity that can be reclaimed is only a reasonable proposition if losing it is cheap. Checkpoints are written periodically during a run, so an interruption costs the time since the last one rather than the whole job, and resumption is idempotent — a resume request arriving twice does not start two continuations.
Progress is an append-only event log rather than a live connection, so a client that disconnects reconnects and continues from the last event it saw. Nothing about a job’s history depends on somebody watching it.
Frequently asked questions
What does "serverless compute across multiple providers" mean?
Capacity is acquired when work exists and released when it does not, sourced across several providers rather than one. You choose a GPU class and a scaling mode; there is no cluster to provision, no instance to keep alive and no reservation to manage.
Which providers do you use?
We do not publish that, in the same way your own architecture diagrams are not on your website. What a caller can observe is published and guaranteed: the class, its memory, its rate, and the scaling behaviour of an endpoint.
Can I choose a region?
Not today. You choose a GPU class, not a location. If data residency is a contractual requirement, raise it before starting rather than after.
What happens if capacity is not available?
A run stays queued and the API returns a wait indication rather than failing silently. Queue time is not billed. For serving, a request to a cold endpoint queues within bounds you set and is refused with a retry hint rather than queueing indefinitely.
Start with the free tier
A magic link creates your account, your tenant and your first API key. No card until you ask for compute.