What is Uno's LoRA diffusion adapter?

It is a small add-on for IFM's K2 Horizon models that lets them generate a block of tokens per forward pass instead of one. The base model's weights are frozen; only a lightweight set of diffusion parameters is trained, by a procedure IFM calls **Diffusion Distillation**, and the result ships as a LoRA adapter you attach at serving time.

Decode is the sequential, latency-dominated half of serving an LLM, and reasoning models and agents make the token chains much longer. Cutting the **number of forward passes** is the main lever on that latency, and Uno's angle is that it buys the reduction without a second model to train and serve, and without retraining the base model.

How does it relate to speculative decoding and diffusion language models?

All three attack the same one-token-per-pass bottleneck. Speculative decoding adds a separately trained draft model whose guesses the big model verifies. A discrete diffusion language model is retrained from scratch to refine whole blocks, which IFM says often costs quality. Uno keeps the original autoregressive model responsible for the output distribution and adds only an adapter, which is why IFM calls the speedup lossless.

LLM· 2026-09-04

IFM releases K2 Horizon — Uno's LoRA diffusion adapter for block-parallel decoding — What does it mean?

TL;DR

What is it: The K2 Horizon release from the Institute of Foundation Models ships Uno, a LoRA adapter that decodes a whole block of tokens per forward pass instead of one, trained by a procedure IFM calls Diffusion Distillation.
Why it’s needed: Decode is the slow, strictly sequential half of serving an LLM — a 500-token answer costs 500 forward passes that each wait on the last, and reasoning models and agents make those chains much longer — so Uno attacks that latency without touching the model's weights.
vs previous: Unlike speculative decoding, it needs no separately trained draft model, and unlike a retrained discrete diffusion language model, which IFM says "often sacrifices quality for speed", it is described as lossless: the frozen autoregressive weights stay "fully responsible for the model's output distribution".

Jargon

Autoregressive decoding: The normal way a language model writes: it predicts one token per forward pass, and each pass needs the token before it. That strict ordering is what makes generation sequential, and slow. Full explainer
Block-parallel decoding: Emitting several tokens in one forward pass instead of one. The win is fewer passes for the same answer; the difficulty is that tokens decided together cannot condition on each other the way strictly ordered tokens can.
LoRA: Low-Rank Adaptation. Instead of retraining a model you train a small pair of extra matrices that ride alongside the frozen weights. Adapters are megabytes rather than gigabytes, and you attach or detach them at serving time. Full explainer
Diffusion Distillation: IFM's name for how Uno is trained: the compact adapters learn to reproduce the frozen model's own output a block at a time, borrowing the parallel-generation machinery of diffusion models. The base weights are never updated.
Discrete diffusion language model: A model trained from the start to write text by refining a whole block of placeholder tokens over several denoising passes. It generates in parallel natively, but IFM notes it "often sacrifices quality for speed". Full explainer
Speculative decoding: Run a small, cheap draft model to guess the next few tokens, then have the big model check them in one pass. Quality is preserved, but you have to train, ship and serve a second model. Full explainer
Lossless (speedup): Here it means the output distribution is unchanged — the faster path reaches the same answers, so the speed costs you no accuracy. IFM claims this for Uno; the release does not publish the mechanism that guarantees it.
A23B / A4B: The active parameter count of a sparse mixture-of-experts model. K2 Horizon 375B-A23B holds 375 billion parameters of capacity but runs roughly 23 billion of them per token.

The news. On September 3, 2026, the Institute of Foundation Models released K2 Horizon, six Apache-2.0 models — 375B-A23B, 36B-A4B, 32B, 7B, 3.7B and 0.9B — together with intermediate checkpoints, training code, data recipes, configurations and training logs. Shipped alongside them is Uno, which IFM describes as a "plug-and-play lossless speedup": a LoRA adapter you attach to a Horizon model so it generates blocks of tokens in parallel instead of one token at a time. Read the release →

