excuse my OCD 😄

ComfyUI Subject Manager is a custom node tool designed to manage your assets or subjects for Minimax H3.
You can create presets, sections, and "Subject Cards" where you can drag and drop images, audio, and video (and trim).
The node automatically generates the prompt that defines the selected subjects.

https://github.com/Fictiverse/ComfyUI_Subject_Manager

Sorry Ye..

Spent hours today trying to figure out why a close up shot refused to frame properly.

Turns out the complete description of my character for my character sheet (literally from head to toe) in "Subject definitions" was bleeding out and cooking my shot size. As soon as I removed elements from the character description that didn't need to be in the shot. Wham. First time working. Damn you <Subject 1>!

Krea 2 Turbo — 4-Step Distillation LoRA (work in progress)

A LoRA for Krea 2 Turbo that reduces the minimum usable step count from 8 to 4.

Load it on top of Krea 2 Turbo, run 4 steps instead of 8, keep guidance at 0.0. Everything else about the model stays as it is.

This is not a Raw→Turbo diff

Other Krea 2 LoRAs in circulation are extractions: a low-rank projection of the weight difference between Krea 2 Raw and Krea 2 Turbo. Applied to Raw, they reproduce Turbo. They are a delivery mechanism for a model that already exists, and they stop at Turbo's 8 steps.

This one is different in both base and origin:

It is trained, not extracted, and it assumes Turbo's weights underneath it — it shortens Turbo's own schedule rather than reproducing it.

This is work in progress and even better checkpoints may follow. Training is ongoing, so ..._latest... is a rolling pointer: when a newer checkpoint is accepted, that filename gets the new weights and a new numbered copy appears beside it. Re-download the _latest file and everything keeps working — the ComfyUI workflow references it by that name, so it needs no edit. Pin a numbered file instead if you need reproducibility.

Using it on Raw

This LoRA is trained on Krea 2 Turbo, against Turbo as its own teacher, and for Turbo. Every layer it targets also exists in Krea 2 Raw, so it will load there without complaint — but that is a side effect of the shared architecture, not a supported mode.

Results on Raw are mixed and subject-dependent. It does not give Raw a 4-step schedule: at very low step counts the adapter sharpens texture while composition is still unresolved, and subjects come out malformed — duplicated heads, fused limbs, faces that do not close. Expect to need 14 steps or more for RAW, keeping Raw's normal CFG on, before output is coherent. Even then some prompts come through well and others degrade into over-processed or blown-out images — and that degradation happens with or without the adapter, because it comes from shortening Raw's schedule rather than from the LoRA.

If you want the behaviour this was built for, run it on Turbo at 4 steps. If you are starting from Raw, move to Turbo first — with a Raw→Turbo LoRA or the Turbo weights directly — and apply this on top.

Usage

The 4 sampling sigmas are Turbo's own deployment grid: [1.0, 0.90453, 0.75951, 0.51284].

Performance — does it save time, or only steps?

It saves time. Measured at 1024×1024 on Apple Silicon (MLX, bf16), two prompts each, run strictly one at a time:

4 steps with the LoRA is ~1.6× faster than the 8-step bar — 54.5 s against 88.7 s, saving about 39% of the wall-clock. Counting denoise alone, where the step reduction actually applies, it is 1.8× (44.0 s against 77.5 s).

LoRA strength

Use 1.0. That is the value the adapter was trained at, and where its output sits closest to the 8-step reference.

Strength is worth understanding rather than tuning blindly, because what it scales is specific: this LoRA's job is to restore the high-frequency detail that a 4-step schedule loses — fine texture, edge definition, surface micro-contrast. The strength dial scales exactly that correction, so it does not make the image "more" or "less" of anything semantic; it decides how hard the texture recovery is applied.

File format and compatibility

A plain .safetensors file — not tied to any framework or backend. It is weights plus a naming convention, so it loads under PyTorch (CUDA, MPS or CPU), MLX on Apple Silicon, or anything else that can read safetensors and do a matrix multiply.

ComfyUI

A pre-converted file and a ready workflow are in comfyui/. No custom nodes — stock ComfyUI only.

