MiniMax H3 on RTX 4070 Ti SUPER: Ada at 16 GB, and the Turbo LoRA question

What You'll Build

A ComfyUI graph on one RTX 4070 Ti SUPER that turns a prompt into a 24 fps clip with its own synchronised stereo soundtrack — dialogue, effects and score denoised jointly with the picture in a single pass.

Two things make this card's page different from the rest of the family. The first is that it is the only consumer card with published few-step Turbo-LoRA reports, and until you read the timestamps the two of them appear to flatly contradict each other about whether the base weights this recipe installs work at all. The second is that this is an Ada card in a release whose headline text encoder is stored in NVFP4 — a format the internet will tell you is Blackwell-only, in advice that names this exact GPU. Both questions have answers, and both answers come from reading files rather than reading forum consensus.

⚠️ Read the licence before you download 42.47 GB. MiniMax H3 is not open-source. The MiniMax H3 Community License Agreement restricts you by territory: clause I.5 defines the Excluded Territories as "means the European Union, the United Kingdom, the Republic of Korea and the United States of America.", and clause V.4 reaches past the weights to what you make with them — "You may not use, reproduce, modify, distribute, or display the MiniMax H3 Works or any of their Outputs or results outside the Applicable Territory."

Two practical notes. The machine-readable license: facet on the card is the uninformative other, so any catalogue filter keyed on that field misses all of this. And nothing downstream relaxes it: the Comfy-Org repack installed below declares the same licence and links back to the same file, community re-quantisations are derivatives, and an adapter's Apache-2.0 tag covers the adapter, not the base weights it loads against — which matters below, where the Turbo LoRA is Apache-2.0 and the model it patches is not. MiniMax publishes a licence Q&A and a per-deployment application route. This is a summary written by a reader of the text, not legal advice.

Hardware data: RTX 4070 Ti SUPER (16GB VRAM, sm_89) · encoder resident by 0.200 GiB, transformer streamed · See benchmark data

ℹ️ 768p is the local ceiling. H3 reaches 2K through a separate H3-Regenerate-2K stage, and the model card says of it: "this module is not yet open-sourced. We will release it once it is ready." — the official route to 2K is an API call back to MiniMax, which puts you under their platform terms on top of the weights licence. What runs on your card is H3-Base, of which the same card's spec table says: "The shorter side is set to 768 pixels by default."

Requirements

Component	Minimum	This recipe
GPU	12GB VRAM via ComfyUI's dynamic VRAM offload	RTX 4070 Ti SUPER (16GB, sm_89) — not measured by us; see Results for what has and has not been published on this card (/contribute)
RAM	32GB with --disable-pinned-memory; 64GB comfortable	— both published reports on this card ran 32GB, so 32 is demonstrated rather than merely arithmetic. This constraint tracks the transformer's size, not your card's.
Storage	42.47 GB of weights	42.47 GB across four files (byte counts from the HuggingFace tree API)
Software	ComfyUI 0.30.0+, PyTorch built against CUDA 13	—

The four files the official text-to-video template loads, byte-exact from the Comfy-Org repack:

File	Bytes	GiB	Destination
minimax_h3_fl2va_pruned_int8_convrot.safetensors	20,970,379,616	19.530	models/diffusion_models/
qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors	15,687,142,551	14.610	models/text_encoders/
minimax_h3_video_vae_fp16.safetensors	5,207,808,496	4.850	models/vae/
minimax_h3_audio_vae_fp32.safetensors	605,254,808	0.564	models/vae/

The min_vram_gb on this page is 12 rather than 16, and that is deliberate: it is the filter floor for the install documented here, not this card's capacity. It rests on Comfy-Org's launch post, which describes shrinking the footprint to 42.5 GB and then says: "Combining this with our dynamic VRAM offloading enables a next-generation 2K video model to run locally on a GPU like the RTX 3060." Read 12 as the vendor's floor and 16 — this card — as the tier where one of the two large modules stops streaming.

