XB-llama - 📦 模型加载器

Every XB-llama workflow starts here. XB_llamaModelLoader takes a GGUF language model - plus an optional vision projector and the right chat handler - and hands you a LLAMACPPMODEL wire that every other llama node in this pack consumes. It's built directly on llama-cpp-python, the same engine that runs llama.cpp locally, so you're getting genuine in-graph GGUF inference rather than a call out to a separate Ollama server. That's the pattern the KB's LLM-in-ComfyUI essay flagged as the community's standing want, and this pack does it natively.

Where your models go

This is the part that trips everyone up first. The node reads from a models/LLM folder inside your ComfyUI directory - not models/unet, not models/checkpoints. Create it, drop your GGUF files in, and the dropdown populates. Vision models need two files: the main GGUF and a separate mmproj (multimodal projector) file, which the node auto-detects from filenames containing "mmproj".

The inputs that matter

• model - dropdown of GGUFs in models/LLM. For a plain text model (e.g., a Qwen or Llama chat GGUF), pick it and set chat_handler to None.
• mmproj - the vision projector, None for text-only. If you load a projector but leave chat_handler at None, the node errors - a vision module without a vision handler is meaningless.
• chat_handler - the big one. This is a dropdown of VLM chat formats the pack supports: Qwen3-VL, Qwen2.5-VL, LLaVA-1.5/1.6, MiniCPM-v2.6/v4.5/v4.6, Moondream2, Gemma3/4, GLM-4.xV, and more. It must match your model family - a Qwen3-VL GGUF with a LLaVA handler won't produce anything sensible. It also gates vision: feed images to XB_llamaInstruct with chat_handler=None and you get a hard error telling you to pick a vision handler.
• n_ctx - context window, default 8192, up to 327680. Bigger context = more RAM/VRAM. The default handles long storyboards fine.
• vram_limit - GB ceiling, default −1 (unlimited). Set it and the node computes how many n_gpu_layers fit, using an AMD-aware efficiency factor (the pack accounts for RDNA4/RDNA3.5 offload characteristics - it's explicitly built with AMD GPUs in mind). It's a reference value; the tooltip warns it can overshoot slightly.
• image_min_tokens / image_max_tokens - token budget per image, mostly relevant for Qwen3-VL style handlers.

Installing the llama stack

The pack's README says "no extra pip dependencies" - that's true for most of XB_ToolBox, but not for the llama nodes. You need llama-cpp-python installed manually, because there's no one wheel that fits every GPU:

# NVIDIA: use a prebuilt CUDA wheel (see JamePeng/llama-cpp-python releases)
pip install llama_cpp_python-0.3.44-cp312-cp312-win_amd64.whl
# or build against your CUDA
CMAKE_ARGS="-DGGML_CUDA=on" pip install llama-cpp-python

# AMD/ROCm: compile a ROCm/HIP build
CMAKE_ARGS="-DGGML_HIP=on" pip install llama-cpp-python

plus the lighter deps from the pack's requirements.txt (gguf, diskcache). If you skip llama-cpp-python, the rest of the pack still loads - you'll just hit a clear Chinese-language error at inference pointing you to the install instructions.

Where people get burned

Mismatched handler/model pairs are the #1 failure - the console messages are in Chinese, so if you're not reading them, the "model outputs garbage" symptom is confusing. The #2 is forgetting the mmproj for vision use: LLaVA-family handlers check for a loaded clip_model_path and refuse image input without it. And keep an eye on n_ctx: an 8B Qwen at 8192 context is fine on most cards, but cranking n_ctx to 32k on a small card pushes the KV cache past what vram_limit accounted for.