A vendor quotes an HPL-MXP figure in the fleet-sizing deck and the room treats it as a cost forecast. It isn’t. HPL-MXP tells you what a machine can do in an ideal dense loop, not what a request costs when your model is actually serving traffic. Between those two facts sits a gap that decides whether you provision against a number your workload will never touch. HPL-MXP is the mixed-precision variant of the classic LINPACK benchmark. It solves a dense linear system, but instead of doing all the arithmetic in FP64, it does the heavy lifting in a lower precision — FP16, BF16, or FP8 — and then uses iterative refinement to pull the answer back toward FP64 accuracy. The headline it produces is an effective FLOPS rate: how fast the machine can crunch dense math when most of the work runs in reduced precision and correctness is recovered cheaply at the end. That is a genuinely useful signal about what the silicon’s tensor units can sustain. It is not a statement about your inference economics, and the two get conflated constantly. What HPL-MXP actually measures The classic High Performance Linpack (HPL) benchmark — the one behind the TOP500 supercomputer ranking — solves a large dense system of linear equations entirely in FP64 and reports the sustained FP64 FLOPS. It is a deliberately arithmetic-heavy, communication-light problem chosen because it stresses floating-point throughput more than almost anything else a machine will run. HPL-MXP keeps the same problem shape but changes the arithmetic strategy. The bulk factorization runs in low precision, where modern accelerators have far more throughput — a datacentre GPU’s FP8 or FP16 tensor rate is typically an order of magnitude above its FP64 rate, per published vendor specifications. The lost accuracy is then recovered through iterative refinement steps that converge back toward an FP64-quality solution. The reported number is the effective FP64-equivalent performance you get by exploiting that mixed-precision path. Two things follow that matter for anyone reading the score: The figure is an upper bound on dense mixed-precision throughput. LINPACK is engineered to keep the tensor units saturated. Almost nothing you deploy in production keeps them that busy. The number depends entirely on the executor — the specific hardware plus the specific software stack (BLAS libraries, kernel implementations, driver, refinement scheme) — that produced it. A different stack on the same silicon produces a different number. This is why how a result was produced matters as much as the result itself, a point LynxBench AI treats as a first-class benchmarking concern. How is HPL-MXP different from the classic FP64 HPL benchmark? The short version: HPL reports what the machine can sustain when every operation must be FP64-accurate; HPL-MXP reports what it can sustain when only the final answer must be FP64-accurate and the path to get there can be cheap. That difference is the whole point of the mixed-precision variant, and it is also exactly the shape of the trade-off modern inference makes. Dimension HPL (classic LINPACK) HPL-MXP Working precision FP64 throughout FP16 / BF16 / FP8 factorization Accuracy target FP64 native FP64-equivalent via iterative refinement What it stresses FP64 tensor/vector units Low-precision tensor units + refinement loop Reported number Sustained FP64 FLOPS Effective (FP64-equivalent) mixed-precision FLOPS Ranking home TOP500 Mixed-precision / HPL-MXP list Relevance to AI Weak — inference rarely uses FP64 Directionally closer — inference lives in FP16/BF16/FP8 HPL-MXP is directionally more relevant to AI than plain HPL precisely because inference runs in the same precision tiers HPL-MXP exercises. But “directionally more relevant” is not “predictive.” It closes the gap; it does not remove it. Why does a high HPL-MXP score not directly predict cheaper cost-per-request? Because a peak-FLOPS figure describes an ideal dense loop, and a request is not an ideal dense loop. Three structural reasons the ceiling and the floor diverge: Your serving path is not compute-bound the way LINPACK is. Autoregressive LLM decode is memory-bandwidth-bound, not FLOP-bound — each generated token reads the full model weights and the growing KV cache, and the tensor units spend much of their time waiting on HBM. HPL-MXP is constructed to avoid exactly this stall. The achieved-vs-peak utilisation for a decode-heavy workload is often a small fraction of the benchmark ceiling (an observed pattern across serving profiles, not a benchmarked constant). Batching, sequence length, and the prefill/decode split reshape everything. Two deployments of the same model on the same GPU can differ severalfold in cost-per-request depending on batch size, context length, and whether prefill and decode are co-located or separated. None of that is visible in an HPL-MXP number. Techniques like prefill/decode disaggregation move the achieved figure far more than the peak spec does. The software stack between spec and serving is where the FLOPS leak. Kernel fusion, graph compilation, attention implementations, and quantization schemes all sit between the theoretical peak and the token you actually bill for. Machine learning compilers cut cost-per-request precisely because that gap is large and addressable — which is another way of saying the peak number never told you where you were. The consequence is a specific, expensive mistake: provisioning a GPU fleet against a peak FLOPS figure and discovering your serving path reaches a fraction of it, so you have bought — and are paying for — capacity that no request ever exercises. Over-provisioning against a benchmark ceiling is the failure class HPL-MXP invites when it’s read as a cost forecast. Which precision tiers does HPL-MXP exercise, and how do they map to inference? HPL-MXP implementations run the factorization in FP16, BF16, or FP8 depending on the hardware generation and the library, then refine. Each tier maps onto an inference decision, but the mapping is loose rather than one-to-one. Precision HPL-MXP role Inference analogue Caveat BF16 Common factorization precision on current accelerators Default serving precision for many LLMs Wide dynamic range; accuracy usually holds FP16 Alternate factorization precision Serving precision where BF16 unsupported Narrower range; can need loss scaling FP8 Newest tier, biggest headline FLOPS Aggressive quantized serving Accuracy is workload-dependent; must be validated per model The trap is assuming that because HPL-MXP hits its big number in FP8 with refinement recovering accuracy, your FP8-quantized model will hold quality just as cheaply. HPL-MXP recovers accuracy against a known correct FP64 answer through a mathematically defined refinement loop. An LLM has no such refinement step — quantization error propagates through generation and shows up as degraded output, not as a residual you can iterate away. Whether FP8 is safe for your model is an empirical question about your weights and your task, decided by evaluation, not by the benchmark’s precision label. We treat that as something to measure per deployment, never to assume. When is HPL-MXP a useful signal — and when is it misleading? It is useful as a relative signal of dense mixed-precision capability across silicon options, and as a sanity check that a machine’s low-precision tensor path is configured and working. If GPU A reports a much higher HPL-MXP figure than GPU B on comparable stacks, A does have more mixed-precision headroom to give — the question is only how much of it your workload can claim. It is misleading the moment it’s used as an absolute cost-per-request predictor. The number that decides your economics is achieved throughput on your serving path at the precision tier you actually deploy — and that only comes from profiling the deployed path. The bridge from a peak-FLOPS figure to a real per-request cost is measurement, not arithmetic: profiling the deployed serving path is what turns an HPL-MXP peak into an achieved throughput and a defensible cost figure. That reconciliation is exactly what our [inference cost-cut pack](Inference Cost-Cut Pack) does — it profiles the buyer’s live serving path so a vendor’s peak claim can be checked against what a request actually costs. For teams sizing fleets, the same discipline underpins how AI infrastructure SaaS providers keep gross margin predictable rather than hostage to a spec sheet. A worked example (illustrative) Suppose a vendor quotes an HPL-MXP figure and you’re tempted to size the fleet from it. Frame the read this way instead: Peak (spec): the HPL-MXP number — treat as the ceiling only. Achieved (measured): profile one representative serving config; record tokens/sec at your batch size, context length, and precision. Ratio: achieved ÷ peak. For decode-heavy LLM serving this is commonly a small fraction (observed across serving engagements; not a published benchmark). Cost-per-request: derive from achieved throughput and the fully-loaded hourly cost of the instance, not from the peak. The gross-margin delta between planning on the peak and planning on the achieved ratio is the entire reason to measure before you buy. FAQ What should you know about HPL-MXP in practice? HPL-MXP solves a large dense linear system with the heavy factorization done in low precision (FP16/BF16/FP8) and then applies iterative refinement to recover an FP64-accurate answer. It reports the effective FP64-equivalent FLOPS achieved through that mixed-precision path. In practice it’s an upper-bound signal of what a machine’s low-precision tensor units can sustain in an ideal dense loop — not a forecast of production performance. How is HPL-MXP different from the classic FP64 HPL benchmark? Classic HPL does all arithmetic in FP64 and reports sustained FP64 FLOPS; it’s the TOP500 ranking benchmark. HPL-MXP keeps the same dense problem but runs the factorization in reduced precision and recovers accuracy via refinement, reporting effective mixed-precision FLOPS. Because inference lives in FP16/BF16/FP8, HPL-MXP is directionally closer to AI workloads — but directionally closer is not predictive. Why does a high HPL-MXP score not directly predict cheaper cost-per-request? Because it measures an ideal, compute-bound dense loop, while LLM decode is memory-bandwidth-bound and rarely saturates the tensor units. Batching, context length, the prefill/decode split, and the software stack all move achieved throughput far more than the peak spec does. The result is that achieved-vs-peak utilisation is often a small fraction, so provisioning against the peak over-buys capacity no request exercises. Which precision tiers (FP16, BF16, FP8) does HPL-MXP exercise, and how do they map to inference? HPL-MXP runs its factorization in FP16, BF16, or FP8 depending on hardware and library, then refines. Each maps loosely onto a serving precision — BF16 as a common default, FP16 where BF16 is unavailable, FP8 for aggressive quantization. The key caveat: HPL-MXP recovers accuracy against a known correct answer, whereas an LLM has no refinement step, so FP8 quality must be validated per model rather than assumed from the benchmark. How do we translate a GPU’s HPL-MXP figure into an achieved-vs-peak utilisation estimate for our workload? Treat the HPL-MXP number as the peak ceiling, then profile one representative serving config to measure achieved tokens/sec at your actual batch size, context length, and precision. The achieved-÷-peak ratio is your utilisation estimate, and cost-per-request follows from achieved throughput and the instance’s fully-loaded hourly cost. That ratio only comes from measuring the deployed path, not from the spec sheet. When is HPL-MXP a useful signal for GPU fleet sizing, and when is it misleading? It’s useful as a relative comparison of dense mixed-precision headroom across silicon and as a check that a machine’s low-precision path is configured correctly. It becomes misleading the moment it’s used as an absolute cost-per-request predictor, because the number that decides economics is achieved throughput on your serving path — which the benchmark cannot see. Benchmark selection only earns its keep once it connects to the number the business actually pays: cost-per-request at the precision tier you deploy. HPL-MXP is a fine answer to “what can this silicon do in an ideal loop.” It is the wrong answer to “what will a request cost me” — and the only way to close that gap is to profile the path the request actually takes.