At 16 GiB the encoder fits and the transformer does not

On a 24 GB card both the denoise pass and the text encoder fit. On a 12 GB card neither does. 16 GiB is the only consumer tier where exactly one of them fits, and knowing which one tells you what your card is actually doing on every step:

text encoder  15,687,142,551 B = 14.610 GiB + 1.191 GiB reserve = 15.800 GiB → clears 16 GiB by 0.200
DiT           20,970,379,616 B = 19.530 GiB + 1.191 GiB reserve = 20.721 GiB → 4.721 GiB short, streams

The 1.191 GiB is not a rule of thumb. minimum_inference_memory() in comfy/model_management.py returns (1024 * 1024 * 1024) * 0.8 plus EXTRA_RESERVED_VRAM, which is 400 MiB on Linux — 1.190625 GiB, printed above rounded to three places.

The knife-edge is real, and that is the finding. On a same-capacity card the encoder was observed at 15,219 MiB during encoding — within 259 MiB of its full staged size, so essentially all of it was resident, and the 0.200 GiB above is not a paper margin. ComfyUI then caps the transformer at whatever budget remains and streams the other 4.721 GiB over PCIe on every sampling step. That is not a failure mode; it is how this tier works.

What this does not tell you is which stage owns the run's high-water mark, and it is worth saying plainly that nobody knows. Every published VRAM figure for a 16 GB card is a whole-run peak; no trace decomposes one by stage. There is even a mechanical argument against the encoder owning it — swapping the attention node moves the run peak by 2.4 GB on the one measured card, and attention is denoise-side, so a peak the encoder set could not move that far. Results carries the numbers. Size your card against the 15.800 GiB encode figure, because that is what decides whether you are in the game at all; do not size it against a peak nobody has isolated.

Three caveats on the 0.200 GiB, in descending order of how likely they are to bite you.

The budget is computed against free VRAM, not capacity. get_free_memory() in the same file reads torch.cuda.mem_get_info(dev), which reports what is genuinely unallocated at that instant. A desktop compositor, a hardware-accelerated browser tab or a second CUDA process spends straight out of that 0.200 GiB, and the driver plus the CUDA context take their cut before ComfyUI starts. On a machine that is also your desktop, assume the margin is gone.

The reserve is larger on Windows and the sign flips with it. EXTRA_RESERVED_VRAM becomes 600 MiB there, and a further 100 MiB is added once the card reports more than 15 GiB — which yours does. Check the indentation yourself rather than taking my word for it: that extra 100 MiB sits inside the if WINDOWS: block, so it is a Windows surcharge and not a general large-card one. Together they lift the floor to 1.484 GiB and the text-encode stage to 16.093 GiB, i.e. 0.093 GiB over a 16 GiB card before anything else has asked for a byte.

Losing the margin costs time, not the render. The weight budget for a stage is

lowvram_model_memory = max(0, free_vram − minimum_memory_required)

with an alternative floor term that on NVIDIA is switched off outright — MIN_WEIGHT_MEMORY_RATIO is 0.4 by default and reset to 0.0 under if is_nvidia(). So when free memory drops, ComfyUI keeps proportionally fewer weights resident and streams the rest. It is the same mechanism that runs the 19.530 GiB transformer here at all.

Installation

1. Put ComfyUI on a CUDA 13 PyTorch

H3's nodes ship in ComfyUI core (comfy_extras/nodes_minimax_h3.py), not as a custom node, from v0.30.0 onward. That module imports torchaudio at load time, so a hand-built environment carrying only torch and torchvision fails at startup.

The CUDA version is a hard gate in ComfyUI's own source, and on this card it gates the one file that genuinely uses your tensor cores. comfy/quant_ops.py parses torch.version.cuda, and below 13 it calls ck.registry.disable("cuda") and logs "WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations." That call removes the comfy-kitchen CUDA backend, which supplies the accelerated kernels for the int8-convrot transformer you are about to download. Note the gate is on the CUDA version, not on the architecture — Ada is not disadvantaged here, it is only as disadvantaged as an out-of-date CUDA makes it.

