BSAI FastH3 VSA Stats

Sparse attention is a category of code that fails quietly. Nothing crashes when the sparse path decides a call isn't worth sparsifying - it just runs dense attention instead, and your generation gets slower and hungrier while looking identical. You end up blaming your GPU, your VAE, or the model, when the patch you installed simply never fired.

BSAIFastH3VSAStats is the pack's answer to that: a read-only diagnostic that tells you whether BSAIFastH3NativeVSA actually participated in the sampling you just ran.

What it tells you

It takes one input, model, and returns one string output, stats. Wire the model that comes out of the VSA node - the patched one. Point it at the loader's raw output and you'll be reading configuration for a patch that isn't on the model you're sampling.

The string is a small block of lines: whether the native comfy_kitchen.sol_attn kernel is available on this machine, the VSA configuration recorded on the model (backend, keep percent, the derived tau, min_tokens, sink mode, the sigma window), the model's shift values for video and audio, then five counters - sparse, dense, native, torch, and errors.

sparse above zero is the whole point. That's the proof the attention override ran on at least one call with a sparsifiable video span. If it's zero, your run was fully dense and every speed claim about VSA applies to somebody else's session.

The model shift (v/a) line earns its keep independently. The 8-step V2 recipe works by patching the model's ModelSamplingAV video shift from 12 to 10, and that patch is invisible everywhere else in the UI. This is where you confirm it landed: 10.0 / 3.0 for V2, 12.0 / 3.0 for the 4-step and TaoMate recipes. If you expected V2 and see 12, your timesteps node is computing sigmas against the wrong shift.

errors is the dense-fallback count. It's not automatically alarming - the VSA engine downgrades to dense on masks, cross-attention, and short sequences by design, and many of those land in dense rather than errors. But a large errors count with a high sparse count is worth a look, because it means a chunk of your attention calls took an exceptional path.

Reading the output

It's an output node, so it executes as part of the prompt even though it produces no pixels. Its stats socket is a plain string, so hook it to a text display node - a Show Text node does the job - if you want it on the canvas. The node's own log also prints the VSA configuration when the patch installs, which is where you'll see the backend, keep percent and tau the recipe actually resolved to.

Install

Same pack, same two minutes:

cd ComfyUI/custom_nodes
git clone https://github.com/xm6018924/BSAI-ComfyUI-FastH3.git

Restart ComfyUI. No dependencies, no model files - this node reads counters from the pack's own sparse-attention module, and those counters are reset each time the VSA patch is applied, so the numbers you're looking at belong to the current patch, not to something that happened forty runs ago.

When the numbers look wrong

sparse: 0 with VSA seemingly enabled has three usual causes. enabled is off on the VSA node - check the boolean, not the log. The sequence was shorter than min_tokens (8192 by default), so every call ran dense; a very short clip or a low resolution can genuinely land there. Or the model didn't get a video span published at all, which in practice means the diffusion model isn't H3 and the VSA node would have raised on that already.

native backend available: false means comfy_kitchen isn't installed or its build has no sol_attn kernel. Not an error - the torch path is doing the work, and on a 40-series card that's the expected state. If you force backend=native with strict_native_backend on, that's when it becomes a hard error instead of a footnote.

And if dense dominates sparse, you're probably running long start_percent/end_percent windows on the VSA node, which are supposed to run dense at the head and tail of sampling. Narrow the window and watch the ratio move.