The DeepSeek Hallucination: Why MLA and MTP Stacking Shatters at the H100 Roofline
Stacking DeepSeek’s MLA and MTP algorithms forces a fatal collision at the GPU compute ceiling, stranding VRAM and destroying inference economics.
By Elias Wong
Sparked by Attention Through Arithmetic Intensity · discussion

The Silicon Valley echo chamber is currently treating DeepSeek-V3 as a software miracle, fixating on its introduction of Multi-Head Latent Attention (MLA) and a Multi-Token Prediction (MTP) objective as the ultimate solutions to inference scaling. The consensus narrative assumes these algorithmic efficiencies can be stacked indefinitely in a software vacuum, generating free throughput without physical consequence. Software does not execute on magic; it executes on the brutal, millimeter-level physics of silicon. A forensic teardown of the arithmetic intensity during the inference decode phase proves these two breakthroughs are on a collision course for the exact same finite pool of idle compute, fundamentally shattering at the hardware roofline.
To understand this physical limitation, we must execute a spatial, bottom-up teardown of the GPU during the token generation phase. In standard generative models, the Key-Value (KV) cache grows linearly with sequence length, rapidly saturating High Bandwidth Memory (HBM) capacity. During decode, reading this massive KV cache for every single generated token dominates the workload, forcing the architecture into a severe memory bandwidth bottleneck. The baseline engineering of MLA is undeniably brilliant: it compresses the latent space to aggressively drop the KV cache footprint from a massive 11.6 GB down to a highly manageable 2.91 GB for a standard enterprise deployment. By drastically shrinking the spatial footprint on the HBM modules, operators can theoretically pack significantly more concurrent sequences into the same VRAM, unlocking massive batch sizes.
However, this compression relies on severe on-the-fly decompression. When you shrink the physical storage footprint on the memory modules, you fundamentally shift the burden across the silicon interposer and onto the streaming multiprocessors. Normalizing the FLOP requirements by the memory bytes accessed, this aggressive latent attention violently spikes the arithmetic intensity of the workload to roughly 242 FLOP/B. The memory bandwidth bottleneck has simply been traded for a compute-intensive decompression tax. Every single time a token is generated, the tensor cores must awaken and burn massive computational cycles projecting the latent vector back into the full key and value matrices.
We need to explicitly do the math on the target hardware to see why this physical trade-off becomes highly dangerous at scale. We can map this directly to the spatial hardware roofline of an Nvidia H100 SXM5 server. According to the foundational specifications, the die delivers 989 TFLOPs of dense FP16 compute alongside 3.35 TB/s of HBM3 bandwidth. If we divide the total available compute by the memory bandwidth, the theoretical ridge point of the H100 sits firmly at 295 FLOP/B.
Visualizing this on a classic roofline model chart plotting the H100's 295 FLOP/B ridge, a steep vector shows MLA pushing the baseline arithmetic intensity up to 242 FLOP/B. Below the 295 FLOP/B threshold, the GPU is memory-bound; the math units spend cycles idling while waiting for electrical signals to traverse the CoWoS package. MLA's cache compression operates perilously close to this absolute compute ceiling. It parasitically drains the GPU's idle decode compute just to reconstruct the KV cache, absorbing the vast majority of the hardware headroom that inference operators typically rely on to run additional throughput optimizations.
This brings us directly to the fatal collision with DeepSeek's second highly touted software trick: Multi-Token Prediction (MTP). MTP attempts to generate multiple future tokens per forward pass by relying on speculative decoding branches, theoretically slashing the latency of standard autoregressive generation. Executing these parallel prediction heads requires its own massive influx of dense matrix multiplications inside the streaming multiprocessors. The algorithm blindly assumes the GPU has the spare logic cycles to evaluate these extra branches while waiting on memory fetches.
As established by our arithmetic intensity normalization, MLA has already evaporated that idle compute. Attempting to concurrently stack MTP directly on top of MLA forces the total arithmetic intensity straight past the 295 FLOP/B ridge and over the cliff into a hard, compute-bound stall. The streaming multiprocessors hit 100% utilization, and the silicon chokes. To quote the underlying reality of this specific architecture directly: "MLA and MTP are both making a compute-for-bandwidth / compute-for-latency trade. MLA has already spent a large part of decode’s idle compute headroom, leaving less of it free for MTP."
Hitting this millimeter-level compute wall triggers a macroeconomic slaughter for datacenter buildouts. Inference unit economics are dictated by a single variable: how large you can push the concurrent batch size before you violate your API latency Service Level Agreements (SLAs). In a purely memory-bound regime, you are restricted by raw VRAM capacity, which MLA theoretically solved. But by pushing the physical system into a compute-bound stall, the time to generate each token (Time Per Output Token, or TPOT) spikes non-linearly the moment you add more users to the node.
Once the H100's tensor cores are fully saturated just decoding MLA states and evaluating MTP speculative branches, you can no longer mask the latency of concurrent network requests. If an inference provider attempts to leverage the 2.91 GB compressed KV cache to scale batch sizes to profitable levels, the compute bottleneck causes their token generation speeds to instantly breach the standard 50-millisecond SLA required for real-time consumer applications. A TCO degradation chart plotting cost-per-token against batch size illustrates exactly how these SLA latency breaches violently ruin the unit economics at the compute bound.
This means operators are deploying clusters of $30,000 silicon but are physically barred from sweating the capacity of the HBM subsystem they paid massive premiums to acquire. They are effectively lighting CapEx money on fire by stranding perfectly good VRAM because the logic units are suffocating under the combined arithmetic weight of these two highly lauded software tricks. You cannot solve a hardware constraint by infinitely stacking software workarounds; you merely shift the bottleneck until the physical silicon shatters under the pressure.
If the AI industry does not stop treating architectural efficiency as a frictionless software game and start aligning it with the brutal, millimeter-level physics of silicon bandwidth, they will strand billions in CapEx on structurally unprofitable inference fleets. We will now dive into the subscriber-only model, detailing the exact FLOP utilization across H100 and H200 SKUs—incorporating the H200 with 141 GB HBM3e at 4.8 TB/s—to map the absolute token-generation limits of a 128-head MLA architecture.