Two hundred places, one deploy
One push lands everywhere at once. Requests resolve to the nearest healthy box without you writing a routing table, or ever maintaining one.
Distance is the part of latency you cannot optimise away.
You can quantise the model, batch the requests and rewrite the kernel, and the packet still has to cross an ocean. Perigee moves the model instead.
Warm hit rate
Cold starts / region
Weights resident
Weights stay warm
A region that has served your model keeps it resident. A new region costs one cold start, not one per call.
Fails to the next ring
A region going dark is a routing event, not an outage. The caller sees a slightly slower answer, not an error.
GGUFsafetensorsONNXTensorRT plan
Core MLLoRA adaptersint4 · int8 · fp16streamingspeculative decoding
Bring the build you already have
Perigee does not ask for your training code or your framework of the month. Ship the artifact you already produce and pick the precision per region.
The same model, measured from the same six cities.
Time to first token from a single origin in us-east, against the nearest Perigee region. The gap is the round trip you were paying for.
Single originPerigee edge
SydneySYD
MumbaiBOM
LagosLOS
TokyoNRT
São PauloGRU
FrankfurtFRA
Illustrative figures for a fictional product. Nothing here was measured.
Three calls, then it is somebody else's problem.
Push the artifact
One build, whatever you already produce. It is checksummed once and replicated from there, so the upload is the slowest part of your day.
Pick a footprint
One region, a continent, or everywhere. It is a number in a config, and changing it is a deploy rather than a migration.
Point your clients at one host
The same hostname everywhere. Anycast puts the call on the nearest edge, and the answer streams back from there.
model = "./build/model-q4.gguf" footprint = "global" # "eu" · "us-west" · 1 warm = true failover = "next-ring"
$ perigee deploy ✓ pushed 4.1 GB · sha256 9f2c…e01 ✓ placed 214 regions · 38s ✓ warm 214 / 214 ✓ live https://infer.perigee.example
What it looks like from the caller's side.
Time to first token
18ms p50
Median from request to first token, measured at the caller.
Regions serving
214
Each one holds a warm copy of your weights.
Answered in region
99.98%
The rest fail over one ring out, slower but never an error.
Hostnames to configure
1
The same address everywhere. Anycast does the rest.
Invented product, invented figures. Nothing here was measured.
Pay for tokens, not for distance.
Every plan uses the same network. What changes is how far your model reaches and how much of it stays warm.
Region
$0/ month
One region of your choice, free for as long as you keep it.
- 1 region, any continent
- 2M tokens a month
- Shared GPU pool
- Community support
Continent
$0.38/ 1M tokens
Up to forty regions with the weights kept warm in all of them.
- Up to 40 regions
- Weights kept resident
- Failover to the next ring
- Per-region precision
- Email support, one-day response
Everywhere
Custom
All 214 regions, reserved capacity, and a person who knows your model.
- Every region, reserved
- Private interconnect
- Regional data pinning
- Named engineer
Prices are invented for this demo.
Things people ask before the first deploy.
Anything else, the docs go deeper, and a person answers the inbox.
What counts as a region?
A metro with its own GPUs and its own copy of your weights. Two edges in the same city count once. A region is the smallest unit you can add or remove.
Do I have to change my client?
Only the hostname. The API is plain HTTP with server-sent events for streaming, and the request and response shapes are the same in every region.
What happens when a region fails?
Anycast stops advertising it and the next ring out picks up the call. In-flight streams are retried once on the new region, and the caller sees added latency rather than an error.
Where does my data go?
A request is processed in the region it lands in and not stored afterwards. On the Everywhere plan you can pin traffic to a set of regions for residency.
Can I run a different model per region?
Yes. Footprint and precision are set per region, so you can serve an int4 build at the far edge and fp16 closer to home from the same deploy.
Put it where
the people are.
Deploy into one region for nothing, and watch what the round trip was costing you.
Deploy in one region free