Order matters: requirements.txt lists torch unpinned, so running it after a cu130 install resolves a default-index wheel over the top and silently undoes the fast path. Install the CUDA 13 stack last, from its own index.

cd ComfyUI
git fetch --tags && git checkout v0.30.2
pip install -r requirements.txt
pip install --force-reinstall --index-url https://download.pytorch.org/whl/cu130 \
  torch torchvision torchaudio

Before going further, confirm two lines in the startup log: the torch version must contain +cu130, and comfy-kitchen's CUDA backend must report 'available': True. If it reports a failed import instead, ComfyUI carries on running normally with the fast path dead — one buried error line and no other symptom.

2. Download the four model files

Run these from the ComfyUI root, and pass the filenames as positional arguments — handing several of them to --include makes everything after the first positional anyway and drops the flag, with only a UserWarning to say so.

pip install -U "huggingface_hub[cli]"

hf download Comfy-Org/MiniMax-H3 \
  diffusion_models/minimax_h3_fl2va_pruned_int8_convrot.safetensors \
  text_encoders/qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors \
  vae/minimax_h3_video_vae_fp16.safetensors \
  vae/minimax_h3_audio_vae_fp32.safetensors \
  --local-dir models

The repo's own paths are already diffusion_models/, text_encoders/ and vae/, so --local-dir models lands all four where the loaders look.

Take the nvfp4 text encoder, and ignore the advice telling Ada owners not to. You will meet that advice — a widely circulated third-party quant hub, Abiray/Minimax-H3-nvfp4-INT4-INT8-Convrot, publishes a GPU-selection guide that names this card by model in its 16 GB tier ("Perfect for RTX 4070 Ti Super, RTX 4080, etc.") and files the nvfp4 encoder under a Blackwell-only heading: "Exclusively for RTX 5090, PRO 6000, and other next-gen Blackwell cards. Do not download these for 30/40 series cards!" Kijai, who is an organisation member on the Comfy-Org repack, answered the same question directly in discussion #16: "The nvfp4 is not for Blackwell only, you can just use it.", and when pushed added that here "it's just used as storage format here, there's nothing hardware specific about that". The section below shows why the file agrees with him. The practical point at 16 GiB is size: the alternative qwen3vl_32b_minimax_h3_int8_convrot.safetensors is 27,141,342,152 B = 25.277 GiB, which is 10.667 GiB more to stream on a card already streaming a transformer. If prompt adherence fails on a complex reference setup, swapping the encoder is a reasonable thing to try — it will cost you time, not an error.

3. SageAttention 2.x — the install is a platform question, not an architecture one

pip install sageattention gets you 1.0.6, which is the newest release on PyPI; the index lists nothing above the 1.x line. That is the wrong kernel generation, and the H3-specific KJNodes patch refuses to load against it rather than running slowly: "sageattention is not new enough version or could not determine CUDA architecture, cannot apply MiniMax H3 Memory Efficient Sage Attention Patch."

There is a reason PyPI is a dead end for everyone, and it is not about your card. The most-used prebuilt-wheel fork, woct0rdho/SageAttention, explains it in its own README: "We cannot publish the wheels to PyPI, because PyPI does not support multiple PyTorch/CUDA variants for the same version of SageAttention." Those wheels are published on the releases page instead, and the same README states what they contain: "CUDA kernels for sm80/89/90 are bundled in the wheels, and also sm120 for CUDA >= 12.8".

Read that line carefully, because it is the sentence a 50-series page cannot quote at you: sm89 is bundled unconditionally, sm120 only in builds targeting CUDA ≥ 12.8. Be honest about how much that buys you — the current release ships four wheels (cu128 and cu130, each against torch2.9.1 and torch2.10.0andhigher), both CUDA lines clear 12.8, so today every one of them carries sm120 as well. The asymmetry is in the rule, not yet in the shelf. What it does mean is that the "no prebuilt wheel, build from source" advice you will find on Blackwell write-ups is a Linux fact rather than a Blackwell one, and it applies to you identically:

