Krea2 TaylorSeer Lite

Set expectations before anything else: this is the one node in the pack where the honest pitch is "meaningfully faster, visibly different." TaylorSeer's own repo sells 3-5x on Flux. What people actually reported when they tried the Flux ComfyUI ports was around 2x with a small dip at conservative settings, and the 3.5x figure only after the quality fell apart - one poster's most conservative run was ~1.66x. Caching schemes all have that shape. What's genuinely new here is the memory story, and it's a real fix rather than marketing.

How it works

For the first warmup_steps steps, the node computes everything normally. After that, every fresh_interval-th step is a full 28-block forward pass, and the steps in between are forecasts: they return early and skip every transformer block in the model.

The forecast comes from Taylor factors held for one tensor - the final denoiser output, after Krea 2's last layer, which is what the released Lite HunyuanImage implementation caches rather than the pre-final hidden state. Finite differences and the forecast itself use integer denoising-step distance, per the TaylorSeer paper's equations 7-9. Because only that single feature is stored, a BF16 cache at 1024x1024 batch 1 costs roughly 0.5 MiB instead of the >5 GiB an earlier per-block implementation needed - that's the difference between "runs on an 8 GB card" and "doesn't."

Two guard rails are worth knowing because they explain why your speed-up isn't linear. The last tail_full_steps steps are always computed in full, so the final detail lands properly. And a forecast is refused - falling back to a full computation - when the guidance regime changes: if GAG or NAG is active and crosses its sigma boundary, the cached output came from a different function and can't stand in for this one. That's correct, and it means combining this with the guidance nodes costs you those boundary steps.

The inputs

• max_order (0-2, default 0) - 0 reuses the latest full output instead of extrapolating. The README is blunt about why: on Krea 2 Turbo's ten large intervals, first-order extrapolation produced visible coloured squares in direct testing, so the released implementations support order 0 and it's the stable default. Orders 1 and 2 exist for longer schedules; touch them only on Raw or a 30-step-plus run.
• fresh_interval (2, minimum 2) - how often a full computation happens. This is your speed dial, and the README says outright that increasing it buys speed at a larger quality cost.
• warmup_steps (3, minimum 2) and tail_full_steps (2) - the full-compute bookends.

Output is model (MODEL). It's a MODEL patch, so it goes in the chain; the pack's example ordering puts it last before the sampler, though the four MODEL nodes are independent.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/iljung1106/Krea2-Training-Free-Improvements
# restart ComfyUI

Zero pip dependencies - the pyproject declares dependencies = [], so this is a clone-and-restart, not another custom-node dependency roulette. ComfyUI Manager will find it by searching "Krea2 Training Free Improvements". Note that it's Euler/simple territory: the node identifies the current step by matching the running sigma against the schedule, and any intermediate evaluation that doesn't line up falls back to a full pass rather than guessing.

Where people get burned

Measure properly. Do one warm-up generation first, then time the same seed with and without the node - the pack's own README warns that model loading, offloading, VAE decode and other MODEL patches can dominate a cold timing and make the comparison meaningless. For reference, the author's four-node workflow on a 3060 Ti 8 GB took 105.7 s with guidance only and 67.5 s with order-0 TaylorSeer plus the final two steps full.

It requires Krea 2's SingleStreamDiT, rejects non-positive CFG branches, and won't run alongside Krea2Edit reference latents - all of which raise rather than degrade silently. If your images are fine but weirdly static in the middle of the schedule, that's what forecasting looks like; drop fresh_interval back to 2 and keep max_order at 0, which on a 10-step Turbo workflow is the only combination worth starting from.