Smaller, faster, safer: running Kimi and GLM at scale Workers AI runs inference for some of the best open models in the world on GPUs in Cloudflare data centers close to your users. Two of the most c
By Coderz Club · 2026-08-04 · Tags: coding
Smaller, faster, safer: running Kimi and GLM at scale
Workers AI runs inference for some of the best open models in the world on GPUs in Cloudflare data centers close to your users. Two of the most capable, and most demanding, are Moonshot s Kimi K-series and Z.ai s GLM. They are large, long-context, mixture-of-experts models, and they are wonderful to use. They are also very hard to serve efficiently because of memory constraints.We ve written before about how we serve large models on Workers AI and about separating the prefill and decode phases of inference to get more out of each GPU. This post looks at three techniques we layer on top of that to fit these models into memory and keep them fast: quantizing the KV cache, compressing the model weights, and, because both of those pack more requests onto shared hardware, protecting the cache those requests share. These optimizations enable us to support more customers at lower costs, with no change in model accuracy.All our experiments and production traffic are running and benchmarked with SGLang, an open-source inference serving framework. We found that SGLang offers the best performance in the market, and we work closely with the SGLang team to upstream patches and new features to make our work available to the open-source community.Quantizing the KV cacheAs a model generates text, it stores the attention keys (K) and values (V) for every token it has already processed in a structure called the KV cache. The cache is what lets the model extend a long conversation without re-reading the entire context on every new token. For a long-context model, it grows quickly, and it is usually the KV cache, not the model s weights, that fills up GPU memory first.By default, the cache is stored in 16-bit precision (BF16). We store it in 8-bit floating point instead (FP8, e4m3), which halves its size. On Kimi K2.6, that raises the amount of context we can hold in memory from roughly 686,000 tokens to about 1.37 million, twice as much.It s worth being precise about where the benefit comes from, because it isn t raw speed. Quantizing the cache adds a small amount of work per token, since the FP8 attention kernel has to convert values as it reads them. What it changes is how many requests we can keep resident at once. The following measurements are for Kimi K2.6 decoding on a disaggregated H200 deployment, comparing the attention kernels directly:Concurrent requestsBF16 KV cache (tok/s)FP8 KV cache (tok/s)11371258731689161,1061,028321,5581,48964Out of memory2,192At any single concurrency level, BF16 is a few percent faster per token. But BF16 runs out of cache at 32 concurrent requests and can t admit a 33rd, while FP8 keeps going to 64 and reaches 2,192 tokens per second, about 41% higher than BF16 s peak, for roughly 30% less cost per token. Because we run prefill and decode as separate pools, we can apply this where it helps most: prefill is compute-bound rather than memory-bound, so there we leave the cache in BF16 and keep its slightly higher throughput.None of this would matter if it changed the model s answers, so we checked. Across our evaluation suite, FP8 and BF16 caches are indistinguishable:BenchmarkBF16 KVFP8 KVGSM8K94.2494.09ARC-Easy89.0689.14ARC-Challenge66.7267.49MMLU89.1189.04MMLU-Pro80.2979.29mcxams (internal benchmark)61 / 6361 / 63Tool-call validity92.2%92.6%Compressing the model weightsThe KV cache is one demand on GPU memory; the model s weights are the other. For GLM 5.2, we compress the weights from 8-bit floating point down to 4-bit integers (INT4) with no loss in accuracy. The checkpoint shrinks from 705 GB to 421 GB, about 40%, and per-GPU memory across an 8-way tensor-parallel deployment drops from roughly 88 GB to 52 GB, which leaves room for around 1.18 million tokens of KV cache on the same hardware.Across our evaluation suite, INT4 and FP8 weights are indistinguishable:Benchmark / CapabilityMetricFP8INT4GSM8KExact match94.39%93.56%GSM8KFlexible94.24%93.48%ARC-EasyAccuracy86.62%86.15%ARC-EasyAcc (norm)84.51%85.19%ARC-ChallengeAccuracy64.93%64.85%ARC-ChallengeAcc (norm)67.24%66.64%MMLUAverage86.60%86.54%MMLU-ProExact80.80%80.47%mcxams (internal benchmark)Passed62 / 6362 / 63Smaller weights make the decode phase faster, and for a clear reason: generating each token means streaming the model s weights out of GPU memory, so decode speed is limited by memory bandwidth. Move less data and every token arrives sooner. The effect is largest at low concurrency, where per-request latency matters most:Concurrent requestsGLM FP8 (tok/s)GLM INT4 (tok/s)INT4 gain16092+55%8425513+21%16683825+21%329941,267+27%641,6721,933+16%Prefill behaves differently. It is compute-bound, and INT4 weights have to be expanded back out before the model can multiply with them, so that extra step makes prefill slower rather than faster, GLM sustains about 10,160 tokens per second of prefill in FP8 versus 8,660 in INT4. As with the KV cache, the disaggregated design turns this i
Workers AI runs inference for some of the best open models in the world on GPUs in Cloudflare data centers close to your users. Two of the most capable, and most demanding, are Moonshot s Kimi K-series and Z.ai s GLM. They are large, long-context, mixture-of-experts models, and they are wonderful to use. They are also very hard to serve efficiently because of memory constraints.We ve written before about how we serve large models on Workers AI and about separating the prefill and decode phases of inference to get more out of each GPU. This post looks at three techniques we layer on top of that to fit these models into memory and keep them fast: quantizing the KV cache, compressing the model weights, and, because both of those pack more requests onto shared hardware, protecting the cache those requests share. These optimizations enable us to support more customers at lower costs, with no change in model accuracy.All our experiments and production traffic are running and benchmarked with SGLang, an open-source inference serving framework. We found that SGLang offers the best performance in the market, and we work closely with the SGLang team to upstream patches and new features to make our work available to the open-source community.Quantizing the KV cacheAs a model generates text, it stores the attention keys (K) and values (V) for every token it has already processed in a structure called the KV cache. The cache is what lets the model extend a long conversation without re-reading the entire context on every new token. For a long-context model, it grows quickly, and it is usually the KV cache, not the model s weights, that fills up GPU memory first.By default, the cache is stored in 16-bit precision (BF16). We store it in 8-bit floating point instead (FP8, e4m3), which halves its size. On Kimi K2.6, that raises the amount of context we can hold in memory from roughly 686,000 tokens to about 1.37 million, twice as much.It s worth being precise about where the benefit comes from, because it isn t raw speed. Quantizing the cache adds a small amount of work per token, since the FP8 attention kernel has to convert values as it reads them. What it changes is how many requests we can keep resident at once. The following measurements are for Kimi K2.6 decoding on a disaggregated H200 deployment, comparing the attention kernels directly:Concurrent requestsBF16 KV cache (tok/s)FP8 KV cache (tok/s)11371258731689161,1061,028321,5581,48964Out of memory2,192At any single concurrency level, BF16 is a few percent faster per token. But BF16 runs out of cache at 32 concurrent requests and can t admit a 33rd, while FP8 keeps going to 64 and reaches 2,192 tokens per second, about 41% higher than BF16 s peak, for roughly 30% less cost per token. Because we run prefill and decode as separate pools, we can apply this where it helps most: prefill is compute-bound rather than memory-bound, so there we leave the cache in BF16 and keep its slightly higher throughput.None of this would matter if it changed the model s answers, so we checked. Across our evaluation suite, FP8 and BF16 caches are indistinguishable:BenchmarkBF16 KVFP8 KVGSM8K94.2494.09ARC-Easy89.0689.14ARC-Challenge66.7267.49MMLU89.1189.04MMLU-Pro80.2979.29mcxams (internal benchmark)61 / 6361 / 63Tool-call validity92.2%92.6%Compressing the model weightsThe KV cache is one demand on GPU memory; the model s weights are the other. For GLM 5.2, we compress the weights from 8-bit floating point down to 4-bit integers (INT4) with no loss in accuracy. The checkpoint shrinks from 705 GB to 421 GB, about 40%, and per-GPU memory across an 8-way tensor-parallel deployment drops from roughly 88 GB to 52 GB, which leaves room for around 1.18 million tokens of KV cache on the same hardware.Across our evaluation suite, INT4 and FP8 weights are indistinguishable:Benchmark / CapabilityMetricFP8INT4GSM8KExact match94.39%93.56%GSM8KFlexible94.24%93.48%ARC-EasyAccuracy86.62%86.15%ARC-EasyAcc (norm)84.51%85.19%ARC-ChallengeAccuracy64.93%64.85%ARC-ChallengeAcc (norm)67.24%66.64%MMLUAverage86.60%86.54%MMLU-ProExact80.80%80.47%mcxams (internal benchmark)Passed62 / 6362 / 63Smaller weights make the decode phase faster, and for a clear reason: generating each token means streaming the model s weights out of GPU memory, so decode speed is limited by memory bandwidth. Move less data and every token arrives sooner. The effect is largest at low concurrency, where per-request latency matters most:Concurrent requestsGLM FP8 (tok/s)GLM INT4 (tok/s)INT4 gain16092+55%8425513+21%16683825+21%329941,267+27%641,6721,933+16%Prefill behaves differently. It is compute-bound, and INT4 weights have to be expanded back out before the model can multiply with them, so that extra step makes prefill slower rather than faster, GLM sustains about 10,160 tokens per second of prefill in FP8 versus 8,660 in INT4. As with the KV cache, the disaggregated design turns this i