Fizgig pairs LoRA training with a per-block repair workbench

The workbench takes LoRAs from other trainers

Most of what Fizgig does after a training run operates on files it did not produce. Each workbench tool works on your own runs or on any LoRA you have downloaded, and it loads kohya, PEFT, OneTrainer, AI-Toolkit and LyCORIS LoRAs, saving `.safetensors` that drop straight into ComfyUI. That reframes what the project is. A LoRA trainer competes on its sampler and its presets. A workbench competes on whether it can take a stranger's checkpoint and do something useful with it, and Repair Studio does this by putting a live slider on every block and baking an exact result, LoRA the Explorer mutates a LoRA into four variants for you to pick from, the Profiler produces a colour-coded per-block report that Repair Studio then reads inline, and Extract shrinks any LoRA to a lower rank. The tools hand off to each other, so the Profiler output is not a report you read and discard, it is a control panel you act on.

Four models with four different floors and four different gaps

The support table is the most honest page in the project, because the cells are full of dashes and the word coming. Flux 2 Klein 9B trains LoRAs on photos down to a 10 GB card, but LoKR is marked with a dash, and slider, edit and full fine-tune are all listed as coming. Krea 2 at 12.9B is the widest: LoRA, LoKR, slider LoRAs and experimental full fine-tune on an 8 GB card, the smallest floor of the four. MiniMax H3 at 33B trains on photos, video clips, sound and voice, needs 16 GB, and marks its slider support as coming. Qwen Image 2.1 covers photos with LoRA, LoKR, slider and edit LoRAs and experimental full fine-tune at 10 GB. Read across the row and the pattern is clear: the newest model in the list is the least complete, and the feature that most differentiates the project, slider LoRAs, exists on two of the four.

When a preview will not fit, training keeps going

Memory is handled by planning rather than by refusing. Precision, block swap and preview sizing are chosen against free VRAM, and the documented behaviour when a preview cannot fit is that training keeps going. That is a deliberate trade with a visible cost. The run survives, and you lose the visual feedback that tells you whether epoch 6 is better than epoch 4, which is exactly the signal LoRA Royale exists to provide by rendering every epoch on one seed with a crossfade. A trainer that stops rather than continuing would force a choice between finishing and watching. Fizgig makes that choice for you, in the direction of finishing. The sampling aids are sized the same way: a gallery that scores likeness live and a run visualiser to scrub epochs are conveniences on top of a run that is expected to continue whether or not those render.

The dependency pins carry written-up scar tissue

`requirements.txt` reads like a post-mortem. `safetensors` is pinned to 0.5.3 with a comment recording that 0.4.5 had no cp313 wheel, which forced a Rust source build on Python 3.13 on cold machines. The hqq pin to 0.2.8.post1 carries a warning not to install that line by hand: its `setup.py` spawns an optional CUDA-kernel build during `egg_info` unless `DISABLE_CUDA=1` is in the environment, and every Fizgig install path sets that variable, `uv_install_deps.py` for CUDA and docker, the ROCm scripts inline. The torch.compile speedup needs triton, which on Windows also needs the MSVC C++ Build Tools, described as not pip-installable, so the installer and update scripts check for them and print the direct download link. When triton is missing or incompatible, compile bails to eager with a console note and training still runs. The core of the pinned stack looks like this:

--extra-index-url https://download.pytorch.org/whl/cu128
torch==2.10.0
torchvision==0.25.0
accelerate==1.6.0
diffusers==0.32.1
transformers==4.57.6
bitsandbytes==0.48.2

The visible README does not carry an install command, and the install section sits past the truncation point, so the dependency spec is the only installation detail available in text. The repository root is where the actual installers live, with `install_fizgig.py` and `install_fizgig.bat` for CUDA and `install_fizgig_rocm.bat` and `install_fizgig_rocm.sh` for AMD, alongside `uv_install_deps.py`, `detect_gpu.py` and `detect_gpu_linux.py`.

