Fireworks Multi-Region Deployments: One Endpoint, Global Capacity

Fireworks AI has added a GLOBAL option for deployments, letting one endpoint draw compatible GPU capacity from multiple regions instead of being pinned to a single location. The company operates across 30-plus regions on dozens of cloud providers, but a large footprint only helps if the scheduler can use it. Previously, a deployment belonged to one region, so if that region lacked enough nodes, the deployment failed even when the fleet had the capacity elsewhere. The new architecture lets a single deployment pull from multiple regions through one endpoint, while the scheduler respects hardware requirements, quota, cost guardrails, reliability tiers, and data residency boundaries.

Scheduling off the request path

Fireworks designed multi-region placement so that global scheduling does not add a per-request round trip or an all-region probe. On the normal public API Gateway path, DNS proximity-steers among healthy gateway pools, and the gateway sends the first attempt to the first candidate in an order built from a control-plane-published router record. Placement is planned ahead of traffic, so requests do not consult the scheduler. On a qualifying failure, the gateway can retry another destination if routing policy permits. Network distance to the selected compute still matters; the design removes a global routing step, not physical distance.

Production signals, not promises

In a seven-day production study, the globally placeable cohort showed higher ready-node fulfillment, and a realized multi-cluster footprint was associated with fewer responses per request. For external-customer-labeled, globally placeable deployments observed in two or more serving clusters, request success rate went from 99.269% for single-region to 99.992% for multi-region. Fireworks says this helps achieve its 99.99% reliability target for globally placeable customer deployments. The company cautions these are observational signals, not an A/B test or a universal uptime promise. Serving-cluster labels are infrastructure clusters, not normalized regions, traffic concentrated in a few accounts, and paired-account outcomes were mixed. Sensitivity checks preserved the aggregate direction but did not make it causal.

Why the rewrite happened

An inference deployment asking for eight nodes might find four eligible nodes in Virginia and four in Iowa. The fleet has eight, but the legacy scheduler rejected the deployment because it asked whether one region had all eight, not whether the fleet did. The constraint was built into the architecture: each deployment belonged to a single region. The new architecture allows one deployment to draw compatible capacity from multiple regions through a single endpoint. Fireworks supports GLOBAL, US, EUROPE, APAC, and CANADA scopes. The company advises choosing the broadest boundary that locality and data-residency requirements allow, since GLOBAL gives the scheduler the most room to find compatible capacity or replan a stuck node when compatible supply exists elsewhere in scope.