Speculative decoding: why MTP and external draft are not the same thing

In speculative decoding, the point is not just to go faster. The point is understanding where the work ends up: inside the model or inside the system you have to integrate.

If you need to adopt it in a product, MTP and DRAFT are not two names for the same idea. They aim at the same goal — generating text faster without giving up the final model's quality — but they move complexity to different parts of the pipeline.

In practice:

• with MTP, the speculative path is integrated into the model
• with external draft, the speculative path is created through the collaboration between two models

The formula I find most useful is this: MTP as integrated speculative decoding, external draft as assembled speculative decoding. It is not an absolute definition: it is an operational distinction. It helps explain where the complexity lives, who takes it on, and how much work remains for the team that has to bring the model into a real system.

Why speculative decoding exists

Speculative decoding comes from a simple problem: large models are good, but expensive in latency. Every token requires work, and that work accumulates.

The core idea is elegant: use a faster path to propose some tokens in advance, and let the stronger model verify them. If the proposal holds, you save time. If it does not, the system falls back to the main path without compromising the final quality of the response.

MTP and DRAFT live in the same conceptual space. The real difference emerges in a single question: who proposes those tokens in advance, and how is that speculative path built?

MTP: when acceleration is inside the model

MTP stands for Multi-Token Prediction. In practical terms, it describes models that already incorporate a mechanism capable of anticipating multiple tokens within their own structure.

It makes sense to describe it as integrated speculative decoding because the acceleration is not assembled from the outside as a combination of two separate models: it already comes packaged in the model's design.

That changes a lot. From an architectural point of view, speculative behavior is part of the model's design. From an operational point of view, an important part of the complexity has already been solved before the model reaches the hands of the team that will use it.

The real promise of MTP, then, is not just "more speed." It is fewer surfaces of failure.

External draft: when acceleration has to be assembled

With an external draft, the speculative system is created by the collaboration between at least two distinct components: a main model (target) and a smaller, faster model (draft). The draft proposes some tokens. The target verifies them. If the proposal is coherent, the system speeds up. If it is not, the target corrects the trajectory.

The idea is powerful, and in some contexts more interesting than MTP. But it is inevitably an assembled system: the acceleration does not live in the model alone, it lives in the relationship between models.

This shifts the center of gravity of the work. You are not simply choosing a model. You are designing a coupling. You have to verify compatibility, inference engine support, format consistency, the balance between the draft's cost and the real throughput benefit, and subtler details such as tokenizers and server behavior under load.

External draft does not ask only for a model decision. It asks for a system decision.

Where complexity really lives

With MTP, complexity tends to sit further upstream: in the model, in the work of the people who designed, trained, and optimized it.

With DRAFT, complexity moves closer to the team adopting the solution. Even when the concept is straightforward, the integration may not be. It is easier to find yourself validating side details: actual feature support, the correct target-draft combination, benefits that exist on paper but shrink in the real pipeline.

If I had to summarize it in one sentence: MTP pushes the problem further upstream; DRAFT leaves it much closer to downstream.

Flexibility versus operational reliability

The advantage of external draft is obvious: you can choose different combinations. A stronger target, a lighter draft, a specific compromise for a precise budget or a particular infrastructure. For teams doing research or working on highly customized stacks, that flexibility is valuable.

But flexibility is not free. Every extra degree of freedom also opens one more possibility for incompatibility, inefficiency, or additional maintenance.

MTP gives up part of that composability in exchange for a more closed but more legible proposal. You cannot reassemble everything however you like, but for that very reason you have fewer points where the system can degrade. For many teams, especially outside pure research, this is not a loss. It is a clear advantage.

Why MTP often starts with an adoption advantage

If the goal is to use speculative decoding reliably — and not to prove that you can orchestrate a low-level speculative system — then MTP almost always starts with an advantage.

I deliberately choose this more cautious formula because there are contexts where external draft is the right path. But in most product-oriented cases, repeatable benchmarks, or concrete adoption scenarios, MTP reduces the number of collateral decisions that absorb time and attention.

The point is not which solution looks more elegant on paper. The point is: where does the team's time end up?

If it ends up in integration, in maintaining a relationship between models, in compatibility verification, and in diagnosing unstable performance, then the theoretical advantage of flexibility risks evaporating. When it is well supported, MTP protects focus better: it lets teams work on the use case, real benchmarks, perceived latency, and operational cost.

When I would still choose an external draft

External draft is not a second-tier solution. It is a more demanding solution.

I would choose it when flexibility is not an occasional advantage, but a structural part of the problem:

• when you need fine-grained control over the relationship between target cost and draft cost
• when the team works on a highly customized platform
• when the primary objective is research, not standardization
• when the infrastructure is built to experiment with different pairs of models

In those cases external draft stops being an unwanted complication and becomes the real design space. Choosing it means wanting that complexity, not merely enduring it.

Conclusion

MTP and DRAFT are not two synonyms with different packaging. They are two architectural choices.

The first incorporates acceleration into the model. The second builds acceleration into the relationship between models. The first tends to simplify adoption. The second tends to increase freedom, but also the integration burden.

If I had to summarize it in one line: MTP is the more ready-made form of speculative decoding; DRAFT is the more composable form.

In real systems, especially when the team's time matters as much as performance, that difference carries far more weight than it first appears.