• On Windows this is a download, not a build. Pick the cu130 wheel matching your torch from the releases page and install it.
• On Linux there is no prebuilt wheel and you build from source, which is a one-liner with the right arch pinned:

pip install ninja packaging
CUDA_HOME=/usr/local/cuda-13.2 PATH=/usr/local/cuda-13.2/bin:$PATH \
TORCH_CUDA_ARCH_LIST=8.9 MAX_JOBS=8 \
pip install --no-build-isolation "git+https://github.com/thu-ml/SageAttention.git"

--no-build-isolation is mandatory — without it pip pulls a second torch into the build and wrecks the environment. TORCH_CUDA_ARCH_LIST=8.9 is this card's compute capability and cuts build time sharply.

An Ada footnote you will never see in a log: these are your kernels. In nodes/ltxv_nodes.py the patch branches on the detected architecture. The sm89 branch quantises Q and K per thread (_qk_quant_gran = 3), converts V with per_channel_fp8, and calls _qattn_sm89.qk_int8_sv_f8_accum_f32_fuse_v_scale_attn_inst_buf — upgrading to the accum_f16 variant when sageplus_sm89_available, which requires both that symbol's presence and get_cuda_version() >= (12, 8). The sm120/sm121 branch calls into the same _qattn_sm89 module but switches to per-warp granularity (_qk_quant_gran = 2); Blackwell borrows the Ada kernels and changes one parameter.

Use the H3-specific node rather than the --use-sage-attention startup flag — it replaces the attention forward wholesale instead of routing through ComfyUI's shared optimised-attention path, so it is the narrower change. But do not read that as a safe harbour, because of what follows.

⚠️ There is an open, unresolved noise bug in sage's FP8 PV kernels, and the path above is in the implicated family. ComfyUI issue #15263 is worth reading before you enable any of this, and worth reading carefully, because its root cause has been revised twice by its own participants. The originally-reported cause — a missing low_precision_attention=False opt-out — was retracted by the reporter on 2026-08-05, and the one-line PR proposing it (#15298) was closed unmerged without landing. A smooth_k theory was retracted too. As of the last comment the suspicion has moved off "FP8 accumulation error" and onto a scale-buffer overrun keyed on the quantisation granularity parameter — the very parameter that differs between the sm89 and sm120 branches above. Nobody has closed it.

Three things bound how much this should worry you, and one of them cuts the other way:

• It is length-gated, far above this page's operating point. The reporter's bisection puts the last clean run at 150,960 tokens and the first noisy one at 167,280, on their shared metric. A second participant computes that H3's own nodes cap you well below that — MAX_PIXELS in nodes_minimax_h3.py is 768 * 1344, which at the top of the trained frame range gives 91,728 tokens, 61% of the last clean row. Every failing run is at a canvas above that cap. The template this page installs runs 864×480 at 124 frames.
• No failure has been reported on the file set this recipe installs. Every noise report is on the bf16 checkpoint and encoder. The only participant running minimax_h3_fl2va_pruned_int8_convrot reported it clean, with a 1.37× sampling speedup, at 864×480 / 124 frames / 20 steps — this page's stock canvas exactly.
• But that participant is on sm_86, and every failing report is on sm_120. There is no sm_89 datapoint either way. Your card sits between the two architectures in the thread and is absent from it. Treat sage here as an unverified accelerator on this GPU, not a known-good one: render a short baseline without it, enable it, and compare the two outputs before you commit to a long job.

Do not respond to this by pinning a specific sage kernel. The thread tested that directly and every explicit mode on the failing hardware either crashed or corrupted memory, which one participant summarises as turning noise into a crash — "strictly worse". If sage misbehaves for you, switch it off and report what you saw.

