Live data from Hacker News

Accelerating Gemma 4: faster inference with multi-token prediction drafters

blog.google

321–330 of 345 posts

Re: Accelerating Gemma 4: faster inference with multi-token prediction drafters

#321
post #261

Speculative decoding is an amazingly clever invention, almost seems-too-good-to-be-true (faster interference with zero degradation from the quality of the main model). The core idea is: if you can find a way to generate a small run of draft next tokens with a smaller model that have a reasonable likelihood of being correct, it's fast to check that they are actually correct with the main model because you can run the…

So we've basically taken the concept of branch prediction from CPUs and applied it to LLMs?

Speculative execution techniques in software & hardware exist everywhere,

- Speculative multi threading

- Data Value Speculation

- Speculative Memory Disambiguation

- Runahead Execution

- Speculative Prefetching

- Multi-path (Dual-path) Execution (goes beyond branch prediction by computing both paths)

- Optimistic Concurrency Control (for database transactions etc)

Re: Accelerating Gemma 4: faster inference with multi-token prediction drafters

#322
post #267

Speculative decoding is an amazingly clever invention, almost seems-too-good-to-be-true (faster interference with zero degradation from the quality of the main model). The core idea is: if you can find a way to generate a small run of draft next tokens with a smaller model that have a reasonable likelihood of being correct, it's fast to check that they are actually correct with the main model because you can run the…

> it's fast to check that they are actually correct with the main model because you can run the checks in parallel. Can you give an intuition as to why it's faster? I would have thought regardless how many you run in parallel, the successful check has to execute the full model to generate the full sequence so you will have exactly the same time needed? Or is it by process of elimination so it terminates early once it…

To add to what others have said here, this is due to the memory hierarchy.

GPUS have different kinds of memory, there's fast-but-small memory and slow-but-large memory.

Conceptually, you can imagine the process of LLM inference as transferring some weights from slow memory to fast memory, doing some calculations on those weights, discarding them from fast memory once the computation is done, loading in the next portion, and so on, until you're fully done.

You can do calculations for multiple tokens in parallel, but to calculate what token n is, you need to already know all the previous tokens 1..(n-1). Therefore, if you don't have spec decoding, you go one token at a time. If you do, you assume that the next tokens actually are what the smaller model gave you, discarding the results in case you were wrong.

With speculative decoding, you can basically load the weights once and apply them to multiple tokens instead of just one, because of the assumption of what the next tokens are that you're making. This decreases the amount of data that has to go between slow and fast memory. As the decode stage[1] is bottlenecked by memory bandwidth and not compute speed, more efficient use of this bandwidth increases your token generation speed.

As another poster said, this idea is closely related to batching. In batching, you re-use the same weights to serve multiple requests. In speculative decoding, you re-use them to accelerate a single one. If you have many users, care only about how many tokens per second your GPUs produce in general, and don't care at all about per-user speed, speculative decoding won't do anything for you.

[1] There are two stages in LLM inference: prefill and decode. In prefill, you do calculations on the tokens of the prompt, prefilling the KV cache to accelerate attention computations at decode time. Because you have access to all the tokens of the prompt, you can process everything in parallel and use your weights very efficiently. Your bottleneck here is the computation units and not memory bandwidth. In decode, you don't know what your future tokens will be, so you can only go one at a time as explained above. In a way, speculative decoding turns decode into a little prefill.

Re: Accelerating Gemma 4: faster inference with multi-token prediction drafters

#323
post #267

Earlier quoted context omitted.

> it's fast to check that they are actually correct with the main model because you can run the checks in parallel. Can you give an intuition as to why it's faster? I would have thought regardless how many you run in parallel, the successful check has to execute the full model to generate the full sequence so you will have exactly the same time needed? Or is it by process of elimination so it terminates early once it…

The small draft model proposes a sequence of tokens d1 d2 d3. The big target model calculates P(d1) P(d2|d1) P(d3|d1 d2) In parallel. If we were just greedy decoding it would be simple. Just stop when the draft model doesn’t predict the most likely token as judged by the target model. At that point, append the correct token from the target model and kick off both models again in parallel. In practice we aren’t using…

while I understand that we are computing the tokens in parallel to get the "faster" result, is there a tradeoff where we're actually utilizing more compute resources by running multiple instances of the large model? That is, while it's faster, is it more efficient?

edit: doing some more of my own research, it sounds like the bottleneck in doing it sequentially is in shifting weights around in memory, so while it uses more compute it doesn't oversubscribe compute resources because the bottleneck is not in supply of compute but in supply and speed of memory. The GPU has a massive supply of compute but sequential decoding only demands a relatively small amount of it. Time is primarily spent waiting on loading values from vram.

Re: Accelerating Gemma 4: faster inference with multi-token prediction drafters

#324

Earlier quoted context omitted.

Pardon my lack of depth on TFA here but in my experience with work, Gemini is far less accurate on queries about technical commands that Claude or OpenAI. Like, I don't trust it at all. Maybe it has its place but not as a general advisor.

I think what you’re seeing here is a difference in the amount of “world knowledge “ encoded in the perceptron parts of the model as opposed to how good the model is at the “transformer” part which you could think of as pure token prediction using only what’s in the context window. If true that would suggest gemini/gemma would be great in a RAG situation where world model isn’t needed as it’s being spoonfed all the re…

That matches my experience.

GPT and Claude would work much better than Gemini, even if the direct feedback was sparse or diffuse.