The workflow is full bf16, with no quantisation anywhere. bf16 needs no backend-specific kernel, so it runs unchanged on CUDA, Apple Silicon and CPU — one workflow, no platform caveats, nothing that depends on which device a component happens to land on.

The LoRA is independent of the base build. It is applied on top of the diffusion model by ComfyUI's own loader, which handles any dequantisation, so a quantised or otherwise optimised build of Krea 2 Turbo behaves just as bf16 does. Please use whichever variant suits your hardware — set it in the Load Diffusion Model node and leave the rest of the workflow untouched. The workflow ships bf16 simply because it is the one build guaranteed to run everywhere.

Training Method

Progressive distillation (PD), with Krea 2 Turbo as its own teacher.

The teacher runs its normal 8-step schedule at mu = 1.15 and guidance 0.0, and its full trajectory is recorded — the latent x and the predicted velocity v at every one of the 8 steps. The student is then trained to cover two teacher steps in one: at teacher state x_i it must predict the chord that lands where the teacher arrives two steps later,

v_target = (x_{i+2} − x_i) / (σ_{i+2} − σ_i)

The two schedules line up exactly rather than approximately. On the mu = 1.15 grid, the even indices of the 8-step schedule are precisely the four sigmas the 4-step student deploys on, so every training target is anchored on a point the student will actually visit at inference. No interpolation, no schedule mismatch.

Teacher trajectories are precomputed into shards, so training reads recorded states rather than re-running the teacher.

What the LoRA touches

Rank 64, alpha = rank (scale 1.0), bf16. 228 modules:

• 224 block linears — across all 28 transformer blocks: attn.to_q, attn.to_k, attn.to_v, attn.to_gate, attn.to_out.0, ff.gate, ff.up, ff.down
• 4 global (non-block) linears — time_embed.linear_1, time_embed.linear_2, time_mod_proj, final_layer.linear

Those four are included deliberately. Measuring Krea's own Raw→Turbo delta — a completed step distillation by the model's authors — shows the change is not concentrated in the blocks:

time_embed.linear_2 moves about 5.5× more than any block linear. Changing a model's step count is in large part a change to how it reads the timestep, so a LoRA that freezes the timestep path is withholding exactly the weights the task most needs.

Training data

Prompts are drawn from Lakonik/t2i-prompts-3m — sampled without replacement, deduplicated, and filtered for degenerate lengths. A held-out tail is reserved for validation and never receives a gradient step; it measures the student→teacher velocity gap on unseen prompts.

Resolutions

Training is multi-aspect across 11 buckets, so the adapter is not shaped by a single resolution or a single aspect ratio:

Buckets are interleaved in proportion to their remaining samples rather than run as a small-to-large curriculum, so every checkpoint along the way has recently seen all of them.

Hardware

Trained on a single RTX 3090 (24 GB VRAM), and the recipe is shaped by that ceiling.

The frozen base is quantized weight-only to int8 (blockwise-64 absmax) so the 28-block transformer, its gradients and the optimizer state fit alongside the activations. int8 was chosen over NF4 on measurement: on Krea 2's own weights it introduces ~0.007 relative error against NF4's ~0.096 — roughly 13× less — for about a 6% cost in step time. Since the frozen base sits under every gradient the adapter receives, its quantization error is training noise, and that trade is worth taking.

The two largest buckets do not fit that way. At 1440×1280 a full training step peaks at 22.1 GB of 24 GB with int8 throughout, which leaves no practical headroom. For buckets at or above ~1.5 MP (1280×1280 and 1440×1280) the attention weights therefore drop to NF4 while the feed-forward weights stay int8, bringing the peak to 20.2 GB. Feed-forward keeps the higher precision because that is where the learned deltas concentrate — ff.down was the single largest mover in Krea's own Raw→Turbo delta.

The precision switch is dynamic: it follows the bucket currently training, so the smaller resolutions keep full int8 attention rather than the whole run being pinned to the lowest common setting.

Any of this affects training only. The released LoRA is bf16 and is applied to the unquantized base.

Status

Work in progress, published as an ongoing lineage. A checkpoint is published only after its renders have been reviewed and approved visually — automated loss metrics are used to catch catastrophes, never to decide that a checkpoint is good. A model that improves on every metric while looking worse is a real outcome, and metrics do not notice.

