A repetition penalty can act before sampling by changing the logits of token IDs that already occur in a selected token history. The operation does not need to compare words, phrases, or rendered strings. Its unit can be the tokenizer’s integer ID, which gives the mechanism a narrower meaning than its name may suggest.
That distinction matters when a decoder emits subword tokens. Two strings that appear similar to a person can map to different token sequences, while a token reused inside unrelated words can still be marked as previously seen.
The penalty sits between model logits and token selection
At one decoding step, an autoregressive model produces a logit vector (z \in \mathbb{R}^{V}) over a vocabulary of size (V). A logits processor can transform that vector before softmax, top-k, top-p, or another selection rule consumes it.
One common repetition-penalty rule uses a factor (p>1). For every token ID (i) present in the configured history, it replaces the corresponding logit with
[ z’_i = \begin{cases} z_i / p, & z_i > 0,\ z_i \cdot p, & z_i < 0. \end{cases} ]
A zero logit remains zero under either branch. Unseen token IDs retain their original logits.
The sign-dependent operation pushes a seen token’s logit away from the favorable direction. A positive value becomes smaller, while a negative value becomes more negative. Simply dividing every seen logit by (p) would not have that property for negative values: a negative number divided by a value above one moves toward zero and can become more competitive.
This formula describes a common decoder implementation, not a universal definition for every API named repetition_penalty. Runtime documentation remains the contract for the exact history scope, ordering, accepted parameter range, and interaction with other processors.
Token identity sets the matching boundary
The history check operates on token IDs. Suppose a tokenizer represents a rendered fragment with several IDs. Penalizing one of those IDs does not directly encode the semantic fact that the complete fragment has appeared before. It records only that the specific vocabulary entry is present in the history considered by the processor.
The reverse case also matters. A token ID may participate in several textual contexts. Once that ID is marked as seen, the adjusted logit can affect a later continuation even when the surrounding word or phrase differs from the earlier occurrence.
Tokenizer details therefore affect the visible result. Whitespace-sensitive tokens, punctuation tokens, byte-level fragments, and subword boundaries can make two textually related forms correspond to different IDs. Repetition control at this layer is consequently not equivalent to string deduplication.
Repeated occurrences do not necessarily compound the factor
A set-style implementation asks whether an ID occurs in history, not how many times it occurs. If token ID (i) appears once or ten times, the processor still applies the configured transformation once to (z_i) at the current decoding step.
That behavior differs from a frequency-based penalty whose magnitude depends on occurrence count. It also differs from an n-gram constraint, which examines a sequence of IDs and can prohibit a candidate that would recreate a configured n-gram.
These mechanisms may all reduce visible repetition, but they encode different state. A repetition penalty can be unary over token identity; a frequency penalty needs counts; an n-gram rule needs ordered token context.
Logit ordering can change before sampling
Because only a subset of vocabulary logits is modified, the ranking of candidates can change. Consider two positive logits, with a seen token at (4.0) and an unseen token at (3.5). With (p=1.2), the seen token becomes approximately (3.33), placing the unseen token above it before softmax.
The effect is conditional on the original values and on every processor applied around it. A penalty factor does not imply a fixed reduction in probability because softmax normalizes all candidate logits together. Top-k or top-p filtering can amplify the practical consequence if a modified token crosses a filtering boundary.
Processor order can also matter. Two nonlinear or selective transformations generally need not commute. A runtime that applies repetition adjustment before candidate filtering can produce a different candidate set from a runtime that filters first and modifies only retained logits. The configured decoding stack, rather than the penalty parameter in isolation, defines the resulting distribution.
History scope is part of the behavior
The phrase “seen token” is incomplete without a history boundary. A serving system may consider the prompt plus generated continuation, only generated tokens, or a bounded recent region, depending on its API and implementation.
Including prompt tokens means vocabulary entries supplied by the caller can be penalized immediately during generation. Excluding them restricts the mechanism to tokens emitted by the decoder. A sliding region changes the state again because an old token can stop qualifying once it falls outside that region.
This boundary can affect structured output. Syntax often requires deliberate reuse of punctuation, delimiters, field names, or control tokens. Penalizing those IDs can alter their relative logits even when repetition is required by the target format. The decoder has no text-level intent signal inside the basic token-ID rule.
The parameter does not define a text-level repetition rate
A larger factor increases the logit transformation for affected IDs under the sign-dependent rule, but it does not map to a fixed percentage of repeated text. Tokenization, the model’s original distribution, sampling settings, processor order, and history scope all intervene between the parameter and rendered output.
For implementation work, the useful boundary is precise: this form of repetition penalty is a logit processor keyed by prior token identity. It can reshape candidate rankings before selection, but semantic repetition, phrase reuse, and formatting constraints exist at different levels. Treating those levels as interchangeable can make decoder behavior appear inconsistent when it is following the token-level rule exactly.