HF Text Feature Extraction
A remote BART embedding, served straight into your CONDITIONING socket
- CONDITIONING
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-basefrom 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.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| endpoint | STRING | — | |
| text | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| CONDITIONING | CONDITIONING | — |