Janus-Pro-7B
Janus-Pro-7B reads images and creates them from a single transformer, and its benchmark numbers make an argument worth reading twice. On instruction-following for text-to-image it scores 80% against DALL·E 3's 67% — while generating at 384×384, roughly an eighth the pixel area of a 1024-pixel image. That gap is not about fidelity; it is about doing what the prompt asked. The design behind it separates visual encoding into two pathways, one tuned for understanding and one for generation, resolving a conflict that single-encoder unified models cannot escape. It also outperforms a 13-billion-parameter unified model on every benchmark but one.

Janus-Pro-7B
A unified multimodal model that beat dedicated image generators at following instructions — while generating at a fraction of their resolution.
Paper: Janus-Pro: Unified Multimodal Understanding and Generation with Data and Model Scaling · Reference implementation
Read the Benchmark Before the Architecture
GenEval measures whether a generated image contains what the prompt asked for: the right objects, the right count, the right colours, the right spatial relationships. It is a test of obedience rather than of beauty.
Janus-Pro-7B scores 80% overall. DALL·E 3 scores 67%. Stable Diffusion 3 Medium scores 74%. Transfusion scores 63%.
Now the part that reframes it: this model generates at 384 × 384. The paper states the output resolution directly in its own figure captions. A 1024-pixel image has roughly eight times the pixel area.
So the result is not "a unified model produces better pictures." It is "a unified model understands the request better, at a fraction of the output resolution." Those are different claims, and only one of them is supported here.
What that means for choosing it. If your bottleneck is a generator that ignores half your prompt — wrong object count, missing element, spatial relationship reversed — this model addresses exactly that. If your bottleneck is output resolution, it does not.
The Conflict the Architecture Resolves
Unified models that both read and create images run into a problem the paper names as the limitation of previous work: one visual encoder cannot serve two opposing purposes.
Understanding wants semantics — what is present, how things relate, what the sign says. Generation wants something a decoder can reconstruct token by token. An encoder optimised for both is optimised for neither.
Janus-Pro decouples the pathways while keeping one backbone:
| Task | Pathway |
|---|---|
| Understanding | SigLIP-L — CLIP's framework with a pairwise sigmoid loss, 384×384 input |
| Generation | LlamaGen tokenizer, downsample rate 16 |

