The MLA up-projection that absorption removes: recomputing K and V from the cached latent

This is the cost MLA hides, and it only appears if you decline the absorption trick. DeepSeek-V2 states that during inference 'since W_UK can be absorbed into W_Q, and W_UV can be absorbed into W_O, we even do not need to compute keys and values out for attention'. Do the naive thing instead and up-project the cached latent every decode step: for DeepSeek-V3's shape (n_h=128, d_nope=128, d_rh=64, d_h(v)=128, d_c=512) that is W_UK = 128*192*512 = 12,582,912 elements and W_UV = 128*128*512 = 8,388,608 elements, 20,971,520 elements = 41.9 MB of bf16 weights read per layer per step. The flops are 2*20,971,520 = 41.9 MFLOP against 41.9 MB, so AI = 1 flop/byte - exactly the bandwidth-bound weight-GEMM regime, and this repeats for all 61 layers: ~2.56 GB of weight traffic per decode step that the absorbed form does not pay. The break-even context length is where the recompute cost exceeds the cache it saves: 41.9 MB of weights amortises over (d_c+d_rh)*2 = 1,152 bytes/token of cache saved, so ~36,400 cached tokens. Below that, recomputing is pure loss; above it, if you are memory- rather than bandwidth-constrained, a non-absorbed MLA kernel can be a reasonable trade. RoPE is what forces the issue: DeepSeek-V2 Sec 2.1.3 shows that with position-sensitive RoPE on the keys, W_UK cannot be absorbed into W_Q because 'a RoPE matrix related to the currently generating token will lie between W_Q and W_UK and matrix multiplication does not obey a commutative law' - and without absorption you 'must recompute the keys for all the prefix tokens during inference, which will significantly hinder the inference efficiency'.

Design consequence: MLA is the rare serving optimization that ADDS arithmetic to REMOVE memory, and whether it is a win depends entirely on which side of the 36,400-token break-even the workload sits. Below it, absorption is strictly correct. Above it, an engine may legitimately choose to spend bandwidth on recomputation to buy batch size, and this is a real dial rather than an implementation detail. Two mistakes are easy to make and both are expensive: (a) implementing MLA without absorption, which silently reinstates a 61-layer weight-streaming pass per token and makes the model look memory-bound on weights instead of fast; (b) forgetting that absorption requires the decoupled-RoPE layout, so an implementation that applies RoPE to the up-projected keys cannot absorb and will not notice until it is profiled. The arithmetic intensity numbers here are the reason to prefer absorption: 114 flop/byte sits just below an H100 SXM's ~295 flop/byte ridge, so absorbed MLA decode attention is still memory-bound but by a factor of ~2.6 rather than ~300. HARDWARE-PARAMETER ROWS ADDED 2026-10-05 (schema authority pass, agent w5-schema). `affected_by_hardware` names PRODUCTS (accelerator record ids); these rows name the hardware QUANTITIES that move this class's cost, which had nowhere to live until flop.hardware_parameters was added in this commit. Every effect below is lifted verbatim from this record's own existing prose and no figure here is new - `magnitude` reproduces numbers the record already quoted. `basis` is 'unverified' where the effect was asserted with nothing concrete behind it, rather than being dressed up. The rows were pulled out of free-text notes; they are not a change to what this record claims.