Uno is an adapter that changes how fast a K2 Horizon model writes, not what it writes. Picture a bricklayer building a wall from an architect's drawing: the drawing settles every question about what the wall looks like, and the bricklayer only decides how fast it goes up. Autoregressive decoding is the brick-by-brick version: one token per forward pass, and every pass has to wait for the token before it. That is tolerable for a short reply and expensive for a reasoning trace, because, as IFM puts it, "even small per-token delays compound into substantial latency."

Both established fixes make you give something up. Speculative decoding brings in a second bricklayer — a small draft model that guesses ahead while the big model checks the guesses in one pass — so quality holds, but you now train, ship and serve an extra model. A discrete diffusion language model instead rebuilds the wall out of different material: it is trained from scratch to refine a whole block at once, which parallelises natively but, in IFM's words, "often sacrifices quality for speed."

Draft Model (1B) — generates K=5 tokens

Paris.Itis

↓ verify all at once↓

Target Model (70B) — one forward pass

✓ Par✓ is✓ .✗ It→The— is

accepted

rejected → corrected

discarded

3 accepted + 1 corrected = 4 tokens from 2 forward passes

↻ repeat until done

Uno's move is to leave the drawing alone and change only the laying. The autoregressive weights stay frozen and, in IFM's phrasing, "fully responsible for the model's output distribution", while a small separate set of diffusion parameters "learns only how to generate more efficiently". Training those parameters is what IFM calls Diffusion Distillation: the adapters learn to reproduce the frozen model's own output a block at a time, the way a prefab panel is cast from the same bricks the wall would have used anyway. The whole thing ships as a LoRA adapter — the same low-rank adapter trick that serves many fine-tunes off one base model — so adopting it is an attach, not a retrain.

Approach	Extra model to train?	Base weights changed?	Quality claim
Autoregressive decoding	No	—	The baseline everything else is measured against
Speculative decoding	Yes — a separately trained draft model	No	Preserved by the verification step
Discrete diffusion LM	Yes — a different model entirely	Retrained from scratch	"often sacrifices quality for speed" (IFM)
Uno	No — a LoRA adapter, at "negligible additional training overhead"	No — frozen	Claimed lossless; no speedup figure published (IFM)

Why the pass count is the thing to watch is easiest to see with round numbers (illustrative — IFM publishes no speedup figure for Uno). Hold three things fixed: a 500-token answer, a decode step that takes 20 ms, and a batch of one. Brick by brick, that is 500 sequential passes, or 10.0 seconds of decode. Now suppose the adapter commits an average of 4 tokens per pass, and each pass costs a little more — say 22 ms, because producing four tokens at once is more work than producing one. You need 125 passes instead of 500: 2.75 seconds, a 3.6× wall-clock reduction, even though every individual pass got 10% more expensive. The lever is the number of passes, not the price of one, which is why this family of tricks pays off exactly where decode dominates the request.

What the release does not give you is numbers. IFM reports that Uno "achieves a better speed–quality tradeoff than leading speculative-decoding systems and both open-weight and proprietary diffusion language models", and that its gains "persist across every batch size we tested" — but it publishes no speedup factor, no block size, and no rule for how a block is accepted. Until those land, the shape of the idea is the news: a frozen model plus a cheap adapter is a far lower-friction way to buy decode speed than either a second model or a second architecture. That the weights and the training code are Apache-2.0 is what makes the claim checkable at all.

Goes deeper in: LLM Serving → Speculative Decoding → Draft Model Variants

Related explainers

This news row produced a single concept, so there are no siblings from the same run. The closest neighbours already on the site:

DiffusionGemma — Parallel block decoding — the natively trained diffusion route Uno is positioned against.
PSD — Parallel speculative decoding for diffusion LLMs — what happens when you put a drafter inside a diffusion model.
PreFT — Prefill-only LoRA adapters — another frozen base model plus a narrowly scoped adapter.

Frequently Asked Questions

Check what you knowMap your AI & GPU knowledge across every track — free, role-based