Janus-Pro-1B

Janus-Pro-1B

One transformer. Two visual pathways. Text and images in, text and images out.

Paper: Janus-Pro: Unified Multimodal Understanding and Generation with Data and Model Scaling · Reference implementation

The Conflict This Model Resolves

Unified multimodal models — ones that both read images and create them — hit a problem that sounds abstract and is not.

Understanding an image and generating one want different representations. Reading needs semantics: what is in the frame, how the parts relate, what the sign says. Generating needs something a decoder can rebuild pixel by pixel. A single visual encoder asked to serve both ends up serving neither particularly well, and the Janus paper names this directly as the limitation of previous approaches.

Janus-Pro's answer is to stop asking one encoder to do both.

Two encoders, one unified transformer behind them. The decoupling removes the conflict; the shared backbone keeps the architecture simple enough to reason about.

The paper's claim is the one that matters for a design like this: it surpasses previous unified models and matches or exceeds task-specific models. A model doing two jobs is only interesting if it does not lose to models doing one.

What Sits Underneath

The base is DeepSeek-LLM-1.5b-base — a language model, extended rather than rebuilt.

That lineage explains the shape of the thing. Janus-Pro is a language model that learned to see and to draw, not an image model that learned to talk. Image generation is autoregressive: the model predicts visual tokens the way it predicts text tokens, one after another, which is why a single transformer can host both behaviours without a separate diffusion stack bolted alongside it.

The generation tokenizer comes from LlamaGen, which applies next-token prediction to images specifically. Same paradigm, different vocabulary.

Any-to-Any, Literally

Hugging Face classifies this model any-to-any rather than as a text or image model. The classification is accurate.

Text in, text out. Ordinary language modelling. Image in, text out. Visual question answering and description. Text in, image out. Generation from a prompt. Image and text in, either out. Reasoning about an image, or working from it.

On the reference implementation a generation_mode flag selects the output modality. Same weights, same call, one parameter deciding whether you receive a sentence or a picture.

That is worth running once locally even if you deploy something else, because it makes the idea of a unified model concrete in a way reading about it does not.

384 × 384, and What That Decides

The input resolution. It is the first thing to check against your task, and frequently the last.

384 pixels on a side is small. Vision models elsewhere in this catalogue read at 1568 pixels and above; recent releases reach 2576 pixels and 3.75 megapixels. This one reads at 384.

What survives at that resolution: the scene, the objects, their arrangement, the general composition, the obvious colour and lighting. A photograph is still recognisably that photograph.

What does not: small text, dense tables, chart axis labels, fine print on packaging, anything in a scanned document, most of what makes a screenshot useful.

The rule is simple. If your image needs to be seen, this works. If it needs to be read, it does not — and no prompt engineering recovers detail the encoder never received.

Specifications

Two licences, two scopes. The code repository is MIT. Use of the model weights falls under DeepSeek's own model licence, which is a separate document with separate terms. Read the second one 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 rather than carrying a number across from a related release.

Capabilities

Which Endpoint Serves It

Resolve this before building, because the model straddles a category boundary that APIs do not.

Image generators live behind an images endpoint. Vision-language models live behind chat completions. Janus-Pro is both, and how any given platform routes that is a deployment decision rather than a property of the model.

Check your model listing and test both paths. A request to the wrong endpoint fails visibly — which is the good outcome, and still better discovered in integration than in a shipped feature.

The examples below cover the generation half.

Using Janus-Pro-1B on DEVUP AI

Endpoint: POST https://api.devupai.com/v1/images/generations

The response carries a signed URL in data[0].url plus a _devup object with the request cost and your remaining balance. The URL is valid for five minutes — fetch the bytes on arrival rather than storing the link.

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-1B",
    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-1B",
  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-1B",
    "prompt": "A photo of an astronaut riding a horse on Mars.",
    "size": "1024x1024",
    "n": 1
  }'

Running It Locally

Unusually practical for a multimodal model, and for research work frequently the better option.

A billion parameters fits on modest hardware — one consumer GPU, considerably less when quantised. Local deployment, offline work, classroom demonstration, and air-gapped environments are all viable here in a way they are not with larger multimodal models.

The mode switch is exposed directly in the Transformers integration, through a generation_mode argument on both the processor and the generate call. Flipping it between text and image output on the same weights is the clearest demonstration available of what a unified model actually is.

Quick-start instructions and the reference implementation live in the project repository.

Where It Belongs

This is a research model, and the paper is the product. The contribution is architectural — evidence that decoupled visual encoding resolves a real conflict — and the weights are how you verify it.

Reach for it when studying unified multimodal design, when working locally or offline, when teaching or demonstrating the idea, when prototyping a pipeline that needs both understanding and generation without maintaining two integrations, and when a small footprint outranks peak quality.

Reach elsewhere for production image generation judged against dedicated models, for reading documents or charts, and for anything requiring high-resolution visual input.

A 7-billion-parameter sibling exists with the same architecture on a larger base. If the approach fits your problem but the capacity does not, that is the next step rather than a different design.

Practical Notes

Match the task to 384 pixels before anything else. Seeing works; reading does not.

Confirm which endpoint serves this model on your account before you build against one.

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, not the prompt.

Run the mode switch once locally if you want to understand what you are deploying.

Moderate prompts arriving from users and review output before publishing, as with any generative model on a public path.

Limitations

384 × 384 input — an order of magnitude below current vision models, and the constraint that rules out document and detail work entirely.

A January 2025 research release. Generation quality is not competitive with models built solely for that job, and the paper makes no such claim against the current generation.

Model weights are not MIT-licensed. The code is. The two are separate documents.

Context length is undocumented on the model card.

Endpoint routing varies by platform, because a model that both reads and writes images does not map onto a single API category.

Not deterministic. Identical prompts produce different images.

One billion parameters buys portability, not depth. World knowledge and reasoning are limited accordingly, and no amount of prompting changes that.

Judge it as a demonstration. The architecture is the achievement; if you need the same idea with more capacity behind it, the larger sibling is where to look.