Nodes/CUI-Lumina2-TeaCache/TeaCache Result Collector
ComfyUI Node

TeaCache Result Collector

The node that writes down how your speedup actually went

By spawner1145·Created about a year ago·Updated 7 months ago· 20
TeaCache Result Collector
  • latent
  • LATENT
  • status
run_id
analysis_fileteacache_analysis.json
trigger

TeaCache is all about a trade: faster renders for a little image quality. "A little" is doing a lot of work there, and the only way to know how much you're actually giving up is to measure it run after run. That's the job of TeaCache_Result_Collector - it sits at the end of the pack's analysis chain, records how a generation actually performed, and appends it to a JSON log in your output folder so you (or the pack's Bayesian optimizer) can compare settings like for like.

It doesn't invent the numbers. The patched model created by TeaCache_Patcher keeps a per-run state machine in memory - how many times the cache was hit, how many inferences actually ran, when the run started. The collector pulls that state, computes the elapsed generation time, and writes one record containing the timings, hit counts, the rel_l1_thresh and coefficients that were used, and (if you also ran the LPIPS evaluator) the perceptual distance from your reference image. The repo ships a filled-in teacache_analysis.json so you can see the exact schema: timestamp, generation_time, cache_hits, total_inferences, rel_l1_thresh, coefficients, lpips_distance, max_lpips_thresh.

Inputs and outputs

  • latent (required) - the KSampler's output latent. It's a passthrough: the collector returns it unchanged, so you can keep it on the wire to a VAE Decode without breaking your graph.
  • run_id (required, forceInput) - the string from TeaCache_Patcher. Without a matching live run, the collector just returns an error message as its status and passes the latent through.
  • analysis_file (default teacache_analysis.json) - the filename written to ComfyUI's output directory.
  • trigger (optional, forceInput) - a string that forces execution ordering. This one matters.

Outputs are the LATENT passthrough and a status string that summarizes what got saved: generation time, cache hits out of total inferences, and the LPIPS distance if there was one. Wire that status into a text/anything viewer and you get a quick at-a-glance report.

The trigger gotcha

Here's the thing that trips people up: the collector has almost no graph dependencies, so ComfyUI is free to run it before your render even finishes. In the example workflow the trick is to wire the LPIPS Evaluator's status output into the trigger input - that forces the collector to execute only after the quality score has been computed, so lpips_distance is actually in the record when it writes. If you skip that wire and run the pack's nodes manually, expect to see the collector fire with empty results and the run cleaned up before the evaluator ever gets its number.

Installing

Same drill as the rest of the pack. ComfyUI Manager, search CUI-Lumina2-TeaCache, install, restart - or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/spawner1145/CUI-Lumina2-TeaCache.git

It's an analysis tool, so the only dependency you need beyond ComfyUI itself is lpips if you want the quality numbers populated (Manager handles it; manual installs should pip install -r requirements.txt).

Honest verdict: if you're not tuning thresholds and comparing scores, you don't need this node at all - the plain TeaCache_Lumina2 node is the one that makes renders faster. The collector exists to close the loop on "is this speedup worth it," and it does that job quietly and well. Just respect the trigger.

Categoryutils/analysis

Inputs (4)

NameTypeDefaultDescription
latentLATENT
run_idSTRING
analysis_fileSTRINGteacache_analysis.json
triggeroptSTRING

Outputs (2)

NameTypeDescription
LATENTLATENT
statusSTRING