Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eagle 3.1: Collaboration Between the EAGLE Team, vLLM Team, and TorchSpec Team

vllm.ai

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Eagle 3.1: Collaboration Between the EAGLE Team, vLLM Team, and TorchSpec Team

#11

Post by NitpickLawyer »

gcr wrote: post #7
androiddrew wrote: post #2

Are these speculative decoders ok to use for AI coding agents or do they only fit certain workloads?

Speculative decoding shouldn't actually change the accuracy of the response. The draft model drafts a couple tokens, and the inference framework verifies that the larger model would have picked them. However, I've found that speculative decoders don't help much if you're running a model locally on limited hardware (for instance, my 32GB VRAM M1 Max from 2021). For one, you have to fit both the large and the small dra…

Your experience might be a bit dated, depending on when was the last time you tried it. MTP (which is a flavor of spec decoding) is showing really solid improvements on local models, even on consumer hardware.

In fact, as the article mentions, you get the biggest gains at low concurrency (so local should apply), with diminishing returns for higher concurrency (if you think in terms of unit of compute, it's probably better to serve more requests in parallel and get more throughput that way).

Eagle3 was great at low context tho, and this seems to improve things at high context. That's really cool, and hopefully it'll turn oout to be useful at those lengths. Eagle3 is also training dependant, so you could try training your own, if your use-cases diverge enough that 3rd party "generalist" models don't suit your needs. (in general nvda, redhat, etc. have provided general eagle3 models for popular families).

Re: Eagle 3.1: Collaboration Between the EAGLE Team, vLLM Team, and TorchSpec Team

#14

Post by pohl »

bbor wrote: post #10

The EAGLE team traced this fragility to a phenomenon we call ‘attention drift’ Ok that’s downright fascinating. I am one of the world’s foremost experts on the AI psychosis sufferers posting grand theories on Reddit, and ‘drift’ is one of the words that chatbots come back to again and again when told to ponder their own Being (so much so that it even shows up in clearly-unrelated/incorrect contexts — pretty sure I’ve…

When one is talking about two things gradually diverging, isn't "drift" a natural, descriptive verb to reach for? I've heard it often when discussing an implementation diverging from a specification, for example.

Re: Eagle 3.1: Collaboration Between the EAGLE Team, vLLM Team, and TorchSpec Team

#15

Post by ketchup32613 »

kbumsik wrote: post #13

> performance often degrades under different chat templates, long-context inputs, or out-of-distribution system prompts. I heard that speculative decoding doesn't affect performance (I meant accuracy). Am I wrong about it?

You're not wrong about that. Speculative decoding does not affect the quality of tokens generated, as each token has to be verified by the parent model before it is output.

Each of the tokens generated by the draft model has to be verified by the parent/original model, but if this acceptance rate falls, then the speedup from speculative decoding would be eliminated. This acceptance rate, and more directly the speedup from draft models, is what "performance" refer s to in the article.

Re: Eagle 3.1: Collaboration Between the EAGLE Team, vLLM Team, and TorchSpec Team

#16

Post by kbumsik »

ketchup32613 wrote: post #15
kbumsik wrote: post #13

> performance often degrades under different chat templates, long-context inputs, or out-of-distribution system prompts. I heard that speculative decoding doesn't affect performance (I meant accuracy). Am I wrong about it?

You're not wrong about that. Speculative decoding does not affect the quality of tokens generated, as each token has to be verified by the parent model before it is output. Each of the tokens generated by the draft model has to be verified by the parent/original model, but if this acceptance rate falls, then the speedup from speculative decoding would be eliminated. This acceptance rate, and more directly the speedup…

So the draft model's performance is directly linked to the overall speed. Thank you for the explanation!

By the way, can it be slower than without speculative decoding in worst case then?

Re: Eagle 3.1: Collaboration Between the EAGLE Team, vLLM Team, and TorchSpec Team

#18

Post by daemonologist »

kbumsik wrote: post #16
ketchup32613 wrote: post #15

Earlier quoted context omitted.

You're not wrong about that. Speculative decoding does not affect the quality of tokens generated, as each token has to be verified by the parent model before it is output. Each of the tokens generated by the draft model has to be verified by the parent/original model, but if this acceptance rate falls, then the speedup from speculative decoding would be eliminated. This acceptance rate, and more directly the speedup…

So the draft model's performance is directly linked to the overall speed. Thank you for the explanation! By the way, can it be slower than without speculative decoding in worst case then?

    > can it be slower than without speculative decoding in worst case then?
Yes - running the draft model costs compute and memory bandwidth, and running the drafted futures through the main model costs compute. If the draft model were really inaccurate or you're already compute-limited (usually: running large batches) you would expect some slowdown.

In practice, for single-user (non-batched) inference with a working configuration, you pretty much always get some speedup. For non-coding tasks I've seen it be nearly a wash for some people, in which case you might want to avoid it due to the extra memory usage (you'd rather use that memory to run a bigger quant/model, even at a slightly lower speed).

Re: Eagle 3.1: Collaboration Between the EAGLE Team, vLLM Team, and TorchSpec Team

#19

Post by tssge »

NitpickLawyer wrote: post #11
gcr wrote: post #7

Earlier quoted context omitted.

Speculative decoding shouldn't actually change the accuracy of the response. The draft model drafts a couple tokens, and the inference framework verifies that the larger model would have picked them. However, I've found that speculative decoders don't help much if you're running a model locally on limited hardware (for instance, my 32GB VRAM M1 Max from 2021). For one, you have to fit both the large and the small dra…

Your experience might be a bit dated, depending on when was the last time you tried it. MTP (which is a flavor of spec decoding) is showing really solid improvements on local models, even on consumer hardware. In fact, as the article mentions, you get the biggest gains at low concurrency (so local should apply), with diminishing returns for higher concurrency (if you think in terms of unit of compute, it's probably b…

The reason speculative decoding shows diminishing returns in batched workloads is because the principle of both is the same.

Speculative decoding predicts a group of tokens and verifies this group using the main model in one pass instead of decoding each token separately. Eg. for this group, the weights are loaded from RAM per group instead of per token: roughly the same computation is performed but not the same memory movement (and other overhead like kernel launches).

Batching utilizes the same mechanism, so speculative decoding is essentially an attempt to batch a single stream using prediction. An attempt, because the verification may reject some tokens if the prediction was inaccurate.

Post reply on HN