Ideogram 4

Ideogram 4

Ideogram 4 is an open-weight text-to-image model with a distinctive structured JSON prompt: instead of a single sentence, the model is trained to read an overall scene description plus a list of regions, each with a bounding box and its own text. Invoke assembles this JSON for you.

License

Ideogram 4 is released under the Ideogram 4 Non-Commercial License. The weights may not be used commercially, and outputs may not be used to build competing models. Ideogram claims no rights in images you generate, but the license does not explicitly grant commercial use of them. The ideogram-ai repositories are gated; the Comfy-Org copy is not, but the same license applies.

This is a summary, not legal advice. Read the full license on the model’s HuggingFace page before using a model commercially.

Installing Ideogram 4

The weights are gated on HuggingFace under a non-commercial license. Open the model page, accept the terms, and make sure your HuggingFace token is set up in the config file before installing. Two bundled builds are available:

• ideogram-ai/ideogram-4-nf4 — nf4 quantized, CUDA only, fits in 24 GB VRAM. Recommended for NVIDIA GPUs.
• ideogram-ai/ideogram-4-fp8 — fp8 quantized, runs on any device, with higher memory use.

Paste either repo ID into the Model Manager’s HuggingFace / URL field to install. Each folder carries everything Ideogram 4 needs.

Single files

Comfy-Org’s Comfy-Org/Ideogram-4 repackage is ungated (the same non-commercial license still applies) and ships the parts separately. Ideogram 4 runs two transformers — a conditional branch and an unconditional one, both active at every step — so a single-file install is four models, and each starter installs all four together:

• diffusion_models/ideogram4_<build>.safetensors — the conditional branch, selected as the model
• diffusion_models/ideogram4_unconditional_<build>.safetensors — the unconditional branch
• text_encoders/qwen3vl_8b_fp8_scaled.safetensors — the Qwen3-VL 8B encoder (not the 4B one Krea-2 uses). A llama.cpp GGUF of the 8B encoder works as well; see Qwen3-VL GGUF encoders.
• vae/flux2-vae.safetensors — the 32-channel VAE, shared with FLUX.2, which is why it installs under the FLUX.2 base

Pick the unconditional branch, the encoder and the VAE in the Components section next to the model — and pick the unconditional branch of the same build as the model. The nvfp4 transformers in that repo are not supported yet and are refused at install; its nvfp4 encoder, text_encoders/qwen3vl_8b_nvfp4.safetensors, loads and keeps its layers packed.

Which branch a file holds is read from the file itself, and from the filename for a build that does not record it, so keep these names as published.

Two safetensors builds of the transformers are supported, and they behave differently in memory:

	download, per branch	resident, per branch
Ideogram 4 (single file, int8) — int8_convrot	8.9 GB	8.9 GB, on every device
Ideogram 4 (single file, fp8) — fp8_scaled	8.6 GB	8.7 GB with fp8_compute or FP8 Storage; 17.3 GB with neither

Both branches are resident at once, so double those figures for the pair.

Which to pick

On an NVIDIA Ada card (RTX 40-series) or newer, with fp8_compute enabled, take the fp8 build: the two are a wash on memory, and fp8 is the faster one because its weights stay quantized and run on the fp8 tensor cores. Measured at 1024px on a 4090, 12 steps: 35.6 s for the fp8 pair against 45.7 s for the int8 pair.

Without the fp8 matmul, the fp8 build still works — through FP8 Storage. That setting keeps the file’s own fp8 weights and per-tensor scales instead of expanding them, and installation switches it on for these files by itself. Measured on a 4090 with fp8_compute off, 1024px: 40.6 s, 22.9 GB peak, 8.7 GB resident per branch — against 45.7 s for the int8 pair. With neither the matmul nor Storage the weights are expanded to bf16 on load, 17.3 GB per branch, and a 24 GB card runs out of memory during the first step.

Use int8 where FP8 Storage is not available. It requires a CUDA or Intel XPU device; on anything else the fp8 build falls back to the expanded path, while int8 keeps its stored codes and dequantizes them per forward on any device with no setting to turn on. The int8 timings above are that dequantizing path; int8 Compute runs the int8 build’s convrot layers on the int8 tensor cores of an NVIDIA GPU instead (not measured on Ideogram 4).

On a 24 GB NVIDIA card without the fp8 matmul (RTX 30-series), the int8 pair plus the 8B encoder still adds up to more than the card holds, so the bundled nf4 build or a GGUF pair is the smaller option there.

GGUF

Community GGUF conversions of the same two transformers load too, and they are the smallest builds. The weights stay packed in memory and are unpacked layer by layer during generation, on every device, so the download size is about the resident size. Three pairs are available as starter models, each of which installs its unconditional branch, the Qwen3-VL 8B encoder and the VAE with it:

	download, per branch	1024px, 12 steps, 4090
Ideogram 4 (GGUF, Q4_0) — molbal/ideogram-4-gguf	5.6 GB	27.9 s
Ideogram 4 (GGUF, Q5_K) — rectangleworm/ideogram-4-gguf	6.4 GB	32.2 s
Ideogram 4 (GGUF, Q5_1) — molbal/ideogram-4-gguf	7.3 GB	not measured

For comparison, the fp8 single-file pair took 37–38 s on the same card. Both GGUF pairs stay fully on the GPU next to the encoder (5.3 and 6.0 GB per branch), where the fp8 pair has to stream part of its second branch. Q5_K is the closer of the two to the fp8 build’s images.

Pick the model and the unconditional branch in Components exactly as for the safetensors builds. Two things are different:

