# 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](/configuration/invokeai-yaml/) before installing. Two bundled builds are available:

- [`ideogram-ai/ideogram-4-nf4`](https://huggingface.co/ideogram-ai/ideogram-4-nf4) — nf4 quantized, **CUDA only**, fits in 24 GB VRAM. Recommended for NVIDIA GPUs.
- [`ideogram-ai/ideogram-4-fp8`](https://huggingface.co/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`](https://huggingface.co/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](/users-guide/models/local-models/krea-2/#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.

:::note[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](/configuration/optimization/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](#installing-ideogram-4) or a [GGUF](#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`](https://huggingface.co/molbal/ideogram-4-gguf) | 5.6 GB | 27.9 s |
| **Ideogram 4 (GGUF, Q5_K)** — [`rectangleworm/ideogram-4-gguf`](https://huggingface.co/rectangleworm/ideogram-4-gguf) | 6.4 GB | 32.2 s |
| **Ideogram 4 (GGUF, Q5_1)** — [`molbal/ideogram-4-gguf`](https://huggingface.co/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.

:::note[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.

:::caution[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.