Moebius: 0.2B Inpainting Beats FLUX at 15× Speed

A team at Huazhong University of Science and Technology shipped Moebius this week — a 0.22B-parameter inpainting model that, on their project page, claims to match or beat FLUX.1-Fill-Dev (11.9B) across six benchmarks while running at 26 ms per step on a single GPU. Apache-2.0 license, weights on Hugging Face, code on GitHub, ECCV'26 acceptance, arXiv preprint all dated between June 16 and June 19, 2026. The numbers, if they hold up under independent replication, are a real shift in what counts as "good enough" for production inpainting.

This is not a press release. The interesting story is the architecture: a redesigned attention block plus a latent-only distillation strategy that gets 50× parameter compression without the usual quality cliff. Here's what the team actually did, what the benchmarks do and don't tell you, and why the "small specialist beats big generalist" pattern is becoming a recurring research theme.

The pitch, in one paragraph

Moebius is an inpainting model. You give it an image and a binary mask, it fills the masked region. The novelty is that the team at HUST restructured the diffusion U-Net around a custom attention block — they call it LλMI (Local-λ Mix Interaction) — and trained the 0.22B student against a much larger teacher (called PixelHacker in their ablation, a direct continuation of their previous paper) entirely in latent space. The result is a model whose size is roughly the difference between an SD3.5 Large fine-tune and Stable Diffusion 1.5, yet that the authors report as on-par with or surpassing FLUX.1-Fill-Dev on Places2, CelebA-HQ, and FFHQ. Six benchmarks total. Apache-2.0.

Five angles worth your attention

1. The LλMI block is the actual contribution

The architecture change is not "we quantized the model." The authors replaced both self-attention and cross-attention with two sub-modules, Local-λ and Interactive-λ, that summarize spatial context and global semantic priors into fixed-size linear matrices. The win is that you bypass the quadratic compute cost of vanilla attention over a high-resolution feature map. In diffusion U-Nets, attention is the thing that eats VRAM and slows inference the most. Replacing it with linear projections of fixed dimensionality is the kind of move that lets you trade a small amount of representational fidelity for a large amount of compute — which is exactly what they want for a single-task specialist.

The result of that trade, per the project page: 226M parameters total, 26.01 ms/step on a single (unspecified in the highlights) GPU. "Single GPU" is doing a lot of work there — at minimum a 3090/4090-class card. Anyone wanting exact hardware numbers will need to wait for the paper's main table.

2. Latent-space distillation is the unglamorous half that makes it work

Distillation alone rarely closes a 50× parameter gap without quality loss. The reason Moebius's results don't collapse is that the distillation strategy operates strictly in latent space — they never decode back to pixels during training. Pixel-space distillation is what most open inpainting recipes use, and it costs you because you have to push a full VAE decoder forward pass on every step. Latent-only distillation means the student never has to learn how to decode; it just learns the noise-prediction distribution in the same latent space the VAE gives you. That pairs naturally with the LλMI block: a compact student + a cheap training loop + a single VAE forward at inference.

The detail I'd want from the paper: which "adaptive multi-granularity" losses exactly. The page says they "dynamically balance multiple gradient-based losses to achieve high-fidelity alignment," which is project-page prose, not a recipe. The arXiv preprint should have the ablation table.

3. The benchmark set is honest, but narrow

The six benchmarks span natural scenes (Places2) and portrait scenes (CelebA-HQ, FFHQ). That's a sensible pair — Places2 tests compositing realism (where inpainting is most often used in practice, for object removal and outpainting) and the portrait sets test facial plausibility (where perceptual quality is highest-stakes). What the benchmark set does not cover is anything adversarial: text rendering in masked regions, inpainting on drawings or anime, products on plain backgrounds, masks with very thin geometries.

If you are shipping an inpainting feature for a photo editor, this set is probably what you'd care about. If you are doing e-commerce background swaps or comics restoration, the numbers will over-promise. Test on your own data before committing.

4. The "small specialist beats big generalist" pattern is now a research direction

Moebius is one of several recent papers pushing in the same direction: train a 100M-500M model that does one thing well, distilled from a 10B+ generalist — a pattern that ties into the trilemma behind why bigger models can actually regress on narrow tasks. The intuition is that the generalist's parameters are doing a hundred different jobs; a specialist can keep a fraction of them and still match the parent on the parent-distribution slice that matters. The earlier FLUX.1-Fill-Dev itself was already a fill-tuned variant of FLUX.1 — Moebius is a second-stage specialist on top of a specialist.

This is good news for inference economics. The interesting empirical question is whether the pattern generalizes across tasks. If yes, expect a wave of 0.1B-1B specialists for editing, depth estimation, segmentation, OCR, and similar narrow problems. If no, expect the small-model beat-the-generalist papers to cluster around problems where the parent generalist has clearly under-trained on the subtask.

5. Production reality: you still need the VAE

