MiniMax H3 Sol-Attn Compatibility Audit / 外部补丁所有权审计 (Advanced/T8)

Attention-replacement patches are where third-party speed hacks and H3 custom nodes fight each other. Two nodes both patch the same attention forward pass, and whichever ran last wins - or neither works and you get silent slowdowns, or worse, wrong output that looks fine. MiniMaxH3SolAttnCompatibilityAuditT8Advanced is the pack's referee: it checks that a separately installed Sol-Attn plugin (from Saganaki22/ComfyUI-sol-attn, v0.6.2+) is actually compatible with this H3 workflow before you trust it - and it passes your MODEL through unchanged either way.

The crucial design point: it doesn't import or run the kernel. It's an audit, not a driver. It checks versions, CUDA/BF16 architecture, whether Sol-Attn truly owns the complete H3 attention patch, whether something is shadowing it, and whether you're combining it with unreviewed DiT/model-wrapper combos. The kernel itself stays in the external plugin, exactly where the plugin's own license (Apache-2.0) puts it.

The inputs

• model - passed straight through to the output; this node is a pass-through with a report, not a model-wrapping operation.
• intended_route - h3_memory_efficient, h3_scheduled, generic_sol, or audit_only. Tells the auditor which Sol-Attn route you think you're using.
• expected_dense_blocks - must match the upstream Sol node's dense_blocks widget (e.g. 0-2,-1). Those blocks intentionally have no Sol forward patch, so the audit expects them to be absent from ownership.
• allow_unreviewed_composition (False) - when off, DiT replacements, whole-model wrappers and unknown full-block patches force ABSTAIN. Turning it on only downgrades that finding to a warning.
• enforcement - report_only (default) or block_hard_conflicts. In block_hard_conflicts, a hard conflict raises and stops execution instead of just reporting.

Outputs: the model (unchanged), compatible (bool), decision, plugin_version, h3_sol_block_count, and report_json.

Why this matters

The pack's README is full of "don't stack global attention patches" warnings - Enhance-A-Video, KJ Sage, BlockCache, STG all fight over the same Attention entry point, and the author's own testing repeatedly found scenarios where a third-party patch bypassed or shadowed H3's intended path. This node is the systematic answer for the Sol-Attn case: confirm ownership before you spend a run, and get a report instead of a silent mystery.

Install

Pack standard -

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

then restart (or Manager, search "MiniMax H3 Audio T8"). But note the extra dependency: you must also install ComfyUI-sol-attn 0.6.2+ separately. The audit only checks it; it doesn't bring the kernels. Reference workflow: examples/workflows/12-system-memory/2026-08-22_H3_Sol_Attn_Compatibility_Audit_Advanced_EXP.json.

The honest take

The author's own results are refreshingly un-hyped: a conservative Sol-Attn T2VA route reached the kernel and ran, but a single ordered A/B showed no speed or memory advantage on that machine, and one reviewer called it a tie. So this audit node isn't telling you Sol-Attn will make H3 fast - it's telling you whether your Sol-Attn setup is safe to run at all. If that's your question, this is the node that answers it without loading a model or executing a kernel.