Skip to content
Learn

AI inference, explained for the people who run it

The commercial inference market optimizes for latency. A large share of real AI work has no human waiting on a spinner, and treating it as deferrable makes it much cheaper. These guides cover how inference is priced, what runs it, how to pick and shrink models, and what happens to your data.

Featured

Integration · 11 min read

Workflow-aware inference: why the request is the wrong unit

Most production AI work is a pipeline, but most inference APIs accept one request at a time. That mismatch throws away the structure a scheduler needs to do anything clever with the work — and three independent research groups have now measured what it costs.

Read the guide →

Start here

Cost & economics

4 guides

Where the money goes: GPU-seconds, throughput, caching, and how a deadline becomes a discount.

Models & quality

5 guides

Open vs. proprietary, choosing the right size, and quantization without wrecking quality.

Infrastructure

4 guides

The hardware and markets underneath inference — GPUs, spot capacity, concurrency ceilings, and what a cold start costs.

Integration

3 guides

Getting work in and out: the OpenAI-compatible batch surface, the JSONL request file, and describing a whole pipeline at once.

The case for batch

It is also the idea behind the name. Otium is Latin for productive leisure — its opposite, negotium, means business and urgency. We named the company after the first one.

01

Most AI work is not interactive

Enriching a catalog, classifying a backlog, summarizing documents overnight, regenerating embeddings after a schema change — none of it has a human watching a spinner. It needs to be done by a deadline, not in a millisecond. Paying interactive prices for it is pure waste.

02

A deadline is a discount

Compute is perishable: an idle GPU-second is gone forever, so it gets sold off cheap when demand is low. Interactive work can’t use it — it needs capacity hot and waiting at 2pm. Batch work can. Every hour of slack you give us is another hour in which cheap compute might show up.

03

The model you build on can be taken away

A hosted frontier model is a dependency you don’t control. It can be deprecated on the vendor’s schedule, restricted to new tiers, priced differently, silently swapped for a newer version that answers differently — or pulled from general availability entirely by someone who isn’t even the vendor. Every one of those events invalidates the prompts you tuned and the evals you trusted. Open weights change that: the file already sits on disk in thousands of places, so no announcement makes it stop existing. Otium runs open models only, which is why we can commit to something a hosted vendor cannot — that the model you built against will still be there.

04

A pipeline is not a pile of unrelated requests

Most production AI work is a chain — extract, classify, look something up, summarize — but the APIs serving it take one request at a time and forget it. That throws away the one fact worth the most: that the steps belong together. Independent research groups have now measured what that costs, and the answer is not small; the same instructions get re-processed for every item, models get reloaded between steps, a malformed answer costs a whole extra round trip, and steps that could have run side by side run in sequence because nothing knew they were unrelated. Describe the whole pipeline up front and a scheduler can do something about all four.

05

Batching flattens the demand curve

The grid and the cloud both struggle with peaks, not totals. Interactive demand is spiky and must be met instantly with always-hot, over-provisioned hardware. Deferrable work can be shifted into the troughs — overnight, off-peak, into idle capacity that already exists — so less hardware sits hot waiting for a spike.

06

Flatter peaks mean less wasted power

Electricity demand peaks are met by the dirtiest, most expensive “peaker” plants, and data centers increasingly drive those peaks. Shifting deferrable compute off the peak reduces the marginal load that peakers serve and lets work soak up cheaper, often cleaner, off-peak and surplus energy. Using capacity that would otherwise sit idle wastes less of both money and power.

Flattening the demand curve

Peaks, not totals, are what force over-provisioning. The same work spread into the troughs needs far less hardware kept hot, and avoids the dirtiest power brought online to meet a spike.

Interactive demand — spiky, met instantly
peak capacity must be provisioned
Same work, deferred into the troughs
far less capacity sits hot

Illustrative, not measured. The mechanism is the point: deferrable load moves off the peak and onto capacity that would otherwise be idle.

Send us the work that can wait.

Deferrable work runs on cheaper capacity and open models nobody can retire. Leave your email and we’ll invite you to the alpha.

No credit card, no spam — one email when your invite is ready.

Closed alpha — onboarding is gated while we calibrate. Already invited? Sign in.