An unpinned triton produced a hang with no log line

That last graceful degradation exists because of a specific failure, and the comment says so. triton is pinned to what torch 2.10 pairs with, noted as 3.6 on Linux with 3.5.1 field-proven, and the reason is written in the file: unpinned, a fresh install picked up triton-windows 3.8, built for a newer torch, and Krea 2 previews hung inside torch.compile with no log line at all, reported from a YouTube video on 2026-09-05. A preview that hangs silently is a bad failure shape for a training tool, because the run looks busy while producing nothing a user can see. The response was to pin the dependency rather than to add a watchdog, and to keep the eager fallback for the case where triton cannot be made to work at all. The rest of the stack is pinned the same way, with torch at 2.10.0, torchvision at 0.25.0, transformers at 4.57.6 and an extra index URL pointing at a cu128 build.

Two features are claimed as unique, with no comparison attached

Two bullets end with the same sentence, that no other trainer does this, and neither is backed by a comparison in the documentation. The first is Context LoRA, which trains on top of a frozen, active LoRA so the two coexist, the stated use being a face on a style or an outfit on a character. Mechanically it is stacking a trainable adapter over an inert one, which is a coherent thing to want and a narrow one. The second is live dataset curation, offered on Krea 2 and Qwen Image 2.1 only. The trainer follows each image's loss while training and intervenes when an image stops teaching the model, throttling it, recaptioning it, and as a last resort setting it aside, plus reporting when the whole run has plateaued. Whether any other trainer does this is not something the project demonstrates, so treat the claim as positioning. The mechanism itself is the interesting part and does not depend on the claim.

Slider LoRAs and the Ultra mode that limits which blocks train

A slider LoRA is one whose strength is a dial between two looks, sad to happy or cool to warm, trained either from a few photo pairs or from a few words, and it exists on Krea 2 and Qwen Image 2.1. Krea 2's Ultra mode trains the composition blocks only, and the stated reason is that the dial then holds up at much higher strengths. The same paragraph carries its own limit: Ultra works best for sliders trained from prompts, and with photo pairs when the change is compositional. A dial that degrades above a certain strength is a real constraint on how the result gets used, since a slider nobody can push past 0.6 is closer to a preset than a control. Edit LoRAs, Qwen only, take a different shape again: pairs of original and edited photos teach a grade, a look or a relight that then applies to any photo. Adaptive LR, EMA and pause-and-resume with a training queue fill out the rest of the training side.

The extract claim has no benchmark, and the release cadence is hourly

One claim in the overview has no measurement attached: that a LoRA extracted from a fine-tune came out better than one trained directly at the same rank. It is the argument for LoKR and for full fine-tuning, and it is also what makes Extract matter beyond file size, since the tool shrinks any LoRA to a lower rank. No benchmark, dataset or evaluation protocol appears with it, so there is nothing to check the claim against, and the Extract feature's own description stays on the safe side of the line by talking about rank rather than quality. Maintenance tells a different story. The last push to master was on 2026-10-01, the day before this was written, and three releases landed within two days: v6.8.1 on 2026-10-01, v6.8.0 as an explicit beta the hour before it, and v6.7.2 on 2026-09-30. Licence is Apache-2.0, and there is no homepage set, so the repository, the release notes under `docs/` and the changelog are where the record lives.

Editorial conclusion

Adopt Fizgig if you already hold LoRAs from other trainers and want to repair or shrink them, since the workbench tools accept downloaded kohya, PEFT, OneTrainer, AI-Toolkit and LyCORIS files rather than only runs you made here. Do not adopt it expecting uniform coverage: LoKR is absent for Klein 9B, slider and edit LoRAs are marked coming for two of the four models, and full fine-tuning is labelled experimental everywhere it exists. Verify first that your card clears the minimum for the specific model, since those run from 8 GB on Krea 2 to 16 GB on MiniMax H3.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. shootthesound/Fizgig on GitHub