Hacker Newsが見ているのはI-DLMの一点、diffusion LLMはAR品質を保ったまま速くなれるのか

Hacker Newsでこの投稿が引っかかった理由はかなりはっきりしている。読者が反応したのは「diffusion for textが面白いか」ではなく、「これで本当により速いserving pathが開けるのか」という点だった。スレッドの初動から、これは単なる研究デモではなく、autoregressive base modelに近い挙動を保ちながらdecode economicsを変えうるのか、という読み方になっていた。

project pageの中心にあるのは introspective consistency という考え方だ。著者たちは、既存のdiffusion language modelはdenoisingはできても、autoregressive modelのように自分が直前に出したtokenを同じ流れで検証する性質が弱いと見る。I-DLMは introspective strided decoding を使い、前に出したtokenを確かめながら新しいtokenを同じforward passで進める。HNが食いついたのはその理屈だけでなく、並んでいる数字でもある。

• I-DLM-8B: AIME-24 69.6、LiveCodeBench-v6 45.7
• LLaDA-2.1-mini 16B: AIME-24 43.3、LiveCodeBench-v6 30.4
• high concurrencyで2.9-4.1x throughput
• gated LoRAでbase AR modelとbit-for-bit identical outputを主張

さらにHNで効いたのはservingの説明だ。ページでは strict causal attention によって SGLang へ直接統合でき、AR serving infrastructureの中で drop-in replacement として扱えると説明している。ここが重要だ。text diffusionは数字がよくても、運用系を作り直す必要が出た瞬間に現場の熱が冷めやすい。このプロジェクトはそこを最初から意識している。32B側の表でもAIME-25 80.0、HumanEval 96.3、IFEval 84.7と並べていて、「速いだけの変則系」ではない印象を作っている。

もちろんHNの反応はすぐ検証モードに入った。release dateの表記に違和感を指摘するコメントもあれば、「つまりもっと速いQwen32Bとして使えるのか」と聞く声もある。この温度感がそのまま価値だと思う。熱狂より先に、運用に持ち込めるかを計算しているからだ。元ソースは I-DLM project page、コミュニティの反応は Hacker News thread で追える。