Back to the tools

Media generation

Forge

Forge is a browser-driven build of Stable Diffusion WebUI: it loads checkpoints, LoRAs and extensions locally, with its own memory management and faster inference.

3 min read

Forge is a widely used variant of Stable Diffusion WebUI: a Gradio interface for diffusion models that runs in the browser but executes on our own machine.

Its documentation describes it as a platform on top of Stable Diffusion WebUI, built to ease development, optimize resource management and speed up inference. The name refers to Minecraft Forge, that is, the intention to become the extended build of SD WebUI.

How it relates to the original WebUI

Forge is based on Stable Diffusion WebUI 1.10.1 and syncs with the original project roughly every 90 days or on important fixes. The interface is familiar, while memory management and the internals of model loading differ.

  • Text to image, image to image, inpainting, outpainting, upscaling and variations are all present, plus parameter sweeps through the X/Y/Z plot.
  • Generation parameters are written into the output file metadata, so an earlier image can be dragged back to restore its settings.
  • A HTTP API exposes the text to image and image to image endpoints, which lets an n8n workflow trigger a generation.
  • Its status table lists integrated extensions, ControlNets, IP-Adapter and FreeU as generally working, while Forge also calls itself a project under construction.

Loading models, LoRAs and VAEs

Models are loaded from the file system, so the directory layout matters.

  • Checkpoints go into models/Stable-diffusion and are picked from the dropdown at the top of the UI, so reloading them needs no service restart.
  • LoRAs belong in models/Lora and are enabled from the prompt with the <lora:filename:multiplier> notation; that text only enables the network, is removed from the prompt afterwards and cannot be used in the negative prompt.
  • Embeddings (textual inversion) live in the embeddings directory and are invoked by filename, while the VAE is selected from models/VAE. A card panel lists the installed extra networks for one-click insertion.

Forge natively supports quantized GGUF and NF4 models with LoRAs, and adds a GPU weight slider plus offload location and method settings. LoRA behaviour on quantized models has its own guide.

Extensions and compatibility

Extensions live in the extensions directory, each in its own subdirectory, and can be installed with git clone or from the Extensions tab.

  • Installing an extension is effectively permitting arbitrary code execution, so the WebUI blocks it whenever the interface is reachable remotely, as with the -share or -listen flags. The block can be lifted, but the documentation advises against keeping that enabled.
  • Forge does not run every extension unchanged: the project keeps a list of which extensions work and which have a recommended replacement, and its status table lists open items such as ControlNet Union support.

Hardware and licences

  • Video memory needs depend on resolution and model; the original WebUI documentation mentions 4 GB cards for 512x512 images behind the -lowvram and -medvram flags, at the cost of performance.
  • Forge’s memory management is tunable, but the project’s own experience is that a GPU weight set too high is a frequent source of errors.
  • Installer packages ship as CUDA and PyTorch pairs, and for the combination marked fastest the documentation notes that xformers may not work.
  • The code is licensed under AGPL-3.0; model weights are separate, for example the SDXL base model under the CreativeML Open RAIL++-M terms.
  • By default the UI listens on a local port without a password, so on a public server it belongs behind authentication and an nginx reverse proxy.

Further reading

At CyberElectro Forge runs in an isolated Docker container next to LM Studio on the same machine.

Tags
  • image generation
  • diffusion
  • LoRA
  • GPU
  • self-hosted