However, the moment I gave Gemini a fast testing framework that gave it instant feedback, it would mill through all kind of problems.

Claude and GPT are seniors.

Gemini is a very motivated mid level.

Re: Accelerating Gemma 4: faster inference with multi-token prediction drafters

#325
post #323

Earlier quoted context omitted.

The small draft model proposes a sequence of tokens d1 d2 d3. The big target model calculates P(d1) P(d2|d1) P(d3|d1 d2) In parallel. If we were just greedy decoding it would be simple. Just stop when the draft model doesn’t predict the most likely token as judged by the target model. At that point, append the correct token from the target model and kick off both models again in parallel. In practice we aren’t using…

while I understand that we are computing the tokens in parallel to get the "faster" result, is there a tradeoff where we're actually utilizing more compute resources by running multiple instances of the large model? That is, while it's faster, is it more efficient? edit: doing some more of my own research, it sounds like the bottleneck in doing it sequentially is in shifting weights around in memory, so while it uses…

It’s not really multiple instances of the same model. Model weights aren’t replicated in vram. The results of multiplying k sequences through the model is larger, but that’s pretty small compared with the model weights themselves.

The bigger constraint is the target model and the draft model needing to share VRAM.

Re: Accelerating Gemma 4: faster inference with multi-token prediction drafters

#326
post #54
post #9

MTP support is being addedto llama.cpp, at least for the Qwen models ( https://github.com/ggml-org/llama.cpp/pull/20533 ) and I'd imagine Gemma 4 will come soon. The performance uplift on local/self-hosted models in both quality and speed has been amazing in the last few months.

I have a dumb performance question. Why when asking a model to change text in a minor way; are we not asking it to generate the operational transformations necessary to modify the text, and then just executing the ot on the existing text vs reproducing every token? Maybe tools are doing that more than I realize?

A coding agent provides an edit tool to the model for making code changes, with this tool typically just providing a find/replace operation. The model may of course need to do a bunch of work (grepping etc) to figure out what to change, but the actual change will just be sent from model to agent as a "replace X with Y" edit tool request, with this "edit" then done locally by the agent.

It's interesting how the agent (at least in case of Claude Code) is then applying this find/replace "edit" to the requested file... Since the agent wants to be platform independent (Linux/Windows/Max) it uses Node.js for file access, and performs the "edit" by itself using Node.js to read the entire file, make the change, then write back an entire new file.

Re: Accelerating Gemma 4: faster inference with multi-token prediction drafters

#327

Speculative decoding is an amazingly clever invention, almost seems-too-good-to-be-true (faster interference with zero degradation from the quality of the main model). The core idea is: if you can find a way to generate a small run of draft next tokens with a smaller model that have a reasonable likelihood of being correct, it's fast to check that they are actually correct with the main model because you can run the…

Maybe it’s just me, but I feel like the LLM crowd are re-discovering Coding and Compression all over again.

Re: Accelerating Gemma 4: faster inference with multi-token prediction drafters

#328

Earlier quoted context omitted.

I guess their point was to demonstrate that it's possible to bake a decently-sized model to a silicon? As with anything related to HW, I guess the lead time will be considerably larger than the software counterparts, so I guess in 1-2 years timeframe we might see something like Gemma 4 baked onto a silicon.

Yeah, I think the important part is the process to convert the model to silicon, not the actual implementation itself. Whether it succeeds now depends a lot on the rate of improvement of model architecture. They're betting on model design and capability improvements slowing down - and then wiping the floor with everyone else with their inference economics.

I think this is the future. When models start converging at "really good" (which I think is already happening) then burning them into ASIC silicon is the natural next step.

Harnesses can keep improving with a fixed model and the throughput opens up new possibilities like doing 10x more "thinking" or exploring parallel paths and picking the best.

Re: Accelerating Gemma 4: faster inference with multi-token prediction drafters

#329

Earlier quoted context omitted.

This is true, we have the numbers to back it up on https://gertlabs.com/rankings?mode=oneshot_coding (check out the efficiency chart too) GPT 5.5/5.4 are the smartest models, but at great token / code bloat cost. Qwen 3.6 Max strikes a good balance. But Gemma 4 26B writes some really efficient code, with great results considering the model size. Things do start falling apart under higher contexts.

I have been experimenting with using Claude Code with both the qwen3.6 31B MOE and 28B dense models. Yesterday the 31B model once got confused on refactoring some Prolog code and took a very long time to get it right. Functionality for coding or refactoring Python or TypeScript is usually good. but runs slowly on my 32B MacMini. Ollama has initial support for bf16 MTP Gemma 4 https://ollama.com/library/gemma4:31b-cod…

If the goal is cost savings, a good compromise is DeepSeek V4 Flash. It'll handle context and agentic work better than any model that can fit on a laptop.

Re: Accelerating Gemma 4: faster inference with multi-token prediction drafters

#330
post #78

these are the updated models: google/gemma-4-31B-it-assistant google/gemma-4-26B-A4B-it-assistant google/gemma-4-E4B-it-assistant google/gemma-4-E2B-it-assistant

for anyone wanting a glossary to explain the naming scheme here: E4B = 4B effective parameters (using per-layer embeddings) E2B = 2B (like above) it = instruction tuned (rlhf and all that jazz) assistant = Multi-token drafters (the new 2x speed up)

> assistant

naming still hard I see

Post reply on HN