Beam Search › Beam Width: The Quality-Compute Tradeoff

Michael BrenndoerferMay 22, 20253 min read
Language AI HandbookAll chapters
Part 12 of 67Sequence-to-Sequence
Chapter 85Beam Search › Beam Width: The Quality-Compute Tradeoff
Reading section 4 of 17 · Beam Width: The Quality-Compute Tradeoff · 3 minSection 4 of 17 · 3 min

Book contents

Section 4 of 17 · 3 min read

Beam Search › Beam Width: The Quality-Compute TradeoffOne section · Sections in this chapter4 / 17 ↓
Reading tools Definitions & inline links

Choose your expertise level to adjust how many terms are explained. Beginners see more tooltips, experts see fewer to maintain reading flow. Hover over underlined terms for instant definitions.

Article links

Make inline references clickable

The beam width kk is the central hyperparameter of beam search. It controls a direct tradeoff between the quality of the search and the computational cost.

With k=1k = 1, beam search reduces exactly to greedy decoding. With k=∣V∣Tk = |V|^T, it becomes exhaustive search. In practice, values between 4 and 10 are common for machine translation; some summarization models use 4, and neural machine translation systems often use 5 or 6.

Why Larger Beams Are Not Always Better

Increasing beam width has diminishing returns in practice. The gain from going from k=1k = 1 to k=4k = 4 is typically much larger than from k=4k = 4 to k=10k = 10. Beyond a certain width, the model has already found most of the high-probability paths, and adding more beams just increases computation without improving output quality.

More surprisingly, very large beam widths can degrade output quality on some tasks. Researchers have found that in neural machine translation, BLEU scores sometimes peak around k=4k = 4 to k=8k = 8 and then decline for larger beams. The reason is related to the model's training distribution: a model trained with maximum likelihood estimation (MLE) learns to assign high probability to sequences that start similarly to the training data. When the beam is large enough to explore low-probability starts, the model encounters territory far from its training distribution, and the output quality degrades. This phenomenon is sometimes called the "beam search curse".

The beam search curse reveals a deep tension in how neural sequence models are trained and how they are evaluated. During training, the model's objective is to assign high probability to the correct next token given the ground-truth prefix. This is a local, next-step objective. At test time, beam search tries to find the globally most probable sequence, which is a different objective. The model was not trained to optimize global sequence probability; it was trained to optimize step-wise conditional probabilities. For well-distributed training data, these two objectives are roughly aligned. But at the edges of the distribution, they diverge, and beam search with a very wide beam will faithfully optimize the wrong objective.

A related concern is that for certain models, specifically language models trained on extremely large corpora, even greedy decoding may produce excellent outputs because the model has learned such a well-calibrated distribution over text. For these models, beam search still helps but the margin over greedy is smaller than for older, weaker models.

Computational Cost

Each step of beam search requires kk decoder forward passes (one per hypothesis in the beam). With a vocabulary of size ∣V∣|V|, you compute k×∣V∣k \times |V| scores at each step, then sort to find the top kk. The total computation is O(k⋅T⋅d)O(k \cdot T \cdot d) where dd is the cost of a single decoder forward pass. In practice, the kk forward passes are batched together, so the overhead relative to greedy is roughly k×k \times the cost per step.

The memory overhead is also non-trivial. Each beam hypothesis maintains its own key-value cache (in transformer models, this stores the attention key and value tensors for all previous tokens). With kk hypotheses, you hold kk separate KV caches simultaneously. For long sequences and large models, this can dominate memory usage. Some systems reduce this overhead by sharing computation across hypotheses when they share a common prefix, a technique called hypothesis sharing or tree-structured KV caching.