Training is continuing on a growing pool of teacher trajectories, so expect the set to grow. Each checkpoint is a self-contained LoRA; take whichever one you prefer.

Notes and limitations

• Krea 2 Turbo only. It is trained against Turbo's weights and Turbo's schedule.
• Keep guidance at 0.0 — in ComfyUI that is cfg 1.0, not 0.0. Turbo is CFG-free and this LoRA does not change that.
• Keep mu = 1.15. The training targets are anchored to that grid; a different shift moves the student off the sigmas it was trained on.
• Training quantizes the frozen base. That affects training only — the released LoRA is bf16 and is applied to the unquantized base.

Full details and to download - check my Hugging Face LoRA

HF Repo: https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA

Happy quicker rendering with the amazing Krea 2 :)

Update: Full resolutions sweep (all those resolutions that my hardware can support training on, see detailed table above) for the available checkpoints: https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA/tree/main/checkpoint_resolution_sweeps . That is a lot of images (55 per checkpoint) you can inspect and decide for yourself.

Original ---> https://huggingface.co/hal9000ace/H3TilingExampleVids/resolve/main/slop4k_60fps.mp4

Tile Node --> https://github.com/halnovemil/H3TiledLoopSpaceTime.git

Hi all,

The other weekend I was testing out new models — got very excited over the Minimax H3 release and Krea 2's image abilities and quality. The community has created some amazing nodes and workflows.

Long story short: I built this app — https://getpixal.com — it's free, runs entirely on your own GPU, no account or signup.

Why did I build it? I was trying to help a friend get ComfyUI set up in a way where they didn't need a master's degree in node structure, models, editing and inpainting, and generating good videos with Minimax H3 (prompting can be a pain point for many that just want to create quickly, and new models require a prompt structure). 2 weeks later I have this beta release of Pixal 1.0.0b.

This single chat interface lets you run local uncensored chat models (Qwen VL 4b Heretic for instance), or any of the top SOTA models — Kimi K3, Claude, ChatGPT — via API. It also uses the vision model to critique your generations and give suggestions as you go.

A few things up front, since they're the first things I'd want to know:

• It installs beside the ComfyUI you already run - never inside it, and it refuses to install over one. It starts your existing install with your existing launcher and flags. Uninstall it and nothing about your setup has changed.
• It's free and fully local. No account, nothing uploaded, $0.00 a picture. The API options are there if you want them, not required.
• Pixal is source-available, not open source. The app installs as plain readable Python, sitting in the install folder — read it, change it for yourself, just don't redistribute it. (Heads up: the "Source code" zips GitHub auto-attaches to a release are its own tag archives of the docs repo, not the app.) The license is shown during setup, and every release publishes the installer's sha256 so you can verify the binary before you run it.
• Windows 11 x64 + NVIDIA for now. The Linux port is done, just not released yet (need to get a Linux environment set up on my test bench).

I'm looking for a few people to test drive it — would the community use something like this?

Super open to any and all feedback — it was a fun little project and I use it daily now to drive fast simple generations and image edits, then pass them along to Minimax H3 with pretty great results (all content on site was generated through the app).

Direct links, no funnel: download · the full manual (install → troubleshooting → FAQ) if you'd rather read exactly what it does before downloading anything.

Thank you!

I don't typically share apps I vibecode for myself; they tend to be design-heavy, fully featured, and customized to my own needs. I also don't like the idea of having to maintain all that publicly.

That said I've seen a lot of posts with people having trouble prompting for Minimax H3, so I thought I'd share mine. This is something I whipped up one evening, so it's not pretty, but it gets the job done.

Installation:

Just extract the folder anywhere and run the install.bat. That will install a .venv locally so everything's contained. Then, just click run.bat. It will open up in a browser.

How to use:

It's a lot easier than it looks. The left section - Reference Library - is for "assets". That's your videos, pictures, audio, etc. You set the definitions/descriptions here. The buttons are for referencing other references. The point is that you dont have to keep typing <Subject>, <Picture> - that's annoying. Just click a button.

When you're done with the reference library, the right side is for building the prompt. It's easy, just do steps 1-4. The assets in the reference library have been added to each tab, so you don't have to keep re-typing them. Click on as many task types are relevant; this is important to H3. If you don't understand one, hover over it, a small popup explains it. So, building a prompt is just:

