Liquid: an autoregressive LLM that emits image tokens instead of CLIP embeddings
(Accepted by IJCV) Liquid: Language Models are Scalable and Unified Multi-modal Generators
At a glance
- What is it?
- FoundationVision's Liquid folds visual comprehension and image generation into one HuggingFace-format language model, with no external visual encoder. The inference scripts are simple; the training path is documented but the pretrain checkpoints are not yet released.
- Who is it for?
- Adopt Liquid if you want a single HuggingFace-format checkpoint that answers questions about an image and generates images from a prompt, and if 7B parameters with an 8-bit fallback fits your GPU. Do not adopt it if you need the 0.5B to 32B scaling family, because the open-source plan in the README still lists those checkpoints as unchecked, or if your pipeline expects a diffusion sampler you can swap out.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 106 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The split Liquid is trying to remove
Most multimodal systems are two models wearing one coat. A vision encoder such as CLIP turns pixels into embeddings, a projection layer maps those embeddings into a space the language model accepts, and a separate diffusion model handles anything that goes the other direction. Each stage has its own checkpoint, its own preprocessing, and its own failure modes. The README states that Liquid instead uses a single large language model and eliminates the need for external pretrained visual embeddings such as CLIP. Images become tokens in the same sequence space as text, and the same autoregressive loop produces either a sentence or an image. That is the whole claim, and it is a narrower claim than it first sounds. Liquid is not a pipeline that wraps existing components more cleanly. It is an argument that the visual encoder is unnecessary if the language model is large enough. The repo targets researchers who want to study that argument and engineers who want one checkpoint to load rather than three.
One token stream, two output modalities
The architecture visible in the material is a decoder-only transformer. Text tokens and visual tokens share the sequence, and generation is next-token prediction in both cases. The framework diagram in assets/liquid_framework.png is the only structural view the README offers, so the exact tokenizer and the visual token construction are not spelled out in the repository text. What the README does commit to is the consequence: a unified token space, which it says lets visual generation and comprehension tasks mutually enhance each other. That is a testable prediction rather than a description. If the two tasks share weights and token space, gradient from image generation should change how the model handles image understanding, and the paper's scaling claim rests on the same coupling. The paper is cited as International Journal of Computer Vision, volume 134, number 1, 2026. The scaling result is stated as a trend: the performance drop caused by training visual and language tasks together shrinks as model size grows. Note the direction. Unified training costs something at small scale, and the claim is that the cost fades with size, not that it was never there.
Three inference scripts and a VRAM ceiling
The README is explicit that inference needs no complex environment because the model is essentially a HuggingFace format language model, so transformers plus basic components is enough. Three scripts cover the three modes. Pure dialogue: python inference_t2t.py --model_path Junfeng5/Liquid_V1_7B --prompt "Write me a poem about Machine Learning." Image understanding: python inference_i2t.py --model_path Junfeng5/Liquid_V1_7B --image_path samples/baklava.png --prompt 'How to make this pastry?' Image generation: python inference_t2i.py --model_path Junfeng5/Liquid_V1_7B --prompt "young blue dragon with horn lightning in the style of dd fantasy full body". The constraint that matters is memory. The README says that on a GPU with less than 30GB VRAM you may need to enable load_in_8bit in AutoModelForCausalLM.from_pretrained in app.py to avoid out-of-memory errors during image generation, and the t2i script accepts the same switch as --load_8bit. The Gradio demo adds two pinned dependency versions, gradio==4.44.1 and gradio_client==1.3.0, then runs python app.py from inside evaluation/. EVAL.md is the place the README points to for recommended versions, and that pointer is worth following before you file a bug against your own environment.
Training is documented, the scaling checkpoints are not
Two files carry the training path: Data.md for data processing and TRAIN.md for pretraining. The news entry dated 2025-03-25 says both were updated, which suggests they are maintained rather than abandoned stubs. The README does not reproduce their contents, so the actual launcher, the config format and the expected dataset layout cannot be confirmed from the repository front page. The open-source plan is where the honest limitation sits. Under Liquid-7B-IT, the web demo, evaluation, checkpoints and training codes are all marked complete. Under Liquid-0.5B to 32B-Pretrain, described as multimodal extension models of six different scales across three model families, the checkpoint line is unchecked. The scaling law is the paper's headline result, and the models that demonstrate it across the full range are not in the release. What you can download today is the 7B instruction-tuned model. If your reason for looking at Liquid is to reproduce the size-versus-degradation curve, the material says you cannot yet do that from released weights.
Where a single-model design costs you
Unified weights mean you cannot swap the image generator. In a diffusion stack you can replace the sampler, add a LoRA, change the scheduler, or drop in a different decoder without touching the text side. With Liquid the image path is the language model, so any change to generation quality is a change to the model that also answers your questions about images. The README frames the shared token space as mutual enhancement; the same coupling is a shared blast radius. The second cost is memory. A 7B model that must hold visual tokens in context is not a small deployment, and the README's own guidance points to 8-bit loading below 30GB of VRAM, which is a quantization trade rather than a free fix. The third is scope. The material describes text-to-image, image understanding and text dialogue. It does not describe video, audio, or editing an existing image, and nothing in the README suggests those are on the roadmap. If your task is inpainting or instruction-based image editing, this is the wrong tool and the repository does not pretend otherwise.
Against a CLIP-plus-diffusion pipeline
The obvious alternative is the conventional composition: a vision-language model built on a frozen CLIP or SigLIP encoder for understanding, plus a diffusion model such as Stable Diffusion for generation, glued by a projection layer or an adapter. The difference is not quality, which the material does not let us compare. The difference is where the parameters live and what that buys. In the composed stack, each component is independently replaceable and independently trainable, and the understanding encoder is frozen, which keeps training cheap. Liquid spends capacity on teaching one model to do both, and its scaling claim is precisely that this spending pays off as parameters grow. That makes the two approaches diverge at the small end. A small composed pipeline works because the heavy lifting is done by pretrained parts. A small Liquid model, by the paper's own framing, carries the unification penalty most heavily. The design is aimed at the large end of the curve, where the released weights currently stop at 7B.
Licence, maintenance and what a fork costs you
The repository is MIT licensed, and the LICENSE file is the authority rather than this article. MIT is permissive, so the code can be reused in commercial settings, but the licence covers the repository. The model weights live on Hugging Face under Junfeng5/Liquid_V1_7B and the demo under Junfeng5/Liquid_demo, and the terms attached to those artifacts are a separate question that the README does not address. Check them before shipping anything. On maintenance, the signals are mixed in a useful way. The last push is dated 2026-06-01 and the news entries run through 2025-03-25, so the repository is active. There are no retrieved releases, which means upgrades arrive as commits on main rather than tagged versions. If you pin to a commit, you are choosing your own stability; if you track main, you inherit whatever the next Data.md and TRAIN.md revision changes. The paper is accepted at IJCV, so the method is fixed in print even as the code moves. The API surface you depend on is small, three inference scripts and a Gradio app, which limits how much a breaking change can cost you. That is the practical argument for trying it: the integration surface is thin enough that evaluating it is a few commands, not a migration.
Editorial conclusion
Adopt Liquid if you want a single HuggingFace-format checkpoint that answers questions about an image and generates images from a prompt, and if 7B parameters with an 8-bit fallback fits your GPU. Do not adopt it if you need the 0.5B to 32B scaling family, because the open-source plan in the README still lists those checkpoints as unchecked, or if your pipeline expects a diffusion sampler you can swap out. Before committing, run inference_t2i.py on your target GPU without --load_8bit to confirm the memory ceiling, and read Data.md and TRAIN.md to see whether the data pipeline matches what you already have.
Community notes