BSAI VRAM Unlock (info)

You hit an OOM your card says you shouldn't

Here's the error that sends people to this node:

torch.cuda.OutOfMemoryError: Allocation on device 0 would exceed allowed memory.
Currently allocated     : 19.20 GiB
Requested               : 512.00 MiB
Device limit            : 24.00 GiB
Free (according to CUDA): 0 bytes
PyTorch limit (set by user-supplied memory fraction) : 17179869184.00 GiB

Two things to unpack. The card reports 24GB. The 19.2GB you're already using didn't max it out. And that last line, which reads like 17 billion gibibytes, is actually bytes mislabeled by torch's own message - 17,179,869,184 bytes, which is exactly 16GiB. Some plugin in your install walked up to PyTorch and called set_per_process_memory_fraction(0.667), quietly reserving a third of your card for nobody. Then your 19.5GB int8 video model asked for memory that physically exists and was told no.

That's the problem BSAI-ComfyUI-VRAM-Unlock exists to solve. Not "make big models fit on small cards" - undo an artificial ceiling somebody else installed.

What it actually does

The pack ships exactly one node class, and the node is not the fix. The fix is a side effect of the pack being installed at all.

Open __init__.py and it's about sixty lines: it saves references to torch.cuda.set_per_process_memory_fraction and get_per_process_memory_fraction, then replaces both, globally, at import time. The replacement does two things. Any attempt to set a fraction below 1.0 gets logged as a warning - with the offending value - and rewritten to 1.0. Any call to read the fraction returns 1.0, so a plugin that caches the old limit and re-checks it doesn't put the ceiling back.

The author skips the obvious alternative, which is patching each offending pack. That approach is exactly as durable as it sounds: plugin updates overwrite your patch, and the next new pack that sets a fraction is a fresh problem. Monkey-patching torch once covers every current and future caller. The README names two culprits in the wild - ComfyUI-QwenVL-Mod via AILab_QwenVL.set_pytorch_memory_fraction(), and RES4LYF's rk_sampler_beta.py, which derives its fraction from the card's VRAM ceiling. RES4LYF is mainstream enough now that a lot of people hit this without ever installing anything unusual.

Inputs and outputs

None, and one. BSAIVRAMUnlockInfo has no inputs at all, and a single output called status - a STRING that always reads "VRAM-Unlock active: torch.cuda set_per_process_memory_fraction forced to 1.0; plugin sub-1.0 fraction calls intercepted."

That's the whole surface. It's a diagnostic, in the plumbing layer where nodes exist to make a graph legible rather than to touch pixels. Wire status into any text display node if you like having proof on the canvas; if you want to confirm the patch survived a ComfyUI update, that's your cheap check. But you can also never add the node to a workflow and keep the entire benefit - the node is a status light, the pack is the patch.

Install

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

Then restart ComfyUI. It's also on the registry, so ComfyUI Manager → search "BSAI VRAM Unlock" works.

No model downloads, no dependencies, no requirements.txt - it imports logging and torch, both of which you already have. That makes it a far lower-risk install than the average custom node in an ecosystem where adding a pack means gambling your transformers version.

Verify it took, in the startup log:

BSAI VRAM-Unlock active: torch.cuda memory fraction forced to 1.0

and, when a plugin tries to cap you:

intercepted set_per_process_memory_fraction(0.700) from a plugin; forcing 1.0

If you see the second line, you've found your culprit by name and value.

Where people get burned

Full physical VRAM is a real policy, not a free win. With the cap gone, this instance will grow until the card is genuinely full. Don't run a second ComfyUI alongside it, don't game while a 14B video model is sampling, and if your driver is prone to TDR on Windows, that risk goes up with it. The README says this plainly and it's the one warning worth taking seriously.

It cannot beat physics. If the model plus activations genuinely exceed 24GB, you still OOM - you just OOM at 24 instead of 16. The right response then is quantization or a smaller resolution, not another flag. And if you're on a card that "barely fits," remember the community finding that unnecessary low-VRAM flags make things slower; take the cap off, then leave the launch flags alone.

The bundled example workflow won't load clean. example_workflows/ contains a multi-hardware demo referencing BSAIOrchestratorGate, BSAIVAEDecodeRouter, BSAIHardwarePerfMonitor, BSAINPU_DepthEstimate and friends - sibling packs by the same author, none of which ship in this repo. Expect a wall of red missing-node boxes. Grind the queue on the workflow, not the demo.

Read the file before you run it. This is a global monkey-patch of torch, in a repo with no stars to vouch for it, and custom nodes execute arbitrary code on import with no sandbox. The good news is that the whole thing is short enough to actually read in two minutes - and you should, because "small package, imports nothing, patches two functions" is a claim you can verify rather than trust.