4. Load the official template

Open ComfyUI, go to Template Library and pick MiniMax H3 Text to Video, or drag in video_minimax_h3_t2v.json. It wires exactly the four files above. The ComfyUI tutorial documents this template plus the image-to-video and reference-to-video variants.

Running

python main.py --disable-pinned-memory

On a 32 GB machine that flag is not tuning, it is the launch command. ComfyUI page-locks host memory to speed transfers to the GPU: MAX_PINNED_MEMORY is set to ram * 0.90 on Linux and ram * 0.40 on Windows, and pinned_hostbuf_size(size) then returns max(0, int(min(size, MAX_PINNED_MEMORY) * 2)) — twice the model size. Work that on your own numbers: the 19.530 GiB transformer alone asks for 39.060 GiB of page-locked host memory, before the 14.610 GiB encoder has requested a byte. On a 32 GB box that request cannot be satisfied, and page-locked pages can be neither swapped nor reclaimed, so the kernel's only remaining move is to kill the process.

That is not only arithmetic — the flag's effect is measured at your memory size. A 15-second RTX 3090 write-up ran the same model and the same 362 frames twice on a 31,997 MB box with only this flag changed: 29,866 MB of host RAM on defaults, killed by the kernel OOM-killer, against 7,508 MB with --disable-pinned-memory, completed in 23 min 17 s. A different GPU, which is the point — pinning is sized from the transformer and your system RAM, not from your VRAM — and he derives the same ram * 0.90 ceiling independently.

What the flag costs in time is not measured, and the reason is structural: nobody has published a completed run on both sides of it, because the unflagged run is the one that gets killed. The one write-up that priced it was withdrawn by its own author on 2026-08-08 as unverified, so treat any percentage you have read for this flag as unpublished. The mechanism still tells you which side of it you are on: at 32 GB the 42.47 GB weight set cannot sit in page cache, so the streaming this tier cannot avoid arrives off the SSD rather than out of RAM — which is why the prerequisites ask for an NVMe rather than any 45 GB of free space. Take the flag anyway; the alternative is not a slower render, it is the OOM killer. --fast-disk attacks the same problem from the other end by preferring reclaimable page cache to unpinned RAM, and is a reasonable alternative rather than a second dose. --cache-none does nothing for this at all: comfy/cli_args.py puts it in the cache group and describes it as "Reduced RAM/VRAM usage at the expense of executing every node for each run." — node-output caching, not weight residency.

--reserve-vram is the one knob that moves this card's knife-edge, in both directions. The argument replaces EXTRA_RESERVED_VRAM rather than adding to it — the assignment sits below both platform defaults — so encoder residency needs 0.8 + reserve + 14.610 ≤ 16, which puts the ceiling at 604 MiB. Read your platform off that:

• Linux defaults to 400 MiB, leaving 204 MiB of slack. Spending it is a real trade, not a free win: that constant exists to keep your compositor alive, and the budget is computed against free VRAM anyway.
• Windows defaults to 700 MiB on a card this size, which is already 96 MiB over the ceiling — and --reserve-vram 0.5 recovers it. That is the single most useful flag on this page if you are not on Linux.
• Do not copy a larger --reserve-vram from a page written for a smaller card. A value like 1.5, which makes sense where nothing fits anyway, is wrong here: it puts the floor at 2.3 GiB and the encode stage at 16.910 GiB, moving the encoder from "fits" to "streams" — the one advantage this capacity has, spent on a flag.

Queue the template unchanged first, and know what "unchanged" means — the numbers stored on the generation node are not the numbers it runs. Its width and height are wired inputs fed by a ResolutionSelector set to 16:9 at 0.4 megapixels, and a connected input beats a stored widget, so the 1344×768 in the node's widgets never reaches the sampler; you get 864×480. Frame count is snapped onto a 17k+5 grid by the template's own math node, so a 5-second request becomes 124 frames. Steps are 20, sampler res_multistep, scheduler simple. To reach H3's native canvas, set the selector to 0.98 megapixels.

