Not All Errors Are Equal: A Systematic Study of Error Propagation in Large Language Model Inference

When computer hardware makes tiny mistakes—often called bit flips—it can cause Large Language Models (LLMs) to give wrong answers. These "soft errors" are transient hardware faults. They manifest as unexpected bit flips in silicon. These errors silently propagate through a program's execution. They alter outcomes without any visible warning.

Until now, most research into these errors focused on traditional High-Performance Computing (HPC) workloads. These workloads usually involve structured matrix multiplications. But as LLMs move into scientific discovery, we face a new problem. How do these errors behave in an autoregressive environment (where each output depends on previous tokens)? Because LLMs generate text token by token, a single mistake can cascade. It can poison the entire conversation. This paper argues that not all errors are equal. The impact of a bit flip depends on exactly when it happens and where it lands in the model's architecture.

The Problem

The status quo for assessing LLM reliability is often an end-to-end black box approach. Researchers look at the final output and ask, "Is it correct?" This fails to account for the complex, multi-stage nature of modern inference. As shown in, modeling errors in LLMs is fundamentally harder than in traditional HPC.

This is due to three distinct challenges. First, there is huge diversity in how companies implement Transformer architectures. Second, tasks like math or coding exhibit different resilience behaviors. Third, the inference process itself is highly complex.

Current methods struggle to distinguish between different inference stages. One stage is "prefill" (processing the initial prompt). Another is "decode" (iteratively generating tokens). As illustrated in, these stages are coupled via the Key-Value (KV) cache.

This is a memory buffer that stores the conversation context. If a fault corrupts the KV cache during prefill, that error is baked into every subsequent decoding step. Existing tools often miss this distinction. They treat the entire forward pass as a single monolithic event. This prevents engineers from identifying the specific "critical points" where a system is most vulnerable.

How It Works

To solve this, the authors developed LLMFI, a configurable and deterministic fault-injection framework. The core architectural choice is to build the injector on top of PyTorch and HuggingFace. It uses "hooks" (functions that intercept and modify data during execution) to inject faults at a granular level.

The framework operates through four coordinated components, as mapped out in : 1.

The Injector: Defines the fault type. It uses forward_hook to simulate computation faults (perturbing activations in the datapath). It uses forward_pre_hook to simulate memory faults (corrupting weights before they are used). 2. The Inspector: Parses the model architecture to find specific targets. It can target a single submodule (like a projection layer), a functional layer (like self-attention), or an entire Transformer block. 3. The Scheduler: Manages the timing. Crucially, it decomposes the inference process into three distinct phases: prefill, first-token generation, and the subsequent decode loop. 4. The Runtime Wrapper: Orchestrates the execution. To ensure results are reproducible, the wrapper enforces "greedy decoding" (always picking the highest-probability token). This removes the randomness found in typical sampling methods.

By decoupling these stages, LLMFI allows for precise experimentation. An engineer can test a bit flip in the very first token versus a bit flip in the 50th token of a math solution.

Numbers

The study identifies "critical stages" for error sensitivity. The authors report that error resilience is highly dependent on the inference stage. In reasoning tasks, the first-token stage is exceptionally fragile to computation faults.

Regarding the impact on accuracy, the paper finds that single bit-flip faults can cause accuracy reductions of up to 5.01% in generative tasks. However, the "where" matters more than the "how much." Looking at, accuracy remains relatively stable through the early and middle Transformer blocks.

However, it degrades consistently in the final 3 to 4 blocks. This suggests the model loses its ability to "self-correct" toward the end of the pipeline.

On the mitigation side, the authors propose several software-only fixes. Their "Selective Checksum-based Protection" strategy only applies error-detecting checksums to specific dimension-reducing layers. This achieves a fault coverage of 80.04% to 90.31%. It does this while only using roughly 30% of the total GEMM (General Matrix Multiply) workload. Furthermore, the "Dual First-token Generation" method generates the first token twice to check for consistency. This catches 82.20% of faults. It does so with a mere 3.37% increase in Time to First Token (TTFT, the latency before the first word appears).

What's Missing

While the study is comprehensive, it has clear boundaries. First, the evaluation focuses primarily on single-bit flips. The authors touch upon multi-bit errors in . However, they admit that multi-bit upsets spanning multiple memory words represent a much more complex design space. This area remains unmapped. For a practitioner running on hardware where ECC (Error Correction Code) might fail, these results might be limited.

Second, the study is heavily weighted toward dense architectures. Although they provide supplementary data for Mixture-of-Experts (MoE) models, the primary takeaways come from dense models like Phi and Gemma. In MoE models, only a fraction of parameters are active at any given time. This inherently masks many memory faults. If your production stack relies on massive MoE models, the "vulnerability map" provided here will likely look different.

Finally, the effectiveness of "Dynamic Shot Inference" (increasing the number of context examples) is noted as being highly task-dependent. The paper does not provide a generalized rule for when to trigger this. This leaves an implementation gap for engineers trying to automate reliability.

Should You Prototype This

Yes, but specifically for the mitigation strategies. Unless you are a researcher studying hardware reliability, you won't need LLMFI. However, the "Dual First-token Generation" and "Selective Checksum" ideas are highly actionable.

If you are deploying LLMs in safety-critical environments where silent data corruption is a risk, the 3.37% latency hit for dual-token verification is a reasonable trade-off. It provides significant confidence for a small cost. The code for the injector is reportedly available; see the paper for the canonical link at https://github.com/hyfshishen/LLMFI. Start by prototyping the dual-token check on your most sensitive reasoning endpoints.

Figures from the paper