vLLM-Omni turns FLUX 3 Image Klein into an API, with a license caveat

A new verified vLLM recipe turns Black Forest Labs’ FLUX 3 Image Klein into a deployable image service through vLLM-Omni. The recipe covers text-to-image generation, single- and multi-reference editing, quantized variants and an optional prompt-expansion service—but it also exposes constraints that matter before anyone treats the example as a production baseline.

One package, two API paths

FLUX 3 Image Klein is a distilled 5.6-billion-parameter image transformer using Qwen3-VL-4B-Instruct as its text encoder. The package bundles the diffusion transformer, image autoencoder and text encoder; FP8R and NVFP4 transformer variants sit under the same checkpoint tree.

vLLM-Omni exposes text-to-image requests at /v1/images/generations. Image editing uses /v1/chat/completions, with references supplied as base64 data URIs. The editing path accepts as many as 10 ordered reference images, allowing prompts to identify “the first image” or later inputs by position.

This is not an image-to-image strength-slider implementation. The reference images become conditioning tokens and generation begins from noise; the recipe says seed selection can materially change how closely an output follows its references. The distilled checkpoint also rejects classifier-free-guidance inputs such as guidance_scale and nonempty negative prompts, and defaults to a fixed 16-step schedule.

The serving path is ready-made, but gated

The recommended route is the vllm/vllm-omni:flux-3-image-klein day-zero container, serving the checkpoint on port 8099 with vllm serve ... --omni. Multi-GPU tensor and CFG parallelism, LoRA loading and Blackwell-only FP8 attention are optional extensions rather than requirements for the basic endpoint.

Access is not open-ended. Operators must accept the FLUX Kommunity License on Hugging Face and authenticate before downloading the checkpoint. The recipe describes that license as permitting non-commercial use with a commercial-output exception for qualifying users. Teams planning a commercial service therefore need to review their eligibility rather than infer rights from the availability of the container command.

What the GB200 numbers establish

The recipe records an end-to-end validation on October 15 using an Arm64, CUDA 13.0 build on one NVIDIA GB200. At the default 1024-by-1024 resolution and 16 steps, text-to-image completed in about 2.1 seconds and image editing in about 2.8 seconds after roughly 105 seconds of engine startup. The BF16 package consumed about 19 GiB of GPU memory.

Those figures establish that this exact software and hardware combination ran both API paths. They are not a cross-hardware benchmark, a sustained-throughput result or a latency guarantee under concurrency: the recipe reports one verified setup and no comparative workload. Its main engineering value is narrower and useful—operators now have a reproducible serving path, endpoint contract and explicit memory and licensing constraints for evaluating the model in their own environment.