Latest in AI
Fireworks Forge: Ultra-Fast Inference, Serverless LoRA and the Pricing Tradeoffs
Fireworks is making specialized models easier to serve, but faster generation and cheaper experimentation solve different problems.
Fireworks announced new inference and training capabilities at Forge on November 3, including Ultra-fast inference and serverless LoRA serving in public preview. The practical change is a wider choice between paying for faster agent responses and avoiding dedicated infrastructure for a specialized model with uncertain demand.
Those are different purchasing decisions. A customer-facing agent may justify expensive low latency, while an experimental classifier may benefit more from having no idle serving bill.
Ultra-fast uses the same model at a higher price
The Forge announcement reports up to 1,500 tokens per second on DeepSeek V4.1 Flash using NVIDIA Blackwell GPUs. Fireworks also says a benchmarked 30-turn agent task fell from one minute to eight seconds. These are vendor-reported results, not a promise for every application.
The mode documentation lists DeepSeek V4.1 Flash 1017 as the supported Ultra-fast preview model. Developers select its dedicated router ID, accounts/fireworks/routers/deepseek-v4p1-flash-1017-ultrafast, rather than a different underlying model. Preview behavior can change.
The distinction becomes clearer in the current pricing table:
| DeepSeek V4.1 Flash 1017 mode | Input per million tokens | Cached input per million | Output per million |
|---|---|---|---|
| Standard | $0.30 | $0.006 | $1.20 |
| Ultra-fast preview | $2.40 | $0.048 | $9.60 |
Ultra-fast is eight times the standard token price across those three categories. Its value therefore depends on what waiting costs the product, not just how impressive the generation speed looks.
A serial agent loop can benefit repeatedly from a faster model call. But if the same loop spends most of its time waiting on a browser, database or external API, faster token generation will have less effect on the total. Teams need to measure time to a completed task alongside cost per completed task.
Serverless LoRA removes idle serving charges
LoRA adapts a base model using a smaller set of learned parameters rather than replacing the entire model. Fireworks' new Specialized Model Inference preview loads those adapters onto shared serverless GPUs.
The initial support is narrow: GLM 5.3 Flash, a maximum LoRA rank of 64, and three loaded adapters per base model per account. Serving costs $0.15 per million input tokens, $0.03 for cached input and $0.50 for output. Training is separate; loading, keeping an adapter loaded and idle time carry no serving charge.
There are operational tradeoffs. The first request after loading can take up to a minute, and the preview has no latency guarantee. Fireworks also warns that serving precision can differ from training. An evaluation should therefore use the served adapter, rather than assume a training result transfers unchanged.
Lower idle cost makes it easier to keep a promising experiment available before its traffic justifies dedicated GPUs. It does not remove the need for a good evaluation set, reliable data or a model that actually improves the task.
For an infrequently used internal classification workflow, that can change when deployment becomes worthwhile. For an interactive service with strict response-time requirements, predictable dedicated capacity may still be the more useful choice.
Separate available products from previews
The Forge bundle also includes generally available higher serverless rate limits and Elastic Burst. Fireworks describes Background Mode as a half-price option for eligible work that can wait, alongside multi-day prompt caching.
Other announcements remain earlier-stage: No Eval, which turns production signals into evaluations, is in private preview, as is Fireworks Sovereign for running its inference stack in customer-controlled infrastructure. Those access states matter when planning a project around the conference announcement.
The broader implication is that model selection increasingly includes serving selection. Two applications can use the same model and reasonably choose different runtimes because one needs the fastest answer while the other needs the lowest cost of keeping an experiment alive. Forge gives teams more of those choices, but the useful comparison still begins with their own workload.
I'm Paras. I work at the intersection of AI, engineering and distribution.
I help technical founders turn infrastructure launches and engineering decisions into clear stories that developers and founders want to read and share.