Add Fizgig LoRA training studio package

[e-nord]

Summary

Adds Fizgig as a new package. Fizgig is a "train · fine-tune · repair · explore" workbench for generative image models. Its stated focus is getting LoRA training working on consumer GPUs, fixing broken LoRAs without retraining, and making variations in seconds.

Upstream: https://github.com/shootthesound/Fizgig (Apache-2.0, tagged semver releases)

Why it fits Stability Matrix

• Focus on newer models: Flux 2 Klein 9B, Krea 2, MiniMax H3 and Qwen Image 2.1 (LoRA training on all of them, plus LoKR and experimental full fine-tuning on some). Minimum VRAM runs from roughly 8 to 16 GB depending on the model.
• Fast LoRA workflow: adaptive LR, weight averaging, context LoRA, pause/resume, and dataset curation with loss watch.
• Wizard-style UI: numbered tabs (Start → Image Prep → Captions → Samples → Training) that walk users from dataset to a running training job.
• More than training: Repair Studio (block-level sliders), LoRA the Explorer, LoRA Royale (epoch comparison and export), Profiler, and Extract (rank reduction).
• Popularity: about 445 GitHub stars and 42 forks since the repo was created in April 2026.

Scope of changes

• New Fizgig package with appropriately integrated references into SM. It's a Tkinter desktop app, so it's similar to OneTrainer.
• Docs: README, supported-packages and hardware-support entries.
• No changes to shared or framework code.

Notes on the less obvious choices:

• Visual Studio Build Tools prerequisite (VcBuildTools). This lets triton / torch.compile's inductor backend compile kernels on Windows, which Fizgig's Compile Blocks speedup needs. Among the trainers, only Fizgig requires it (ComfyZluda is the only other package that does), and it makes the first install take a bit longer because the VS bootstrapper runs. Open to making it an option to make this explicitly opt-in.
• Launches lora_trainer_gui.py directly, not launch.pyw. launch.pyw re-spawns itself under pythonw.exe and exits, which would orphan the GUI and break console output and Stop.
• DISABLE_CUDA=1 during the requirements install. Without it, hqq's sdist tries to build CUDA kernels. Upstream's requirements.txt warns about this.
• Pinned torch lines are skipped from requirements.txt, so torch is installed once, from the cu128 index, instead of first pulling a multi-GB PyPI build.
• cu128 index, because torch 2.10 has no cu130 wheels.
• Releases are tracked (ShouldIgnoreReleases stays false), unlike the other trainers, because Fizgig publishes real semver releases.
• Shared folders default to None, like the other trainers. Symlink is opt-in through Shared Model Strategy and junctions only output_loras into the shared Lora folder, so new LoRAs show up in ComfyUI and other packages. Model weights aren't shared, because Fizgig puts every weight type into a single flat models/ directory.

Testing

• Install tested on Windows 11 with an NVIDIA GPU: the solution builds cleanly, and I installed Fizgig through the SM UI on a dev build. Ran and used it.
• ROCm is out of scope. Fizgig supports AMD GPUs through ROCm in some form, but I don't have hardware to test it.
• Currently taking standard Linux support claim at face value from the upstream.

Questions

I'm not sure whether you're accepting PRs for new packages. If not, no worries. I'm happy to adjust anything as well.

[NeuralFault]

The AMD setup seems pretty standard from the upstream package's documentation.

StabilityMatrix's Windows ROCm helper framework uses the current stable production ROCm 10 repository instead of the old nightlies (no longer getting updated in lieu of new permanent repository)

Plus the custom Win-rocm bitsandbytes wheel from 0xDELUXA.
So pretty much in-line with other packages that have AMD support wired in on Windows for StabilityMatrix.
I can assist in wiring this up if need be, or do it post-merge.

Linux can use upstream pytorch as its rocm 7.14 now. Can be set up with RocmIndex = "rocm7.14" in the PipInstallConfig similar to the ComfyUI package config. Big blocker for it is that the default PyTorch version would have to be set to 2.14 for AMD on Linux for this. So this route may not be the optimal one as Fizgig upstream docs instruct on using AMD's official repository.

The ROCm helper will handle both Windows and Linux soon, so can then wire the package to it and have it pull the Pytorch/ROCm installs from AMD's official repo as per upstream package instructions.

But overall looks to be very doable. Can just be Nvidia/CUDA only in-app at the start and I can work in the AMD support and testing myself afterwards if you're not sure on it yourself.

[mohnjiles]

Thanks for putting this together! Fizgig looks like a great addition 😁 A couple of installer details to sort out before merging:

• I’m fine with including VS Build Tools where they help, but can we make it clear before installation that they’re installed system-wide and remain after uninstalling Fizgig?
• Could we install the intended CUDA Torch build before the remaining requirements, keeping the relevant constraints? Even with the direct Torch requirements filtered out, accelerate can pull it in transitively, which looks like it could cause an extra download/reinstall

Starting with Windows/NVIDIA seems reasonable, with Linux validation and NeuralFault’s offered AMD work tracked separately. Thanks again! :3

[e-nord]

Sure thing, there's now a VS Build tools warning in the pre-defined spot for disclaimers and Torch is installed first via existing pre-pip install args if that suffices.

Also smoke tested an install and started it up in WSL2 if that counts enough for Linux XD

I originally had RoCM in scope and a separate branch for it that 'looks' correct. But since I can't formally test/validate, should I just push it as a draft PR and leave it hanging for NeuralFault to finish out with the Windows and eventual Linux-side RoCM helper support?

[NeuralFault]

I originally had RoCM in scope and a separate branch for it that 'looks' correct. But since I can't formally test/validate, should I just push it as a draft PR and leave it hanging for NeuralFault to finish out with the Windows and eventual Linux-side RoCM helper support?

Can just have the CUDA support in place and I can work in the ROCm afterwards post-merge.

[mohnjiles]

Thanks for the quick turnaround on the last round! I compared the installer against upstream v6.8.3 and found two things worth sorting out, both inline. The rest are small nits, take or leave them :3

[ionite34]

Looks great, thanks! It slots into the existing package seams cleanly. A few things I liked:

• Torch goes first with pins read straight from upstream's requirements, so they can't drift.
• The lora_trainer_gui.py launch has its reason written down.
• The shared-folder decision is documented. 🐺

One optional follow-up, not blocking: user pip overrides aren't applied to PrePipInstallArgs in StandardPipInstallProcessAsync, so Fizgig's real torch install can't be overridden. A torch override would only change the second, requirements step. It's probably worth fixing in the shared code at some point.

[mohnjiles]

Thank you!