New to deployments? Start with our Deployments Quickstart to deploy and query your first model in minutes, then return here to learn about configuration options.
- Better performance – Lower latency, higher throughput, and predictable performance unaffected by other users
- No hard rate limits – Only limited by your deployment’s capacity
- Cost-effective at scale – Cheaper under high utilization. Unlike serverless models (billed per token), on-demand deployments are billed by GPU-second.
- Broader model selection – Access models not available on serverless
- Custom models – Upload your own models (for supported architectures) from Hugging Face or elsewhere
Creating & querying deployments
Create a deployment:--deployment-shape default has Fireworks pick a validated shape for the model — see Letting Fireworks pick a shape. To choose a shape yourself, run firectl deployment-shape-version match --model <model-id> first and pass a shape’s name to --deployment-shape.
Check current placement
Change placement
There is no supported command to change region placement on an existing deployment. To change placement, recreate the deployment:Code examples
- Python (Fireworks SDK)
- Python (OpenAI SDK)
- JavaScript
- curl
Deployment status states
Deployment states from the Gateway API spec:CREATING- still being createdREADY- ready to be usedUPDATING- in-progress updates happeningDELETING- being deletedDELETED- soft-deletedFAILED- creation failed (see status for details)
Inactive:state == READY && max_replica_count == 0 && ready_replica_count == 0Scaled to 0:state == READY && min_replica_count == 0 && max_replica_count > 0 && desired_replica_count == 0 && ready_replica_count == 0
Deployment.State enum values.
Deployment shapes
Deployment shapes are the primary way to configure deployments. They’re pre-configured templates optimized for speed, cost, or efficiency, including hardware, quantization, and other performance factors. Every shape is validated by Fireworks, so a deployment created from a shape uses a known-good configuration of GPU count, precision, and serving parameters. Over the API,deploymentShape also accepts the special value default: the server picks a validated shape for the model for you — pass --deployment-shape default with firectl. For details, see Letting Fireworks pick a shape.
- Fast – Low latency for interactive workloads
- Throughput – Cost-per-token at scale for high-volume workloads
- Minimal – Lowest cost for testing or light workloads
match reports the deployable set. Shapes your account cannot deploy on are dropped, exact base-model matches are preferred over same-model-type and parameter-count siblings, and LoRA addon and live-merge models are matched against their base model. Over the API, the equivalent is Match Deployment Shape Versions. To see every validated shape matching a base model instead (including ones your account cannot use), use firectl deployment-shape-version list --base-model <model-id> — base models only, it fails on LoRA addon and live-merge models. match does not take addons into account. For a deployment with --enable-addons, use the Match Deployment Shape Versions API with enableAddons set.Letting Fireworks pick a shape
Every client surface accepts a special value that has the server pick a validated shape for the model and apply it, the same as passing that shape explicitly:- firectl
- REST API
- Python SDK
acceleratorType no shape validates), the request fails with an error naming the conflicting fields, the compatible shapes, and how to create the deployment without a shape. If no shape is compatible with the model at all, the request also fails — in that case, contact us and we’ll help you find or add one.
Explicitly creating a deployment without a shape (advanced users only)
Every surface accepts an explicit opt-out that creates the deployment without a shape. Setting it together with a shape is an error — a deployment is either shaped or explicitly shapeless.- firectl
- REST API
- Python SDK
Managing & configuring deployments
Basic management
By default, deployments scale to zero if unused for 1 hour. Deployments with min replicas set to 0 are automatically deleted after 7 days of no traffic.
GPU hardware
Choose GPU type with--accelerator-type:
NVIDIA_A100_80GBNVIDIA_H100_80GBNVIDIA_H200_141GBNVIDIA_B200_180GBNVIDIA_B300_288GBAMD_MI325X_256GBAMD_MI350X_288GB
Not every model runs on every GPU. Each model is validated only on specific accelerator type, GPU count, and precision combinations — many models support just one or two entries from the list above. To see what a model supports, match its deployment shapes:The
GPUS, ACCELERATOR, and PRECISION columns are the validated combinations; the model’s page in the Fireworks console shows the same options under dedicated deployments. Setting --accelerator-type or --accelerator-count to a combination no shape validates will typically fail at creation — often with a generic Internal error occurred message that does not name the hardware mismatch. If you need hardware no shape covers, contact us.Autoscaling
Control replica counts, scale timing, and load targets for your deployment. See the Autoscaling guide for configuration options.Multiple GPUs per replica
Use multiple GPUs to improve latency and throughput. First check whether a multi-GPU deployment shape already exists for your model:--accelerator-count — see the warning under GPU hardware for why omitting --deployment-shape entirely should be a last resort:
Preemptible deployments (eval / batch)
For the training eval workflow, see Evaluating Trained Models. Preemptible deployments let you run evaluation and batch workloads without holding dedicated on-demand capacity. Passing--preemptible at creation opts the deployment into borrowing idle reserved GPUs instead of reserving GPUs exclusively for you, so you do not pay to hold dedicated capacity for an eval that only runs occasionally.
Because the capacity is borrowed, it can be reclaimed (preempted) at any time and is not guaranteed. In practice a preemptible deployment usually stays up long enough to run an eval end to end, but you must treat disappearance as a normal outcome, not an error.
Guarantees vs. risks
No unique availability risk. Preemptible does not make capacity harder to get. If there is no capacity for a preemptible deployment, there is no capacity for an on-demand one either. The only difference is that a preemptible deployment can also be taken back after it starts.
Requirements
firectl>= 1.7.26.--preemptibleis a newer flag and is silently ignored on older builds (no error, and the deployment is created as standard on-demand). Check withfirectl versionand upgrade if you are below this version.
Create a preemptible deployment
--wait blocks until the deployment is ready (1 hour default; tune with --wait-timeout).
Check status and then send eval requests as you would to any deployment:
Advanced
- Speculative decoding - Speed up text generation using draft models or n-gram speculation
- Quantization - Reduce model precision (e.g., FP16 to FP8) to improve speeds and reduce costs by 30-50%
- Performance benchmarking - Measure and optimize your deployment’s performance with load testing
- Managing default deployments - Control which deployment handles queries when using just the model name
- Publishing deployments - Make your deployment accessible to other Fireworks users
Next steps
Autoscaling
Configure autoscaling for optimal cost and performance
Upload custom models
Deploy your own models from Hugging Face
Quantization
Reduce costs with model quantization
Regions
Choose deployment regions for optimal latency
Reserved capacity
Purchase reserved GPUs for guaranteed capacity
Training
Train models for your specific use case