🖥️Load Embeddings

Every RAG setup needs two different kinds of model doing two different jobs: a language model that generates the final answer, and an embedding model that turns text into vectors so you can find the relevant chunks in the first place. Load Embeddings is squarely the second job - it loads a text-embedding model and hands it downstream to any of this pack's knowledge-base and search tools, which is what lets them do semantic retrieval instead of dumb keyword matching.

Why you need a separate model for this

An LLM and an embedding model are architecturally different things doing different work. The LLM generates text token by token. An embedding model reads a chunk of text once and outputs a fixed-length vector - a point in high-dimensional space where semantically similar text ends up near other semantically similar text. Once you have vectors for every chunk in your knowledge base and a vector for the user's query, finding "the relevant bits" is a nearest-neighbor search, which is fast and doesn't require the LLM to read your entire document every time. This node is where that embedding model gets loaded, separately from whatever chat model you're using elsewhere in the graph.

Inputs and output

Three required fields, no optional ones. model_path is a string pointing at the embedding model - following this pack's convention elsewhere, that's either a local folder path or a Hugging Face repo ID for something like a sentence-transformers or BGE-style embedding model. is_enable is the standard toggle this pack puts on nearly every node - off, and the node presumably no-ops rather than loading anything. device picks where the model actually runs, with four choices: auto (the sane default - picks CUDA if available, falls back sensibly), cuda, mps for Apple Silicon, or cpu. Embedding models are generally much smaller than chat LLMs, so cpu is a genuinely viable choice here even on machines where you'd never dream of running your main LLM on CPU.

The output is a single ebd_model of type EBD_MODEL - a type specific to this pack, which tells you it's meant to plug into other LLM Party nodes rather than general ComfyUI machinery. This pack's knowledge-base and search tools (Wikipedia search and similar) accept an embedding-model input for exactly this purpose: turning a pile of retrieved text into ranked, relevant chunks instead of dumping everything at the model.

Where it fits

The README frames this pack's ambition as reaching "industry-specific word vector RAG and GraphRAG" for local knowledge-base management, and this node is the entry point for that. Without it, the knowledge-base tools either fall back to naive retrieval or need you to skip the embedding path some other way - with it, you get proper semantic search over whatever documents or web content you've fed into the graph.

Installing it

Standard pack install, nothing embedding-specific required beyond what's already in requirements.txt:

• ComfyUI Manager: search "comfyui_LLM_party", install, restart.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/heshengtao/comfyui_LLM_party, then pip install -r requirements.txt inside your ComfyUI Python environment, restart.

If you're pointing model_path at a Hugging Face repo ID rather than a local folder, the first run downloads the model to your local HF cache - that download happens the first time the node executes, not at install time, so don't be surprised by a slow first queue run.

Common issues

The most common failure is the same one every "path or HF repo ID" field in this ecosystem has: a typo'd repo ID fails with an unhelpful download error, and a local path that's slightly wrong (pointing at the parent folder instead of the model folder, for instance) fails the same way. Get the exact repo ID from the model's Hugging Face page rather than typing it from memory.

The second is device mismatch under memory pressure - if you're already running a large local LLM on cuda and then also load the embedding model onto cuda, you're stacking VRAM usage from two separate models. Embedding models are small, but on an already-tight GPU budget, setting device to cpu for this node specifically is a cheap way to free up VRAM for the model that actually needs it, since embedding lookups aren't nearly as latency-sensitive as chat generation.