A "3B" image model sounds like something you can drop on any spare GPU. Iris-3B Turbo, from Sperid Labs, unteaches that. We wrapped it in a custom backend (the code that loads a model once and then answers requests) behind an endpoint that accepts OpenAI's image API JSON. The model behaved. What bit us were the numbers around it: download size, the GPU memory (VRAM) it really holds, and the size of its answers.
Every command and measurement is in our Iris-3B Turbo write-up with timings and memory figures.
Iris-3B in one paragraph
Iris-3B is an Apache-2.0 image model that works on pixels. Models like FLUX and Qwen-Image draw a compressed sketch that a separate decoder expands. Iris has no decoder: it works on a grid of 16x16 pixel squares and finishes each one itself. It starts from random noise and cleans it up a little on each pass: 100 passes for the base model, 4 for Turbo, the same network retrained. The authors' paper tested the pixel idea on depth and photo restoration, and the abstract reports the outcome without spin: "We find no significant improvement from using a pixel-space generative prior."
Trap one: the repo is four models
Clone speridlabs/iris-3b and you pull 41.9 GB: the base model, Turbo, a depth estimator and an upscaler. For fast text-to-image you only want the Turbo folder, about 6 GB:
hf download speridlabs/iris-3b --include "turbo/*" --local-dir iris-3b
A second model, Qwen3-VL-4B-Instruct from Alibaba's Qwen team, reads your prompt, and the code downloads it on first run: 8.88 GB more. Of the 130 seconds from deploy call to ready, about 72 went to fetching it, against 12 for Turbo. If your cold start (the time from launching a server to its first answer) matters, cache the text model too.
Trap two: file size is not memory size
The weights ship in bf16, a 16-bit number format. The authors' loader converts them to fp32, which takes twice the space, and then runs the math in 16-bit anyway (PyTorch calls that autocast). So the 3B network takes about 12 GB, plus about 8 GB for the text model. nvidia-smi showed Turbo at about 21 GB once loaded and about 23 GB at peak.
A 24 GB RTX 4090 sits right on the line, and we did not try one. We ran on a 48 GB NVIDIA A40 rented on RunPod, and the loaded and peak memory figures for Turbo and the base model are in the full article.
Time the GPU and the request separately
The backend timed generation with cuda.synchronize(), which waits for the GPU to finish before the timer stops; the client timed the whole HTTP round trip. For a 1024x1024 image on the A40 the GPU clock read 1.96 seconds on every run, while the caller waited 2.8 to 2.9 seconds. Four images in one request took 7.0 seconds, 1.75 each. Sperid Labs quotes about 0.7 seconds per image on an H100 when making four at once. We did not reproduce that, so our A40 figure is not a check of theirs.
The 100-pass base model needed about 90 seconds for the same image, roughly 46 times Turbo's time.
Two backend choices worth stealing. Turbo only knows seven fixed sizes around one megapixel, so a requested size is rounded to the closest of them rather than rejected. And the starting noise is generated on the CPU from the seed (the number that fixes the randomness), so a given seed starts from identical noise whatever GPU runs it.
Trap three: two PNGs, one silent timeout
Asking for two 1024x1024 PNGs in one request produced a 9.1 MB response. Messages inside InferenceKey are capped at 8 MB. The worker (the process on the GPU machine) hit the cap and dropped the result immediately; the caller heard nothing until a generic timeout about 5 minutes later. Our example now rejects multi-image PNG with an immediate HTTP 400 and suggests JPEG or WebP (four JPEGs came to 688 KB). On any stack: know the biggest message your transport accepts before clients ask for batches.
Another limit on our side: a custom backend has 300 seconds to report ready, fixed on machines InferenceKey provisions. Ours took 113, so a slow download could push it over.
Where Turbo falls short
Photos, art styles and a word or two of lettering came out well: "LISBOA" on a poster and "OPEN LATE" on a sign were spelled correctly. Longer text did not. Asked for a chalkboard menu with four prices, Turbo wrote them without decimal points. The base model, after 90 seconds rather than 2, restored the decimal point in three of the four prices but wrote some lines twice.
The vendor's scores point the same way: on their long-text test Turbo gets 0.804, the base model 0.857 and Qwen-Image 0.943. A pianist also came out with a third hand. One seed per prompt and no rival model on the same prompts: examples, not a quality study.
Credit
Sperid Labs built Iris-3B, Turbo, the depth and upscaler versions and the paper, by Hanqiu Li Cai and Chema Garabito. The community got to a fast 4-pass Iris first: pentacoxian-dev trained iris-3b-turbo-lora on a single consumer GPU. The text model is from Alibaba's Qwen team, and the final pixel stage follows the design of PixelDiT, another group's model. Training builds on other groups' methods, among them Meta's DINOv2 and Microsoft's Dion. We first heard about Iris in the AI Search channel's news video. Our share: the backend, the SDK example and the measurements, run on a private test copy of InferenceKey.
Per-size timings, the benchmark table and the backend source are in the complete Iris-3B Turbo deployment notes on inferencekey.com. If you own a 24 GB card, the open question is yours.
Top comments (0)