Both feed one unified autoregressive transformer built on DeepSeek-LLM-7b-base. Image generation is next-token prediction over visual tokens, the same mechanism the model uses for text — which is why a single transformer hosts both behaviours without a separate diffusion stack beside it.
The paper attributes the benchmark results directly to this decoupling, and the evidence is in the comparison table: every unified model it beats uses a shared encoder.
Three-Stage Training
The improvement over the original Janus came from training rather than from a new architecture.
Stage one extends pre-training across diverse data. Stage two fine-tunes with adjusted data ratios. Stage three applies supervised refinement across both modalities.
Two data additions are named specifically: 72 million synthetic aesthetic samples for generation, and 90 million multimodal understanding samples for the reading side. The paper credits these with improving output stability — particularly on short prompts, where earlier versions were least reliable.
That detail is worth keeping. A model that handles a terse prompt well is a model you can put behind a user-facing input box, where nobody writes a paragraph.
Benchmark Results
From the paper. Understanding benchmarks first, then generation.
Multimodal understanding
| Benchmark | Janus-Pro-7B | Original Janus |
|---|---|---|
| MMBench | 79.2 | 69.4 |
| MME-Perception | 1567.1 | 1338.0 |
| MM-Vet | 50.0 | 34.3 |
| MMMU | 41.0 | 30.5 |
| POPE | 87.4 | 87.0 |
MM-Vet moved from 34.3 to 50.0 — the largest proportional gain, on the benchmark measuring integrated capabilities rather than any single skill.
MMMU at 41.0 is the honest counterweight. That benchmark tests multi-discipline expert reasoning, and 41.0 is modest. This model understands images well; it does not reason like a frontier model while doing so.
Visual generation
| Benchmark | Score |
|---|---|
| GenEval (overall accuracy) | 80% |
| DPG-Bench | 84.19 |
DPG-Bench runs 1,065 long, dense prompts — each decomposed into checks for entity presence, attributes, relations, and counts. It is the hardest available test of whether a model followed a complicated instruction rather than a simple one.
The comparison worth noting
The paper reports that Janus-Pro-7B outperforms TokenFlow-XL (13B) on every benchmark except GQA — a unified model nearly twice its size.
A Discrepancy Worth Flagging
The paper reports 80% on GenEval. Independent research using this model as a baseline reports 76.31%.
Both figures are published. The difference comes from implementation, sampling settings, or evaluation harness rather than from the model changing.
The practical takeaway: a three- to four-point spread on the same model and the same benchmark is normal, and it is why a benchmark number tells you roughly where a model sits rather than exactly what it will do on your prompts. Measure on your own cases before committing.
Specifications
| Model ID | deepseek-ai/Janus-Pro-7B |
| Base model | DeepSeek-LLM-7b-base |
| Understanding encoder | SigLIP-L |
| Generation tokenizer | LlamaGen, downsample rate 16 |
| Image input | 384 × 384 |
| Image output | 384 × 384 |
| Modality | Text and images in → text and images out |
| Pipeline tag | any-to-any |
| Code licence | MIT |
| Model licence | DeepSeek Model License |
| Released | January 2025 |
The two licences are separate documents. The code repository is MIT. Use of the model weights falls under DeepSeek's own model licence. Read the second against your deployment; the first does not extend to it.
Context length is not stated on the model card. Confirm it from the model configuration.
Capabilities
| Capability | Value |
|---|---|
input_types | text, image |
output_types | text, image |
image_input_resolution | 384x384 |
image_output_resolution | 384x384 |
image_generation | Supported |
image_understanding | Supported |
unified_model | Yes — one transformer, decoupled encoders |
generation_mode | Selects text or image output |
deterministic | No |
requires_prompt | Yes |
384 on Both Sides
The single constraint that decides where this model fits, and it applies twice.
On input, 384 pixels is enough to see a scene and not enough to read one. Objects, arrangement, composition, colour, and lighting survive. Small text, dense tables, chart labels, fine print, and most of what makes a screenshot useful do not.
On output, 384 pixels is a thumbnail by current standards. The generation benchmarks say the model puts the right things in the frame; they say nothing about how large that frame is.
What this is good for: concept exploration where composition matters and resolution does not, layout and arrangement studies, pipelines that upscale afterwards, and any case where instruction adherence is the thing you were failing at.
What it is not for: final assets, print, anything inspected closely, and document reading of any kind.
Which Endpoint Serves It
Worth settling before you build. A model that generates images belongs behind an images endpoint; a model that reads them belongs behind chat completions. This one does both, and how a platform routes that is a deployment decision rather than a property of the model.
Check your model listing and test both paths. The examples below cover generation.
Using Janus-Pro-7B on DEVUP AI
Endpoint: POST https://api.devupai.com/v1/images/generations
The response returns a signed URL in data[0].url with a _devup object carrying the request cost
and your remaining balance. The URL is valid for five minutes — fetch the bytes on arrival.
Python
import urllib.request
from openai import OpenAI
client = OpenAI(
api_key="$DEVUP_API_KEY",
base_url="https://api.devupai.com/v1",
)
response = client.images.generate(
model="deepseek-ai/Janus-Pro-7B",
prompt="A photo of an astronaut riding a horse on Mars.",
size="1024x1024",
n=1,
)
image_url = response.data[0].url
with urllib.request.urlopen(image_url) as res:
image_bytes = res.read()
with open("output.png", "wb") as f:
f.write(image_bytes)Node.js
import DevupAI from "devupai";
import { writeFile } from "node:fs/promises";
const client = new DevupAI({
apiKey: process.env.DEVUP_API_KEY,
});
const response = await client.images.generate({
model: "deepseek-ai/Janus-Pro-7B",
prompt: "A photo of an astronaut riding a horse on Mars.",
size: "1024x1024",
n: 1,
});
const image = await fetch(response.data[0].url);
await writeFile("output.png", Buffer.from(await image.arrayBuffer()));cURL
curl -X POST "https://api.devupai.com/v1/images/generations" \
-H "Authorization: Bearer $DEVUP_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-ai/Janus-Pro-7B",
"prompt": "A photo of an astronaut riding a horse on Mars.",
"size": "1024x1024",
"n": 1
}'⚠️ Note the size parameter. The model's native output is 384 × 384. What a larger requested size
produces depends on the serving layer — upscaling, padding, or rejection. Verify what you actually
receive before designing around a dimension.
Writing Prompts for an Instruction-Follower
The benchmark results point at what this model rewards, and it is not the usual vocabulary.
Be specific about what belongs in the frame. GenEval tests object presence, counts, colours, and spatial relations — the things this model was measured on following. "Two red cups to the left of a blue bowl" is the kind of prompt it handles better than most.
State counts explicitly. Counting is where most image models fail and where this one was specifically evaluated.
State spatial relationships. Left, right, above, behind, in front of. Another GenEval category, another place the measured advantage lives.
Long prompts are fine. DPG-Bench runs dense multi-requirement prompts, and 84.19 says the model holds them together rather than executing the first clause and improvising the rest.
Short prompts are also fine — the three-stage training specifically targeted stability on brief inputs, which earlier versions handled poorly.
Do not reach for resolution vocabulary. "8K", "ultra-detailed", "highly detailed" describe an output this model does not produce at any prompt.
Running It Locally
At seven billion parameters this is heavier than its sibling and still modest by multimodal standards — a single capable GPU, less when quantised.
The Transformers integration exposes the modality switch through a generation_mode argument on both
the processor and the generate call. Flipping it between text and image output on identical weights
is the clearest demonstration available of what a unified model is, and it is worth doing once even
if you deploy through an API.
Quick-start instructions live in the project repository.
Where It Belongs
The paper is the product, and the architecture is the claim. Decoupled visual encoding resolves a real conflict, and these numbers are the evidence.
Choose it for: instruction-faithful generation where composition matters more than resolution, unified pipelines that need both reading and creating without two integrations, research into unified multimodal design, local and offline deployment, and concept work that gets upscaled later.
Choose something else for: final production imagery, print, document and chart reading, and high-resolution work of any kind.
A 1-billion-parameter sibling exists with the same architecture on a smaller base. If the approach suits you but this footprint does not, that is the alternative — at a measurable cost in both understanding and generation scores.
Practical Notes
Check 384 against your task before anything else, and check it on both sides.
Write prompts that test obedience — counts, colours, spatial relations. That is what this model was measured on and what it does better than its resolution suggests.
Confirm which endpoint serves it on your account, and confirm what a larger requested size actually
returns.
Read the model licence separately from the code licence.
Output is not reproducible; the same prompt gives a different image each run. Keep the file.
Treat published benchmark figures as approximate — the same model and benchmark span several points across independent evaluations.
Moderate prompts arriving from users and review output before publishing.
Limitations
384 × 384 on input and output. The defining constraint, and it rules out document work and final assets equally.
A January 2025 release. Generation fidelity is not competitive with current dedicated models, and the paper claims instruction-following rather than image quality.
MMMU at 41.0. Expert-level multi-discipline reasoning is a weak point, and no prompting recovers it.
Model weights are not MIT-licensed. The code is.
Context length is undocumented on the model card.
Endpoint routing varies by platform, because a model that reads and writes images does not map onto one API category.
Not deterministic. Identical prompts produce different images.
Published scores vary across evaluations by several points on the same benchmark. Measure your own cases.
Judge it as a demonstration of an idea, not as a production image generator. That is what it was built to be, and it succeeds at it.