ialhabbal VLLM Advanced

The basic ialhabbal_VLLM node does one thing well: describe the image. This is the same node with the training wheels off - every knob the transformers backend actually has, exposed on the canvas. If you only ever want "describe this picture," skip it. If you want the same answer twice, want it faster, want it on your Mac's GPU, or want to steer how creative the model gets, this is the version you reach for.

It loads the same Qwen3-VL HuggingFace checkpoints into models/LLM/Qwen-VL, runs through the same processor and AutoModelForVision2Seq machinery, and even defaults to the same 2B instruct model. Everything the plain node does, this does - it just lets you change the sampling behavior that was previously hardcoded.

The inputs that matter

Beyond model_name, quantization, preset_prompt/custom_prompt, max_tokens (now up to 4096) and keep_model_loaded, you get:

• temperature (0.1–1.0, default 0.6) - sampling randomness. The tooltip's framing is right: 0.2–0.4 for focused, predictable output, 0.7+ for creative. For captioning a LoRA set, keep it low; for prompt writing, nudge it up.
• top_p (0–1, default 0.9) - nucleus sampling. Leave it near default unless output feels incoherent.
• num_beams (1–8, default 1) - beam search. This one's a trap in a good way: set it above 1 and it disables temperature/top_p and switches to greedy, more stable decoding at the cost of speed. Beam search and sampling are mutually exclusive in the code, so don't crank both expecting them to combine.
• repetition_penalty (default 1.2) - >1 punishes repeated phrases. If your caption loops, raise it; if it sounds stilted, bring it down toward 1.0.
• frame_count (1–64, default 16) - how many frames get sampled from a video input. More frames = more context, more time, more VRAM.
• device - auto, cpu, mps, or explicit cuda:0/cuda:1 for multi-GPU rigs. This is the Mac escape hatch: mps runs on Apple Silicon instead of silently using the CPU.
• use_torch_compile - off by default; on compatible CUDA/Torch 2.1+ builds it pays a one-time compile cost for faster subsequent runs. Only worth it for batch jobs.

Everything else - the preset prompts, seed, keep_model_loaded, attention_mode - behaves exactly like the base node. Output is a single RESPONSE string.

Why you'd actually pick this one

Two scenarios, honestly. First, reproducibility: with num_beams on and a fixed seed, you get deterministic output, which matters if you're captioning a training set and don't want the model to describe the same image differently on the tenth run. Second, resource control: the device selector plus frame_count are how you squeeze this onto a machine where the plain node's defaults would OOM.

Installing and running

Same suite, same install - ComfyUI Manager search "ComfyUI-ialhabbal", or:

cd ComfyUI/custom_nodes
git clone https://github.com/ialhabbal/ComfyUI-ialhabbal.git

Restart, then find ialhabbal VLLM Advanced in the node browser. The heavy dependencies (transformers, bitsandbytes, accelerate) come with the pack.

Common issues

• Nothing changes when I move temperature - check num_beams. If it's above 1, sampling is off by design.
• torch.compile stalls on first run - that's the compile pass, not a hang. It can take minutes; subsequent runs are faster.
• MPS still slow - 4-bit quantization is your friend on Mac; 4-bit plus mps is the way people actually run this on Apple Silicon.
• VRAM contention - you're now running an LLM and a diffusion model. keep_model_loaded off between runs, or use a 4-bit quant.