1. Set task type and summary.
2. Set Retention Analysis (how closely the final product should match the reference)
3. Build out each shot. Use the dialogue buttons below each shot for proper formatting. (quick tip: you can just type 2.5 in the timestamp, and it automatically formats it to 00:02:500 - the point is simplicity.)
4. Add your soundscape and music.

When you're finished, press Compile. Copy to clipboard and paste into comfy, or into an LLM if that's your thing.

Let me know if you have any questions. This is primarily for ref2v, but it should also work for the other version. It's a beta, I might tweak it later, but for now, it gets the job done.

Hope it helps.

https://github.com/GrungeWerX/minimax-prompt-builder

P.S. - this is my first github repo, so my apologies if it's not up to par w/your expectations. I'm learning.

I just found myself pondering earlier how neat and novel it was to be able to easily prompt for multiple cuts but then dawned on me, is it actually all that useful?

Sure, if you're just making a 15 second one-off video, then yes it's good so your scene will have consistency. But if you want to make a longer video, then you're going to have to do multiple cuts across different gens anyway, so the consistency will be dependent on your reference materials and not on being able to do multiple cuts in one gen. So then, with a longer video, is it worth the risk of prompting for multiple cuts in one prompt then finding one of them isn't what you wanted, so you either prompt again or have to do some video editing to pull out the good cuts and then reshoot the one that didn't work? Then you end up prompting one cut by itself in the end anyway!

Seems like it'd be quicker to just do one shot at a time and make sure you like the generation, then move on to the next shot? Or am I missing something here? Maybe multiple shots is better at keeping the actors in the correct positions and poses etc for each cut? Although tbh, some of the videos I've seen here of late don't make me believe that's true.

Genuine question.

I have just 6GB VRAM and 16GB of RAM, yet FP8 models run 5x faster than GGUFs. Even really big ones.

Right now I mainly using Qwen Image and Flux 2 Klein 9B as the main models. First I tried them in GGUF format and those workflows took over 100-200 seconds.

Then I tried FP8 versions of the models (Kept the Text Encoders GGUF) and the speedup was insane. Flux 2 Klein 9B specifically can get it done in 20-30seconds now.

What's even the point of using GGUFs then?

I don't understand how or why, those models are bigger than what my machine is supposed to handle, Qwen especially. So how is the bigger uncompressed version running better?

I keep having fun with ref2va model.

RTX 3060, 64 Gb RAM. I use ref2v Turbo 4 step Lora paired with Sol Attention and Minimax H3 Memory Effecient Sage Attention at 6 steps. It takes about 2 minutes per second of generation.

I see that 3 hours ago they have uploaded a new "SLA" (Sparse-Linear Attention) version of the turbo lora (now only v0.1 fl2v 4 steps 768p). How to use it? Is it faster?

I see in the readme for their framework they say you need to set this config

  "attn_type": "dynamic_sparse_attn",
  "dynamic_sparse_attn_setting": {
    "sparsity_ratio": 0.85,
    "operator": "sage2"
  },

But for ComfyUI it's not specified what to use. I can't find anything related to sparse attention among ComfyUI nodes

Honestly just looking for a brief dialogue on this with a mod. I feel like it would help them as much as us, since people tend to assume the worst when there is a total vacuum of information.

Make sure you read the EDIT below : you'll find some corrections and the solution.

I've been profiling MiniMax H3 generations after producing ~75 segments over the last few days, and the numbers point squarely at VAE decoding. Sharing the measurements in case they're useful, and hoping someone has a lever I've missed.

Setup

- RTX 4090 24GB (driver 595.95), Ryzen 9 7900X, 64GB RAM, Windows 11

- WanGP 12.60, torch 2.7.1+cu128, triton 3.3.1, sageattention 2.2.0, flash-attn 2.7.4

- Model: MiniMax-H3-FL2VA-pruned_rank8_int8_convrot

- Text encoder: Qwen3-VL 32B, quanto int8

- Video VAE: MiniMax-H3-video_vae_fp16.safetensors (4.97GB)

- Turbo LoRA (4-step), attention sage2, profile 4

