InvokeAI

Invoke's model management system handles the full lifecycle of models through three major subsystems:

1. Model Identification (configs/): Determines the model's type, architecture, format, and metadata during installation.
2. Model Loading (load/): Loads models from disk into memory for inference.
3. Model Running: Executes inference on loaded models. This is typically implemented in architecture-specific code adjacent to model_manager/ and is executed within nodes in the graph execution system.

The system is extensible, supporting various architectures, formats, and quantization schemes.

The Gallery Panel allows you to review and organize generated images, videos, and uploaded assets using Boards.

• Uncategorized Board: Always present by default.
• Custom Boards: Create new boards using the Add Board (+) button to group specific projects.
• Polymorphic Boards: Images and videos coexist on the same board and are sorted by creation time.
• Board Tabs: Each board contains two tabs:
  1. Images/Videos: Generated media shown interleaved by time.
  2. Assets: External images uploaded for use as Image Prompts or in Image-to-Image workflows.

You can rename a board by clicking its name under the thumbnail and typing a new name, or move images between boards via drag-and-drop onto board thumbnails.

PatchMatch is an algorithm used to infill images, specifically serving as a high-quality first step for outpainting (filling in transparent areas using AI).

Unlike other infill methods like LaMA, cv2 infill, or random tiles, PatchMatch uses the existing image data around the target area as a reference to generate new data with similar character and quality. This makes the initial infill more coherent before the AI generation step begins.

Performance Note: PatchMatch is CPU-bound. Execution time increases proportionally with the size of the infill area. Expect noticeable slowdowns for areas around 512x512 pixels, and several seconds for 1024x1024 pixels.

The InvokeAI Canvas is a complex feature built using KonvaJS (native, not React bindings) to render a drawing environment. It supports layers, drawing, erasing, undo/redo, exporting, and both frontend and backend filters.

The architecture is based on a hierarchy of plain-JS classes called Modules, all of which inherit from CanvasModuleBase. These modules encapsulate specific functionalities and can be singletons (like the CanvasManager or CanvasToolModule) or non-singletons (like individual object renderers).

Understanding the scope of a .invk file is critical for managing project portability.

| Excluded | | The actual model, LoRA, or embedding files (only references are saved) | | Workflow editor state | | Gallery boards or images outside the specific canvas |

Each external model has specific capabilities that dictate how it behaves in the Invoke UI. Invoke dynamically adjusts the parameters panel based on what the selected model supports.

Common capability constraints include:

• Generation Modes: Supported modes (e.g., txt2img, img2img). Note that Inpainting is not currently supported by external providers.
• Reference Images: Whether the model accepts reference images and the maximum count allowed.
• Dimensions: Allowed aspect ratios and resolutions.
• Parameters: Support for negative prompts, seeds, or batch sizes greater than 1.

If a specific setting or field is missing from your parameters panel, it is because the currently selected external model does not support that feature.

InvokeAI supports two primary methods for expanding dynamic prompts, though the availability of the toggle depends on your interface:

• Combinatorial Expansion: Systematically walks through every possible combination of the provided groups until the Max Prompts limit is reached.
• Random Expansion: Samples prompt variations randomly from the possible set. This mode can be made repeatable by using a specific seed.

Note on UI availability:

• The linear UI currently uses combinatorial expansion for its positive prompt preview and does not expose a manual switch between these modes.
• Node and backend contexts expose both random and combinatorial modes more explicitly.

The CollectInvocation is used to group items from iterators.

Preparation and Hydration:

• Grouping: The materializer groups prepared parent execution nodes by their iteration path. It creates one collector execution node per group.
• Hydration: During _prepare_inputs(), the runtime gathers materialized incoming item values into a collection.
• Ordering: Inputs are sorted by iteration path to ensure collected results are stable across expanded iterations.
• Merging: Incoming collection values are merged first, and then incoming item values are appended.

InvokeAI distinguishes between two roles in Multi-User mode:

Regular User

• Capabilities: Generate images (Linear, Canvas, Upscale, Workflows), manage personal image boards, create/save/load personal workflows, customize UI preferences (hotkeys, canvas settings, generation defaults), and view available models (read-only).
• Restrictions: Cannot install/delete/modify models, cannot manage user accounts, cannot access system configuration, and cannot view or modify other users' private boards, images, or workflows. They see redacted details for other users' jobs in the generation queue.

Administrator

• Capabilities: All Regular User capabilities, plus full model management (add, delete, configure), user account management, full access to all users' generation queues, boards, images, and workflows, and access to system configuration.

Models are instantiated from disk into memory using Loader Classes located in load/model_loaders/.

Loader Implementation: Loaders are registered using the @ModelLoaderRegistry.register(base=..., type=..., format=...) decorator. They must implement _load_model(self, config: AnyModelConfig, submodel_type: Optional[SubModelType]) -> AnyModel to load weights and return the in-memory representation.

Model Cache: The ModelCache manages models in memory subject to RAM and VRAM limits. It handles:

• Moving models between CPU (storage device) and GPU (execution device).
• LRU (Least Recently Used) eviction for RAM.
• Smallest-first offload for VRAM.
• Partial loading for large models on CUDA.
• Thread-safe operations via locks.