Train an image-model LoRA on a cloud GPU

The trainer I reach for first is Ostris's AI Toolkit, because it ships a FLUX.1-dev LoRA config for 24 GB cards and DeployGPU's smallest VM has 48 GB, so a first FLUX LoRA is a folder of captioned images, one YAML file and one command. kohya_ss is the other common choice, and it comes with a web GUI that needs more care on a rented VM. Before either, read the license of the base model, because the weights of the two FLUX [dev] models come under non-commercial licenses.

Pick the base model and the GPU: 48 GB for FLUX.1, 80 GB for FLUX.2

The licenses and gating come from the Hub's model metadata and the sources are the AI Toolkit README, the kohya_ss LoRA guide and Hugging Face's FLUX.2 post, all checked 1 October 2026. That post also says LoRA fine-tuning of FLUX.2 is even harder than inference, and the AI Toolkit README gives no training figure for it, so treat 80 GB as the starting point for FLUX.2 [dev] and read the FLUX page first. On a 48 GB card the FLUX.1 pipeline has headroom, which you can spend on resolution or batch size once the first run works.

The license decides whether the LoRA can earn money

FLUX.1 [schnell] and FLUX.2 [klein] 4B are Apache-2.0 according to the Hub and the FLUX page, and SDXL carries the OpenRAIL++ license. The FLUX.1 [dev] and FLUX.2 [dev] repositories are gated, so accept the terms on each model page in a browser before the download works.

Prepare the dataset: images plus .txt captions

AI Toolkit's README describes the format: a folder of images with a text file of the same name beside each, so image2.jpg pairs with image2.txt. Only jpg, jpeg and png work, and the README says webp has issues. The text file holds only the caption, and a [trigger] placeholder in it is replaced by the trigger_word from your config. Images are never upscaled, they are downscaled into buckets, and you do not need to crop or resize them. Send the folder with rsync, as the transfer guide explains:

rsync -avP -e "ssh -p 22" ./dataset/ ubuntu@YOUR_VM_IP:~/dataset/

Install AI Toolkit on a plain GPU VM

Launch a plain GPU VM, which the dashboard labels Bare Metal, and use the SSH user for your provider: ubuntu on QuantaCloud and Hyperstack, Ubuntu with a capital U on Massed Compute, and root on Verda. These are the manual steps from the README, which asks for Python 3.10 or newer:

git clone https://github.com/ostris/ai-toolkit.git
cd ai-toolkit
python3 -m venv venv
source venv/bin/activate
pip3 install --no-cache-dir torch==2.13.0 torchvision==0.28.0 torchaudio==2.11.0 --index-url https://download.pytorch.org/whl/cu130
pip3 install -r requirements.txt

If python3 -m venv complains, run sudo apt-get install -y python3-venv first. The README pins a CUDA 13.0 build of PyTorch, which needs a driver whose CUDA Version in nvidia-smi is 13.0 or higher. If yours shows less, pick the matching index as the PyTorch install guide explains. The README also describes an experimental AI Toolkit Manager that sets up the environment for you. For the gated FLUX.1 [dev] download, create a token with read access and export it without echo:

read -rsp "Hugging Face token: " HF_TOKEN; export HF_TOKEN; echo

Configure the run and start it

cp config/examples/train_lora_flux_24gb.yaml config/my_lora.yml
nano config/my_lora.yml
python -u run.py config/my_lora.yml 2>&1 | tee train.log

Edit the name, the dataset path and, if you want one, the trigger word:

      trigger_word: "p3r5on"
      datasets:
        - folder_path: "/home/ubuntu/dataset"

The shipped config sets a rank of 16, a batch size of 1, adamw8bit at a learning rate of 1e-4, gradient checkpointing, 2000 steps, which its own comment calls a good range between 500 and 4000, and 8-bit quantization of the base model. It saves every 250 steps, keeps the last 4 saves, and writes sample images every 250 steps so you can judge progress by eye. The FLUX.1 [dev] model files total 33.74 GB per the FLUX page, so the first run starts with a long download. Run the command inside tmux, as keeping jobs running after you disconnect shows. The README says Ctrl-c stops training and the next run resumes from the last checkpoint, and that interrupting a save will likely corrupt that checkpoint. Copy checkpoints off the machine as they appear, as checkpoint and resume explains.

kohya_ss: the GUI route, kept private

git clone --recursive https://github.com/bmaltais/kohya_ss.git
cd kohya_ss
./gui-uv.sh --headless --listen 127.0.0.1 --server_port 7860

# On your laptop
ssh -N -L 7860:127.0.0.1:7860 ubuntu@YOUR_VM_IP

The kohya_ss Linux install page lists Python 3.10.9 or newer and below 3.13, and the NVIDIA CUDA Toolkit 12.8. Its README says to start with --headless on a remote machine, because native dialogs on the server can block training indefinitely. Its examples use --listen 0.0.0.0 and --inbrowser --share. On DeployGPU, leave those out. DeployGPU does not firewall VMs, so anything on 0.0.0.0 is on the internet, and the --share flag is described as sharing the Gradio UI. Open http://localhost:7860 while the tunnel runs, as the port forwarding guide explains. For SDXL, kohya_ss's guide says to set the maximum resolution to at least 1024x1024 and recommends --network_train_unet_only.

The AI Toolkit web UI at port 8675 needs the same care. Its README says it is reachable at your server's IP address, and it offers an AI_TOOLKIT_AUTH password. The command line path above has no server at all, so I use it. If you want the UI, set that password, run sudo ufw allow OpenSSH and sudo ufw enable, and reach it through a tunnel.

Save the LoRA before you stop

Pull the result to your own machine, or let the trainer push it for you with push_to_hub: true, an hf_repo_id and hf_private: true in the config's save section, which its comments describe. Use a token that can write to that one repository.

rsync -avP -e "ssh -p 22" ubuntu@YOUR_VM_IP:~/ai-toolkit/output/ ./output/

To try the LoRA, copy it into the loras folder of a ComfyUI deployment, as the ComfyUI models guide shows. The ComfyUI template gives you a browser UI to test it in.

Six things that go wrong