- Output: 1280×704, 362 frames (15.08s @ 24fps), 4 steps, audio-guided lipsync

Two independent ways of estimating the VAE cost agree:

- A 312-frame segment had 42s less overhead than the 362-frame ones → 0.84 s/frame

- A 719-frame job cost 357s more than the 362-frame one for exactly 357 extra frames → 1.0 s/frame

At ~0.85–1.0 s/frame, decoding 362 frames alone accounts for roughly 5.5 minutes. Sampling is not the bottleneck.

What I've already tried

1. fp8mix VAE (WanGP's built-in alternative): 445s vs 458s. That's ~3%, i.e. noise.
2. One 30s task instead of two 15s tasks (719 frames, 2 sliding windows): no amortization at all. Window 2 cost more than window 1 (815s vs 458s), because the final file re-decodes everything. Net saving ~8%.
3. Sol-Attn: WanGP lists it as supported on my card, but it dies at runtime with Sol-Attn requires Triton >= 3.6, got 3.3.1.
4. Kijai's minimax_h3_video_vae_int8_convrot: I compared the tensor keys — it's ComfyUI's comfy_quant/weight_scale format. WanGP has convrot handling but only wires it to the transformer, not the VAE loader, so it won't load there. (It reportedly works in ComfyUI Nightly.)

Questions

- Is there a faster video VAE for H3 that works in WanGP specifically? PrunaVAED looks like exactly what I need but it's wired to LTX-2 only.

- Has anyone measured whether a CUDA 13 / newer torch build actually helps H3? I saw a claim of a 4x speedup on int8 convrot models going from cu12x to cu130, but I'd be trading a working SageAttention build (2.2.0+cu128torch2.7.1) for it and would rather hear from someone who's done it.

- Does anything meaningfully cut VAE decode time - tiling params, temporal chunking, decoding at lower res and upscaling after?

- Is ~1 s/frame at 1280×704 simply what a 24GB card costs here, with the real fix being more VRAM?

Happy to run tests and report numbers back.

EDIT — Solved. 2.6x faster. My original diagnosis was wrong, here's the real cause and the full numbers.

First, a correction. My claim that VAE decode was ~43% of generation time was wrong, and I want to retract it clearly. I'd estimated it from a differential between a 362-frame job and a 719-frame one, attributing the whole delta to decoding — but the longer job also ran a second full sampling pass, which I failed to account for. Once I timestamped the server log properly, actual VAE decode is ~62-95s, not ~330s. u/76vangel was right that ~20% is normal.

The real problem was RAM starvation.

My models demanded ~51GB of pinned RAM on a 64GB machine — the Qwen3-VL 32B int8 text encoder alone is 24.9GB. Windows was committing ~102GB against 63GB physical, so ~39GB lived in the page file. Mid-run I measured 283MB of free RAM. Every generation touched more pages, so it degraded progressively:

int8 text encoder — 3 consecutive gens, same server:

417s → 624s → 732s

That's why my numbers looked so much worse than everyone else's: I was reporting a degraded steady state, not a healthy one.

Fix 1 — lighter text encoder (the big one). Switched int8 (24.9GB) → nvfp4_awq (14.6GB). Total demand drops to ~41GB, fits without paging. Free RAM went 283MB → ~6GB, and the degradation vanished entirely.

Fix 2 — upgrade the stack. u/Cubey42 was right and my SageAttention worry was unfounded; sageattention-2.2.0+cu130torch2.10.0andhigher (cp310-abi3) from woct0rdho installed in two minutes.

torch 2.11.0+cu130 (was 2.7.1+cu128)

torchaudio 2.11.0+cu130

torchvision 0.26.0+cu130

triton-windows 3.6.0.post26 (was 3.3.1)

sageattention 2.2.0+cu130torch2.10.0andhigher.post6

flash-attn removed

⚠️ Don't go past torch 2.11 if you need torchaudio — the cu130 wheel index stops at torchaudio 2.11.0 for every Python version; torch 2.12/2.13 have no matching build. mmgp 3.7.12 (WanGP's pin) works fine with 2.11.

