Skip to content
Use cases
Computeruns today
Compute

Serve inference when traffic spikes

Add capacity for the hours you need it and stop paying when the spike passes. Nothing continues to bill after the container stops.

Traffic arrives in peaks. Capacity bought for the peak is idle for everything that is not the peak.

Why it is hard

  • The peak sets the bill

    Provisioning for the worst hour of the week means paying for that hour's capacity during the other hundred and sixty seven.

  • Scaling down is slower than scaling up

    Adding capacity when traffic arrives is the easy half. Most of the money is lost in how long it takes to give it back.

  • Idle still costs

    A reserved instance serving nothing costs the same as one serving everything, which is what makes over-provisioning quietly expensive.

What answers it

  • Add capacity for the hours you need it

    Launch against live listings when the spike starts. No reservation to negotiate and nothing to plan a quarter ahead.

  • Stopping is immediate

    The meter ends with the container. Giving capacity back is the same action as stopping it, and it takes effect at once.

  • Idle costs nothing because it does not exist

    There is no reserved pool sitting underneath. You hold hardware while you are using it and not a second longer.

How billing works

usage_eventsbilled per second, EURlaunchmeter starts with the containerheartbeat10s at the price frozen at matchstopmeter stops, nothing after
heartbeatsent twiceusage_eventsledger_entriescharge · provider_share 85%account_balancesa view: sums, never a columnone fresh row, summedthe retry: unchangedunique(instance_id, seq)

per second, to the microeuro · no minimum · no egress fee · idle costs nothing

Metering starts when the container does and stops when it stops. The rate is frozen the moment you match, so a provider re-pricing cannot change a running rental, and an aborted run costs what it used.

Bring your own image, or use the one that ships with CUDA and OpenSSH.