ZImage Triton Accelerate

If you run Z-Image Base on a mid-range card, you know the pain: ~3.5 minutes a frame on a 3060. Quantizing helps VRAM but not speed. This node - the only node in the ComfyUI-ZImage-Triton pack, shown in the UI as ZImage Triton Accelerate - is the one genuinely different option: it swaps Z-Image's slow PyTorch operations for hand-written Triton kernels and gets you a ~1.24–1.30x speedup on Base with no new model files, no custom CUDA build, and no API key. Yes, the name is a lie in one sense - "Triton" is NVIDIA's GPU programming language, not the Poseidon guy - but it's refreshingly honest in the way that matters: it's real kernel-level acceleration, not a wrapper around someone else's endpoint.

Why this is the only option for Base

Here's the landscape the README lays out, and it's accurate. Nunchaku (SVDQuant, W4A4) is genuinely faster, but it only supports Z-Image Turbo - Base support was requested and closed as inactive. GGUF and FP8 get you into VRAM, not faster: weight-only quantization reduces memory but dequantizes back to BF16 during inference, so compute time barely moves. torch.compile is reported broken with Z-Image in ComfyUI (broken output images, looks like SageAttention/Triton conflicts). So if you're on Base - the non-distilled model with the seed diversity and negative prompts - this node is currently the only kernel-level speedup that exists for it. Turbo gets a bump too (up to ~1.38x in some configs), but there the win is smaller because Turbo is already so fast.

How it works

Under the hood ZImageTritonApply isn't loading anything. It takes your existing BF16 model and monkey-patches the S3-DiT transformer's forward passes, replacing six hot spots - RMSNorm, SwiGLU, QK-Norm + RoPE, the post-attention norm/gate/residual, and more - with fused Triton kernels that share the original weights (zero extra VRAM). If you toggle INT8 on (the default), it goes further: W8A8 quantization with Hadamard rotation, applied offline so runtime overhead is basically nil. The rotation spreads outlier weights so INT8 doesn't wreck quality, and embedding/AdaLN/first/last blocks are skipped as "sensitive layers." The node is also careful - if you change the config it restores the original forwards before re-patching, and if you feed it a model that isn't Z-Image/Lumina2 it logs a warning and passes it through untouched.

The inputs that matter

There are only two, which is the point.

• model (MODEL, required) - your Z-Image checkpoint straight from UNETLoader.
• enable_int8 (BOOLEAN, default ON) - the one real decision. ON gives you the full ~1.29x speedup and about 3.5GB of VRAM saved (transformer weights drop from ~11.7GB to ~6.9GB). OFF runs the Triton kernels alone: best quality, still ~1.05–1.11x faster, and full-strength LoRAs.

The output is a single model socket - just wire it into your KSampler (or a LoRA stack) exactly where the UNETLoader output used to go. It's a true drop-in; your existing workflow keeps working.

Install

ComfyUI Manager is the easy path: search "ZImage Triton Accelerate" (it's on the official registry). Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/newgrit1004/ComfyUI-ZImage-Triton.git
pip install -r ComfyUI-ZImage-Triton/requirements.txt

Dependencies are light: triton>=3.1.0 and scipy. That's it - no version-matched CUDA wheels, which is the whole pitch versus Nunchaku. You need an NVIDIA GPU with INT8 tensor cores (RTX 2060+). AMD and Apple Silicon need not apply; Triton kernels are CUDA.

Where people get burned

The first inference after loading is slower, not faster. Triton compiles its kernels (~3.6s, cached afterward across restarts) and the INT8 pass takes ~10–20s of Hadamard rotation and weight quantization every time the model loads. Give it one generation before judging.

The bigger trap is LoRAs. With INT8 on, quantized layers (~80% of the transformer) use pre-LoRA weights, so LoRA styling comes through partially - present but weaker. The README says it plainly: for full LoRA fidelity, flip INT8 off. If you stack many LoRAs, the INT8 mode is still fine (speedup holds regardless of count); just know you're trading a bit of LoRA oomph for the faster it/s.