<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>AMD Telecom, Author at AMD Telecom</title>
	<atom:link href="https://www.amdtelecom.net/author/amd-telecom/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.amdtelecom.net/author/amd-telecom/</link>
	<description></description>
	<lastBuildDate>Thu, 01 Oct 2026 08:41:31 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.2</generator>

<image>
	<url>https://www.amdtelecom.net/wp-content/uploads/2021/09/amd-logo-blue.svg</url>
	<title>AMD Telecom, Author at AMD Telecom</title>
	<link>https://www.amdtelecom.net/author/amd-telecom/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>SwiGLU Explained: Why Modern LLMs Replaced GELU in the Feed-Forward Block</title>
		<link>https://www.amdtelecom.net/swiglu-explained-gated-ffn/</link>
		
		<dc:creator><![CDATA[AMD Telecom]]></dc:creator>
		<pubDate>Thu, 01 Oct 2026 08:41:31 +0000</pubDate>
				<category><![CDATA[Blog]]></category>
		<guid isPermaLink="false">https://www.amdtelecom.net/?p=7619</guid>

					<description><![CDATA[<p>Two-thirds of a transformer block's parameters sit in the feed-forward path. Here is how SwiGLU gates them, why the 8/3 width rule keeps compute flat, and where it fails.</p>
<p>The post <a href="https://www.amdtelecom.net/swiglu-explained-gated-ffn/">SwiGLU Explained: Why Modern LLMs Replaced GELU in the Feed-Forward Block</a> appeared first on <a href="https://www.amdtelecom.net">AMD Telecom</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>Architecture discussions about large language models tend to orbit attention: context length, cache size, sparsity patterns. Yet in a standard transformer block, the feed-forward network holds roughly twice as many parameters as attention does, and a corresponding share of the per-token matrix-multiply work. The choice of nonlinearity inside that block is therefore not a cosmetic detail. It changes what the block can represent, and if you are careless, it changes your compute bill.</p>
<p>Over the past few years most open-weight models have converged on the same answer: a gated feed-forward block built from SiLU, usually written SwiGLU, instead of a single GELU or ReLU in the middle of two projections. The switch adds a third weight matrix, which sounds like a 50% increase in feed-forward cost. It is not, because the hidden width is shrunk to compensate. This article covers where the activation sits, what gating actually buys you, the arithmetic behind the width rule, and the ways the change fails in practice.</p>
<h2>Where the activation function lives</h2>
<p>A transformer block does two things in sequence. Attention mixes information <em>across</em> tokens. The feed-forward network then processes each token position independently: project the hidden vector up to a wider space, apply a nonlinearity, project back down. No token talks to another inside it. It is a per-position feature transformation, and it is the main place in the block where a per-channel nonlinearity acts on the representation.</p>
<p>The parameter arithmetic is worth doing once. With model dimension <code>d</code>, the attention projections for queries, keys, values and output are four <code>d x d</code> matrices, so about <code>4d²</code> weights. A classical feed-forward block with hidden width <code>4d</code> uses two matrices of size <code>d x 4d</code>, so <code>8d²</code> weights. That is two-thirds of the block&#8217;s parameters sitting in the feed-forward path, and a proportional share of its matrix-multiply FLOPs per token. Anything you change there is a budget decision.</p>
<h2>What a single curve cannot do</h2>
<p>ReLU zeroes negative inputs. GELU and SiLU are smooth alternatives that let a small amount of negative signal through near the origin and flatten out for large negative inputs; neither is strictly monotonic, but both behave like a soft, fixed bend. The important property they share is more basic than their shape: they are applied coordinate-wise. Each hidden unit&#8217;s output depends only on its own pre-activation value. The same curve is applied to every one of the thousands of channels, identically, at every position.</p>
<p>That means the block has no mechanism to decide, based on the input, that channel 417 should be suppressed in this context while channel 93 should pass through at full strength. The weights can scale channels, but the scaling is fixed after training. Everything the nonlinearity contributes is a static bend, not a routing decision.</p>
<h2>Gated linear units: a gate path and a value path</h2>
<p>Gated linear units, introduced for convolutional language models by Dauphin et al. (2017), change that. Instead of one up-projection, you compute two from the same input: a <em>value</em> vector and a <em>gate</em> vector. The gate is passed through a squashing nonlinearity and multiplied element-wise into the value. The product is then projected back down to the model dimension.</p>
<p>The consequence is multiplicative rather than additive. Each output channel is now a product of two different projections of the input, one of them passed through a nonlinearity, so a channel can be driven towards zero by evidence that has nothing to do with its own value path. In practical terms:</p>
<ul>
<li>The block can open some feature lanes and close others depending on the token and its context.</li>
<li>Interactions between channels become second-order, not just the first-order mixing a linear layer provides.</li>
<li>Gradients flow through two paths, which changes the conditioning of training — usually for the better, sometimes for the worse if the gate degenerates.</li>
</ul>
<h2>SwiGLU: SiLU on the gate, linear on the value</h2>
<p>SwiGLU is the variant that stuck. The gate uses SiLU, also known as swish, defined as <code>x * sigmoid(x)</code>: smooth, unbounded above, with no flat dead region for small negative inputs. The value path stays linear. The full block is <code>down(SiLU(x @ W_gate) * (x @ W_up))</code>, with <code>*</code> as an element-wise product. Biases are typically omitted.</p>
<p>The systematic comparison comes from Shazeer&#8217;s <em>GLU Variants Improve Transformer</em> (2020), which evaluates several gated feed-forward variants against ReLU and GELU baselines on text-to-text pretraining and reports better perplexity for the gated variants at matched parameter counts. The PaLM paper (Chowdhery et al., 2022) and Meta&#8217;s LLaMA paper (Touvron et al., 2023) both state that they use SwiGLU in their feed-forward layers, and most open-weight model families released since have followed.</p>
<h2>The 8/3 rule, and why it is not optional</h2>
<p>Three matrices instead of two is the obvious objection. The fix is to narrow the hidden dimension. Call the gated hidden width <code>h</code>. The gated block uses three matrices between <code>d</code> and <code>h</code>, so <code>3dh</code> parameters. Setting that equal to the <code>8d²</code> of the classical block gives <code>h = 8d/3</code> — two-thirds of the usual <code>4d</code>. Parameter count matches, and since feed-forward FLOPs per token scale with parameter count, so does compute.</p>
<p>LLaMA 7B is a clean illustration: the LLaMA paper (Touvron et al., 2023) gives it a model dimension of 4096, and the released model configuration sets the feed-forward hidden size to 11008. Eight thirds of 4096 is about 10,923; 11008 is that value rounded up to a multiple of 256, which keeps the matrix shapes friendly to GPU kernels.</p>
<p>The mistake to avoid is keeping <code>4d</code> while adding the gate. You will get a model that trains better than the baseline and conclude SwiGLU works, when in fact you have simply spent 50% more on the feed-forward block. Any comparison worth acting on is run at matched parameters and matched FLOPs, not matched width.</p>
<h2>Implementation details that decide whether it works</h2>
<ul>
<li><strong>Fuse the two up-projections.</strong> Materialise a single matrix of width <code>2h</code> and split the result into gate and value halves. One larger matrix multiply generally uses the hardware better than two smaller ones.</li>
<li><strong>Round the hidden width.</strong> Take <code>8d/3</code> as a target, then round to a multiple that suits your kernels and your tensor-parallel degree, as LLaMA does.</li>
<li><strong>Put dropout after the product.</strong> Dropping units inside the gate path corrupts the gating signal itself rather than regularising the block&#8217;s output.</li>
<li><strong>Watch the gate path at initialisation.</strong> If the gate collapses towards a constant early in training, the block degenerates into a plain projection-plus-nonlinearity and the benefit disappears. Initialisation scale and learning rate for that projection are the first things to check when a gated model underperforms.</li>
<li><strong>Do not assume the gain transfers.</strong> The reported improvements come from language-model pretraining. On small models, narrow domains or non-language tasks, the difference can be within noise, and you need your own matched-budget comparison to know.</li>
</ul>
<h2>What this means for organisations training their own models</h2>
<p>The useful lesson is not &#8220;use SwiGLU&#8221; — most frameworks already default to it. It is that the strongest architecture decisions are the budget-neutral ones: a change that improves loss while holding parameters and FLOPs fixed compounds across every training run and every deployment of that model. Evaluating such a change honestly requires discipline about the control, which is why the 8/3 width rule matters as much as the gating formula. The same reasoning applies elsewhere in the stack, from <a href="/hybrid-attention-long-context-llms/">how much full attention a long-context model actually needs</a> to <a href="/llm-quantization-explained/">how many bits each weight is stored in at serving time</a>.</p>
<p>It also affects planning. A gated feed-forward block changes the shape of every matrix in two-thirds of your parameter budget, which propagates into memory layout, tensor-parallel splits and checkpoint sizes. Decide it before you start a long pretraining or continued-pretraining run, not after. AMD Telecom trains and fine-tunes deep-learning models and large language models on its own in-house GPUs.</p>
<p>If you are weighing architecture choices for a model you intend to train on your own data, our <a href="/ai-model-training">AI Model Training</a> and <a href="/ai-model-development">AI Model Development</a> pages cover this work. <a href="/contact-us/">Contact us</a> to discuss your case.</p>
<p>The post <a href="https://www.amdtelecom.net/swiglu-explained-gated-ffn/">SwiGLU Explained: Why Modern LLMs Replaced GELU in the Feed-Forward Block</a> appeared first on <a href="https://www.amdtelecom.net">AMD Telecom</a>.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Why Attention Is Memory-Bound: Inside FlashAttention and IO-Aware Kernels</title>
		<link>https://www.amdtelecom.net/flash-attention-io-aware-kernels/</link>
		
		<dc:creator><![CDATA[AMD Telecom]]></dc:creator>
		<pubDate>Thu, 01 Oct 2026 08:38:38 +0000</pubDate>
				<category><![CDATA[Blog]]></category>
		<guid isPermaLink="false">https://www.amdtelecom.net/?p=7617</guid>

					<description><![CDATA[<p>Attention is limited by memory bandwidth, not arithmetic. Here is how tiling, online softmax and recomputation make FlashAttention exact and fast.</p>
<p>The post <a href="https://www.amdtelecom.net/flash-attention-io-aware-kernels/">Why Attention Is Memory-Bound: Inside FlashAttention and IO-Aware Kernels</a> appeared first on <a href="https://www.amdtelecom.net">AMD Telecom</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>Most discussions of transformer cost start with arithmetic: attention scales quadratically with sequence length, so doubling the context quadruples the work. That is true, but it is not the reason attention is slow on real hardware. On a modern accelerator the multiplications are comparatively cheap. What costs time is moving the numbers between the GPU&#8217;s main memory and the small, fast memory that sits next to the arithmetic units.</p>
<p>FlashAttention, introduced in 2022 by Dao et al. as <em>FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness</em>, is built around that observation. It does not approximate attention, drop tokens or sparsify the score matrix. It reorganises the computation so that the large intermediate matrices are never written to main memory at all: the same output, far less data movement. Variants of it are now the default attention path in mainstream training and serving stacks.</p>
<h2>Attention is memory-bound, not compute-bound</h2>
<p>Consider what a single attention head does for a sequence of length <code>N</code>. It computes an <code>N × N</code> matrix of scores, applies a softmax across each row, then multiplies the resulting probabilities by the values. A naive implementation materialises two full <code>N × N</code> matrices — the raw scores and the post-softmax probabilities — in memory.</p>
<p>The arithmetic is worth doing yourself. At a sequence length of 8,192 in 16-bit precision, one such matrix is 8,192 × 8,192 × 2 bytes ≈ 134 MB — for a single head. With 32 heads that is about 4 GB of intermediate data for one attention layer in one forward pass, all of it written out and read back, with the softmax step touching it twice.</p>
<p>Meanwhile the matrix multiplications are exactly the dense, regular work that tensor cores handle well. Arithmetic throughput has grown faster than memory bandwidth, so the kernel spends most of its wall-clock time waiting for transfers. Adding FLOPs to such a kernel costs almost nothing; removing memory traffic is what makes it faster.</p>
<h2>Two levels of memory, one bottleneck</h2>
<p>The hardware picture is simple. High-bandwidth memory (HBM) is the large pool quoted on the spec sheet, tens of gigabytes. On-chip SRAM — the shared memory and registers attached to each streaming multiprocessor — is tiny by comparison: the FlashAttention paper puts an A100 at 40 GB of HBM against roughly 20 MB of on-chip SRAM in total, with the on-chip memory roughly an order of magnitude faster.</p>
<p>An <code>N × N</code> score matrix at long context does not fit in 20 MB, so a standard implementation has no choice but to stage it through HBM, and every round trip is a stall. The design question becomes: can we produce the same result while keeping every intermediate inside the fast memory?</p>
<h2>Three ideas that make it work</h2>
<ul>
<li><strong>Tiling.</strong> Split the queries, keys and values into blocks small enough that a tile of the score matrix fits in SRAM. Load a block of queries, stream blocks of keys and values past it, and compute the scores, their softmax contribution and the output accumulation inside fast memory. Q, K and V are read once; the output is written once.</li>
<li><strong>Online softmax.</strong> Softmax normally needs the whole row: subtract the row maximum for numerical stability, then divide by the sum of exponentials. Tiling means you only ever see part of a row. The fix is to carry a running maximum and a running sum alongside the partial output, rescaling the accumulated result whenever a new tile raises the maximum. The algebra works out exactly.</li>
<li><strong>Recomputation.</strong> The backward pass needs the attention probabilities to compute gradients. Rather than keeping them from the forward pass — which would reintroduce the memory cost — FlashAttention recomputes them from Q and K using the saved softmax statistics. That is more arithmetic in exchange for less traffic, the right trade when arithmetic is the abundant resource.</li>
</ul>
<p>Put together, the kernel is an outer loop over query blocks and an inner loop over key and value blocks, with the running statistics and the partial output held in fast memory. The output is exact — the same attention, not a cheaper approximation of it — which is what makes it safe to apply to an already-trained model.</p>
<h2>What changed in versions 2 and 3</h2>
<p>The first version parallelised across the batch and the attention heads, which leaves GPUs underused when the batch is small and the sequence is long — precisely the long-context regime people care about. FlashAttention-2 (Dao, 2023) added parallelism over the sequence dimension, reduced the non-matmul work around the softmax and improved how work is partitioned between warps. The paper reports roughly 2× over the original, with attention reaching 50–73% of the theoretical maximum matmul throughput on an A100.</p>
<p>FlashAttention-3 (Shah et al., 2024) targets Hopper-class hardware, exploiting asynchronous tensor-core instructions and the tensor memory accelerator through warp specialisation: some warps do nothing but fetch the next tile while others compute on the current one, forming a producer–consumer pipeline. The paper reports 1.5–2.0× over FlashAttention-2 on H100 in FP16, and higher throughput again in FP8.</p>
<p>Each generation extracts more overlap between data movement and arithmetic, and each is tied more tightly to a particular GPU architecture. Related work such as ring attention extends the same tiling logic across devices, splitting one sequence over several GPUs.</p>
<h2>Turning it on, and when you do not get it</h2>
<p>In practice this is rarely a code-writing exercise. PyTorch dispatches <code>scaled_dot_product_attention</code> to a fused backend when the inputs and hardware allow it, and Hugging Face Transformers exposes an attention implementation argument when a model is loaded. The work is in the conditions, not the call:</p>
<ul>
<li><strong>Hardware generation.</strong> The flash-attn project requires Ampere or newer for FlashAttention-2, and its version 3 kernels target Hopper. Older cards fall back to a slower path.</li>
<li><strong>Dtype and shape constraints.</strong> Fused kernels typically require half or bfloat16 inputs and particular head dimensions. Step outside them and you silently get the reference implementation.</li>
<li><strong>Masking and bias.</strong> Causal and padding masks are supported; arbitrary additive attention biases often are not, and a custom mask is a common reason a model quietly loses the fast path.</li>
<li><strong>Verify, do not assume.</strong> Profile the kernel that actually ran. A change upstream can disable fusion without any error message.</li>
</ul>
<p>It also composes with the rest of the stack. Memory saved on activations is memory available for the KV cache, which is why these kernels and the paged cache described in <a href="/serving-llms-on-your-own-gpus/">serving LLMs on your own GPUs</a> are usually deployed together, and why <a href="/hybrid-attention-long-context-llms/">hybrid attention designs</a> assume an efficient exact kernel as their baseline.</p>
<h2>What this means for organisations training on their own hardware</h2>
<p>The lesson generalises beyond attention. When you budget a training run or a fine-tune, the first question is not how many FLOPs the model needs but where the bytes are going; a kernel waiting on HBM will not go faster on a card with more tensor cores. Before reaching for architectural changes that alter model quality, confirm that the exact, well-optimised kernels are actually being used — throughput with no accuracy trade-off, and often the difference between a long-context experiment being affordable or not.</p>
<p>It also changes how you read hardware requirements. Because these kernels are tied to specific GPU generations and precisions, the gap between an older and a newer card is wider than the headline specifications suggest. AMD Telecom trains and fine-tunes deep-learning models and large language models on its own in-house GPUs.</p>
<p>If you are planning a training run or assessing what your infrastructure can realistically support, our <a href="/ai-model-training">AI Model Training</a> and <a href="/ai-model-development">AI Model Development</a> services are a good place to start — <a href="/contact-us/">contact us</a> to discuss your requirements.</p>
<p>The post <a href="https://www.amdtelecom.net/flash-attention-io-aware-kernels/">Why Attention Is Memory-Bound: Inside FlashAttention and IO-Aware Kernels</a> appeared first on <a href="https://www.amdtelecom.net">AMD Telecom</a>.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>How Reasoning LLMs Are Trained: Verifiable Rewards and GRPO</title>
		<link>https://www.amdtelecom.net/how-reasoning-llms-are-trained-grpo/</link>
		
		<dc:creator><![CDATA[AMD Telecom]]></dc:creator>
		<pubDate>Wed, 30 Sep 2026 20:33:27 +0000</pubDate>
				<category><![CDATA[Blog]]></category>
		<guid isPermaLink="false">https://www.amdtelecom.net/?p=7606</guid>

					<description><![CDATA[<p>How reasoning models are trained with verifiable rewards and GRPO, why the critic network disappeared, and what can still go wrong.</p>
<p>The post <a href="https://www.amdtelecom.net/how-reasoning-llms-are-trained-grpo/">How Reasoning LLMs Are Trained: Verifiable Rewards and GRPO</a> appeared first on <a href="https://www.amdtelecom.net">AMD Telecom</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>Give a standard language model a hard maths problem and it answers in two seconds: fast, confident and sometimes incomplete. A reasoning model takes longer. It writes out a plan, tries an approach, checks it, backtracks when it hits a contradiction, and only then answers. Surprisingly, both can use the same transformer architecture. The difference is how they were trained.</p>
<h2>From likely text to correct answers</h2>
<p>Pre-training teaches a model to predict the next token, so it is rewarded for sounding likely, not for being right. Instruction tuning and preference training make it fluent, helpful and safe, but none of these stages directly rewards multi-step reasoning. Reasoning models add a further stage: <strong>reinforcement learning on problems whose answers can be checked</strong>. The model writes a chain of thought and an answer; a correct answer earns a reward, a wrong one does not. Nobody tells it <em>how</em> to reason.</p>
<h2>The classic recipe needed four networks</h2>
<p>Reinforcement learning from human feedback (RLHF) runs four models side by side:</p>
<ul>
<li>the <strong>policy</strong>, which writes the answers;</li>
<li>a <strong>reward model</strong>, trained on thousands of human rankings to score them;</li>
<li>a <strong>critic</strong> (value model), which estimates a baseline so each update knows whether an answer did better or worse than expected;</li>
<li>a frozen <strong>reference</strong> copy, which stops the policy drifting too far.</li>
</ul>
<p>Two of the four, the reward model and the critic, exist only to manufacture a learning signal.</p>
<h2>Verifiable rewards remove the reward model</h2>
<p>For maths and code there is no need to <em>learn</em> what a good answer looks like: you can check it. Run the tests, compare the final number, verify the proof. This is <strong>RLVR</strong>, reinforcement learning with verifiable rewards: a verifier returns 1 or 0, with no human labels and no training. The reward is still there; only the learning of it is gone. The boundary is honest: it works where cheap, exact checks exist, gets expensive for proofs and agentic tasks, and does not apply to open-ended writing.</p>
<h2>GRPO removes the critic</h2>
<p><strong>GRPO</strong> (group relative policy optimisation) replaces the critic with something almost embarrassingly simple. For each prompt, sample a group of answers and score each one. The group&#8217;s average reward <em>is</em> the baseline; an answer&#8217;s advantage is how far it landed above or below its peers. The update itself uses the same clipped objective as PPO. Four models become two: the policy and the reference. That means one less large network in GPU memory during training.</p>
<h2>What emerged when DeepSeek let it run</h2>
<p>DeepSeek-R1-Zero skipped the usual warm-up of supervised examples entirely and applied RLVR straight to a pre-trained base model. Nobody rewarded length, yet the average response length grew steadily during training, because longer reasoning reached verifiable answers more often. The DeepSeek-R1 paper (2025) describes behaviours such as re-checking and reflecting on earlier steps emerging without any demonstrations. The outputs were hard to read, sometimes switching language mid-thought, so the full DeepSeek-R1 used four stages instead: a small supervised &#8220;cold start&#8221; for readable style, then RL, then fine-tuning on the model&#8217;s own best answers, then RL again. A strong reasoning model can then be <em>distilled</em>: smaller models fine-tuned on its reasoning traces gain much of the ability without any RL of their own.</p>
<h2>What goes wrong in practice</h2>
<ul>
<li><strong>Entropy collapse.</strong> Rewards concentrate probability on what already works. Push too far and the model stops exploring, and the reward curve flattens because it stopped trying anything new, not because it solved the task.</li>
<li><strong>Hidden biases in the objective.</strong> Dividing by response length dilutes the signal for long correct answers, which quietly teaches the model that longer is better. Dividing by the group&#8217;s standard deviation over-weights problems that are trivially easy or impossibly hard. The Dr. GRPO paper (&#8220;Understanding R1-Zero-Like Training&#8221;, 2025) simply drops both terms.</li>
<li><strong>Mixture-of-experts instability.</strong> In sparse models, the router&#8217;s choice of experts changes between updates. The Qwen team&#8217;s GSPO paper (2025) reports that about 10% of the activated experts change after each update in Qwen3-30B-A3B. Token-level probability ratios then explode or collapse. <strong>GSPO</strong> computes the ratio over the whole sequence instead, which averages out the churn; the Qwen team used it to train its Qwen3 models.</li>
</ul>
<h2>Two caveats worth knowing</h2>
<p><strong>Does RL create new reasoning, or amplify what was already there?</strong> The evidence points both ways. A 2025 study from Tsinghua University (&#8220;Does Reinforcement Learning Really Incentivize Reasoning Capacity in LLMs Beyond the Base Model?&#8221;) found that a base model sampled enough times eventually matches the RL-trained one; other studies on controlled tasks report abilities the base model never shows. The question is open.</p>
<p><strong>Reasoning is not factual reliability.</strong> RL rewards correctness where it can be verified; open-ended facts get no such feedback. OpenAI&#8217;s own system card for o3 reports a hallucination rate of 33% on its PersonQA benchmark, against 16% for o1. A model can reason confidently when it should be uncertain, so factual answers still need grounding in your own data.</p>
<h2>What this means for training models on your own data</h2>
<p>At AMD Telecom we train models on our own in-house GPUs. RL with verifiable rewards is interesting well beyond maths contests, because many business tasks <em>can</em> be checked automatically:</p>
<ul>
<li>data extracted from a document compared against the system of record;</li>
<li>generated SQL that must run and return the expected rows;</li>
<li>classifications with known labels;</li>
<li>structured output that must satisfy a schema (see <a href="/llm-structured-output-valid-json/">how LLMs are forced to return valid JSON</a>).</li>
</ul>
<p>Where such a verifier exists, critic-free methods like GRPO make the training loop simpler and lighter on GPU memory. Where it does not, you are back to human judgement, and your evaluation should be as careful as your training.</p>
<p>If you want a model trained on your own data and checked against your own definition of correct, see our <a href="/ai-model-training">AI Model Training</a> and <a href="/ai-model-development">AI Model Development</a> services, or <a href="/contact-us/">talk to our experts</a>.</p>
<p>The post <a href="https://www.amdtelecom.net/how-reasoning-llms-are-trained-grpo/">How Reasoning LLMs Are Trained: Verifiable Rewards and GRPO</a> appeared first on <a href="https://www.amdtelecom.net">AMD Telecom</a>.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>How LLMs Are Forced to Return Valid JSON: Constrained Decoding Explained</title>
		<link>https://www.amdtelecom.net/llm-structured-output-valid-json/</link>
		
		<dc:creator><![CDATA[AMD Telecom]]></dc:creator>
		<pubDate>Wed, 30 Sep 2026 20:33:20 +0000</pubDate>
				<category><![CDATA[Blog]]></category>
		<guid isPermaLink="false">https://www.amdtelecom.net/?p=7604</guid>

					<description><![CDATA[<p>How constrained decoding makes a language model return valid JSON every time, and what it still cannot guarantee in a business process.</p>
<p>The post <a href="https://www.amdtelecom.net/llm-structured-output-valid-json/">How LLMs Are Forced to Return Valid JSON: Constrained Decoding Explained</a> appeared first on <a href="https://www.amdtelecom.net">AMD Telecom</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>In a chat window, a language model can answer however it likes. In a business process it cannot. When its output feeds another system, such as a tool call, a CRM record or an invoice line, every brace, quote, field name and allowed value is fixed in advance, and one missing quotation mark breaks the whole object. So how do you make a model that writes one token at a time <em>always</em> return valid JSON?</p>
<h2>Why prompting and retries are not enough</h2>
<p>The obvious first step is to ask for JSON in the prompt. That makes the right structure more likely, but it cannot make every wrong continuation impossible. The usual defence is a pipeline: generate, parse, validate against a schema, and retry or repair on failure. Take a simple weather lookup to see its limits. One attempt drops a quote and fails the parser. Another is valid JSON but writes <code>units</code> instead of <code>unit</code>, so it fails the schema. Both are caught, but only after the tokens were generated and paid for. Repair can fix punctuation, but it becomes guesswork once the mistake is bigger than a comma.</p>
<h2>Constrained decoding: block illegal tokens before they are chosen</h2>
<p>At every step the model scores thousands of candidate next tokens, and a sampler picks one. Constrained (grammar-based) decoding places a filter between those two steps. Any token that would make a valid completion impossible is masked: its probability is set to zero. The sampler can only choose among the tokens that survive. Legal tokens keep their relative scores; the mask does not make them equally likely and does not change the model&#8217;s weights.</p>
<p>The loop is <strong>mask, sample, advance</strong>. After each token the constraint moves on, because what is legal next depends on everything generated so far. The model is not even allowed to stop early: the end-of-output token is masked until the object is complete. The same idea works for other formal languages, such as SQL, XML or program syntax, not just JSON.</p>
<h2>The hard part: tokens are not characters</h2>
<p>A model token can contain a quote, a comma, part of a field name, or several JSON boundaries at once. Suppose the output so far is <code>{"city": "Paris", "unit": "</code> and the only allowed values are <code>C</code> or <code>F</code>. The tokens <code>C</code>, <code>C"</code> and even <code>C"}</code> all keep a valid completion possible. <code>Celsius</code> starts with the right letter but cannot be completed validly, so it is masked, however highly the model scored it. A reliable constraint therefore tests the <em>whole</em> token against the grammar, not just its first character.</p>
<p>Simple choices such as C-or-F can be tracked with a small finite-state machine. Nested objects and arrays need parser state that remembers every bracket still to be closed. In practice an engine <em>compiles</em> the supported part of the JSON Schema, together with the model&#8217;s tokenizer, into a recognizer that can answer &#8220;which tokens are legal now?&#8221; quickly at every step.</p>
<h2>How well does it work?</h2>
<p>Three questions are easy to blur, and deserve separate answers:</p>
<ul>
<li><strong>Validity.</strong> When OpenAI introduced strict structured outputs in 2024, it reported that its model matched the supplied JSON schemas in 100% of its internal tests, against under 40% for an earlier model relying on instructions alone.</li>
<li><strong>Coverage.</strong> Engines enforce different subsets of JSON Schema. The JSONSchemaBench study (2025) found marked differences in which schema features the popular engines support.</li>
<li><strong>Speed.</strong> Overhead depends on the engine, hardware, schema and caching. It can be negligible or significant, so measure your own setup.</li>
</ul>
<h2>What it guarantees, and what it does not</h2>
<p>Constrained decoding guarantees <em>form</em>: every emitted token kept a valid completion possible, and output ended only when the structure was complete. It does not guarantee:</p>
<ul>
<li><strong>Meaning.</strong> A call for Paris is perfectly valid even if the user asked about Prague.</li>
<li><strong>Completion.</strong> A token limit, a cancellation or a dropped connection can still cut the output short.</li>
<li><strong>Permission.</strong> A well-formed request is not an authorised one.</li>
</ul>
<p>Those remain separate layers: semantic checks against the request, permission gates with least privilege, and validation of the effect in the downstream system. In short: the decoder can guarantee the brackets, not the weather, and not the permission to fetch it.</p>
<h2>Why this matters for AI in business processes</h2>
<p>Assistants that trigger actions and models that automate transactions and workflows, part of our <a href="/ai-model-development">AI Model Development</a> service, live or die by machine-readable output. Constrained decoding removes a whole class of failures, such as broken JSON, missing fields and invented enum values, before they happen, instead of catching them with retries. It works best alongside:</p>
<ul>
<li>schemas kept deliberately simple and within what your engine fully supports;</li>
<li>business-rule checks on the values themselves;</li>
<li>explicit permissions on every action a model can trigger.</li>
</ul>
<p>Structured, predictable output also combines well with speculative decoding for speed; see <a href="/serving-llms-on-your-own-gpus/">serving LLMs on your own GPUs</a>. If you are planning an AI application that has to talk to your systems, see our <a href="/ai-model-development">AI Model Development</a> and <a href="/ai-model-training">AI Model Training</a> services, or <a href="/contact-us/">talk to our experts</a>.</p>
<p>The post <a href="https://www.amdtelecom.net/llm-structured-output-valid-json/">How LLMs Are Forced to Return Valid JSON: Constrained Decoding Explained</a> appeared first on <a href="https://www.amdtelecom.net">AMD Telecom</a>.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>LLM Quantization Explained: Running Bigger Models on Fewer GPUs</title>
		<link>https://www.amdtelecom.net/llm-quantization-explained/</link>
		
		<dc:creator><![CDATA[AMD Telecom]]></dc:creator>
		<pubDate>Wed, 30 Sep 2026 20:33:13 +0000</pubDate>
				<category><![CDATA[Blog]]></category>
		<guid isPermaLink="false">https://www.amdtelecom.net/?p=7602</guid>

					<description><![CDATA[<p>How quantization shrinks large language models to fit on fewer GPUs, makes them faster, and makes fine-tuning on your own data practical.</p>
<p>The post <a href="https://www.amdtelecom.net/llm-quantization-explained/">LLM Quantization Explained: Running Bigger Models on Fewer GPUs</a> appeared first on <a href="https://www.amdtelecom.net">AMD Telecom</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>The memory a language model needs follows one simple rule: <strong>number of parameters × bytes per value</strong>. A 70-billion-parameter model stored in 32-bit floating point needs 280 GB just for its weights. In 16-bit it needs 140 GB, in 8-bit 70 GB, and in 4-bit 35 GB, which fits on a single 80 GB GPU with room to spare. How many bytes each number gets is a choice, and that choice is what quantization is about.</p>
<h2>Smaller is also faster</h2>
<p>It is natural to assume that generating text is limited by compute. For one conversation at a time, it is not: producing each token means reading every weight from GPU memory once, and the GPU&#8217;s arithmetic units spend most of their time waiting for data. Memory bandwidth is the real bottleneck, so fewer bytes per weight translate almost directly into more tokens per second on the same chip.</p>
<h2>How quantization works</h2>
<p>Quantization maps continuous values onto a fixed grid. An 8-bit integer has 256 levels, and a 4-bit one only 16. A <em>scale</em> sets how much real value each step represents, and a <em>zero point</em> makes sure zero is exactly representable. Each weight snaps to the nearest grid point; the gap is the quantization error. At 8 bits the grid is fine and errors are tiny; at 4 bits they become large enough that simple rounding is no longer good enough.</p>
<p>Granularity matters as much as bit width. One scale for a whole matrix is dominated by a few outlier values and wastes most of the grid on everyone else. Giving each row its own scale is better; giving each small group of weights (typically 128) its own scale is better still, at a small storage cost. Per-group scaling is the standard for 4-bit models.</p>
<p>The number formats differ too. <strong>BF16</strong> keeps the wide range of 32-bit floats with less precision, which is why it is preferred for training, where gradients can spike. <strong>FP16</strong> has more precision but overflows above 65,504. <strong>FP8</strong> is becoming a training format in its own right. <strong>NF4</strong> is a 4-bit lookup table whose 16 values follow a normal distribution, matching the shape of real weight distributions.</p>
<h2>The main methods</h2>
<p>Almost everything deployed today uses <em>post-training quantization</em>: take a trained model and a small calibration set of a few hundred samples, and quantize in minutes to hours instead of retraining for days. The best-known methods:</p>
<ul>
<li><strong>GPTQ</strong> quantizes a layer one column at a time and adjusts the remaining weights to compensate for each rounding error, using second-order information about which weights the output is most sensitive to. The GPTQ paper (Frantar et al., 2022) showed 4-bit models staying close to their 16-bit accuracy where plain rounding degrades sharply, and quantized a 175-billion-parameter model in about four GPU hours.</li>
<li><strong>AWQ</strong> (activation-aware weight quantization) observes that about 1% of weight channels matter far more than the rest, judged by how strongly they are used, not by how large they are. It scales those channels up before quantizing so that they lose less precision. It won best paper at MLSys 2024.</li>
<li><strong>SmoothQuant</strong> targets 8-bit weights <em>and</em> 8-bit activations. It moves the difficulty of rare activation outliers into the weights, so that both can run on 8-bit hardware for high-throughput serving.</li>
<li><strong>GGUF</strong>, the format behind llama.cpp, runs quantized models on CPUs and consumer hardware. Its &#8220;K-quants&#8221; such as Q4_K_M give sensitive layers more bits and average a little under five bits per weight, so a 7B model shrinks from about 13.5 GB in 16-bit to around 4 GB. Q4_K_M is widely used as the default balance of size and quality.</li>
</ul>
<h2>Fine-tuning on limited GPUs: QLoRA</h2>
<p>Quantization is not only for inference. QLoRA freezes the base model in 4-bit NF4 and trains only small low-rank adapter matrices kept in 16-bit, so gradients flow through a tiny fraction of the parameters. A second trick, double quantization, compresses the scale factors themselves. The result, as the QLoRA paper (Dettmers et al., 2023) showed, is that a 65B model can be fine-tuned on a single 48 GB GPU, which put large-model fine-tuning within reach of teams without data-centre budgets.</p>
<h2>Don&#8217;t forget the KV cache</h2>
<p>At long context lengths the KV cache, the stored keys and values of the conversation so far, can outgrow the weights. For a model like Llama 2 70B it is about 320 KB per token in 16-bit, or roughly 40 GB at 128,000 tokens. Storing the cache in 8 bits halves that memory and 4 bits quarters it. Serving engines such as vLLM support an 8-bit (FP8) cache; the quality cost is usually small but should be measured on your own tasks. Our article on <a href="/serving-llms-on-your-own-gpus/">serving LLMs on your own GPUs</a> covers the cache in more detail.</p>
<h2>How low can you go?</h2>
<p>Larger models tolerate compression better, because their redundancy absorbs the rounding noise. Research on the trade-off between bits and accuracy (Dettmers and Zettlemoyer, &#8220;The case for 4-bit precision&#8221;, 2023) found 4-bit to be almost always the best choice for a fixed memory budget: a larger model at 4 bits beats a smaller model at higher precision. Below about 3 bits, standard methods break down. Research methods such as QuIP#, AQLM and QTIP use vector quantization to make 2-bit usable, and Microsoft&#8217;s BitNet b1.58 goes to three values per weight, but it has to be trained that way from scratch.</p>
<h2>A practical map</h2>
<ul>
<li><strong>One user or a few, memory-bound:</strong> 4-bit weights with 16-bit activations (GPTQ or AWQ).</li>
<li><strong>High-throughput serving:</strong> 8-bit weights and activations, or FP8 on hardware that supports it.</li>
<li><strong>CPUs, laptops and edge devices:</strong> GGUF, starting from Q4_K_M.</li>
<li><strong>Fine-tuning on your own data with limited GPUs:</strong> QLoRA.</li>
</ul>
<h2>What this means when the GPUs are your own</h2>
<p>At AMD Telecom we train models on our own in-house GPUs. On fixed hardware, quantization decides which model sizes fit, how many can run side by side and how many tokens per second each one delivers. It also makes adapting larger models to your own data practical. One caution applies everywhere: perplexity is only a proxy. Always evaluate the quantized model on your own tasks, such as your documents, your languages and your output formats, before it goes into production.</p>
<p>If you want a model trained or adapted on your own data, see our <a href="/ai-model-training">AI Model Training</a> and <a href="/ai-model-development">AI Model Development</a> services, or <a href="/contact-us/">talk to our experts</a>.</p>
<p>The post <a href="https://www.amdtelecom.net/llm-quantization-explained/">LLM Quantization Explained: Running Bigger Models on Fewer GPUs</a> appeared first on <a href="https://www.amdtelecom.net">AMD Telecom</a>.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Serving LLMs on Your Own GPUs: KV Cache, PagedAttention and Speculative Decoding</title>
		<link>https://www.amdtelecom.net/serving-llms-on-your-own-gpus/</link>
		
		<dc:creator><![CDATA[AMD Telecom]]></dc:creator>
		<pubDate>Wed, 30 Sep 2026 20:33:06 +0000</pubDate>
				<category><![CDATA[Blog]]></category>
		<guid isPermaLink="false">https://www.amdtelecom.net/?p=7600</guid>

					<description><![CDATA[<p>The KV cache, PagedAttention and speculative decoding decide how fast a model answers and how many users your own GPUs can serve.</p>
<p>The post <a href="https://www.amdtelecom.net/serving-llms-on-your-own-gpus/">Serving LLMs on Your Own GPUs: KV Cache, PagedAttention and Speculative Decoding</a> appeared first on <a href="https://www.amdtelecom.net">AMD Telecom</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>Training a model is only half the work. Once it is running on your own GPUs, three techniques decide how fast it answers and how many people it can serve at once: the KV cache, PagedAttention and speculative decoding. None of them changes what the model says. They change how much memory and time each answer costs.</p>
<h2>1. The KV cache: never redo finished work</h2>
<p>A language model writes one token at a time, and every new token attends to all the tokens before it. Done naively, generating token 1,000 would mean recomputing the keys and values of the 999 tokens before it, even though none of them has changed. The KV cache stores those keys and values once and reuses them, so each step computes only what is new: the query, key and value of the latest token. The work per token stops growing with everything that came before, and generation becomes several times faster.</p>
<p>The price is memory. For every token in every conversation, each layer keeps a key and a value vector. The size is simple to estimate:</p>
<p><strong>KV cache per token = 2 × layers × key-value heads × head dimension × bytes per value</strong></p>
<p>Take a 70B-class model that uses grouped-query attention, with 80 layers and 8 key-value heads of dimension 128, stored in 16-bit precision. That is about 320 KB per token, or roughly 2.6 GB for a single 8,000-token conversation. Sixteen such conversations at once need around 42 GB for the cache alone, on top of the model weights. Grouped-query and multi-query attention exist precisely to shrink this: several attention heads share one set of keys and values.</p>
<p>The cache only matters at inference. During training the whole sequence is processed in parallel, so there is nothing to reuse.</p>
<h2>2. PagedAttention: manage GPU memory like an operating system</h2>
<p>Knowing the cache size is not enough; it also has to be placed in GPU memory. Traditional serving reserves one contiguous block per request, sized for the longest answer it might produce. Most requests finish far shorter, so the reserved space sits idle, and as requests come and go, free memory breaks into gaps too small for the next request. A request can be rejected while plenty of memory is technically free. The authors of vLLM (Kwon et al., SOSP 2023) found that existing serving systems wasted 60–80% of their KV-cache memory this way.</p>
<p>PagedAttention, the core of the open-source vLLM engine, borrows virtual memory from operating systems:</p>
<ul>
<li><strong>Fixed-size blocks.</strong> The cache is cut into small blocks, commonly 16 tokens each, placed anywhere in GPU memory. A block table maps each conversation&#8217;s logical order to the physical blocks.</li>
<li><strong>Allocation on demand.</strong> A conversation takes a new block only when it fills the last one, and returns all its blocks the moment it finishes.</li>
<li><strong>Prefix sharing.</strong> When many requests start with the same text, such as a long system prompt shared by every user of an assistant, that prefix is stored once and referenced by all of them.</li>
<li><strong>Continuous batching.</strong> Instead of waiting for a whole batch to finish, a finished request is replaced by a waiting one at the very next step, so the GPU never idles.</li>
</ul>
<p>In the vLLM paper, waste fell below 4%, and throughput rose 2–4× over earlier serving systems such as FasterTransformer and Orca at the same latency.</p>
<h2>3. Speculative decoding: let a small model guess, let the big model check</h2>
<p>Even with a perfect cache, each token still needs a full pass through the large model, one after another. Yet many tokens are easy: after &#8220;The capital of France is&#8221;, almost any model would say &#8220;Paris&#8221;. Speculative decoding exploits this. A small, fast draft proposes several tokens; the large model checks all of them in a single forward pass; correct tokens are kept, and generation resumes from the first wrong one.</p>
<p>It is lossless. Each drafted token is accepted with a probability based on how likely the large model finds it, and a rejected token is resampled from the large model&#8217;s own distribution. The result is statistically identical to running the large model alone, just with fewer expensive passes.</p>
<p>There are three common ways to draft:</p>
<ul>
<li><strong>A separate small model</strong> from the same family: no training needed, but it costs extra GPU memory.</li>
<li><strong>Small trained draft heads</strong> on top of the large model (EAGLE, Medusa): little extra memory, but some GPU hours of training.</li>
<li><strong>Self-speculation:</strong> the model drafts using only its first layers, then verifies with the full depth.</li>
</ul>
<p>The original speculative-decoding papers from Google Research and DeepMind reported roughly 2–3× faster generation with unchanged output, and trained-draft methods such as EAGLE and Medusa report similar or larger gains. Acceptance is highest for predictable output such as code and structured data, and lower for creative writing. Speculative decoding pays off with small batches and people waiting for long answers. It adds little when the GPUs are already saturated with large batches, or for very short replies.</p>
<h2>How the three fit together</h2>
<p>The KV cache makes each token cheap. PagedAttention packs those caches so that far more conversations fit on the same GPUs. Speculative decoding shortens the wait inside each conversation. The first two raise throughput, the third cuts latency, and modern serving engines such as vLLM combine all three.</p>
<h2>What this means when the GPUs are your own</h2>
<p>At AMD Telecom we train models on our own in-house GPUs, and serving on hardware you own has the same constraint: the GPUs are fixed, so every gigabyte counts. A few habits make a large difference:</p>
<ul>
<li><strong>Size the KV cache before choosing a model.</strong> Multiply the per-token cost by your context length and the number of concurrent users. Very often the cache, not the weights, sets the limit.</li>
<li><strong>Serve with a paged cache and continuous batching.</strong> Leaving 60–80% of cache memory unused means buying GPUs you do not need.</li>
<li><strong>Put shared instructions in one common prefix.</strong> Prefix sharing turns a long system prompt from a per-user cost into a one-off.</li>
<li><strong>Use speculative decoding for interactive, structured work,</strong> such as assistants, data extraction and code, and measure acceptance on your real traffic.</li>
</ul>
<p>For the other big memory lever, reducing the weights themselves, see <a href="/llm-quantization-explained/">LLM quantization explained</a>. For how newer model architectures shrink the cache itself, see <a href="/hybrid-attention-long-context-llms/">hybrid attention</a>. If you are planning an AI application or want a model trained on your data, see our <a href="/ai-model-development">AI Model Development</a> and <a href="/ai-model-training">AI Model Training</a> services, or <a href="/contact-us/">talk to our experts</a>.</p>
<p>The post <a href="https://www.amdtelecom.net/serving-llms-on-your-own-gpus/">Serving LLMs on Your Own GPUs: KV Cache, PagedAttention and Speculative Decoding</a> appeared first on <a href="https://www.amdtelecom.net">AMD Telecom</a>.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Hybrid Attention: Why 2026’s Long-Context LLMs Use Less Full Attention</title>
		<link>https://www.amdtelecom.net/hybrid-attention-long-context-llms/</link>
		
		<dc:creator><![CDATA[AMD Telecom]]></dc:creator>
		<pubDate>Wed, 30 Sep 2026 20:15:24 +0000</pubDate>
				<category><![CDATA[Blog]]></category>
		<guid isPermaLink="false">https://www.amdtelecom.net/?p=7597</guid>

					<description><![CDATA[<p>Why the newest long-context language models keep full attention in only a few layers, and what it means for teams training models on their own GPUs.</p>
<p>The post <a href="https://www.amdtelecom.net/hybrid-attention-long-context-llms/">Hybrid Attention: Why 2026’s Long-Context LLMs Use Less Full Attention</a> appeared first on <a href="https://www.amdtelecom.net">AMD Telecom</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>Look inside several of the newest long-context language models and one pattern stands out. In Alibaba&#8217;s Qwen3-Next, only one in every four sequence-mixing layers uses full attention; the three layers in between use a cheaper recurrent mixer. Moonshot AI&#8217;s Kimi Linear repeats the same 3:1 pattern, and Ant Group&#8217;s Ling 2.5 goes further, with seven cheap layers for every full-attention layer. Attention has not been removed. It has become selective.</p>
<p>This article explains why that is happening, how the cheap layers manage to remember, and what it means for teams that train and serve models on their own hardware.</p>
<h2>The bill hybrids are cutting: the KV cache</h2>
<p>Full (softmax) attention is what lets a transformer answer &#8220;what was the access code?&#8221; thousands of tokens later. The keys and values of every past token are kept in the KV cache, so a query can look up exactly the position it needs. The price is paid during generation: in every full-attention layer, each new token adds another set of keys and values, so the cache grows with the length of the context, multiplied by the number of layers, attention heads and head dimension. At a million tokens of context, the model reads gigabytes of cache for every token it writes.</p>
<p>Two trends have made this the main bottleneck. Reasoning models now write tens of thousands of output tokens to answer a single question, and agentic workflows run many rounds of tool calls that all share one long context. Anything that shrinks the KV cache is worth doing.</p>
<h2>How the cheap layers remember</h2>
<p>Linear attention replaces the growing cache with a fixed-size state: every token writes a small update into it, and a query reads from it. Cost now grows linearly with the length of the sequence instead of quadratically. The catch is that the naive version only ever adds. Once more associations have been written than the state can hold, they blur into each other, and precise recall fails.</p>
<p>The fixes arrived one layer at a time:</p>
<ul>
<li><strong>The delta rule (DeltaNet).</strong> Before writing, the layer reads what the state currently holds for a key and writes only the difference, so an old association is replaced rather than piled on. Mathematically it is one step of online gradient descent on the memory for every token.</li>
<li><strong>A decay gate (from Mamba-2).</strong> Old information is allowed to fade, which gives the layer a learned memory horizon.</li>
<li><strong>Gated DeltaNet.</strong> Decay, targeted erase and write strength in one update. In the Gated DeltaNet paper (Yang, Kautz and Hatamizadeh, ICLR 2025), the combination outperformed both Mamba-2 and DeltaNet on in-context retrieval and long-context tasks.</li>
<li><strong>Per-channel decay (KDA, used in Kimi Linear).</strong> Every feature gets its own forgetting rate, so something like an identifier can persist while filler fades quickly.</li>
</ul>
<p>Chunked formulations built from dense matrix multiplications let these layers train efficiently on GPUs.</p>
<h2>Why keep any full attention at all?</h2>
<p>A compressed memory is good, but it is not exact. When a task needs one precise detail from far back in the context, a few full-attention layers still do what a fixed-size state cannot, and that is why the 2026 hybrids keep a handful of them. Where they sit matters too: NVIDIA&#8217;s Jet-Nemotron paper searched which layers of a pre-trained model to keep as full attention and found that only a few specific layers need it for retrieval, while the rest can become linear or sliding-window layers.</p>
<h2>The retrofitting trap</h2>
<p>MiniMax shipped hybrid models in 2025 and then returned to plain full attention for MiniMax M2. In its own explanation, the company says its hybrid models matched full attention on standard benchmarks but showed clear deficits in complex multi-hop reasoning at larger scale. Variants it built by continuing to pre-train with cheaper attention, for hundreds of billions of tokens and more, lost ground on retrieval, multi-hop reasoning and in-context learning, and standard benchmarks were slow to reveal it.</p>
<p>The hybrids that are working in 2026, such as Qwen3-Next, Kimi Linear and Ling 2.5, were designed as hybrids from the start.</p>
<h2>The payoff</h2>
<p>In a hybrid model only the full-attention layers keep a per-token cache: about a quarter of the layers in a 3:1 design, and one in eight in a 7:1 design. Moonshot AI reports that Kimi Linear needs up to 75% less KV-cache memory than full attention and decodes up to six times faster at a context of one million tokens. The cache still grows with the context; what changed is how many layers pay for it.</p>
<h2>The 2026 landscape</h2>
<ul>
<li><strong>Hybrid linear attention:</strong> Qwen3-Next, Qwen3.5, Kimi Linear, Ling 2.5. Mostly cheap layers, a few full-attention layers, designed in from scratch.</li>
<li><strong>Hybrid state-space and transformer:</strong> NVIDIA Nemotron 3, AI21&#8217;s Jamba, IBM Granite 4. The same idea, with state-space (Mamba) layers as the cheap mixer.</li>
<li><strong>Sparse attention:</strong> DeepSeek V3.2 and GLM-5, both using DeepSeek Sparse Attention. Attention in every layer, but each token attends only to a small, selected subset of earlier tokens.</li>
<li><strong>Full-attention holdouts:</strong> such as MiniMax M2.</li>
</ul>
<p>The design question has moved from &#8220;attention or recurrence?&#8221; to &#8220;where in the layer stack is full attention worth paying for?&#8221;</p>
<h2>What this means when you train and serve models on your own GPUs</h2>
<p>At AMD Telecom we train and fine-tune models on our own in-house GPUs, with data collected by our BigParser platform and prepared on our big-data platform. For teams in the same position, the move to hybrid attention has three practical consequences:</p>
<ul>
<li><strong>Memory decides context length and concurrency.</strong> On a fixed set of GPUs, KV-cache memory often limits how long a context you can serve and how many sessions run at once. Hybrid open-weight models can fit much longer contexts, or more concurrent users, on the same hardware.</li>
<li><strong>Fine-tune a hybrid; don&#8217;t build one by conversion.</strong> Start from a model that was designed as a hybrid, rather than retraining a full-attention model into one, which is the trap described above.</li>
<li><strong>Evaluate on your real workload.</strong> Throughput numbers and standard long-context benchmarks can look good while multi-step and agentic quality quietly drops. Test on the conversations and tool chains your application actually runs.</li>
</ul>
<p>For the other levers that decide how much a model costs to run on your own hardware, see <a href="/serving-llms-on-your-own-gpus/">serving LLMs on your own GPUs</a> and <a href="/llm-quantization-explained/">LLM quantization explained</a>. If you are planning an AI application or want a model trained on your own data, see our <a href="/ai-model-training">AI Model Training</a> and <a href="/ai-model-development">AI Model Development</a> services, or <a href="/contact-us/">talk to our experts</a>.</p>
<p>The post <a href="https://www.amdtelecom.net/hybrid-attention-long-context-llms/">Hybrid Attention: Why 2026’s Long-Context LLMs Use Less Full Attention</a> appeared first on <a href="https://www.amdtelecom.net">AMD Telecom</a>.</p>
]]></content:encoded>
					
		
		
			</item>
	</channel>
</rss>
