Fizgig: a LoRA workbench for Klein 9B, Krea 2 and MiniMax H3

Which problem Fizgig actually addresses

Training a LoRA for a large image or video model is usually a stack of separate scripts: one to prepare a dataset, one to caption, one to train, one to test the result. Fizgig collapses that into a single workbench aimed at three named model families, Flux 2 Klein 9B, Krea 2 and MiniMax H3. The README describes it as a "train · fine-tune · repair · explore workbench" and lists four verbs that map to four jobs: train a new adapter, fine-tune the base model itself, repair an adapter that already exists, and extract or remix one into variations.

The repair path is the least common feature in this space. Most training tools assume the adapter is correct and the dataset is the problem. Fizgig instead exposes the internals of an existing LoRA so you can see what individual blocks do, which the README frames around MiniMax H3: a LoRA has 52 blocks, and the repair studio renders each one switched off so you can watch its effect on a clip. That is a debugging tool for people who already have a broken or over-trained adapter and would rather inspect it than retrain from scratch.

The audience is narrow on purpose. If you are training against a different base model, most of the value here does not transfer, because the presets, the block layout knowledge and the precision options are all tied to the three named families.

The training mechanism and what the presets hide

Fizgig exposes both LoRA and LoKR as adapter types, and the release notes give a concrete example of why the distinction matters in practice: for LoKR on Krea 2, the project states that a 5e-5 learning rate is wanted, and the Network Type hint surfaces that when you pick LoKR. That is a small detail with a large consequence. It means the tool carries per-model, per-adapter-type knowledge and surfaces it at the point of decision instead of burying it in a config file.

The same pattern shows up in weight averaging. EMA 0.98 is on by default for Krea 2 and for MiniMax H3. The release notes describe the measurement method behind that default: on a four-way A/B, EMA at 0.98 sat five likeness points above EMA-off on late epochs with half the epoch-to-epoch spread, and reached 50% just as early. Whether you trust that number depends on how you feel about self-reported A/B results, but the claim is at least stated with a method and a comparison, not asserted bare.

For MiniMax H3 specifically, the architecture notes describe several optimizations layered together. An int8 base runs a fused forward kernel on every training step, a fused backward is on by default, and TREAD token routing thins clip steps by half their video tokens. Each clip also trains its sharpest face frame as a photo. These are the kinds of choices that normally live in a research repo and never reach a usable tool, so seeing them as defaults is the strongest argument for Fizgig's existence.

VRAM tiers and the streaming machinery

The headline claim is training on consumer GPUs down to 16 GB. That number is not free. The release notes describe an H2D ring that streams the base model through the card when memory is short, and a 4-bit HQQ precision added in 5.1 as a third option between int8 and 4-bit NF4. The stated trade-off is explicit: HQQ sits at roughly 6.3% base error for about 15 GB, and runs at about half NF4's step speed, so Auto never selects it. You have to pick it deliberately.

That is an honest kind of limitation to publish. The tool does not pretend the low-VRAM path is free; it names the cost in step speed and leaves the decision to you. The same pattern appears in a launch warning added in 5.4.1 for systems with under 32 GB of system RAM, where previews would exhaust memory. And 5.3.1 notes that 24 GB cards run the int8 base in the studio with blocks streamed, while the text encoder parks in RAM on a 64 GB box.

Reading these together, the real minimum is not one number. It depends on which of the three model families you train, which precision you pick, whether you run previews, and how much system RAM you have alongside VRAM. The README's 16 GB figure is a floor for some configurations, not a guarantee for all of them.

Getting it running

The README's install path is a badge link to an install section plus a one-click RunPod deploy with an RTX 5090 template, positioned for people with no GPU or a bigger one. A Linux launcher is mentioned in the 5.1 release notes, added alongside the Checkpoint to LoRA button on the fine-tune cards. The updater and a download button are described as fetching the training adapter used by the MiniMax H3 presets, which means the first run pulls additional weights beyond the repository itself.

