Run modes
Four ways to get capacity: Serverless, Batch, Dedicated and Private. Same API, with usage and commitments defined by mode.
A run mode is how capacity is provided, not a different product. The call you write does not change when you move between them, which is what makes moving a decision you can revisit.
Tokens measure traffic across all four modes. Serverless and Batch price tokens. Dedicated and Private can add capacity commitments; the proposal defines the billed unit and whether model usage is included. See Pricing and Billing.
Grid Serverless#
Elastic, pay per use. Capacity follows your traffic and scales to zero when idle, and you pay only for what runs.
This is where to start. It is the mode the quickstart uses, and for most workloads it is also where to stay: traffic that varies is exactly what elastic capacity is for.
The trade is the cold start. A lane that has been idle releases its capacity, and the next
request waits for it to come back. Grid reports that as 503 with a Retry-After header
instead of holding your request open, so your client decides how long to wait. Keep retry
with backoff in your client and this is a non-event. See
Errors and cold start.
Available on the invite.
Grid Batch#
Asynchronous inference at a discount. You queue the work, it runs in controlled windows, and it costs less per token than the same work would on Serverless.
Use it for work with no reader waiting: document processing, retrieval preparation, evaluation runs, regression sweeps over a corpus. Anything where the answer being ready in an hour is as good as it being ready in a second.
Grid Batch is inference, not training. It runs the same models against many inputs. If what you want is to change a model rather than run it, that is training: it runs as jobs rather than requests, it is metered differently, and it is arriving by invitation.
Rate card v1 prices eligible Batch tokens at 50% of their Serverless rate, including model-specific cached-input rates. Pricing shows the published references.
Available on the invite.
Grid Dedicated#
Committed capacity for traffic that does not vary. You get dedicated throughput, defined concurrency and pinned model versions, and you commit to the capacity rather than paying per call for it.
The case for it is margin and predictability. When a workload's volume is steady, paying per request means paying a premium for elasticity you are not using.
Dedicated is sold directly. Dedicated collects configuration, quantity, desired region, start and duration. Brazil inventory is planned for May 2027. A written quote confirms availability, minimums, service levels, costs and inclusions.
Grid Private#
An isolated environment for regulated workloads. Your own weights inside your own boundary, with audit trails and release controls.
This is the mode for teams whose constraint is not cost or latency but where the data is allowed to be and who can be shown to have touched it.
What isolation means in your case depends on your requirements, and we are not going to describe a generic boundary here and let you assume it covers yours. Private is scoped per engagement. Bring the requirement and we will tell you what we can commit to.
Available by arrangement.
Choosing#
| If your traffic is | Use |
|---|---|
| Variable, or you are just starting | Grid Serverless |
| Queueable, with no reader waiting | Grid Batch |
| Steady and predictable in volume | Grid Dedicated |
| Bound by isolation, residency or audit requirements | Grid Private |
Start with the mode that fits the workload. Revisit the choice as volume and requirements change, and confirm the new capacity and commercial terms before moving.