What Ada actually gets from these three files

The NVFP4 question deserves a real answer rather than a forum consensus, and the repack answers it three different ways in three files. Each safetensors header carries a per-layer comfy_quant descriptor; reading them over HTTP range requests gives this:

File	Quantised layers	Descriptor	input_scale tensors
qwen3vl_32b_minimax_h3_nvfp4_awq (installed)	350	{"format": "nvfp4", "full_precision_matrix_mult": true}	0
minimax_h3_fl2va_pruned_int8_convrot (installed)	200	{"format": "int8_tensorwise", "convrot": true, "convrot_groupsize": 256}	0 (by design)
minimax_h3_fl2va_pruned_fp8_scaled (alternative)	200	150 × {"format": "float8_e4m3fn"}, 50 with full_precision_matrix_mult	150

The hardware gate does behave differently on your card. supports_nvfp4_compute() in comfy/model_management.py returns false for any device whose compute-capability major is below 10, and yours is 8 — so at startup ComfyUI lists nvfp4 under emulated ops rather than Native ops, where a Blackwell card would show it as native.

It makes no practical difference, and the reason is in the first row of that table. Every one of the encoder's 350 quantised layers declares full_precision_matrix_mult: true, and comfy/ops.py builds its _use_quantized predicate with not self._full_precision_mm as a conjunct. That flag alone skips the quantised matmul and dequantises the weight into the compute dtype first — on a 5090 exactly as on this card. The file corroborates it from the other side: it ships weight_scale, weight_scale_2 and pre_quant_scale, and zero input_scale tensors, activation scales being precisely what an FP4 tensor-core matmul needs. So the 14.610 GiB encoder is a container and nothing more, on every architecture. That is exactly the contribution you want at 16 GiB — just do not pick it, or reject it, for the tensor cores.

The generalisable line is worth keeping: hardware support is a property of the format; use is a property of the file. The third row proves the distinction is real rather than rhetorical. The fp8_scaled transformer variant ships 150 layers with a bare float8_e4m3fn descriptor and 150 matching input_scale tensors — a file that genuinely does opt into FP8 matmul, and Ada's supports_fp8_compute() passes it (major >= 9 is false, but major < 8 and minor < 9 both fail, so the gate returns true at 8.9). Nobody has published a like-for-like comparison of it against the int8-convrot build this template installs, and at 20,958,205,608 B it is within 0.012 GiB of the same size, so it changes nothing about the fit. It is a lead, not a recommendation.

Output lands in ComfyUI/output/video/ as an MP4 with the stereo track already muxed in.

Results

