MiniMax H3 Qwen Prefix Cache Stats / 前缀缓存统计 (Advanced)

This is a read-only gauge, not a tool that changes anything. It peers into the bounded in-memory prefix cache that the pack's MiniMaxH3QwenReferencePrefixCacheT8Advanced node maintains for the H3 Qwen3-VL encoder, and reports hit/miss/size counters as JSON. If you've ever enabled a cache and wondered whether it's doing anything, this is how you find out instead of guessing.

The cache it reads is the one that stores the visual-reference prefix - the expensive vision-tower tokens computed from your reference image/video. Prompt text still gets recomputed every run by design. So the stat that matters is the hit rate: if you're re-encoding the same reference frames over and over (batch jobs, seed variants, A/B comparisons), hits should climb. If they stay near zero, you're re-encoding every time and the cache is just eating RAM.

Inputs

• cache_handle - the H3_T8_QWEN_PREFIX_CACHE output from the Reference Prefix Cache node. This is required; there's no way to guess which cache you mean.
• after_report - an optional string, and the clever part. ComfyUI runs nodes in dependency order, and a stats node connected to a cache handle can fire before the encoding actually happened. Feed it the cache node's own report_json (or any downstream report) and it forces this node to execute later, so the counters reflect real work. The source literally fingerprints this node as "always rerun" (NaN) so it never gets skipped as unchanged.

Output: a single report_json string. It's an output-node, so it's meant to be a terminal preview - wire it to a text/console display and read the numbers.

Installing

Same pack as its sibling cache node - T8mars MiniMax H3 Audio T8:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8

or ComfyUI Manager → search "MiniMax H3 Audio T8". No pip deps for this node; it just reads an in-memory object.

Where it fits

Honestly, this is a debugging companion. You'd only add it to a workflow you're already tuning, when the cache's maximum_cache_mib budget is something you care about. Two patterns actually use it:

1. Verification - after enabling memory_lru_exp mode on the cache node, confirm the hit rate is what you expect before you trust the speedup.
2. Budgeting - check report_json for current size against the cache node's memory budget, and decide whether to raise it or kill the cache.

The one thing to remember is that a cache only helps if your reference prefix repeats across runs. If every run uses a different reference video, the cache is doing extra bookkeeping for nothing, and this stats node will show you exactly that. Use it as the "is this worth it" meter, not as a permanent workflow fixture.