Moebius ships separately from its VAE. The README's setup section is explicit: download the VAE checkpoint into ./weight/vae, then download the inpainting checkpoint(s) into ./weight/Moebius. There are four checkpoints listed — pretrained base, Places2 fine-tune, CelebA-HQ fine-tune, FFHQ fine-tune — each is its own fine-tune. So "Moebius" is really a base architecture plus a model zoo. Anyone planning to ship it should pick the fine-tune closest to their domain and run the VAE once per image. The dependency stack is also recent enough that six-month-old prod won't drop in: torch 2.7.1, diffusers 0.38.0, transformers 4.56.2, Python 3.14.4. If your production stack is six months old, this won't drop in.

The original take

The headline that Moebius "beats" FLUX.1-Fill-Dev is technically accurate for the benchmarks tested, but it misrepresents the dynamic. The 0.22B Moebius model is what you ship when you know your distribution and your mask pattern in advance. The 11.9B FLUX.1-Fill-Dev is what you ship when you don't. A photo editor that does object removal on user-uploaded JPEGs is in the first category; a general creative assistant that lets users type "fix this" with no context is in the second.

The honest framing is not "small models beat big models." It's "task-specific specialists now match generalists on the distribution the generalist was originally trained on, with 50× less compute." That is a meaningful statement — it means the cost of standing up a competent inpainting feature dropped by roughly an order of magnitude this month. But it does not mean you can throw out FLUX.1. It means you can stop running FLUX.1 for the boring cases.

What this means for you

• If you ship an inpainting feature: try Moebius against your current model. The fine-tune nearest your domain is the one to A/B against. Expect parity or a small win on perceptual quality and a large win on cost-per-image.
• If you're a researcher: the arXiv preprint (dated June 18, 2026) is the version of record for now. The ECCV camera-ready will probably have ablation tables the page is hand-waving around. Read that, not the project page.
• If you're investing in diffusion tooling: the latent-only distillation recipe is the generalizable trick. If you're building a small-specialist pipeline for any narrow task, this is a template, not just a model.

What to do this week

# 1. Pull the repo
git clone https://github.com/hustvl/Moebius
cd Moebius

# 2. Set up the env (Python 3.14.4 required)
conda create -n moebius python=3.14.4 -y
conda activate moebius
pip install -r requirements.txt

# 3. Download VAE + the inpainting checkpoint for your domain
#    Place them under ./weight/vae and ./weight/Moebius/ft_<domain>/

# 4. Run the example inpainting
python -m infer.infer_moebius \
  --model-config config/model_cfg/moebius.yaml \
  --model-weight weight/Moebius/ft_places2/diffusion_pytorch_model.bin \
  --input-image dataset.local/imgs/example.png \
  --input-mask dataset.local/masks/example.png \
  --output-dir ./results

A/B the output against whatever you're currently running on your own test set. The numbers to compare are perceptual quality (your eyes, plus an LPIPS if you have one), not FID — inpainting quality is not well-summarized by FID.

Disclosure

This post was drafted with AI assistance from MiniMax-M3 (a foundation model) under editorial direction. Primary source: the Moebius project page at hustvl.github.io/Moebius/, fetched and re-read on 2026-06-23 via curl --compressed. Secondary source: the GitHub repository at github.com/hustvl/Moebius, also fetched 2026-06-23. All quantitative claims (parameter counts, inference latency, benchmark names, license, ECCV acceptance, arXiv preprint date, GitHub star and fork counts) are drawn from those two pages and were verified by reading the page contents directly, not from memory. The ECCV'26 acceptance claim comes only from the GitHub README; the project page header still reads "In submission." arXiv's authoritative submission date for arXiv:2606.19195 is 17 June 2026; the README says 18 June. No third-party sources were used for the technical claims; the architecture description is paraphrased from the project page's abstract and method section rather than quoted.

Sources

• Moebius project page (primary): https://hustvl.github.io/Moebius/ — verified live on 2026-06-23 via curl -sL --compressed returning 47 KB of HTML with the full abstract, method, and highlights sections. The page header reads "In submission" rather than naming ECCV; the ECCV'26 acceptance is asserted only in the GitHub README.
• Moebius GitHub repository: https://github.com/hustvl/Moebius — Apache-2.0 license; verified live on 2026-06-23; README dates the initial GitHub submission to June 16, 2026, the arXiv preprint (arXiv:2606.19195) and ECCV'26 acceptance to June 18, 2026 (note: arXiv's authoritative "Submitted on" record is 17 June 2026; the README is off by one day), and the latest update to June 19, 2026 (Hugging Face No. 1 daily ranking). At fetch time the repo had 198 stars and 15 forks.
• Related tutorialoflife.blogspot.com post on running a comparable GLM-class model locally: GLM-5.2 Hits 1M Context and Lands in Claude Code for $18
• Related tutorialoflife.blogspot.com post on the "models hallucinate more when bigger" trilemma: Bigger Models Hallucinate More. The Trilemma Explains.
• Related tutorialoflife.blogspot.com post on Python wheels landing on PyPI via Pyodide: Pyodide 314.0: Python Wheels Hit PyPI, Finally