Fireworks AI's GLM 5.2 Fast Doubles Throughput for Coding Agents

Fireworks AI ships a new serving tier for Z.ai's GLM 5.2 that runs 2-3x faster than its Standard path with no quality drop.

·
·
Fireworks AI's GLM 5.2 Fast Doubles Throughput for Coding Agents
Read4 min
TypeNews
TopicLlms · Api
SubtopicLong Context
  • Fireworks AI launched GLM 5.2 Fast, a serving tier that runs ~2x the Standard path.
  • Same weights, same 1M-token context, same tool-call and JSON-schema behavior as Standard.
  • Speedup from speculative decoding, prefill/decode split, and workload-specific MoE and attention sharding.
  • Pricing: $2.10 input, $0.21 cached, $6.60 output per 1M tokens on the Fast router.
  • Reported 81.8% on SWE-bench Verified and peak of 446 tok/s on Artificial Analysis.
  • Coding agents including Factory's Droid are already routing to the Fast endpoint.

Fireworks AI has launched a new serving tier called GLM 5.2 Fast, a re-optimized inference path for Z.ai's flagship open-weight model that roughly doubles token throughput without touching the weights. On the same workload, GLM 5.2 Fast runs about 2x the Standard path, a self-comparison that holds regardless of where any single Artificial Analysis snapshot lands. Coding-agent platforms like Factory's Droid are already routing traffic to it.

The pitch is simple: same model, same 1M-token context, same tool-call and JSON-schema behavior, but faster generation and aggressive cache pricing tuned for long agent loops.

Why speed matters for GLM 5.2 specifically

GLM 5.2 is built for long-horizon agent work, and Fireworks reports that Z.ai designed it for long-horizon tasks on a 1M-token context. In practice, agents read repo context, plan, call tools, edit files, and run tests over many turns. Fireworks says the average prompt length on its public GLM 5.2 endpoints is around 90k tokens, which makes both throughput and cache economics dominant cost drivers.

That is where the Fast tier is aimed. It sits alongside the existing Standard and Priority paths, and you switch tiers with a model ID change rather than a rewrite of your stack.

How they got the 2x

The speedup does not come from a distilled or quantized stand-in. Fireworks uses speculative decoding tuned to GLM 5.2, drafting candidate tokens that count only once the full model verifies them, so the speed comes from serving mechanics rather than a smaller model standing in. A few other levers stack on top:

  • Split parallelism strategies. GLM 5.2's architecture is really two serving problems in one model: a large mixture-of-experts MLP stack and a sparse MLA attention stack, and each wants a different parallelism strategy.
  • Expert sharding for the MoE. Around 98% of GLM 5.2's parameters live in its expert weights, but each token activates only a small subset of them, so spreading experts across GPUs lowers per-GPU weight residency, which frees up HBM for KV cache, batching, and long contexts.
  • Data-parallel attention. The main attention path is DeepSeek's MLA, which stores compressed latent KV shared across heads. Rather than replicate that KV across tensor-parallel ranks, Fireworks shards across requests so each request's KV stays local.
  • Prefill/decode separation. Prefill is separated from decode and cached context is reused, so long agent prefixes do not compete with generation every turn, which matters most in coding loops where repeated prefixes dominate token spend.

There is also a sparse-attention wrinkle worth knowing about. GLM 5.2 uses DeepSeek Sparse Attention with an addition called IndexShare, where a cheap indexer selects the most relevant 2,048 prior tokens per query and the expensive attention runs only over that top-k. That is what keeps 100k-token requests from scaling like dense attention would.

The part that could go wrong, and didn't

A faster path is worthless if tool calls start failing or JSON schemas drift. Before launch, Fireworks ran the same eval suite on Standard and Fast and required them to match, so "no quality change" is a measurement rather than a promise, across tool-call validity, JSON-schema adherence, and long-context behavior on representative agent harnesses. Structured outputs use the same JSON-schema and BNF grammar path as Standard.

On agent quality, GLM 5.2 scored 91.4% on GPQA-Diamond running on Fireworks' own engine and GPUs, validating Z.ai's reported 91.2%, and the Fast tier is claimed to hit 81.8% on SWE-bench Verified on Fireworks GPUs.

Pricing and how to switch

The Fast router costs more per token than Standard but is offset by roughly 2x throughput and a heavy prompt-cache discount. Cached input on Fast is $0.21 per 1M tokens, versus $2.10 for fresh input, which matters because most tokens in a long agent loop are re-sent context.

PathModel IDInput / Cached / Output per 1M
Standardaccounts/fireworks/models/glm-5p2$1.40 / $0.14 / $4.40
Standard + Prioritysame + service_tier="priority"$1.75 / $0.18 / $5.50
Fastaccounts/fireworks/routers/glm-5p2-fast$2.10 / $0.21 / $6.60

Switching is a one-line change against the OpenAI-compatible API:

response = client.chat.completions.create(
    model="accounts/fireworks/routers/glm-5p2-fast",
    messages=[{"role": "user", "content": "Write a migration plan for this codebase."}],
)

Anthropic-compatible endpoints work too, so drop-in usage from Claude Code or similar harnesses via FireConnect keeps working. The Fast router is exposed as a serverless endpoint with no reserved GPU commitment, and Priority can be layered on for admission control under load.

Where this lands in the stack

Fireworks is currently listed among the fastest providers for GLM 5.2 on OpenRouter, with a peak reported at 446 tokens per second on Artificial Analysis. For anyone running long-context coding agents on an open-weight model, the practical question is no longer whether GLM 5.2 is fast enough for interactive use, but whether the cached-token economics beat the closed-model alternative your team is currently paying for.

Comments

avatar