Click any words you think contain an error. Click again to unmark.
Mark at least one word to submit.
**Decode** in a large language model produces one token at a time. For each new token the GPU must read the model's weights and the growing key-value cache from its main memory (HBM), do a small amount of math, and write the result back. The slow part is reading the data, not doing the math.
This is what people mean by memory-bandwidth-bound. At batch size one, the arithmetic per token is a thin matrix-vector multiplication. Modern GPUs finish that math much faster than they can deliver the weights it needs. So while the math units are idle, the memory bus is pegged.
The plan in the question switches to a model with thirty percent fewer attention FLOPs but the same weight count and the same KV cache size. The bytes that get streamed from HBM on each token step are unchanged. The math gets faster, but the math was never the limit. The realized TPOT improvement is close to zero, not the predicted thirty percent.
The correct levers attack bytes-per-token. Quantize the weights from bf16 to FP8 or INT4 to halve or quarter the weight read. Switch to a model with GQA or MLA to shrink the KV cache. Batch many requests together so each HBM read serves many tokens. Less math, same memory, does nothing.
**The proposal optimizes the wrong axis.** At batch 1, decode is firmly memory-bandwidth-bound. Each step streams the full weight set plus the KV cache from HBM; the per-token math is a thin matrix-vector product the compute units finish in a fraction of the bandwidth time. Cutting FLOPs by thirty percent while leaving bytes-per-token unchanged shaves time off a subproblem that was already overlapped with the memory read, so net wall-clock improvement is closer to zero than thirty.
Formally, the roofline at batch 1 sits on the bandwidth slope. Per-step time is approximately bytes-read divided by HBM bandwidth, capped from below by that ratio regardless of FLOP rate. For a 70B bf16 model the weight read alone is about 140 gigabytes per step; on an A100 at 2 TB/s that is roughly 70 ms of unavoidable memory time. The matmul fits inside that window with room to spare. Removing some of the matmul does not shrink the window.
The correct levers all target bytes-moved-per-step. FP8 weights halve the weight read to roughly 70 GB, cutting TPOT roughly in half on the same hardware. INT4 quartiles it. GQA-8 or MLA shrink the KV cache by eight to one hundred times, easing the KV term of the read. Batching amortizes the weight read across many requests, raising tokens per second per GPU dramatically while leaving any one request's latency roughly fixed. Moving to a higher-bandwidth GPU (H100 at 3.3 TB/s, H200 at 4.8, B200 at 8) cuts the read time directly.
The FLOP-reduction proposal would only matter if the workload were prefill, which is compute-bound, or if the batch were large enough to push decode past the compute crossover. Neither is the case here, so the prediction of thirty percent TPOT improvement is unsupported by the math.
Quick reference
TL;DR
Decode is memory-bandwidth-bound at batch 1: per-step time is set by reading weights and KV cache from HBM, not by the matmul.
Picture a chef whose kitchen is so small that they can only carry one armful of ingredients at a time from the pantry. Once the ingredients are on the counter, chopping them is fast; the slow part is the trip to the pantry and back. Speeding up the chopping does nothing if the chef still has to make the same long walk for the same ingredients. Decode in a large language model is like that. Each new token forces the GPU to fetch the same enormous bag of weights from far-away memory. The actual math is done in a blink once the data arrives. A model that does thirty percent less chopping still walks the same distance to fetch the same load, so the meal is not faster.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Prefill latency or TTFT on long prompts Prefill processes the whole prompt in parallel and is compute-bound for large prompts on capable hardware, so attention-FLOP reductions actually do help here.
Very small models on very fast hardware A 1-7B model on H100/B200 can become compute-bound even at modest batch sizes because the weight read is small enough that math becomes the long pole.
Very large batches on a high-bandwidth GPU Past the bandwidth/compute crossover, the workload becomes compute-bound and FLOP reductions start to matter directly for throughput.
Specialized attention variants whose FLOP win comes from cutting per-step KV reads Some 'fewer FLOPs' variants also shrink bytes-per-step (sparse attention with KV eviction, MoE-style attention). Those help decode for the bandwidth reason, not the FLOP reason, but the FLOP claim coincidentally lands.
Quick scan · 2–4 min
Everything important, quickly.
3 min: name decode as bandwidth-bound at batch 1, derive the TPOT floor from weights/HBM bandwidth, debunk the FLOP-reduction prediction, and prescribe the bytes-per-step levers (quantization, GQA/MLA, batching, faster GPU).
Real-world examples
Real products, models, and research that use this idea.
1vLLM and SGLang both report that single-stream Llama-3 70B decode at batch 1 sustains roughly 30-50 tok/s on A100 and 70-100 tok/s on H100, scaling with HBM bandwidth rather than FLOPs.
2NVIDIA's H200 release notes pitch the 76% bandwidth bump over H100 as the headline inference win, not the unchanged FLOP rate.
3FP8 weight quantization in TensorRT-LLM and vLLM consistently delivers ~1.7-1.9x TPOT improvements on the same GPU, matching the predicted bandwidth scaling.
4DeepSeek-V3 and V4 use MLA precisely to shrink the KV-cache term of the decode-step read, making long-context decode tractable on commodity hardware.
5Groq's LPU markets a >1000 tok/s single-stream rate by pairing modest compute with extremely high SRAM bandwidth and no HBM, a direct confirmation that bandwidth, not FLOPs, sets decode latency.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QAt what batch size does decode cross over from bandwidth-bound to compute-bound on a 70B model on H100?
Sign in or go Pro to see the approach for this follow-up.
QWhy does FP8 weight quantization deliver close to the predicted 2x TPOT improvement while a 30% FLOP reduction delivers almost zero?
Sign in or go Pro to see the approach for this follow-up.
QIf decode is bandwidth-bound, why do GPUs keep adding compute capacity instead of just more HBM bandwidth?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Treating decode as compute-bound and shopping for lower-FLOP models. At batch 1, decode is bandwidth-bound; the matmul finishes well before the HBM read, so cheaper math saves nothing on wall-clock.