Comment by roadside_picnic

2 days ago

In my experience this is a substantial difference in the ability to really get performance in LLM related engineering work from people who really understand how LLMs work vs people who think it's a magic box.

If your mental model of an LLM is:

> a synthetic human performing reasoning

You are severely overestimating the capabilities of these models and not realizing potential areas of failure (even if your prompt works for now in the happy case). Understanding how transformers work absolutely can help debug problems (or avoid them in the first place). People without a deep understanding of LLMs also tend to get fooled by them more frequently. When you have internalized the fact that LLMs are literally optimistized to trick you, you tend to be much more skeptical of the initial results (which results in better eval suites etc).

Then there's people who actually do AI engineering. If you're working with local/open weights models or on the inference end of things you can't just play around with an API, you have a lot more control and observability into the model and should be making use of it.

I still hold that the best test of an AI Engineer, at any level of the "AI" stack, is how well they understand speculative decoding. It involves understanding quite a bit about how LLMs work and can still be implemented on a cheap laptop.

5 comments

roadside_picnic

Reply
amelius  2 days ago

But that AI engineer who is implementing speculative decoding is still just doing basic plumbing that has little to do with the actual reasoning. Yes, he/she might make the process faster, but they will know just as little about why/how the reasoning works as when they implemented a naive, slow version of the inference.

  • roadside_picnic  2 days ago

    What "actual reasoning" are you referring to? I believe you're making my point for me.

    Speculative decoding requires the implementer to understand:

    - How the initial prompt is processed by the LLM

    - How to retrieve all the probabilities of previously observed tokens in the prompt (this also help people understand things like the probability of the entire prompt itself, the entropy of the prompt etc).

    - Details of how the logits generate the distribution of next tokens

    - Precise details of the sampling process + the rejection sampling logic for comparing the two models

    - How each step of the LLM is run under-the-hood as the response is processed.

    Hardly just plumbing, especially since, to my knowledge, there are not a lot of hand-holding tutorials on this topic. You need to really internalize what's going on and how this is going to lead to a 2-5x speed up in inference.

    Building all of this yourself gives you a lot of visibility into how the model behaves and how "reasoning" emerges from the sampling process.

    edit: Anyone who can perform speculative decoding work also has the ability to inspect the reasoning steps of an LLM and do experiments such as rewinding the thought process of the LLM and substituting a reasoning step to see how it impacts the results. If you're just prompt hacking you're not going to be able to perform these types of experiments to understand exactly how the model is reasoning and what's important to it.

    • amelius  2 days ago

      But I can make a similar argument about a simple multiplication:

      - You have to know how the inputs are processed.

      - You have to left-shift one of the operands by 0, 1, ... N-1 times.

      - Add those together, depending on the bits in the other operand.

      - Use an addition tree to make the whole process faster.

      Does not mean that knowing the above process gives you a good insight in the concept of A*B and all the related math and certainly will not make you better at calculus.

      1 reply →