Nodes/ComfyUI_HF_Inference/HF Text Feature Extraction
ComfyUI Node

HF Text Feature Extraction

A remote BART embedding, served straight into your CONDITIONING socket

By bitaffinity·Created 2 years ago·Updated 2 years ago· 5
HF Text Feature Extraction
    • CONDITIONING
    endpoint
    text

    This is the weird one. HF Text Feature Extraction takes a string, sends it to a Hugging Face embedding model over the internet, and hands the resulting vector back to ComfyUI as a CONDITIONING - the exact type that KSampler's positive and negative sockets expect. Every other node in the bitaffinity/ComfyUI_HF_Inference pack hands you plain text or an image. This one tries to hand you guidance.

    What it's doing

    Two inputs, that's it:

    • endpoint (STRING) - the model ID, e.g. facebook/bart-base from the README, or a full URL.
    • text (STRING, multiline) - the text you want embedded.

    The node POSTs {"inputs": text} to https://api-inference.huggingface.co/models/{endpoint}. Hugging Face's server runs the model and returns the embedding vectors. The node turns those into a float16 tensor, moves it to CUDA, and wraps it in the standard ComfyUI conditioning format ([[tensor, {}]]). Wire it into KSampler and you're conditioning the sampler on whatever a BART encoder thinks of your sentence.

    That's a genuinely experimental thing to do, and the README's model choice hints at why it can work at all: facebook/bart-base produces 768-dimensional embeddings, which is the same width as SD1.5's CLIP text encoder. If the dims don't line up with the model you're sampling, you'll get a shape error or silent nonsense. Embeddings, as the knowledge base loves to remind people, are locked to the encoder that made them - don't expect a BART vector to mean much to a model trained against CLIP.

    Where it fits

    Real talk: for a beginner this is the "I'm going to condition a sampler on a cloud embedding and see what happens" node. That's a fun afternoon, not a production technique. The more believable use is text-level: pull a semantic representation of a string into the graph for comparison or routing logic, the way people use embedding vectors to find "similar" prompts. It's a neat demonstration that ComfyUI's CONDITIONING type is just a tensor wearing a hat.

    One sharp gotcha

    The node hardcodes .to('cuda'). Everything else in this pack is happy on a CPU-only machine - the models run remotely - but this one will crash if your ComfyUI install has no CUDA GPU. If you're running the pack on CPU and it works everywhere except this node, that's why. It also means even on GPU boxes you're allocating on device, so it wants a real CUDA runtime, not the CPU build of torch.

    Installing it

    Same as every node in the pack, and refreshingly light - the only Python dependency is requests:

    git clone https://github.com/bitaffinity/ComfyUI_HF_Inference custom_nodes/ComfyUI_HF_Inference
    cd custom_nodes/ComfyUI_HF_Inference
    pip install -r requirements.txt
    

    Restart ComfyUI (or search "ComfyUI_HF_Inference" in ComfyUI Manager), then set a Hugging Face token - free tier is fine - as an environment variable:

    HF_AUTH_TOKEN=hf_yourtokenhere python main.py
    

    Expect the cloud to be slow sometimes

    The README warns the serverless API only reliably serves models 10GB and under and "fails for random reasons on different models." First calls to a cold model can sit for a minute or two while Hugging Face boots a container; the pack reads the reported estimated_time, waits, and retries once, so usually you just get a pause. But this node's conditioning output is a debugging spiral waiting to happen - a shape mismatch surfaces as a sampler error that points nowhere near this node. If a workflow that used to run breaks after you add this, check the embedding dims first.

    CategoryHF_Inference/Text

    Inputs (2)

    NameTypeDefaultDescription
    endpointSTRING
    textSTRING

    Outputs (1)

    NameTypeDescription
    CONDITIONINGCONDITIONING