The Anatomy of Diffusion LLMs


In today's newsletter:

  • The anatomy of diffusion LLMs.
  • ​Evaluate MCP-powered LLM apps.
  • 20 most common magic methods in Python OOP.

TODAY'S ISSUE

Deep dive

The anatomy of diffusion LLMs

This week’s deep dive covers one of the most important architectural shifts happening in language modeling right now: diffusion LLMs.

Read the full Part 1 deep dive here →

It builds a complete understanding from first principles:

  • how autoregressive generation is structurally memory-bandwidth bound)
  • why Gaussian noise can’t work on discrete tokens
  • how masked diffusion solves this with an ELBO-derived training objective
  • the math behind the forward and reverse processes
  • unmasking strategies
  • block diffusion for KV cache compatibility
  • and a detailed engineering comparison between the two paradigms.

Read the full Part 1 deep dive here →


Why care?

Every production LLM today, GPT-4, Claude, Gemini, LLaMA, generates text the same way: one token at a time, left to right.

Each token requires loading the full model weights through GPU memory, performing a tiny computation, and then loading all the weights again for the next token. On an A100, this means roughly 1 FLOP per byte of data moved, while the GPU is designed for 100+ FLOPs per byte.

Diffusion LLMs take a completely different approach. They start with a fully masked sequence and iteratively unmask all tokens in parallel, using bidirectional attention at every step. This shifts inference from memory-bandwidth bound to compute-bound, which is exactly where modern GPUs are efficient.

The results are catching up fast. Block diffusion (BD3-LM) is within 0.5 perplexity points of autoregressive on LM1B. LLaDA at 8B parameters matches LLaMA 3 on MMLU and exceeds it on TruthfulQA and HumanEval. And models like Dream 7B are already being served in production with SGLang.

Understanding how it works at a mathematical level, from the forward masking process to the ELBO objective to block-level KV caching, is going to be increasingly valuable as these models scale.

You can read the Part 1 here →

👉 Over to you: Do you think the future of LLM generation is pure diffusion, pure autoregressive, or some hybrid of the two?

MCP

Evaluate MCP-powered LLM apps

There are primarily 2 factors that determine how well an MCP app works:

  • If the model is selecting the right tool?
  • And if it's correctly preparing the tool call?

Today, let's learn how to evaluate any MCP workflow using DeepEval’s latest MCP evaluations (open-source).

This issue was written while referring to the DeepEval docs →

Here's the workflow:

  • Integrate the MCP server with the LLM app.
  • Send queries and log tool calls, tool outputs in DeepEval.
  • Once done, run the eval to get insights on the MCP interactions.

Now let's dive into the code for this!

1️⃣ Setup

First, we install DeepEval to run MCP evals.

It's 100% open-source with 11k+ stars and implements everything you need to define metrics, create test cases, and run evals like:

  • component-level evals
  • multi-turn evals
  • LLM Arena-as-a-judge, etc.

2️⃣ Create an MCP server

Next, we define our own MCP server with two tools that the LLM app can interact with.

Notice that in our implementation, we intentionally avoid specifying any descriptive docstrings to make things tricky for the LLM.

3️⃣ Connect to MCP server

Moving on, we set up the client session that connects to the MCP server and manages tool interactions.

This is the layer that sits between the LLM and the MCP server.

4️⃣ Track MCP interactions

Next, we define a method that accepts a user query and passes that to Claude Opus (along with the MCP tools) to generate a response.

We filter the tool calls from the response to create an object of MCPToolCall class from DeepEval.

5️⃣ Create a test case

At this stage, we know:

  • the input query
  • all the MCP tools
  • all the tools invoked
  • and the final LLM response

Thus, after execution, we create an LLMTestCase using this info.

6️⃣ Define metric

We define an MCPUseMetric from DeepEval, which computes two things:

  • How well did the LLM utilize the MCP capabilities given to it?
  • How well did the LLM ensure argument correctness for tool call?

The minimum of both scores is the final score.

7️⃣ Run the evaluation

Finally, we invoke DeepEval’s evaluate() method to score the test case against the metric.

This outputs a score between 0-1 with a 0.5 threshold default.

We run multiple queries for evaluation.

The DeepEval dashboard displays the full trace, like:

  • query
  • response
  • failure/success reason
  • tools invoked and params, etc.

As expected, the app failed on most queries, and our MCPUseMetric spotted that correctly.

This evaluation helped us improve this app by defining better docstrings, and the app, which initially passed only 1 or 2 out of 24 test cases, now achieves a 100% success rate:

This issue was written while referring to the DeepEval docs →

Find more details in DeepEval’s GitHub repo →

Python

20 most common magic methods

Here’s a visual that lists the 20 most common magic methods used in Python OOP:

In my experience, these are possibly the only 20 magic methods you would ever need in most Python projects utilizing OOP.

Syntactically, they are prefixed and suffixed with double underscores, such as __len__, __str__, and many more. That is why they are also called “Dunder methods” — short for Double UNDERscore.

