Article
PEARL
On this page 4
Reading Notes on PEARL
When I previously read EAGLE, I saw the author link this paper below it. I recently needed to study PD disaggregation, so this was a good opportunity to read and take notes on PEARL.
Core Idea
Traditional speculative decoding verifies only after producing a complete sequence of draft tokens. Verification and drafting therefore have a logical ordering: no drafting occurs during verification, and no verification occurs during drafting.
To run the two processes in parallel, PEARL proposes two verification strategies.

Core Concept
The two strategies are pre-verify and post-verify:
pre: This strategy breaks the restriction that verification must wait for a complete draft. It verifies the prefix as soon as the first draft token appears. If the first token is rejected, every later token will be rejected as well. The approach still respects logical ordering and seems like a generally applicable way to use otherwise idle resources.post: This strategy breaks the vanilla requirement that the next draft generation wait for verification to supply a prefix, merging the gaps between consecutive draft generations. If an entire draft is accepted, the draft model can continue generating because its current trajectory remains healthy; there is no need for the verified prefix to interrupt it. When verification fails, the system returns to pre-verification.

In the vanilla implementation, the draft model generates tokens and the target then verifies them. Alternating the two leaves two idle periods:
- The target model is idle while candidates are generated.
- The draft model is idle during verification.
PEARL fills these gaps by having the target perform an extra “verification” while drafting. Since no candidates yet exist, this is not truly verification: pre-verify is a target-model decoding step that generates a new token. As long as that step is slower than generating candidates, it can perform useful pruning before the real verification, or post-verify.
During post-verify, the draft model continues generating. In the worst case verification fails and those candidates are discarded, but latency is not lost—ignoring wasted compute outside a serving scenario. Any successful verification produces some benefit.
Thinking
The method feels natural, but like branch prediction in a pipeline it depends on the probability of choosing the right direction—in this case, the draft acceptance rate.
We can derive an expression by defining:
- : generation time
- : verification time
- : maximum length of one draft
- : per-token acceptance rate
- : duration of one section
Starting from one inference cycle—and therefore one pre-verify—verification can either succeed or fail.
On failure:
On success, several consecutive post-verification stages may occur, with probability:
Weighting the cases gives:
For comparison, the average utility of vanilla speculative decoding is:
Taking and produces the following plot. The gain is significant when the acceptance rate is high.

The acceptance rate also declines as the accepted sequence grows. Real behavior therefore does not follow a geometric sequence and will be slightly worse than this estimate.