• The branch comes from the filename alone. No published GGUF records which branch it holds, so a file whose name contains unconditional or uncond installs as the unconditional branch and anything else as the conditional one. Keep the published names; to fix a renamed file, remove the model, give the file its published name back and install it again.
• Other GGUF repositories of Ideogram 4 (for example leejet’s or stduhpf’s) load as well. IQ4_NL files work but are unpacked on the CPU at every step, which is much slower. Q8_0 is not offered as a starter: at about 10.1 GB per branch it is larger than the fp8 build.

Memory use during generation

Ideogram 4 keeps both transformer branches loaded for the whole generation. With the single-file builds on a CUDA or ROCm GPU (with partial loading on, the default), InvokeAI checks whether the pair fits next to the working memory a generation needs. If it does not, it keeps only part of the second branch on the GPU and streams the rest in each step. On a 24 GB card with the fp8 pair this keeps about 2.4 GB free instead of 1.2 GB. The bundled nf4 and fp8 folders are not affected. Three things follow:

• A streamed layer computes on a slightly different path, so images at the same seed can differ from those generated with both branches fully on the GPU.
• If generations still run out of memory, raise device_working_mem_gb in invokeai.yaml (for example to 8).
• If you set max_cache_vram_gb, InvokeAI does not limit the second branch this way, because the cache already plans from that limit.

Prompting Ideogram 4

When an Ideogram 4 model is selected, Invoke builds the structured JSON prompt automatically:

• The positive prompt becomes the overall scene description.
• Each enabled Regional Guidance layer on the Canvas contributes one object element. The layer’s Positive prompt describes it, and its box is the rectangle around everything painted on the layer inside the generation frame. The shape does not matter, and separate painted areas on one layer share one box. A layer without a positive prompt is left out.
• To drive the model directly, paste a raw JSON object into the prompt box — anything starting with { is passed through unchanged, and regional guidance layers are ignored.

When a layer with a positive prompt has paint inside the generation frame, the main prompt cannot be blank: Invoke is disabled with Ideogram 4 needs a prompt to place regional guidance in its layout. Enter a prompt or disable the regional guidance layers. Every region is an object, so the layer offers no Region type. Regional negative prompts, auto-negative and regional reference images are not used with Ideogram 4; the layer hides its negative prompt and auto-negative controls.

The caption is built when the generation runs, so dynamic prompts and batches vary the description inside it. The exact JSON that was encoded is saved in the image’s metadata as ideogram4_caption; recalling the image restores the prompt you typed.

No negative prompt

Ideogram 4 does not use a negative prompt — it has a dedicated unconditional branch instead, so the negative prompt box has no effect.

Generation settings

• Sampler Preset — the primary quality/speed control. Quality (48 steps), Default (20 steps), and Turbo (12 steps) each bundle a step count, a guidance schedule, and the schedule shift.
• Advanced overrides (all optional, leave on Auto to use the preset’s values): Steps, Guidance Scale, Schedule Shift (mu), and a Color Palette that biases the generated colors.

Built-in safety filter

Ideogram 4 ships with a content safety filter baked into the released model weights. When it triggers, the model outputs a placeholder image reading “Image blocked by safety filter” instead of your image. This is the model’s own filter — it is not Invoke’s NSFW checker (it fires even with the NSFW checker off) and cannot be disabled from Invoke.

The filter is known to false-positive on completely benign prompts, and the quantized builds can trigger it more readily. Invoke always sends the model a structured JSON prompt, which tends to trip the filter less than plain text; if you hit it, rephrasing or adjusting the prompt usually clears it.

LoRA

Ideogram 4 LoRAs are supported in the layouts trainers publish them in: ai-toolkit and the LoRAs on Civitai (diffusion_model. prefix, fused attention), including LoKR, and the diffusers training script (transformer. prefix, split attention projections, which Invoke fuses), as single files or, for a diffusers repository, as a folder holding pytorch_lora_weights.safetensors. Kohya-flattened names (lora_unet__layers_0_feed_forward_w1) are recognized for the block modules only; a flattened file that also trains input_proj, final_layer or the other top-level modules is not recognized. DoRA files, and files with layers that match no Ideogram 4 transformer module, are refused when you install them; LoHA files are not recognized. Add them in the Guidance section like any other concept.

• Both branches. Every published Ideogram 4 LoRA is one set of weights trained on the conditional model. Invoke applies it to the unconditional branch as well, the way ai-toolkit samples: applied to the conditional branch alone, guidance amplifies the LoRA’s effect, and style LoRAs come out oversaturated. In a workflow, connect the LoRA loader to the denoise node’s Transformer input only; LoRAs on Transformer (Unconditional) are refused.
• Quantized builds. On the GGUF files, the bundled fp8 and nf4 folders, the int8 single files, and the scaled-fp8 single files when they stay in fp8 (with fp8_compute or FP8 Storage), the LoRA is applied alongside the weights instead of being merged into them. It then stays in VRAM for the whole generation, and InvokeAI reserves room for it. The bundled fp8 folder is the exception: its weights always stay fully on the GPU, so the LoRA’s room comes out of what the generation has. On a 24 GB card that costs nothing measurable at 1024×1024; above that the folder already runs at the card’s limit without a LoRA, and a large LoRA makes that tighter. A LoKR is applied in weight space on these builds and is noticeably slower than a plain LoRA of the same size (on the GGUF Q4_0 pair at 1024×1024 and 20 steps, about 70 s per image against 40 s).
• Turbo LoRAs. Few-step LoRAs such as TurboTime work, but Invoke’s sampler presets always end with a polish step at a fixed guidance and keep the unconditional branch, so they do not run as the guidance-free model those LoRAs aim for.
• Unconditional LoRA. A LoRA meant to stand in for the unconditional transformer installs as an ordinary LoRA; that replacement role is not supported.

Earlier versions identified Ideogram 4 LoRAs as Z-Image LoRAs. Select such a LoRA in the Model Manager and use Re-identify to fix it.