Here’s a brief description of each of them.

1) __new__:

  • This method is invoked before __init__ to allocate memory to an object.
  • In most cases, we wouldn’t need it.
  • Yet, at times, I have used this to define checks and allocate memory only when certain conditions are met.
  • Another common usage is to define singleton classes — classes with only one object.

2) __init__:

  • Most common in this list.
  • This is invoked after memory allocation to assign value to an object’s attributes.

3) __str__:

  • Executing print(obj) outputs the memory address of the object, which is not interpretable.
  • Defining this method lets us print the object in a readable format.

4) __int__: Invoked when we execute → int(obj).

5) __len__: Invoked when we execute → len(obj).

6) __call__: Invoked when a class object is called as a function → obj().

7) __getitem__: Invoked when an object is indexed → obj[key].

8) __setitem__: Invoked when an object is indexed and a value is set → obj[key]=value.

9) __delitem__: Invoked when an object’s index is deleted → del obj[key].

10) __contains__: Invoked when the in operator is used → item in obj.

11) __bool__: Invoked when an object is used in a boolean context → if obj or bool(obj).

12) __iter__: Invoked when we iterate over an object → for x in obj.

13) __eq__: Invoked when == operator is used to compare two objects → obj1 == obj2.

14) __ne__: Invoked when != operator is used to compare two objects → obj1 != obj2.

15) __gt__:

  • Invoked when > operator is used to compare two objects → obj1 > obj2.
  • Other than __gt__, we also have:
    • __lt__: less than.
    • __le__: less than or equal to.
    • __ge__: greater than or equal to.

16) __add__: Invoked when two objects are added → obj1 + obj2.

17) __mul__: Invoked when two objects are multiplied → obj1 * obj2.

18) __abs__: Invoked when we compute the absolute value of an object: abs(obj).

19) __neg__: Invoked when the unary operator - (minus) is used on an object → -obj.

20) __invert__: Invoked when ~ (tilde) operator is used to invert an object → ~obj.

Now you know the most common Magic methods in Python and how they are used.

We went into much more detail and covered many advanced concepts and programming details of Python OOP here: Object-Oriented Programming with Python for Data Scientists.

Also, if you want to get really good at Python OOP, learn about Python Descriptors.

I find them to be massively helpful in reducing work and code redundancy while also making the entire implementation much more elegant.

We covered it in this newsletter here: Define Elegant and Concise Python Classes with Descriptors.

👉 Over to you: Did I miss any common magic methods? If yes, which one(s)?

THAT'S A WRAP

NO-FLUFF RESOURCES TO...

Succeed in AI Engineering roles

All businesses care about impact. That’s it!

  • Can you reduce costs?
  • Drive revenue?
  • Can you scale ML models?
  • Predict trends before they happen?

We have discussed several other topics (with implementations) in the past that align with such topics.

Here are some of them:

All these resources will help you cultivate key skills that businesses and companies care about the most.

Partner with US

ADVERTISE TO 900k+ AI Professionals

Our newsletter puts your products and services directly in front of an audience that matters, including thousands of leaders, senior data scientists, machine learning engineers, data analysts, etc., around the world.

Get in touch today by replying to this email.

Today’s email was brought to you by Avi Chawla and Akshay Pachaar.

Update your profile | Unsubscribe

Looking for more? Unlock our premium DS/ML resources.

© 2026 Daily Dose of Data Science

Daily Dose of Data Science

Daily no-fluff issues that help you succeed and stay relevant in DS/ML roles.

Read more from Daily Dose of Data Science

Master Full-stack AI Engineering In today's newsletter: The operating system for AI research labs! Why agent crashes are nothing like database crashes. [Hands-on] Deploy a Qwen 3 Agentic RAG. TODAY'S ISSUE OPEN-SOURCE The operating system for AI research labs! Transformer Lab is an open-source ML platform that orchestrates GPUs across any cloud and runs any training or eval workflow you define: supports LoRA, QLoRA, DPO, ORPO, SIMPO use it from a GUI, CLI, or agent skill. works with MLX,...

Master Full-stack AI Engineering In today's newsletter: Fine-tune any LLM directly from Claude! Speculative decoding in LLMs. tSNE Projections can be misleading. TODAY'S ISSUE fine-tuning Fine-tune any LLM directly from Claude! We built a Hugging Face fine-tuning studio that lets you fine-tune any LLM directly from Claude: The app connects to the HF Hub for model and dataset search. It handles chat template formatting for the training data, and lets you configure LoRA rank, quantization,...

Master Full-stack AI Engineering In today's newsletter: Markov decision processes and value functions in RL. How LLM inference works internally. TODAY'S ISSUE AI engineering Markov decision processes and value functions in RL Last week, we launched a hands-on course series on reinforcement learning. Part 2 is now available, and you can read it here → Reinforcement learning nanodegree part 2 Part 1 gave you the RL interaction loop and the exploration-exploitation tradeoff through bandits, and...