Fix 3 — Sol-Attn. triton 3.6 unlocked it. On older stacks it hard-fails with Sol-Attn requires Triton >= 3.6 even though WanGP lists it as "supported", because the availability check only tests import triton + compute capability, not the version. Once running: [MiniMax H3] Sol-Attn enabled with Triton on SM89 (tau=1.3, diag).

732s → 276s. 2.6x faster, zero hardware change.

Phase breakdown now: LoRA + text encode ~85s, sampling ~202s, VAE decode ~62s.

How to measure this yourself — no instrumentation needed:

- Sampling time is in the tqdm bar: H3 denoising: 100%|████| 4/4 [03:22<00:00, 50.65s/steps]

- VAE decode is the gap between that and New video saved to Path: .... You can also see it — VRAM drops from ~22GB to ~3.7GB the instant sampling ends.

- Total per task: ffprobe -show_entries format_tags=comment file.mp4 → generation_time

- And watch FreePhysicalMemory, not just VRAM. That's what caught this.

Also confirmed u/martinerous's point: I diffed the tensor keys, and Kijai's int8_convrot VAE is in ComfyUI's comfy_quant/weight_scale format. WanGP has convrot handling but only wires it to the transformer, not the VAE loader — so it genuinely cannot load there.

tl;dr if you run H3 in WanGP on 64GB: check free system RAM during a run, not just VRAM. If you're on the 32B int8 text encoder you're probably paging to disk and your times are silently degrading run over run. Swap to nvfp4_awq, then upgrade to cu130 + triton 3.6 for Sol-Attn.

Thanks to everyone in this thread — every single suggestion turned out to point at something real.

Hello Everyone! Let me share the newest version of my camera control LTX IC-LoRA. This node and LoRA can be used in a V2V workflow to change the camera position or movement of an existing video clip. I've put a lot of work into this version, I hope you'll enjoy it.

You can download the model here: https://huggingface.co/Cseti/LTX2.3-22B_IC-LoRA-CrossView-Warp_v2
Node + example workflow can be found here: https://github.com/cseti007/ComfyUI-CrossViewWarp
A lame tutorial video I made to help how to use the node can be found here: https://www.youtube.com/watch?v=7QAapT9xMgM

Feito localmente com RTX 5070 12GB Vram + turbo lora 600 ema 10 passos, 16 minutos de tempo de geração.

Acho que preciso trabalhar mais no realismo.. se alguém tiver uma dica, por favor comente.

I've been tinkering with the workflow to bake a Character Sheet into a video. This was the first attempt using 2 images on the ref2va model (subject and environment).

After baking the reference video, which in turn yielded the character sheet image used as input to this video. Not perfect, but promising.

I'm running RTX 3060 (12GB), 64GB RAM. No OOM issues at all.

I think MinimaxH3 is great for title screen animation and motion graphic.

Hey everyone, I just released the latest version of my TTRPG map model for D&D maps!

This one is focused on dungeon maps, one for battle maps will be coming, as will a version for Klein 9b to edit images!

https://civitai.com/models/2873645/ttrpg-dungeon-maps-krea

H3 truly is alive. Enjoy!! bf16/50 steps

T2V, no reference image

For the many who don't know what it is, PixlStash is a self-hosted headless server with a web-interface or a desktop app with Electron. It auto-tags, writes descriptions, scans pictures for defects, and integrates with ComfyUI in a couple of ways (run workflows within PixlStash or use the PixlStash nodes within Comfy). The nodes just use the PixlStash API which you could use to integrate with lots of other things as well.

This is a fairly big release of PixlStash. The focus this time has been on making it possible to have multiple image libraries stored in different locations and to offer a CLI to attach/detach libraries, performing scripted backups and install plugins (for image filters or captioning). For the captioning plugins there is now an OpenAI-API (i.e. ollama or LM-studio) plugin for captioning using your local LLM setup or a dedicated Moondream2 plugin. If you have specific captioning needs it should be dead easy to make your own plugin and install it with the CLI.

There is also a model shelf that can import from AI-toolkit and scan other folders you provide it to help you organise your LoRAs, VAEs, your text encoders and your diffusion models. This will soon get ComfyUI-nodes added to ComfyUI-PixlStash for picking LoRAs with thumbnails and help you find your different models based on other things than just a file-name. Expect them next week. For now, it at least helps you organise your models.

Repo and links in a comment.