• Speed: our catalogue has no benchmark rows for this pair — /check/minimax-h3/rtx-4070-ti-super returns verdict: unknown. More surprisingly, no measurement of the plain text-to-video path on this card has been published anywhere I could find: sweeping all 36 discussions on the Comfy-Org repack and all 22 on the Turbo adapter, every mention of an RTX 4070 Ti SUPER is one of the two Turbo-LoRA reports below, and a web search adds nothing. The one timing that exists for this GPU is Evados's 8-step Turbo run at 1280×720 — "8/8 [06:16<00:00, 47.03s/it] On a RTX 4070ti super 16 gb vram and 32gb ram." — which is a few-step accelerated path and therefore no guide at all to a stock 20-step render. If you run this, a timing sent through /contribute would be the first datapoint this page has.
• VRAM usage — the number to size against: 15.800 GiB at the text-encode stage, being 14.610 GiB of encoder weights plus ComfyUI's 1.191 GiB reserve floor. That clears a 16 GiB card by 0.200 GiB on Linux and exceeds it by 0.093 GiB under the larger Windows reserve. The transformer's 20.721 GiB demand is 4.721 GiB short and streams. That the encoder really does become resident is measured, on a different 16 GB card: on the repack's discussion #6 an RTX 5070 Ti owner posting as UdonJP logged "24.1 GiB after TE load (VRAM 15,219 MiB, 100% util = encoding)" — 15,219 MiB being within 259 MiB of the encoder's staged size. Different architecture, same capacity, same four files, and one person's report rather than a controlled benchmark.
• What is not settled, and you should not inherit it from any page: which stage owns the run's peak. Every published peak for this model is a whole-run figure, and on 16 GB there are exactly two of them, both in UdonJP's discussion #6 post above — "VRAM peak was 14,197 MiB for 30 s @ 640x480 and 14,437 MiB for 5 s @ 1344x768", one person, one machine. Neither is a denoise-stage figure, and a page that presents whole-run peaks as stage peaks has relabelled them. A longer write-up used to sit behind those two numbers and no longer does: its author withdrew it on 2026-08-08, saying its content could not be vouched for, so the node-by-node peak table and the wider peak band that circulated from it have been removed rather than pinned to a commit — a pin preserves checkability, not truth. What would settle the question is one run with VRAM polled at 1–2 second intervals, logging the encode peak and the sampling peak separately; if you own this card, that measurement through /contribute is worth more than another timing. Live data, when it exists, will be at /check/minimax-h3/rtx-4070-ti-super.
• System RAM: the two published reports on this card both ran 32 GB, and both completed renders, which is the most useful thing either of them tells you. Neither states its launch flags, so treat that as evidence 32 GB is workable rather than evidence the flags are optional. The 5070 Ti measurements above come with their author's own caveat that "it is inference from a 125 GB box."
• Quality notes: the model's known weakness is faces at distance, reported on the repack's discussion #30, and no amount of VRAM buys you out of it. Frame for close and medium shots.

For the full benchmark data, see /check/minimax-h3/rtx-4070-ti-super.

Optional: the Turbo LoRA, and the two reports on this exact card

larryvrh/MiniMax-H3-Turbo-Lora renders in 4–8 steps instead of ~20, driven by the node pack Larryvrh/ComfyUI-MiniMax-H3-Turbo. On a card this size step count is the largest single lever you have, so it matters more here than it does on a card that holds the whole transformer — and this is the one GPU in the catalogue where somebody has actually written down what happened.

Both reports come from an RTX 4070 Ti SUPER 16GB with 32GB of RAM, and read side by side they look irreconcilable:

• Evados, on the adapter's discussion #3, completed the 8-step run quoted above at LoRA strength 1.8 on euler/beta, and closed the same post with a flat warning: "Don't work with the pruned model."
• kangklx, on discussion #20, states "My current hardware is an RTX 4070 Ti SUPER 16GB with 32GB of system RAM." and runs the LoRA on the pruned int8-convrot base this page installs — reporting severe artefacts at 4 steps, then, after switching to the pack's dedicated Turbo Sampler, that "it has moved from severely corrupted / unusable to generally usable and worth further tuning." with the residual finding that "there still appears to be a remaining audio-quality issue at 4 steps". A third participant in that thread is blunter: "Forget about 4 step. 4 step is bad. Minimum is 6 steps".

They are not actually in conflict — they are six hours apart across a fix. Evados posted at 04:05 UTC on 2026-08-06. That same morning, on discussion #11, several users reported the pack erroring out on pruned_int8_convrot, and at 10:57 UTC the adapter's author replied "Node updated for pruned base." Twenty-two minutes later a user confirmed it, with a caveat about console noise: "It does work with this pruned base and your ckpt500, it just spams the console with these errors." The node pack's own commit history dates the whole sequence to the minute, and it is more decisive than the forum reply: the pack's first commit is 06:53Z on 2026-08-06, two and three-quarter hours after Evados posted, and pruned/curve support — run-time adaln injection — lands in e7ad532 at 10:55Z, two minutes before that reply. Evados was not using this node pack; discussion #3 is about re-keying the LoRA for ComfyUI's stock loader, which is the path that cannot carry the adaln update at all. His report was true of what he ran.