The configuration surface visible in the material is mostly in-app rather than file-based. The 5.3.1 notes describe Steps, Turbo and Render size boxes for the repair studio's slider loop, load-strength dials, first and last frame pinning, and a Reference mode that uses ref2va with a `<Picture 1>` token in the prompt. The 5.0 notes describe a single checkbox that applies a full fine-tuning recipe, with a planner sizing the run to your card.

What the material does not give is a command-line interface, a config schema, or a documented Python API. If you need to script Fizgig into an existing pipeline, the supplied material does not show how. That absence is worth weighing before you plan around it.

Where Fizgig is the wrong tool

The clearest failure mode is model lock-in. Every optimization, preset and repair feature is tied to Flux 2 Klein 9B, Krea 2 or MiniMax H3. The block-level repair studio assumes MiniMax H3's 52-block layout. The EMA default is justified per model. The precision options are described for the H3 base. Point Fizgig at a different architecture and none of that transfers, so the tool's main advantage disappears and you are left with a GUI wrapper around training code you could run directly.

The second constraint is the precision ladder. If your card cannot hold the int8 base and you fall back to HQQ, the release notes state you are trading roughly half the step speed for the memory saving. On a long run that is not a rounding error. A user who needs both low memory and fast iteration may find that neither int8 nor HQQ gives them both, and NF4 is described as the faster but less accurate end of the range.

The third is documentation shape. The supplied material is a README plus a series of release notes. Release notes are good at describing what changed and poor at describing what the system does now in full. Anyone who needs to know the complete set of supported options, or the exact behaviour of a preset across versions, will be reconstructing that from changelogs.

How this differs from a general-purpose trainer

The obvious alternative is a general-purpose diffusion training toolkit such as the one Fizgig credits for its training adapter, ostris's work, which is designed to support many architectures through a common configuration surface. The difference in approach is depth versus breadth. A general trainer gives you one set of abstractions that work across model families, and you supply the per-model knowledge yourself. Fizgig inverts that: it supports three families and bakes in the per-family tuning, at the cost of supporting nothing else.

That inversion shows in the 5.2 release note, which states that Fizgig's Optimised Likeness Learning and the training adapter each fall short alone, but together reach higher likeness sooner and finish above either. A general-purpose toolkit would not make that combined claim, because it would not own both halves. Fizgig owns both halves, so it can ship the combination as a default.

The trade-off is that you inherit Fizgig's opinions. If its EMA default, its likeness-block approach or its precision ladder conflicts with what you have already validated on your own data, you are working against the tool rather than with it. A general trainer leaves that decision to you by default.

Maintenance, licensing and what to verify

Fizgig is Apache-2.0, which permits commercial use and modification, and the repository is not archived. The release cadence visible in the material is fast: 5.6.1, 5.6.0 and 5.5.0 all landed within roughly two days in September 2026. A cadence that tight means presets and defaults can shift under you between runs, and the release notes are the only record of what moved. The 5.6.1 note, for example, changes the default H3 LoRA behaviour by making the new training path the default on every run with nothing to set, while stating that trigger words work exactly as before.

Licence implications beyond the code itself are worth checking separately. The material mentions a training adapter fetched by the updater, and the three base models are third-party weights with their own terms. Apache-2.0 covers Fizgig's source, not the models or adapters you download through it. That is not legal advice, just a pointer to read the relevant model licences before commercial use.

On maintenance cost, the fast release cadence cuts both ways. Fixes arrive quickly, as the 5.6.1 note about Krea 2 previews no longer spilling VRAM on 16 GB cards shows. But anyone pinning Fizgig for reproducibility will want to track which version produced which adapter, because the defaults are not static across releases.

Editorial conclusion

Adopt Fizgig if you already work with Flux 2 Klein 9B, Krea 2 or MiniMax H3 and want training, repair and extraction in one place, with presets that encode per-model tuning rather than leaving every hyperparameter to you. Do not adopt it if your pipeline is built on a different base model family, or if you need a documented API surface rather than a GUI workbench. Before committing, check the install path for your GPU tier in the README, confirm which of the three model families your use case actually targets, and read docs/RELEASE_NOTES_v5.6.1.md to see what changed in the most recent release.

Official sources

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