Frontier Lab Training Infrastructure As A Service

Frontier-lab training infrastructure, now as a service

GLM 5.2 is live! Opus-level intelligence at open-source rates. Pay per token on serverless. Try it today.

Blog

Frontier Lab Training Infrastructure As A Service Frontier-lab Training Infrastructure, Available Now as a Managed Service for GLM 5.2

PUBLISHED 6/24/2026

Table of Contents The features that used to be frontier-lab-only Validations How we did it, and why it's hard Zero KLD, end to end What you get on Fireworks today Why it matters: frontier specialized intelligence as a service

Table of Contents

The hard part of reinforcement learning on a frontier model has never been the algorithm. It's the infrastructure that keeps training and inference numerically identical: zero KLD, end to end. At Fireworks, we've long invested in solving this challenge, and are now offering it as a managed service, starting with GLM 5.2. For years, the club of teams getting reinforcement learning to actually work on giant models was limited to the top frontier labs. Not because they had better algorithms, but because they had the unglamorous infrastructure underneath: training and serving stacks engineered to produce the same numbers, run after run, request after request. That infrastructure is built on concepts people outside those labs have never had to think about, for example batch invariance and zero-KLD across training and serving : making the rollout engine and trainer produce the same numbers end to end. It sounds like plumbing, but it's the difference between an RL run that hill climbs successfully, and one that quietly falls apart. The toolkit that used to be locked inside a handful of labs is now available as a managed service on Fireworks on GLM 5.2 , the OSS model sitting at the very top of independent community leaderboards. We are offering frontier specialized intelligence as a service: not a frontier you rent prompts from, but one you can post-train and reinforce on the same infrastructure the top labs built in-house. The features that used to be frontier-lab-only

Reinforcement learning on an LLM is a loop: the model generates responses, those responses are scored , and the trainer nudges the weights. The whole thing rests on the assumption that the probability the trainer thinks the model gave each token matches the probability the serving engine actually used to generate it. When that holds, learning signal flows. When it doesn't, you're optimizing against noise. Holding that assumption on a modern frontier model is genuinely hard, and Fireworks gives you the tools the big labs built to do it: • Batch invariance for Large MoEs - a request returns the same result no matter what other traffic happens to share its batch. Without it, an "on-policy" run is quietly off-policy: the rollout was generated by a subtly different model than the one you're updating, just because the server was busy. The building blocks are increasingly public: open-source engines ship batch-invariant kernels for smaller, dense models ( vLLM , SGLang ), and DeepSeek's DeepGEMM , the kernel library behind DeepSeek-V4 , provides batch-invariant grouped-GEMM kernels for MoEs. It replaces cuBLAS end to end and drops the split-K trick precisely because split-K breaks invariance. But a pile of batch-invariant kernels is not a batch-invariant system. True end-to-end invariance means every reduction - attention, the MoE router, the expert GEMMs, and the multi-rank all-reduce stack - stays consistent together, under real production load. Delivering that whole-system guarantee for a frontier MoE like GLM 5.2 as a managed service is, to our knowledge, a first in the industry. • Zero-KLD train/serve alignment - for a model like GLM 5.2, the usual patches don't reach far enough. The popular Mixture-of-Experts fix, router replay (replaying the serving engine's expert choices inside the trainer), handles which experts fire but it can't touch the other place these models diverge: which tokens the sparse-attention indexer selects. Those selections aren't tractable to replay. So there's no halfway house here. The generation engine, the prompt-reading path, and the trainer have to share one numerical definition, so what you train is exactly what you served: zero KLD, end to end.

Zero-KLD Train/Serve Loop: The same request flows through serving prefill and generation, then through the trainer path. The two streams converge when served logits and trainer logprobs match at KLD = 0. These are exactly the pieces most platforms don't have, and their absence is why so many RL efforts stall. Validations

Here is the same RL task, the GLM countdown reasoning task, run two ways. Both use the same algorithm and data. The only difference is the numerics underneath. Validation Runs: The same GLM countdown reasoning task behaves differently when the trainer and rollout engine disagree: reward collapses and clipping throws away learning signal. With zero-KLD numerics, the loop stays on-policy. Without the Fireworks numerics stack, the trainer and the rollout engine disagree (train-inference KL around 0.013), and the run leans hard on the industry's usual crutch: importance sampling and clipping were discarding about 45% of every batch's tokens just to stay upright. It still wasn't enough. Around step 20 the reward collapses , falling from around 0.9 to under 0.2 as the policy chases a target that no longer matches what it generated. With the Fireworks stack, the trainer and serving engine run at zero KLD, end to end - bit-for-bit identical - with zero tokens clipped , and reward stays healthy across the entire run. Same task, same algorithm. The only thing that changed was making the numbers agree. Run Train-inference KL Clipped tokens Reward behavior Without the Fireworks numerics stack Around 0.013 and drifting About 45% Collapses around step 20, from around 0.9 to under 0.2 With the Fireworks stack 0 0% Stays healthy across the full 25-step run

That's the trap with the importance-sampling-and-clipping approach: it's a tax , not a fix. Every clipped token is learning signal thrown away, and past a point no amount of clipping saves a run whose numbers don't line up. How we did it, and why it's hard

It comes down to a property of floating-point math that trips up almost everyone: addition isn't associative. (a + b) + c doesn't equal a + (b + c) down at the bit...