🌀 BV Comfy CLIP LLM Provider

If you've ever set up an LLM prompt-enhancer node in ComfyUI, you've hit the same fork in the road: paste an API key into some provider node and let your prompt text leave the machine, or run a second model server (usually Ollama) alongside ComfyUI. BV Comfy CLIP LLM Provider is the third path - it reuses the text encoder you already loaded and turns it into the LLM that rewrites your prompts. No key, no network, no second runtime.

It's part of BV Node Pack, whose regional-prompting setup includes a prompt-enhancer pipeline that separates "propose a change" from "apply it." This node is one of the two BV_LLM_PROVIDER sources that feed the enhancer; the other is the BV Remote LLM Provider, which talks to Ollama or an API. Same output type, completely different philosophy.

The catch is in the name

A normal CLIP text encoder encodes - prompt in, tensor out. It has no generate() method and nothing to decode. This node explicitly checks for a generative CLIP and refuses to run anything else: looking at the source, it verifies the CLIP object exposes tokenize, generate, and decode, and that its cond_stage_model also has a generate. If any of that is missing you get a clear error - "CLIP encoder '...' is not generative" - before any inference happens. That's the "fails before inference" behavior in the node description, and it's genuinely better than a cryptic crash mid-sampler.

The model BV expects here is the Qwen3-VL 8B text encoder that Comfy Org publishes for its Qwen-Image and Flux workflows, specifically qwen3vl_8b_fp8_scaled.safetensors. The README's tested recommendation, and the local-quality baseline it beat in their tests. You download it, drop it in ComfyUI/models/text_encoders, load it into your graph the way you'd load any text encoder, and wire the resulting CLIP into this node.

The provider's generate call is deliberately boring: greedy decoding (do_sample=false), fixed seed, no sampling tricks. That's a feature for you - the same input produces the same rewrite, so you can actually A/B test prompt changes instead of fighting nondeterminism.

What you wire where

Just two connections:

• clip (CLIP, required) - your loaded Qwen3-VL text encoder.
• provider (BV_LLM_PROVIDER, output) - feed this into BV Regional Prompt Enhancer's provider input.

That's the whole node. It doesn't read your prompt itself; it's a provider contract that the enhancer consumes.

Installing and the honest cost

Install the pack, not the node - there's nothing to download for this one:

cd ComfyUI/custom_nodes
git clone https://github.com/BlackVortexAI/bv_nodepack.git

or search BV Node Pack in ComfyUI Manager. Then restart ComfyUI and hard-refresh the browser with Ctrl + F5 - this pack ships a frontend extension, and stale JavaScript is the classic "why isn't the new node here" gotcha.

The real cost is hardware, not setup. That 8B text encoder is running on the same GPU that's about to sample, and it's a big one - the README is blunt that this path "uses more of the generation machine's resources" than a local Ollama call. It's the right choice when you don't want to run a second server or hand a key to anyone, and it's the wrong choice when your VRAM is already at its limit. If the FP8 file won't fit comfortably alongside your checkpoint, the pack's own docs point you to the Ollama path for a reason.

One more thing worth knowing: since the provider is purely local and deterministic, there's no API bill to worry about and no cache to clear. Where people get burned is usually expecting any old CLIP to work - it won't, and the error is the feature telling you so.