Introspective Diffusion Language Models
Posted by zagwdt 7 days ago
Comments
Comment by thepasch 6 days ago
And then through a LoRA adapter, you can ground the diffuser on the base model’s distribution (essentially have it “compare” its proposals against what the base model would’ve generated), which effectively means: exact same byte-for-byte output for the same seed, just roughly twice as fast (which should improve even more for batched tasks).
I’m not an expert, more of a “practicing enthusiast,” so I might be missing something, but at first glance, this reads super exciting to me.
Comment by oliver236 6 days ago
Comment by awestroke 6 days ago
Comment by radarsat1 6 days ago
It's the same reason there's a difference in speed between "prompt processing" and "generation". The former is just taking the pre-generated prompt and building the KV cache, which is parallel, not autoregressive and therefore way faster.
Comment by qeternity 6 days ago
So let's say a draft model generates 5 tokens, all 5 of these can be verified in parallel with a single forward pass of the target model. The target model may only accept the first 4 tokens (or whatever) but as long as the 5 forward passes of the draft model + 1 prefill of the target model is faster than 4 forward passes of the target, you will have a speedup while maintaining the exact output distribution as the target.
Comment by nodja 6 days ago
When you already know the tokens ahead of time you can calculate the probabilities of all tokens batched together, incurring significant bandwidth savings. This won't work if you're already compute bound so people with macs/etc. won't get as much benefits from this.
Comment by Majromax 6 days ago
Comment by dd8601fn 5 days ago
If that’s wrong I would certainly appreciate being corrected, though. But if it’s right, a 2.9x speed-up after rejected tokens, nearly for free, sounds amazing.
Comment by nodja 5 days ago
Comment by Balinares 6 days ago
Comment by anentropic 6 days ago
then once successfully trained you get faster inference from just the diffusion model
Comment by a1j9o94 6 days ago
Comment by porridgeraisin 6 days ago
Let me explain what is going on here. This is basically a form of multi-token prediction. And speculative decoding in inference. See my earlier post[1] to understand what that is. TL;DR, in multi-token prediction you train separate LM heads to predict the next as well as next to next token as well as... Upto chosen next kth token. Training multiple LM heads is expensive and can be unnecessary, so what people typically do is have a common base for all the k heads, explained further in [1]. These guys do another variant.
Here is what they do mechanically, given a sequence p consisting of five tokens PE([p1, p2, p3, p4, p5]). Where PE(.) adds relative position info to each token.
1. Create an augmented sequence PE([p1 MASK MASK MASK MASK]). Do a training pass on that, with the ground truth sequence p1..5. Here it is trained to, for example, to predict p3 given p1+pos=-2 MASK+pos=-1 MASK+pos=0, loosely notating.
2. Then separately[2], train it as usual on PE([p1 p2 p3 p4 p5]).
Step (1) teaches it to do multi-token prediction, essentially the single LM head will (very very loosely speaking) condition on the position `k` of the special MASK token and "route" it to the "implicit" k'th LM head.
Step (2) teaches it to be a usual LLM and predict the next token. No MASK tokens involved.
So far, you have trained a multi-token predictor.
Now during inference
You use this for speculative decoding. You generate 5 tokens ahead at once with MASK tokens. And then you run that sequence through the LLM again. This has the same benefits as usual speculative decoding, namely that you can do matrix-matrix multiplication as opposed to matrix-vector. The former is more memory-bandwidth efficient due to higher arithmetic intensity.
here is an example,
query = ["what", "is", "2+2"]) prompt = PE([...query, MASK*5]) you run output = LLM(prompt). Say output is ["what", "is", "2+2", "it", "is", "4"]. Note that the NN is trained to predict the kth next token when faced with positionally encoded MASK tokens. So you get all 5 in one go. To be precise, it learns to predict "4" given ["what", "is", "2+2", MASK, MASK]. Since it does not need the "it" and "is" explicitly, you can do it in parallel with generating the "it" and the "is". "is" is predicted given ["what", "is", "2+2", MASK], for example, and that also doesn't depend on the explicit "it" being there, and thus can also be done in parallel with generating "it", which is just normal generating the next token given the query. And then you use this as a draft in your speculative decoding setup.
Their claim is that using a multi-token predictor this way as a draft model works really well. To be clear, this is still causal, the reason diffusion models have hype is because they are capable of global refinement. This is not. In the same thread as [1], I explain how increasing the number of MASK tokens, i.e increasing `k`, i.e the number of tokens you predict at once in your multi-token prediction setup quickly leads to poor quality. This paper agrees with that. They try out k=2,3,4,8. They see a drop in quality at 8 itself. So finally, this is 4-token-prediction with self-speculative decoding(sans LayerSkip or such), removing seemingly no existing limitation of such setups. It is definitely an interesting way to train MTP though.
[1] https://news.ycombinator.com/item?id=45221692
[2] Note that it is computationally a single forward pass. Attention masks help you fuse steps 1 and 2 into a single operation. However, you still have 2 separate loss values.
Comment by Reubend 5 days ago
Then again, their results with it are great. It would be interesting to benchmark it against standard SD on a model that already uses MTP.
Comment by porridgeraisin 4 days ago
Comment by radarsat1 5 days ago
Comment by krackers 1 day ago
Comment by xiphias2 6 days ago
https://z-lab.ai/projects/dflash/
And DDTree?
Comment by andsoitis 7 days ago
Comment by recsv-heredoc 7 days ago
This startup seems to have been at it a while.
From our look into it - amazing speed, but challenges remain around time-to-first-token user experience and overall answer quality.
Can absolutely see this working if we can get the speed and accuracy up to that “good enough” position for cheaper models - or non-user facing async work.
One other question I’ve had is wondering if it’s possible to actually set a huge amount of text to diffuse as the output - using a larger body to mechanically force greater levels of reasoning. I’m sure there’s some incredibly interesting research taking place in the big labs on this.
Comment by IanCal 6 days ago
However quality is really important. I tried that site and clicked one of their examples, "create a javascript animation". Fast response, but while it starts like this
``` Below is a self‑contained HTML + CSS + JavaScript example that creates a simple, smooth animation: a colorful ball bounces around the browser window while leaving a fading trail behind it.
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>JavaScript Bounce Animation</title> <style> body, html { margin: 0; padding: 0;
```
the answer then degrades to
``` radius: BALL_RADIUS, color: BALL_COLOR, traivD O] // array of previous {x,y} positions }; ```
Then more things start creeping in
``` // 3⃣ Bounce off walls if (ball.G 0 ball.radius < 0 || ball.x + ball.radius > _7{nas.width) { ball.vx *= -1; ibSl.x = Math.max(ball.radius, Math.min(ball.x, canvbbF4idth - ball.radius)); } if
```
and the more it goes on the worse it gets
``` Ho7 J3 Works 0 Atep | Description | ```
and
``` • prwrZ8}E6on 5 jdF wVuJg Ar touc> 2ysteners ,2 Ppawn \?) balls w>SFu the 8b$] cliM#]9 ```
This is for the demo on the front page, so I expect this is a pretty good outcome compared to what else you might ask.
Comment by cataflutter 6 days ago
I also asked it some technical details about how diffusion LLMs could work and it provided grammatically-correct plausible answers in a very short time (I don't know the tech to say if it's correct or not).
Comment by RugnirViking 6 days ago
Comment by nl 6 days ago
Comment by girvo 6 days ago
https://www.emergentmind.com/topics/dflash-block-diffusion-f...
Comment by roger_ 6 days ago
There are several Mac implementations of it that show > 2x faster Qwen3.5 already.
Comment by moostee 7 days ago
Comment by andsoitis 6 days ago
Comment by Topfi 6 days ago
Sadly, it does not perform at the level of e.g. Haiku 3.5 for tool calling, despite their own benchmarks claiming parity with Haiku 4.5, but it does compete with Flash Lite there too.
Anything with very targeted output, sufficient existing input and that benefits from a seamless feeling lends itself to dLLMs. Could see a place in tab-complete too, though Cursors model seems to be sufficiently low latency already.
Comment by nl 6 days ago
I have an agentic benchmark and it shows Mercury 2 at 19/25 in 58 seconds and Mimo v2 Flash at 22/25 in 109 seconds
https://sql-benchmark.nicklothian.com/?highlight=xiaomi_mimo... (flip to the Cost vs Performance tab to see speed more graphically too)
Comment by Topfi 6 days ago
Comment by nl 6 days ago
https://chatjimmy.ai/ from Taalas seems down at the moment but if you really want speed.... 18,000 tps is something to experience
Comment by feznyng 6 days ago
Comment by Topfi 6 days ago
Kimi, Mimimax and GLM models provide far more robust coding assistance at sometimes no cost (financed via data sharing) or for very cheap. Output quality, tool calling reliability and task adherence tend to be far more reliable across all three over Mercury 2, so if you consider the time to get usable code including reviews, manual fixes, different prompting attempts, etc. end-to-end you'll be faster.
Only "coding" task I have found Mercury 2 to have a place for code generation is a browser desktop with simple generated applets. Think artefacts/canvas output but via a search field if the applet has been generated previously.
With other models, I need to hide the load behind a splash screen, but with Mercury 2 it is so fast that it can feel frictionless. The demo at this point is limited by the fact that venturing beyond a simple calculator or todo list, the output becomes unpredictable and I struggle to get Mercury 2 to rely on pre-made components, etc. to ensure consistent appearance and a11y.
Despite the benchmarks, cost and speed figure suggesting something different, I have had the best overall results with Haiku 4.5, simply because GPT-5.4-nano is still unwilling to play nice with my approach to UI components. I am currently experimenting with some routing, using different models for different complexity, then using loading spinners only for certain models, but even if that works reliably, any model that I cannot force to rely on UI components in a consistent manner isn't gonna work, so for the time being it'd just route between less expensive and more expensive Anthropic models.
Coding wise, one more exception can be in-line suggestions, though I have no way to fairly compare that because the tab models I know about (like Cursors) are not available via API, but Mercury 2 seems to perform solidly there, at least in Zed for a TS code base.
Basically, whether code or anything else, unless your task is truly latency dependent, I believe there are better options out there. If it is, Mercury 2 can enable some amazing things.
Comment by LoganDark 6 days ago
Comment by simianwords 6 days ago
Comment by moeadham 6 days ago
Comment by simianwords 6 days ago
Comment by Topfi 6 days ago
[0] https://docs.inceptionlabs.ai/get-started/models#mercury-2
Comment by mlmonkey 6 days ago
Comment by sdenton4 6 days ago
Consider that outputting two tokens at a time will be a (2-epsilon)x speedup over running one token at a time. As your block size increases, you quickly get to fast enough that it doesn't matter sooooo much whether you're doing blocks or actual all-at-once generation. What matters, then, is there quality trade-off for moving to block-mode output. And here it sounds like they've minimized that trade-off.
Comment by RugnirViking 6 days ago
Comment by mlmonkey 5 days ago
Maybe "thinking" will fix this aspect, but I see it as a serious shortcoming.
Comment by ilaksh 6 days ago
Comment by zhangchen 6 days ago
Comment by shepardrtc 5 days ago
Comment by ramon156 6 days ago
> 2025-04-12: Released I-DLM-8B, I-DLM-32B, and I-DLM-8B-LoRA on HuggingFace.
Is this old already? Not saying that's a bad thing, since it seems very sophisticated. Just curious if there's an update
Comment by oersted 6 days ago
Comment by scotty79 6 days ago
Comment by 2001zhaozhao 6 days ago
Comment by keyle 6 days ago
Comment by enesz 6 days ago
Comment by akcd 6 days ago
Comment by Openpic 6 days ago
Comment by salviati 6 days ago
> I understand it improved by 3x, but has the bottleneck shifted from Memory Bandwidth to Compute? Or is Memory Bandwidth still dominant?
But why did you post your comment in Japanese? We have so many good options for automated translation nowadays!
でも、なぜ日本語でコメントを投稿したんですか?最近は自動翻訳の良い選択肢がたくさんあるのに!
Comment by flakiness 6 days ago
The original Japanese comment is clearly machine translated from another language to English. @Openpic is trolling.
I'd just downvote.