A Stable Diffusion server on AUTOMATIC1111 or Forge, sized by VRAM

Card memory per model family

VRAM decides which checkpoints load at all; the GPU's speed only decides how long each image takes. These are the figures the projects and Stability AI publish, not benchmarks of ours.

Resolution, batch size, LoRAs, ControlNet models and upscalers all sit in the same memory, so treat each row as a floor. AUTOMATIC1111's own install notes say the VRAM needed depends largely on the image resolution you ask for.

Running short of VRAM

Both WebUIs trade speed for memory rather than refusing outright. In AUTOMATIC1111, --medvram splits the model into its text encoder, VAE and UNet and keeps only one on the card at a time, which the wiki says costs a little speed. --medvram-sdxl applies that only when an SDXL checkpoint is loaded. --lowvram goes further, splitting the UNet into modules, and the wiki calls the effect on performance devastating.

Forge manages memory itself and exposes a GPU Weight slider for Flux. Its author warns that setting it too high is the cause of most slowdowns. On 6, 8 and 12 GB cards the tutorial reports NF4 as significantly faster than FP8, and only slightly faster on cards above 16 GB.

Offloading moves model parts into system RAM, so a small card leans hard on host memory. Size the RAM with the card, not after it.

AUTOMATIC1111 or Forge

• AUTOMATIC1111 1.10 is the reference WebUI. Its 1.10 release notes add Stable Diffusion 3 support, with the T5 text model off by default. Forge's README describes the original WebUI as almost static now.
• Forge is built on AUTOMATIC1111 1.10.1, keeps its interface, and adds the memory manager plus native Flux support in NF4 and GGUF quantisations.
• Node graphs are a different tool. If you want saved, branching workflows instead of tabs, read the ComfyUI GPU server page; the card sizing above carries over.

Installing on Ubuntu

1. Install the NVIDIA driver and confirm nvidia-smi lists the card. You choose the driver and CUDA release; nothing upgrades it under you.
2. Create an ordinary user. webui.sh refuses to run as root unless forced, and it should not run as root on a machine with a public address.
3. Install the dependencies from the README and clone the repository. For Forge, clone https://github.com/lllyasviel/stable-diffusion-webui-forge.git instead; the README says it installs the same way.
4. On Ubuntu 24.04 the system Python is too new for the WebUI: the README has you add Python 3.11 (or 3.10) from the deadsnakes PPA, install it together with its venv package (sudo apt install python3.11 python3.11-venv), and set python_cmd="python3.11" in webui-user.sh.
5. Only then run ./webui.sh. The first start builds a venv and downloads torch; put checkpoints in models/Stable-diffusion.

sudo apt install wget git python3 python3-venv libgl1 libglib2.0-0
# Ubuntu 24.04: add Python 3.11 first
sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt update
sudo apt install python3.11 python3.11-venv
git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui
cd stable-diffusion-webui
echo 'python_cmd="python3.11"' >> webui-user.sh
./webui.sh

Reaching the UI without opening it

By default the WebUI binds to localhost on port 7860. Leave it there and forward the port over SSH from your workstation with ssh -N -L 7860:127.0.0.1:7860 sd@your-server, then open http://127.0.0.1:7860 locally. Nothing new is exposed, and SSH already authenticates you.

If several people need it, --listen binds Gradio to 0.0.0.0. Pair it with --gradio-auth-path pointing at a file of user:password pairs, readable only by the WebUI user (chmod 600), --tls-keyfile and --tls-certfile so those passwords do not cross the network in clear, and a firewall rule that admits only your office addresses. --api adds the REST API; give it --api-auth too.

export COMMANDLINE_ARGS="--listen --port 7860 --gradio-auth-path /home/sd/webui-auth.txt --tls-keyfile /home/sd/key.pem --tls-certfile /home/sd/cert.pem"

An extension is arbitrary code. The wiki says installing one is equivalent to permitting arbitrary code execution, so the WebUI switches off extension installs from the browser whenever --listen, --share, --ngrok or --server-name is set. --enable-insecure-extension-access turns them back on; the wiki asks you to use it only when needed and remove it afterwards. Install extensions over SSH instead, and leave --allow-code off.

What the machine gives the workload

On our GPU dedicated servers the card sits in a PCIe slot of a machine rented to one account and is passed straight through to your operating system: no vGPU profile, no MIG partition, no time-slicing. Every core, all the memory, both disks and root are yours, with an iLO or iDRAC console on a separate management network for when a driver change takes the network down.

The catalogue spans 8 GB GeForce and Quadro cards for SD 1.x and SDXL, 12 and 16 GB cards for SD 3.5 Medium and quantised Flux, and 24 GB and 48 GB cards for FP8 Flux with room for ControlNet and upscaling. GeForce parts carry no ECC, which matters little for image generation where a flipped bit means one bad image. Checkpoints are large downloads; the port is unmetered, so pulling a dozen of them costs nothing extra.

A GPU machine already racked and taken as it stands is live about 30 minutes after the order is approved; a server built to order with the card you pick takes 4 to 24 hours. Pick the city nearest the people using the UI, New York, Miami, San Francisco, Amsterdam or Bucharest. Terms are monthly with no contract.

When this is the wrong machine

For a few images a week, a whole monthly server is more than the job needs. For a public image service with many users, a WebUI is the wrong front end: it is built for one operator or a small team behind a password. Training large models from scratch is a multi-GPU question rather than a WebUI one.