Vercel is advertising more than 1,000 generated tokens a second for its new DeepSeek endpoint. The model is still DeepSeek V4.1 Flash 1017. The change is how it is served, and the faster service has a price: Fireworks’ published Ultra-fast rates are eight times its Standard rates for the same named model.
Across Fireworks, Baseten, Cerebras, Groq, OpenAI and the gateways that connect them, speed now comes from several different things. Sometimes it means dedicated capacity. Sometimes it comes from specialised chips or a draft-and-check decoding system. A routing shortcut can also select a faster host without changing the model at all.
“Ultrafast” is not a shared technical standard. Nor does a tenfold improvement in token generation necessarily make an application ten times faster. A coding agent still has to read its context, wait for tests and decide what to do next.
DeepSeek makes the model. Fireworks serves it. Vercel routes the request.
Three names appear in the launch because they do different jobs. DeepSeek develops the model. Fireworks operates the accelerated inference service that runs it. Vercel AI Gateway supplies the interface through which an application reaches that service.
Vercel identifies Fireworks as the host for deepseek/deepseek-v4.1-flash-1017-ultrafast. Its announcement lists a one-million-token context window and a public preview without a waitroom or session time limit. That context figure is the amount the endpoint can accommodate, not evidence that a full million-token request will generate at the advertised speed.
Fireworks dated its own Ultra-fast preview announcement 3 November. Its mode documentation targets six to eight times the generation speed, with up to ten times for agentic coding tasks, and says it is not a different model. The company also says quality remains the same. These are provider claims, not a matched evaluation conducted by Sulat.
The public mode documentation reviewed here does not explain the exact hardware, precision or acceleration recipe behind that endpoint. It would be a mistake to attach every technique discussed later in this article to Fireworks’ implementation. The serving route is disclosed; the complete recipe is not.
The preview also has lower rate limits than Standard, and Priority is unavailable for Ultra-fast. Fireworks distinguishes Priority, which reduces the chance of requests being dropped during peak traffic, from its speed modes. A fast stream and guaranteed capacity are different purchases.
The clock starts before the words appear
A token is a piece of text, not necessarily a whole word. Output tokens per second describes how quickly those pieces arrive, but the clock used to calculate it matters.
Time to first token measures the wait between sending a request and receiving its first token. That wait can include the network trip, queueing and prefill, when the model processes the input. For a reasoning model, the first token may belong to its reasoning rather than the answer a person is waiting to read.
Time to first answer token includes that reasoning wait. End-to-end completion latency runs until the final token arrives. For a complete agent task, the application must also count the time spent executing tools between model calls.
A provider can report a decoding rate measured after the first token, while a benchmark divides output tokens by the entire request duration. Both can be expressed in tokens per second. They are not interchangeable. Aggregate throughput is different again: it counts work across many simultaneous requests, rather than the speed one person receives.
Consider a hypothetical turn that produces 1,000 tokens. At 100 tokens a second, generation takes ten seconds. At 1,000 tokens a second, it takes one. If the turn also has two seconds of other request overhead and eight seconds of tool execution, the total falls from 20 seconds to 11. That is a 45% reduction, not a tenfold speed-up. The output length and every other delay are held constant in this illustration.
The savings can accumulate through serial tool loops, because the next decision cannot start until the previous result returns. But if most of the time goes into compiling code, searching a remote service or waiting for human approval, faster decoding affects only a small share of the task.
Faster serving is spreading beyond one model
Baseten explicitly says its Fast variants use the same weights as their base models, with dedicated capacity for higher sustained throughput. They have separate model names, prices and rate limits. If Fast capacity is unavailable, Baseten uses base-model capacity, so selecting Fast does not mean every request will retain the same performance.
Its current DeepSeek V4.1 Flash 1017 Fast listing advertises 611 tokens a second and a one-million-token context. The figure belongs to Baseten’s listing; it is not a head-to-head result against Fireworks’ over-1,000 claim. Prompt lengths, concurrency and timing boundaries are not aligned in those two announcements.
Moonshot’s Kimi and Z.ai’s GLM also have accelerated serving paths. Fireworks currently documents accounts/fireworks/routers/kimi-k3-fast and accounts/fireworks/routers/glm-5p3-fast, targeting more than 100 generated tokens a second. Its price card puts both Fast variants at a 50% premium to their Standard counterparts. Choosing Fast here changes the serving mode; choosing a separately trained Flash model changes the model itself.
Vercel announced Kimi K3 Fast in July, naming Baseten and Fireworks among its US-based providers. With its speed: 'fast' option on the base model, the gateway can fall back to standard speed when the fast tier is unavailable. Its June GLM 5.2 Fast announcement named Wafer and attributed the results to Vercel’s own testing. That earlier GLM version is historical context, not a substitute for checking today’s GLM 5.3 endpoint.
OpenRouter’s Nitro shortcut takes another approach. Appending :nitro sorts eligible hosts by throughput and admits priority-tier endpoints, which can cost more. It does not admit OpenAI’s Ultrafast endpoints: those require an explicit tier or endpoint selection. Nitro is routing, not a new set of model weights or a universal acceleration algorithm.
OpenRouter also lets an application sort by latency instead of throughput, and filter providers by quantisation or data policy. Its performance preferences can deprioritise a slow endpoint rather than exclude it entirely. If a workload needs a strict region or a particular serving configuration, a speed-oriented default is not enough.
Specialised chips, different models and a changed OpenAI offer
Cerebras builds around a wafer-scale processor. Groq’s LPU design uses on-chip memory and software-scheduled execution. These hardware approaches are distinct from buying a higher-priority queue on the same service. Neither company’s architectural explanation makes every cloud request immune to network delays or capacity limits.
Cerebras’ current Shared Inference catalogue lists OpenAI’s open-weight gpt-oss-120b at approximately 3,000 tokens a second and Qwen 3.8 27B at approximately 1,850. Groq’s catalogue lists GPT-OSS 120B at 500 and GPT-OSS 20B at 1,000. These are each provider’s advertised figures, not measurements with a common workload.
The 20B and 120B models are different models. Choosing the smaller one is a capability and cost decision as well as a serving decision. Qwen 3.8 27B is another model family again. A higher token rate on one does not establish that it will finish a coding task correctly before another.
OpenAI’s history shows why a launch page is not enough to establish current access. In August it previewed GPT-5.6 Sol Ultrafast on Cerebras, claiming up to 750 output tokens a second and access for a selected group. Sulat covered that earlier announcement.
The current API guide instead documents Ultrafast for GPT-6 Astra and GPT-6.1 Sol, available to all API users, with separate rate limits. It recommends persistent WebSocket connections for agents making frequent tool calls, because repeatedly establishing connections can eat into the latency gain. The August speed figure should not be carried across to these models as if it were a current benchmark.
For GPT-6.1 Sol, Ultrafast supports US and EU data residency and global processing. GPT-6 Astra’s Ultrafast residency support is US-only, alongside global processing. The current guide does not identify the underlying hardware for each route, so the earlier Cerebras partnership alone cannot establish where every current Ultrafast request runs.
How a large model can produce tokens faster without becoming smaller
A server normally generates text step by step. Speculative decoding changes the work around that process: a faster draft system proposes several next tokens, and the target model checks them together. When enough proposals are accepted, the system needs fewer sequential passes through the larger model.
Together’s ATLAS research, published in October 2025, provides a documented example rather than a theory about the new Fireworks service. Its adaptive speculator learns the workload’s patterns while a static speculator remains available as a fallback. Together reported around 500 tokens a second for DeepSeek V3.1 after adaptation to Arena-Hard traffic, at batch size one on four B200 GPUs. It also tested Kimi K2. Those older results explain the mechanism; they are not current service guarantees for Kimi K3 or DeepSeek V4.1.
Drafting is useful only when its proposals save more time than they cost. Predictable code or repeated patterns can be easier to draft than a changing mix of unrelated requests. Together’s algorithm verifies proposals against the target distribution, but that property does not certify every other optimisation in a hosted endpoint.
Baseten’s DeepSeek V4 Pro 0813 engineering account describes native MXFP4 weights, a DSpark speculator and changes to how prefill and decoding workers are allocated. It also stresses correct input encoding and output parsing for tool calls.
Quantisation uses lower-precision numbers to reduce memory or computation. Its effect depends on which weights or states are changed and how the model is evaluated. Cerebras says Shared Inference models are unpruned and describes selective weight-only storage quantisation, with high-precision operations. Groq describes its TruePoint Numerics approach as preserving accuracy. These are specific disclosures and provider assurances, not grounds for saying all fast models lose quality, or that none do.
Sampling defaults, reasoning effort, output limits and tool-call parsers can affect the result even when a model name stays unchanged.
The independent evidence measures more than a speed demo
Artificial Analysis’ October 2026 AA-AgentPerf study and accompanying researcher announcement describe replaying coding-agent trajectories with growing contexts and pauses for tools. Across its reported workload, 97% of input tokens repeated the preceding request on average. That makes retaining and finding the right prompt cache a major part of serving agents efficiently.
Its GPU comparisons also expose the difference between a fleet and a person. Total throughput includes cached input as well as new input and generated output; roughly 96% of counted tokens in those charts were cached input. The quoted per-user decoding speed is a different measure, taken after the first token and usually shown at the 25th percentile across requests.
In the DeepSeek V4 Pro results, Vera Rubin had a large throughput-per-power advantage at some faster decoding settings. Yet when the comparison included time to first token, GB300 matched or beat its throughput per megawatt at most speeds. The study measures accelerator power, not all datacentre electricity. It is evidence about specified serving configurations, not a league table of retail API plans.
Artificial Analysis reported updated NVIDIA-submitted configurations reaching 1,249 tokens a second for one DeepSeek V4.1 Flash agent on Vera Rubin, versus 848 on GB300. This is independent benchmarking infrastructure carrying a hardware supplier’s submitted configurations. It is not independent confirmation that Vercel’s Fireworks preview delivers the same rate to ordinary customers.
Artificial Analysis’ API performance methodology moved to version 3 on 3 November. Headline output speed now includes time to first token, averages measured workloads over five days and incorporates multi-turn agentic work. Its multi-turn timing excludes time spent running tools. Screenshots from before and after that change should not be treated as an unchanged speed series.
The organisation’s Endpoint Accuracy Index re-runs tool calling, hard reasoning and long-context recall against individual hosts, with dated results and confidence intervals. Its GPT-OSS provider page shows that endpoint accuracy is not uniform. That does not isolate one cause, and it does not establish the new Fireworks Ultra-fast endpoint’s accuracy. It does explain why the model developer’s original score is not enough to validate a serving host.
What the faster lanes cost
The table is a rate-card snapshot, not a speed or quality ranking. It lists direct-service prices; a gateway can select a different billable endpoint. Cached input is separate from ordinary input, and context capacity does not promise low latency at that length.
| Host, model and tier | Input | Cached input | Output |
|---|---|---|---|
| Fireworks · DeepSeek V4.1 Flash 1017 · Standard | $0.30 | $0.006 | $1.20 |
| Fireworks · DeepSeek V4.1 Flash 1017 · Ultra-fast preview | $2.40 | $0.048 | $9.60 |
| Baseten · DeepSeek V4.1 Flash 1017 Fast | $0.60 | $0.014 | $2.40 |
| Cerebras · gpt-oss-120b | $0.35 | Not listed here | $0.75 |
| Groq · openai/gpt-oss-120b | $0.15 | $0.075 | $0.60 |
| Groq · openai/gpt-oss-20b | $0.075 | $0.037 | $0.30 |
| OpenAI · GPT-6.1 Sol · Standard, short context | $2.00 | $0.10 | $10.00 |
| OpenAI · GPT-6.1 Sol · Ultrafast, short context | $12.00 | $0.60 | $60.00 |
For Fireworks’ DeepSeek 1017, the listed input, cached-input and output prices all rise eightfold in Ultra-fast. Kimi K3 Fast and GLM 5.3 Fast carry smaller, 50% premiums. OpenAI’s current GPT-6.1 Sol Ultrafast prices are six times Standard. None of those multiples says how much a completed task costs: a model that uses more reasoning tokens, retries a failed tool call or solves the wrong problem can change the bill.
OpenAI’s short-context prices apply through 272,000 input tokens. Longer requests have higher rates, cache writes are separately priced, and eligible regional processing adds a 10% premium. Its model page lists a 1,050,000-token context window, but maximum input is 922,000 tokens and maximum output is 128,000. Those limits serve different purposes and should not be collapsed into a single “one million” claim.
For work that can wait, Fireworks lists batch inference at half its serverless input and output rates.
Cerebras’ paid GPT-OSS endpoint lists roughly 131,000 tokens of context versus 65,000 on its free tier. Groq’s enterprise Performance tier requires uncached context below 8,192 tokens, despite its ordinary GPT-OSS catalogue listing 131,072. Baseten warns that enforced endpoint limits can differ from a catalogue’s advertised maximum and that serving regions can change without a compliance policy. These are not equivalent access packages.
Latency beyond text generation
A fast stream of reasoning tokens is not necessarily a prompt answer. Voice adds other stages, including recognising speech, deciding a turn has ended and generating audio; a text model’s token rate alone does not measure conversational delay.
A p95 latency describes a threshold that 95% of measured requests meet, leaving the slowest 5% beyond it. Rate limits, queueing and recovery after a failed stream can matter more to that experience than a record single-request run.
Discover more from Sulat AI & Tech News
Subscribe to get the latest posts sent to your email.