The mechanism is in the node's source, and it explains why this could not have worked before the fix: on a pruned base the LoRA's adaln update lives in a 2688-dimensional silu(t_emb) space that the pruning has collapsed into a curve, so it cannot be applied as a weight patch at all. The node re-injects it at run time from a small interpolation grid bundled with the pack. Loading the same LoRA through a stock loader on a pruned base therefore drops exactly the time-conditioning weights — which is what the adaln_proj.linear.weight shape ... is invalid errors in those threads are.

What this leaves genuinely unsettled is quality at low step counts, and that part has not been resolved by anybody. kangklx's 20-step no-LoRA baseline on the same pruned file is clean — he says it "works correctly when I disable the Turbo LoRA and run the normal 20-step H3 workflow." — while his 8-, 6- and 4-step Turbo runs degrade progressively, and his audio complaint survived the sampler fix and the author's follow-up patch. Nobody has published a same-machine before-and-after on any 16 GB card. The adapter's card describes the current weights as a paused training round with over-sharp grain and the nodes as prototype code.

So: get a known-good 20-step baseline first, then try Turbo against it at 8 steps before 4, and update the node before you conclude anything. The pack's low_vram switch merges the LoRA into the weights for a lower peak — useful on 16 GiB — at the cost of a softer result specifically on quantised and pruned bases, which is what you are running.

Troubleshooting

[ERROR] ERROR lora diffusion_model.blocks.N.adaln_proj.linear.weight shape ... is invalid

Console spam, not a failure — several users on discussion #11 confirmed the render completes and looks right. It is the pruned-base path described above announcing that the adaln slice of the LoRA cannot be applied as a weight patch. Update the node pack first; if the messages persist and the output is good, ignore them.

RuntimeError: Expected all tensors to be on the same device with the Turbo node

Reported specifically when running with VRAM offloading flags — which is every run on this card, since the transformer streams by construction. It was a device mismatch inside the run-time adaln injection and is fixed in current main (the injection now casts to the input's device). If you hit it, git pull the node pack before doing anything else.

The sage patch refuses to load, or someone tells you to upgrade ComfyUI to 0.31

Two separate things. Check pip show sageattention first: 1.0.6 means you have the PyPI package, which cannot satisfy the sm_89 path — see Installation step 3, and note that SageAttention 3 installs under a different package name (sageattn3) that the --use-sage-attention flag does not resolve. Second, advice to "update to 0.31" circulates and is simply wrong: no such release exists, and v0.30.2 was the newest tag when this page was written. The real floor is 0.30.0.

ComfyUI is killed, or throws MemoryError, while loading

System RAM ends more H3 runs on this tier than VRAM does, which is why --disable-pinned-memory is in the launch command rather than here. If it still dies, --fast-disk is the other lever. A MemoryError raised specifically by UNETLoader has a duller second cause worth eliminating first: a truncated download that is the right byte size and the wrong hash. Re-hashing a 21 GB file is cheaper than re-diagnosing it.

Generation is far slower than a 16 GB card should be

Grep the startup log for a comfy-kitchen import failure or for the cu130 warning quoted in Installation step 1. Either one silently removes the int8-convrot fast path while ComfyUI keeps running normally, and on this card that is the single most likely explanation for landing near a much smaller GPU's timings. What it is not is the nvfp4 encoder being emulated on Ada — that costs you nothing a Blackwell card is not also paying, for the reasons set out under Running.

Nothing here matches your problem

Runtime errors belong at ComfyUI/issues, template problems at workflow_templates/issues, attention-patch problems at ComfyUI-KJNodes/issues, and Turbo-LoRA problems at the node repo's issues. And if you get a clean stock run on this card, a timing sent through /contribute is worth more to the next reader than every derived number here — this page currently has none.